1
クラウド時代の
組込
み
システム技術
「オープン」化する組込み
Ken Sakamura, Ph.D.
Chair of T-Engine Forum/uID Center
Professor of The University of Tokyo
オープン
な
領域が
3
オープン
と
いえば…
最初はOSだった
5 1
2001年、武田賞のテーマは「オープン」
左から ・Linuxのライナス・トーバルズ ・GNUのスートルマン ・TRONの坂村オープンなレイヤ
が
拡大
OS
ミドルウェア、ライブラリ
開発環境、ブラウザ、データベース
ハードウェア
7
組込み分野でも
オープンの応用
が
拡大
最近5年でOpen Sourceがカバーする
組込システム応用分野はますます拡大
通信から航空機、宇宙に至る
産業領域全体をカバー
宇宙に利用されるTRON
■
「すざく」ミッション
2005年7月10日打ち上げ、高度約550kmの楕円軌道を回る ブラックホール近傍から出るX線を宇宙望遠鏡で観測 宇宙の構造がどのように進化してきたかの手がかり■
DHUはμITRON2.0 OS
■
「すざく」の後継2013年打ち上げ予定の
ASTRO-Hには「SpaceWire」が搭載され、
T-Kernelで動作
9
これから
の
技術環境
開発環境だけでなく利用環境のオープン化も
システム自体も「オープン」へ
ネットワーク
の
高速化、
低コスト化、常時接続化
組込みシステムも
クラウドと接続するのが常態化
例えば家庭内の電力利用統計も、家庭内にサーバーを立てて
データ管理・分析するより全電化製品をクラウドにつなぐ方が容易に
「クラウドと実世界を繋ぐモノ」としての組込み
11
例えば家庭内の電力利用統計のクラウド化
ホームサーバー前提の従来型モデル サーバー、ネットワークの構築・保守管理 サービス・アップデート、新規繋ぎ込み 他メーカーとの連携等…多くの問題 「ホームネットワーク」は主流にならずユビキタス
機能分散システム
へ
…
組込みシステムが
「眼・耳」や「手・足」となり現実世界の状況を知り、また操作し…クラウドが
現実世界から上がるビッグデータを処理し…スマートフォンが
13
システム
アーキテクチャ
の
オープン化
いつでも・どこでも・リアルタイム接続の時代
組込み端末がクラウドの「末端」となる
機能分散型システムの一般化
組込みシステムをネットワーク端末とするクラウドサービスへ
多様なOSによるオープンな機能分散
15
組込み機器のこれからの特徴
■
情報処理能力は変わらない
一次データ処理としてローカルでのセンサーデータ解析は必要 それ以上の記録・高度なデータ記録・解析・グラフ化・管理などはク ラウド側で処理■
ユーザインタフェースはむしろ小さく
高度なユーザーインタフェースはスマートフォンで行えば本体側の 操作はむしろ簡単に■
ネットワーク機能にすべてが集約
T-Kernel 2.0
と
T2EX
これからのオープンな「組込み」のための
2.0化
17 17
T-Kernel1.0からT-Kernel2.0(T2)へ
■
バージョンアップ版のT-Kernel 2.0をリリース
(2011年5月)
従来のT-Kernel 1.0の設計方針や特長は不変 T-Kernel 1.0に対しては上位互換 • ソース互換およびバイナリ互換■
CPUの高性能化、デバイスの大容量化を活か
す追加機能
64ビットデータの導入 マイクロ秒単位の時間管理機能 大容量デバイスへの対応■
ワンストップサービス
T2で提供されるソフトウェア
■
T-Kernel2.0
動作対象機種の tef_em1d に合わせてARM11コア依存部を追加■
T-Monitor
ハードウェアの初期設定 T-Kernelのブート処理 割込みや例外のハンドリング ハードウェア階層の対話型デバッグ機能 • メモリやレジスタの参照■
デバイスドライバ
時計(RTC) シリアルコンソール タッチパネル スクリーン(LCD) システムディスク19
T2で提供されるソフトウェア
■
Eclipse開発環境
Windows PC上で動作 コンパイルやビルド 実機へのプログラム転送と実行 デバッグ機能 • ブレークポイントの設定 • 変数値の参照や変更など ※このほか、Linuxのコマンドベース(非GUI)の開発も可能■
QEMUによるエミュレータ
Windows PC上で動作 • ハードウェア(実機)がなくても開発できる CPUおよびボード搭載の各デバイスに対応 • タイマ、microSDカード、I2C、UART(シリアル)、USB、RTC、LCD、タッチパネル、 LANなどT-Kernelのプログラム開発
■
統合開発環境Eclipseでプログラム開発、デバッグ
ICE不要、PC上の仮想環境での開発も可能21
T-Kernel関連
の
機能分散向け製品
T-Kernel for Android Open Accessory
■
Android端末用の周辺機器をT-Kernelで開発するた
めの開発評価キット
■
OSの適切な役割分担をサポート
リアルタイムの機器制御はT-Kernelで23
組込み向けハイパーバイザー
「RTH withT-Kernel」
■
T-Kernel 2.0 と RTH(Real-time Hypervisor)
により、Windowsが苦手とするリアルタイム制
御処理を、同一CPU内のT-Kernelで実現
■
WindowsとT-Kernel
双方のメリットを活か
した組込み機器の開
発が可能
Qt for T-Kernel
■
オープンソースで洗練されたGUI機能などを提
供
■
Qt Creatorなど使ってT-Kernel用のGUIを開
発可能
■
LinuxやWindows上のQt資産をT-Kernel上で
利用
25
T
2
EX
T-Kernel2.0 Extension
27
T2EX誕生の背景
■
T-Kernel搭載の組込み機器への要求を分析
■
「リアルタイム」を維持したまま機能追加したい
要求度の高い機能: ファイル管理とネットワーク通信■
「コンパクト」も維持する必要がある
WindowsやLinuxなど情報系の重いOSは使えない CPUコアがMMUを持たないケースも応用例1: デジタルカメラ
■
シャッター制御、オートフォーカス、
手ぶれ補正の処理
リアルタイム性が必須
■
撮影した画像の保存
ファイル管理機能が必須
■
スマートフォンから無線LAN経由でリモコン操作
29
応用例2: PC用のプリンタ
■
インクジェットの噴射やノズルの移動
リアルタイム性が必須
■
SDカードからのプリント
ファイル管理機能が必須
■
スマートフォンから無線LAN経由で印刷
ネットワーク通信機能が必須
T2EXの基本方針(1)
■
T-Kernel 2.0の軽量性を活かす拡張機能
ファイル管理やネットワーク通信などを追加 T-Kernelの「タスク」から直接呼び出せるAPI■
「プロセス」の機能は敢えて導入しない
プログラムの独立性を保ちながら開発するには有用だが、オーバー ヘッドが不可避 プロセスの導入には CPUコアにMMUが必須、コンパクトな組込み 機器では採用しにくい Linuxなどの情報系OSとの差別化を図る31
T2EXの基本方針(2)
■
標準CライブラリやPOSIXとの互換性、親和性に配
慮
fopen()、fread()、fwrite()、fprintf()などを導入 一般的なC言語プログラムの移植が容易で開発効率向上■
各機能を取り外し可能なモジュールとして実装
不要な機能の削除によりさらにコンパクト化 機器のハードウェアの低コスト化にも貢献■
安全性の向上
ページング等の高機能なMMUを必須としないメモリ保護機能 すべてのAPIをスレッド安全な仕様としてマルチタスク環境下での誤使 用を回避T2EXの機能
■
メモリ保護機能
■
ファイル管理機能
■
ネットワーク通信機能
■
カレンダ機能
■
プログラムロード機能
33
T2EXのソフトウェア全体構成
T2EXネットワーク通信機能
■
BSDソケットが提供する機能をほぼ利用可能
■
小さいフットプリント
■
リアルタイムスケジューリングを用いて優先度
を考慮した通信プログラムの作成が可能
■
より堅牢なアプリケーション
35
T2EXのファイル管理機能の実際
■
各APIの基本機能や使い方はPOSIXやLinuxと
ほぼ同様
ただし、API名称に "fs_" のプリフィックスが付く
fd = fs_open(path, flags, mode) でファイルをオープン fd にファイルディスクリプタを取得
↓
fs_read(fd, buf, count) でファイルをbufに読み込み fs_write(fd, buf, count) でbufからファイルに書き込み
↓ fs_close(fd) でファイルをクローズ
ファイル管理機能の主なAPI
fs_attach ファイルシステムの接続 fs_detach ファイルシステムの切り離し fs_open ファイルのオープン fs_close ファイルのクローズ fs_lseek ファイルの読み書きオフセット位置の変更 fs_read ファイルの読み込み fs_write ファイルへの書き込み fs_rename ファイルの名前・位置を変更 fs_unlink ファイルの削除 fs_fsync ファイルの同期 fs_creat ファイルの作成 fs_sync ファイルシステムの同期37
ネットワーク通信機能の主なAPI
so_accept ソケットへの接続の受け付け so_bind ソケットに名前をつける so_close ソケットを閉じる so_connect ソケットの接続 so_getsockname ソケットの名前取得 so_getsockopt ソケットオプションの取得 so_setsockopt ソケットオプションの設定 so_listen ソケット上の接続を待つ so_read ソケットからの読み込み so_recv ソケットからのメッセージ受信 so_select 多重化 I/O の同期をとる so_write ソケットへの書き込み so_send ソケットへのメッセージ送信 so_socket 通信のエンドポイントを作成 so_gethostname ホスト名を取得 so_sethostname ホスト名を設定T2EX: まとめ
■
T2EXの意義
コンパクトな組込み機器の高機能化、ネットワーク化に対応した、T-Kernel 2.0の拡張機能 T-Kernel 2.0とともに、高機能化した組込み機器の開発効率向上、 開発期間短縮、開発コスト削減に貢献■
T2EXの用途
デジタルカメラ、プリンタ、電子文房具的な機器、OA機器、ヘルス ケア機器、PCやスマートフォン用の周辺機器など39
組込みLinuxと
の
比較
組込みLinuxとの比較
■
組込みLinuxとは？
組込みLinuxは、あくまで標準Linuxを組込み用途にカスタマイズし たもの したがって、根本に関しては標準Linuxシステムと大きな違いはない • プロセス、ファイルシステム、POSIX API, …■
T2EXははじめから組込みを対象として設計さ
れており組込みLinuxとは設計レベルで根本
41
例: Linuxのブートプロセス
■
一般的なLinuxのブートプロセス
ブートローダのロード LinuxカーネルのRAMへのロード 初期RAMディスク(initrd)のロードとマウント 初期RAMディスク上のカーネルモジュールのロード ルートファイルシステムのマウント Initプロセスの実行 アプリケーションプログラムの実行■
POSIX由来の機能がシステムの根幹をなしており、
結果的に組込み用途には無駄が生じてしまう
データの保存が不要なシステムでもファイルシステム機能は切り離せな い 単一プロセスのシステムでもプロセス機能は必須 プロセス が必要 ファイル システム が必要組込みLinuxと比較したT2EXの特徴
■
タスクベースのシステム
プロセス・ファイルシステムを必須としない軽量な構成 タスクベースのシステム上に、高度なアプリケーションを実現できる プロセスベースのシステムに対し、ROM/RAMの使用を大幅に削減■
軽量なメモリ保護機能
プロセスのような多重論理空間によらない、省メモリ・高速なメモリ保護 機能を提供■
OS機能の選択
T2EXのOS機能は、デバイスドライバと同じレベルで、結合したり切り離 したりすることができる ファイル管理機能やプログラムロード機能といった、Linuxの主要なOS機 能ですら簡単に取り外しできる 不要な機能を切り離すことで、ROM/RAMの利用を大幅に減らすことが できる43
組込みLinuxと比較したT2EXの特徴
■
省ROM/省RAM
T2EXではデバイスドライバ・OS機能の構成と設定に応じて、 ROM: 100KB～610KB, RAM: 70KB～16MBの範囲でシステムを構 成可能 一般的な組込みLinuxのシステムでは、数MB以上のROMおよびRAM が必要になる■
明確に仕様化されたシステムレベルAPI
組込み開発者は、多くの場合、デバイスドライバやカーネル等のシステ ムレベルの開発に興味がある しかし、Linuxではカーネルレベルでは明確なAPIが定まっておらず、バー ジョンアップにより頻繁にAPIやパラメータ等が変わってしまう状況にあ るT-Kernel 2.0, T2EXでは tk_xxx_yyy() 形式の明確なAPIが定義され ており、T-Kernel 1.0以来互換性を堅持している
これから
の
制度環境
社会レベルのオープンサービスに結びついた
組込みシステムを活かせる制度環境が必要
45
オープンな組込みシステムの
理想
の
サービスは…
よく考えると…
多くのものが、政府、自治体、民間、個人の複雑な連携が必要
複雑な連携自体はICTの高度化により技術的に可能に
しかし、技術以外の点で多くの難しい問題
このような役割分担を権限、責任、さらにはセキュリティやインセンティブの観点からどのよう
に
実現するか
本質は「ガバナンス・チェンジ」
本質は「技術面」よりむしろ「制度面」
ガバナンスを「集中から分散へ」
ガバナンスを「クローズからオープンへ」
47
制御
の
ガバナンス
属人か、属家か、属サービスか
制御のガバナンスは
個人
に属するか、
家（の中にその機器があるという場所コンテクスト）
に属するか、
組込み機器を通じて
サービスを提供する主体
に属するか
制御
の
ガバナンス
誰が責任を取るか
逆に責任を取る主体が決まっていれば事故が起こっていいのか?
「自動機械の手にかかるぐらいなら、むしろ人間のミスで死にたい?」49
データ
の
ガバナンス
組込み機器の使用によって日々生まれる
様々なデータは「誰ものもの」か?
「誰が管理」し「誰が保証」し「誰が利用を許可する」のか?
エコのためになるなら地域で使用できるか
安全性向上のためならメーカーが利用できるか
すでに自動車の走行データは安全性向上のためにメーカーが収集しているプライバシー
意識
も
変化
SNSによるプライバシー意識の変化
個人情報保護で行政が拘束されている一方でFlickerなどに
平気でプライベート写真を上げる若者たちも
個人がクレジットレシートをアップしそれを話題に盛り上がる「買い物SNS」まで出現「プライバシーだから守れ」だけではない時代に
WiFi体重計のツイート機能のようにライフログのSNS化へ
51
システム
も
それに対応し
なければならない
これからの組込みシステムにおいては
データと制御のガバナンスの
高度な管理が重要に
家庭から出さなければいいという問題ではない
単なる暗号化を超えて権限のグループ管理やデータ部分的露出など 平時と有事の権限設定変更など53 毛沢東の赤ワイン 電脳建築家、世界を食べる 角川書店 2012/8刊
この続きは
TRONSHOW
で
…
55
