SWEST3 分科会F4 「私が想う組込みシステムに必要なRTOS保護機構　　　　　　　〜保護されることの幸せ〜　　　　」 ------------------- 会場の様子 ------------------- ◎会場の広さ６０席（各テーブル３席×２０テーブル） ◎参加人数３０人前後　★内訳ソフト開発関係者：７〜８人 OS開発関係者：４〜５人大学関係者：７〜８人 ◎雰囲気　会場は席やテーブルを移動することなく、一般発表で使用された形そのままで行われた。ポジショントークはなく、この分科会の直前に行われた一般発表E3で行われた発表「μITRON仕様へのメモリ保護の導入」から引き継がれる形で司会者が議論のポイントをあげ、それに対しての意見を参加者から募るという形で進行した。当初はなかなか意見が出なかったため、インタビュー形式で行われていたが、しばらくすると、自発的に意見する人たちが出始めた。学生を除く参加者のほとんどが何らかの形で意見を述べていたが、中にはこの討論を見守るという姿勢の人も見受けられた。会場の前のスクリーンには、通常は議論のポイントが映されていたが、アルゴリズム等の説明が必要になると、その都度説明用のプレゼンテーション資料が表示され、説明がおこなわれた。 ◎議論のポイント　ポイント０：組込みシステム用のRTOSにも保護機能が必要ですよね？　ポイント１：何のために保護機能が（最も）必要か　ポイント２：どのようなシステムに保護機能が必要ですか　ポイント３：保護機能を使うために、どの程度の設計変更なら許されるか　ポイント４：保護機能のために、どの程度のオーバーヘッドなら許容するか ---------------------- 内容 ---------------------- ◎議論ポイント０：組込みシステム用のRTOSにも保護機能が必要ですよね？　議論前に参加者の意識調査。　反対派はいない。参加者はRTOSの保護機能を求めている。ポイント１：何のために保護機能が（最も）必要か　一般発表E3で行われた発表「μITRON仕様へのメモリ保護の導入」において、導入する動機・目的　（１）デバック支援のための保護機能　（２）信頼性向上のための保護機能　（３）セキュリティ確保のための保護機能　参加者にとってどの目的で保護機能がほしいのかの調査。　（１）：６人　（２）：８人　（３）：少数　　（１）において　　　●この保護機能がほしい人の理由　　　　・誰かが変なコードの書き込みをしたために、バグ発見に何日もかかる　　　　　　→　ICEではダメ？　　　　　　→　ICEだと高いし、使えないこともある。　　　　　　→　OSからのlogが欲しい　　　●この機能について　　　　・デバック終了後はいらないからオーバーヘッド削減のためはずすか？　　　　　　→　安定して動作しているのなら外さない。　（２）において　●この保護機能がほしい人の理由　　　　・買ってきたアプリケーションの信頼性が低く、現状ではそのアプリに専　　　　　用のプロセッサを用意しているが、できれば分けたくない。　　　　　　→　アプリ自身のバグは許したくはないが仕方ないので、OSに信頼性　　　　　　　　を求める。　（３）の目的で保護機能がほしい人の理由　　　●この保護機能がほしい人の理由　　・外からのダウンロードについて　　　　　　→　（３）の保護は絶対に必要　☆OSの保護について　　OSの保護には普遍性がある。そのため、OSだけで保護すればよいわけではなく、　言語や仕様、CPUなどのハード（ただし、ハードによる保護はOSの保護に含むと考　えてもよい。）でも保護は必要となる。さらに、マネージメントとプロセスからの　アプローチと技術側の底上げが必要となる。　☆保護が必要となる敵・保護するための敵がこの議論ではあきらかではない。つまり、敵はプログ　　　　　ラマなのか、悪意のある人なのか？例えば、買ってきたアプリはバグが取　　　　　れないので敵である。しかし、さらにいえば、これはプログラマの過失な　　　　　ので、プログラマが敵ということになる。そこで、敵がプログラマの場合　　　　　に必要な保護は（１）および（２）となる。では、（３）が必要とされる　　　　　状況の敵は？といえば、外部からの悪意のある人たちと言うことに。さら　　　　　に別の面として、QoSの保護はいろいろな側面があり、例えばマルチメディ　　　　　ア再生の際、悪意のあるモジュールによる音飛びやコマ落ちなどは、予期　　　　　しない負荷変動が敵である。ポイント２：どのようなシステムに保護機能が必要ですか？　●プログラムサイズが１Mを越えたシステム　●高い信頼性が求められるシステム　●外部から信頼性の低いモジュールを導入した場合　・もし、保護機能が大したオーバーヘッドにならなければそのまま使うかという質問。　　返答は使わないというより、使いにくいということに。理由としては、保護機能導　　入以前の今までのシステム（特にメモリ保護について）がそのまま使えなくなるた　　め。そのため、その点を考慮して最初からつくるなら、使うということに。　・保護機能より異常が発生した際の回復機能のほうが重要なのでは？という問いでは、　　保護とともに、回復のサポートもOSにいれたほうがよいのではということに。ただ　　し、　サポートして欲しいが、行き過ぎてRTOSに支障をきたす（極端に言えばRTOS 　　でなくなる）のはもっと困るという意見も　・自動車制御では、プログラムのバグで事故（販売時はもちろん、テストドライバに　　よるテスト時も含めて）が起こることはあってはならない。そのため、開発の際に　　検証にかなりの時間を費やす。現状ではテストドライバーによるテスト時等、アプ　　リ側で異常時は車を止めているし、フェイルセーフは現状ではハードでカバーして　　いるが、OS側で何らかの対策をしてもらえば、検証時間が減らせるという意見が出る。　・いかなるシステムにおいても計算アルゴリズムがおかしいのはOS，言語でがんばっ　　てもダメであるが、潜在的なバグにおいてはOSの段階で保護できれば早く発見され　　る可能性がある。そのため、先の開発期間の短縮（OS9で事例あり）も可能となるし、　　自動車開発では（２）の信頼性向上もカバーできる可能性もある。ここで、他社と　　自社のものが共有されると、事故等発生時にどちらの責任かわかりにくいのでは？　　という意見がでるが、開発サイドは開発段階では大体わかるし、販売してからどち　　らの責任か追及してもしょうがないという考えで開発しているという意見がでた。　・異常時の回復サポートをOSではどこまで？という質問では、開発にはロールバック　　が必要なのではという意見がでるが、ソフトのバグはロールバックしてもいつまで　　も一緒ということで、ICEでシステムの振舞いを全部ダンプしておけばデバックは楽　　ということになった。ポイント３：保護機能を使うために、どの程度の設計変更なら許されるか？　・自社のものではなく、他社のもので自社のモジュールがつぶされた例について、共　　有利用するメモリに対する保護が必要である。しかし、メモリ保護導入はオーバー　　ヘッド大なので、どこまで入れるかということで、次のような議論が行われた。　・メモリ保護にUNIXのものを利用したらという意見が出るが、現状ではなかなか厳しく、　　動作クロックを挙げると利用可能でしょうが、消費電力も大きいため、組込みには向　　かないということに。　・OS屋さんとアプリ屋さんで保護したい目的が異なることについて、OS屋さんはまず　　OSを守りたく、エラーはアプリ側からしか起こらないが理想である。一方、アプリ　　屋さんはOSよりもアプリを保護してほしい。この違いをどうするかも今後のテーマに。　・異常の原因がOS？ライブラリ？言語？客？のどれなのか、どれが悪いのかが異常発　　生時すぐにわかるようにしてほしいという意見も。ポイント４：保護機能のために、どの程度のオーバーヘッドなら許容するか？　・性能ダウンは数パーセントなら許せるのなら、今はCPUの高速化が進んでるから可能　　でしょうという意見。そこで、タスクの切り替えとかでオーバーヘッドが倍になるん　　じゃないかという意見が。この意見に対して、実際システム上でOSが使っているのは　　わずか１〜２％なので、倍になってもそれほど気にならないと思われるということに。　　さらに、オーバーヘッドが倍になったのなら、CPUのクロックも倍にすればよいが、　　そのほうが価格等による制約が大きいという意見も。　・自動車制御では１〜２％ならゆるせても、５％は難しいという意見。OS開発の視点で　　は、半導体の技術向上は著しく早いから、１０パーセント以内のオーバーヘッドは誤　　差のうちという風に開発するものによる違いが浮き彫りになる。　・0,1だけのリング保護はOSとアプリのそれぞれの保護だけなら十分かもしれないが、　　IO入出力やメモリ保護もある場合、アプリの保護は難しいのではという意見を受け、　　アプリの保護は0,1だけでは複雑で、オーバーヘッド1,2％は難しいということに。　・CISCタイプのMMUにおいて、TLBを１回ミスすると数μ秒止まるのはオーバーヘッドと　　して許せるかどうかについて、実際リアルタイム系のところをスルーしないのなら、　　このミスは許容範囲ではない。しかし、TLBミスはオーバーヘッドが少し増えた程度　　に考えたらよいのではということに。なぜなら、メモリの動的確保は時間がかかるか　　ら、TLBミスは気にならないし、むしろコンテキストスイッチのほうが重要である。　　さらに、TLBミスやタスクの切り替えより、メッセージ通信のオーバーヘッドの方が大　　きいためである。だが一方で、メッセージ通信のオーバーヘッドはどうしようもない　　ため、ほかでオーバーヘッドを減らすことは重要であるという意見も。しかし、その　　重要さに以上に、複雑になるのが嫌ということも。　・キャッシュミスは許容してますか？という問いに対しては、ワーストケースはキャッ　　シュがあっても一緒で、キャッシュミスよりもTLBミスの法がオーバーヘッドは大き　　いという意見。なぜなら、キャッシュミスはメモリには一回しかアクセスしないが、　　TLBミスは何回もメモリにアクセスするためである。そこで、ARMのMPUはTLBミスが発　　生しないのでリアルタイム性の観点からの利点は大きいし、TLBが考慮できないとき　　でもメモリ保護できるという意見。しかし一方では、自動車制御ではキャッシュは　　必ずミスするものだ！という考えで開発しており、よってキャッシュはあってもいい　　が、考慮はしないということだった。　・ここで、オーバーヘッドに関しての解法を議論。それにたいして、１つは共有メモリ　　を設けて、大きなデータはそこを通すということと、２つ目はページリマッピングす　　るということに。ただ、ARMと一緒にするのは難しい。しかし、マルチメディア処理　　では有効であるため、これをRTOSに追加したいということに。　・ただし、全体としてオーバーヘッドの許容範囲は製品によって異なるため、それぞれ　　にあわせて作りかえるのは大変だが、外部要因からのメモリ保護は重要であるため、　　RTOSの保護機能として必要ということに。　　・最後に今後はOSに何をやらせて、言語に何をやらせるかから議論したほうがよいので　　はという意見がでる。これに対し、言語でやれば細かく保護できるけど、オーバーヘ　　ッドは大きくなるという意見が。ただ、信用できないソフトのために、OSに限らず保　　護が欲しいということに。 ------------------ 全体を通じて ------------------ ◎中心となった議論　RTOSに保護機能が必要という点では参加者全員一致だったので、議論はRTOSにどのよう　な保護機能がどの程度必要か、それに伴うオーバーヘッドの許容範囲について議論が行　われた。 ◎方向性　RTOSの保護機能についての議論から、言語や仕様にも保護機能を求める方向へ議論が行　われた。 ◎結論　今回の分科会のまとめは、シビアな自動車制御もメモリサイズが１Ｍと大きくなってき　ているなど組込みの規模が大きくなってきており、将来的には必然的に必要となってく　ると思われるので、RTOSだけでなく、開発言語による保護機能も含めて、考えていく必　要があるということになった。 ◎感想　RTOSの保護機能がほしいということは参加者全員の願いであることは十分に伺えたが、　どんな保護を求めているのかと言えば、実際にはイメージが沸きにくく、今一つ盛り上　がりに欠けた議論となった。しかし、参加者同士による対決姿勢みたいなものはほとん　どなく、挙げられたポイントやある人の開発における悩みや質問に対して、ほかの参加　者が答えるなど、比較的なごやかな議論であったと感じた。