===================================================================== セッションF4 「私が想う．組込みシステムが要求するRTOSの保護機能」〜保護されることの幸せ〜 ===================================================================== 【会場の広さ】 : 60席【参加者の数】 : 30人 ====================================================================== 【内容】豊橋技術科学大学の高田先生によるポジショントーク・議論のポイント1 アンケート組込みシステム用のRTOSにも保護機能が必要である? -> 参加者の方は同意保護機能の説明 OSの持つ保護機能とは、OS上で動作するあるアプリケーションソフトウェアにバグがあった場合に、そのバグに起因するOSや他のアプリケーションに波及するのを防ぐための機能 -> 参加者の方は同意 ITRON仕様に保護機能を導入する目的 1.デバッグのため 2.信頼性向上モジュールに障害があること事態ゆるせないのではないか信頼性用件の異なるモジュールが共存できる 3.セキュリティ確保のための保護機能・議論のポイント2 何のたための保護機能が(最も)必要であるか A氏 : 何を(何から)保護したいのか．デバッグのため保護機能がほしい．現在開発対象の機器ではブラウザを使用しているがバグがありよくシステムをダウンさせる．そのため保護のためプロセッサを分けているが，それらを一つにまとめたいと考えています．高田 : 信頼性のための保護ですよね．ブラウザは，信頼性用件の異なるものですよね． A氏 : そうです． B氏 : デバッグのための保護がありがたい．誰かが変なことをしてしまい，そのモジュールが原因となって他の人が書いたモジュールまで正常に動作しなくなり，足を引っ張られてしまう．バグの場所が分からない．高田 : デバッグ時だけあればいいのですか B氏 : そうです．高田 : ICEが保護機能を持てばいいのでしょうか B氏 : それでもいいですけどでもICEは高価ですから客のところにいってバグチェックするときにログがあれば便利なので常にデバッグ機能を有効にするのもありと想う．高田 : どんな目的で保護機能がほしいかのアンケートをします． 1の目的6人 2の目的8人 3の目的1人 C氏 : OSでめんどうを見るということは，あらゆる目的でほしいことと言える．また，OSのみで保護をするのではなく，仕様，ハードウェア，言語でもすることができるので，OSがするべき保護とは何かクリアにする必要がある．高田 : プロセスやマネージメントからのアプローチで品質をあげるのも大事であり両方する必要がある．ハードウェアがする保護はOSがするべきで，なぜならいきなりアプリがMMUを使って保護を行うのは現実的ではないからです．言語に関してはJava等あるが，現実的ではない． C氏 : OSで保護する場合の，敵はなにがあるかを洗い出す必要がある．高田 : OSは大きな粒度の保護で，言語は小さな粒度の保護である． C氏 : 敵は，プログラマのミスと言える．高田 : あげた3つ以外に保護の必要な対象はあるでしょうか． D氏 : リソース(QOS)の保護は考えないのでしょうか．高田 : 広い意味で3に入るのではないでしょうか．しかし，QOSの保護は別と考えられますね． QOSの保護の場合，敵は悪意のあるプログラムもありますが，圧縮レートの変更など，予期しない負荷変動が含まれますね．高田 : 次の項目に進みます．・議論のポイント2 どのようなシステムに保護機能が必要ですか? プログラムサイズが1Mを越えたら? 高い信頼性の求められるシステム? 外部から信頼性の低いモジュールを導入した場合高田 : OSも変更する必要はありますか? A氏 : マイクロカーネル等に変更する必要はあると思います．今までだと，ライブラリ呼び出しで行えてきたことが，そのままできなくなると，これまでとシステムの作り方が変わってしまい．大変そうである． G氏 : 私はマイコンのコンパイラをやっていますが，コンパイラで組込みシステムもサポートできないかねたを探している．具体的なイメージがわかない． C氏 : あればいいのですが，現在コードの2割りが本質的な機能だが，8 割りがエラー処理になってしまう問題をどうにかしてほしい．高田 : Aさんの例では，ブラウザが落ちれば，ブラウザのみ落とせばいいのですよね． A氏 : そうです．高田 : ブラウザが確保していたリソースを解放する必要がありますよね． A氏 : そうです．単に保護だけをして，資源を解放してくれなければあまりうれしくない．高田 : UNIX的なものがあればいいのでしょうか? A氏 : そこまでは必要と思いませんが，ガイドライン的なものがあればいいんではないか．あまりUNI的にするとRTOSではなくなってしまう． E氏 : 議論ポイント1の2のモジュールに障害があること自信がすでに許されないに関してですが． ECUを開発しているが，テスト中は品質には問題ないが，ドライバーの安全のためテストが必要なため，サポートされるとうれしい機能です．高田 : 車を安全に停めるのは，車特有のことで，例外ルーチンで書く機能があればいいと思いますが． E氏 : CPU全体を停めることはできない．高田 : 私は1だと思います． D氏 : フェールセーフの概念は入っていないのですか． E氏 : 入っているが，OSにこういう機能があれば開発工程が変わるのではないかと思っている． D氏 : 例を教えてください． E氏 : 2重系をハードウェアに加えてアプリケーションレベルでも行っている．高田 : 計算アルゴリズムがおかしいのはどうやっても対処できないですが，ドライバーが乗っている場合，メモリ保護があればバグが早く見つかるということですね． E氏 : そうです．高田 : OS-9の話だが，枯れたモジュールを移植したとき保護機構によりポインタの異常が見つかったという話がある．自動車の人の話を聞くと，いろんな会社のアプリケーションとセンサーを持ってくるので，バグの切り分けのため保護機能が必要だと思う． E氏 : 売る時に保護機能が必要かどうかは疑問である．高田 : 自動車の信頼性条件は高いので，2のモジュールに障害することが許されないというものに該当するのではないか．高田 : QOSに関してはどうでしょうか． C氏 : どこで発生したかを知るという意味では有効．高田 : ICEを使えばバス上のデータはとれると思いますし，これがデバッグに有効だと思われる．高田 : 保護機能を使うために，どの程度の設計変更なら許されるのか知りたい． F氏 : 現在ITRON4.0に保護機能をつけたものを検討している．対象は，ウェアラブルPC等でアプリケーションはMPEG4である．どうして必要であるかというと，他の会社のモジュールと自社のモジュールを組み合わせた場合，バグが発生してその原因が他社のモジュールだったため，いきどうりを感じた． UNIXの保護を入れると重すぎてしまう．I/Oが多いのだが，UNIXと同等のことをしていれば，動画の再生にオーバーヘッドが増加し，クロックを上げる必要があり，消費電力が上昇してしまうという問題がある．そのため，UNIXより軽い保護機能がほしいと思っている．高田 : レスポンスは車の方が速く，スループットはマルチメディア系の方が速いですよね．各社のモジュールを使った場合，問題の切り分けをしたいという話ですが，OS屋はまずOSを保護したい．これは，よくユーザープログラムのバグをOSのバグと思われてしまうからです．ユーザーは自分のアプリをを他のモジュールから守りたいという要求がある． H氏 : OSの上で動くクロスライブラリを作っている．その時，OSが悪いのかライブラリか，それとも言語か，どの人かと原因が分からなくなって困るという問題がある．問題の切り分けをするために何かできないか考えている．高田・議論のポイント4 保護機能のために，どの程度のオーバーヘッドなら許容しますか? A氏 : リアルタイム系であるサーボ系なら困るがミリ秒オーダーの個所ではいいと思う．1%ならいいかも． D氏 : そんなぎりぎりに作っているのでしょうか? A氏 : そんなにぎりぎりではない．高田 : アセンブラからCに移行する場合にも同じ問題があったのではないでしょうか． A氏 : その時は2倍になったので話にならなかった．高田 : 結構のびますよね．おそらく2,3倍になると思います．しかしながら，システムに含まれるOSの時間が1%なら2倍になっても問題がないと思う．OSの実行時間が10%も含まれるものはないと思われる． A氏 : そんなにないとは思うが，ファイルシステム等には結構含まれると思う．リアルタイム系はあまりAPIを呼ばないのでそんなに気にはならないと思う． E氏 : 車はコスト第一です．OSの時間は5%ぐらいだと思う．CPUは自分のしたいことに近いものを選択する．1,2%はいいが5%はイメージ的につらいと思う． F氏 : コストに対しては関与しないが，全体のオーバーヘッドに関してはLSI技術が上がるため問題にならないと思う．1割程度なら誤差の範囲だと思う． I氏 : メモリ保護のアプリケーションに関してですが，リング保護になると，アプリケーション毎の保護をどのリングでやるのだろうかという疑問がある．アプリケーションはリング1の同じところにある．OSとアプリケーションの保護はできると思うが，同じリングにあるアプリケーション同士の保護は不可能だと思う．高田 : プロセスモデルであれば，他のメモリは見えないので保護になる．決してアプリは0，1のリング保護では不足であると考えている． I氏 : OSの複雑さが増すと思われます．高田 : オーバーヘッドの観点では，保護にはMMUは必要であります． CISCタイプのMMUがあるが，TLBミスがたまに発生するがこれは，リアルタイムシステムに対して許されるのでしょうか． A氏 : ページサイズは可変でしょうか．高田 : CISCタイプのMMUではページサイズは4k or 8kの固定です．1エントリ1ページです． A氏 : リアルタイム系はリアルメモリで動作させれば気にならないと思う．マージンがある不確定要素があるのは許せない． J氏 : SparcのMMUでは，論理区間のマッピング物理空間にマッピングされ結構時間がかかってしまった．最近のMMUでは，そんなにオーバーヘッドがかからないと思うので，気にならないとおもいますが．高田 : キャッシュのパージ等が入ると結構はいると思います． J氏 : 論理空間の切り替えに時間がかかると思いますが．高田 : リアルタイム性の高い個所は保護の対象とせず，直接物理空間に張り付けるので，特に問題にならないと思われます． J氏 : 開発しているシステムではタスクが100あり，オーバーヘッドのうち，タスク間の通信が多くを占めています．高田 : メッセージ通信のオーバーヘッドですが，これまでポインタわたしのものをメモリコピーしなければならないというオーバーヘッドが出てしまうというのが気になるのでしょうか．高田 : TLBミスはキャッシュより影響が大きい．そのため，キャッシュが許容できなければTLBはそもそも許容できないのではないでしょうか． E氏 : 車の制御では，平均値より最悪値が重要なので，キャッシュは常にミスするものとして使っています．テストでは許容できますが，製品としては許されない．高田 : ARMのMPUの話メモリ変換を行わず，メモリ保護のみを提供する．命令/データに対して，最大8つの固定優先度付きの保護領域に対してアクセス保護を設定．保護領域のサイズは4KB-4GB．しかし，領域は最大で8個までしか使えない．高田 : メッセージ通信の話に戻りましょう F氏 : マルチメディア系では，データの送受信が多くなされるため，コピーが増えるのはまずい．高田 : 新しいメモリ管理とメッセージ通信の機能異なる保護ドメイン間でのコピーを必要としない高速なメッセージ通信．ページ単位でメモリブロックを割り付けるメモリプールの紹介します． K氏 : FAやセットボックス用のソフトウェアの開発をしています．保護機能の応用に関しては必要性がお客さんのところにいくと感じます．ソフトウェアの品質という点ではまた，デバッグのために必要になると思います．いまでは必要ないと思いますが，これからCPUの発展とともにプログラムサイズの増加がこれからあると思うので必要だと思います．開発期間が短くなる方法としては期待しています．高田 : 本当はOSでやる保護，言語でやる保護といった議論がこのでは必要だったかなと思います．Javaを使えという話もありますよね． D氏 : 保護といってもいろいろあると思います．マルチメディアではあまり重要じゃないかもしれませんね．また，保護にも幾つかのレベルが必要かもしれませんね． A氏 : 言語による保護の方がいいのかも知れませんね．本社のソフトの GUI言語には，エラー保護があって，デバッグ効率が上がっているので．このOSの保護の範囲は狭いので過度的なものとも思われる． D氏 : 現状Javaのスピードは許されるのでしょうか． A氏 : GUIに対する応用では許されると思いますが．高田 : 言語では粒度が細かくなるのでオーバーヘッドが大きくなってしまいますよね． A氏 : そうですね．制御系のソフトはきっちり作られているが，情報系はきっちりつくられていないイメージがしますね．高田 : 今回の分科会はある程度具体的な数値を含めてとても参考になりました．言語の話も含めて考える必要があるかなと思います．これから，どのなアプリでも肥大化しているので，メモリ保護は必然ではないのかなと思われます．内容は以上． ====================================================================== 【記録者自身の感想】参加者の業種さ多種多様であったためそれぞれ保護機能に求めているものが異なっていた．参加者の中には直前の一般発表での高田先生のITRONの保護機能の発表を聞いていない方が多く議論の出発点が整っていなかった印象をうけた．保護機能に関しては，まだ実装例がなく使用例もあまりないため，保護機能自体のイメージがあまりできないため，あまり議論が盛り上がらなかったと思われる．