チュートリアル3A: Recent Architecture Issues for Real-Time Embedded Systems 会場規模: 約50人 参加人数: 約25人 開催時間: 09:00〜10:45 講師: Dr.Doug Locke(TimeSys) チェア: 中島氏(早稲田大学 助教授) 通訳兼任 講師紹介:  長年 Real-TimeSystem 関連に携わられており、近年では Real-TimeJAVAの 仕様策定に貢献 概要:  Real-Time Linux、Real-Time Java、Real-Time CORBAについての話。 チュートリアル内容、およびQ&A:  Real-Timeは、予測可能性、オーバーロード時に安定していること、レスポンス タイムを保証できることであり、処理が速いことや、効率が高いことではなく、 また「組み込み」と同義でもない。  大体の組込システムでは時間的制約があり、それを限られた資源で達成しなくて はならない。Linux はタイムシェアリング用のシステムなので、構造自体が時間制 約を満足するものではない。Javaはメモリ管理が簡潔に記述できるが、ガベージコ レクションに時間がかかる。CORBAはスループットを上げるために考えられており、 予測可能性がないと述べ、従来のLinux、Java、CORBAではリアルタイム処理には適 応していない。 近年の解決法: 1.Real-Time Linux: 概要:  Resource Kernelは、あるLinuxプロセスに関してCPU資源を予約する。  プロセスが無限ループに陥っても、Resource Kernelが予約分以上の資源を使わ せないなどして時間的制約を保証する。  Linuxのカーネルには最小限の変更だけを行ってResource Kernelはカーネルスペ ースで動き、Linux Kernelをコントロールする。  また、Resource Kernelを使わないやりかたとして、Real-Time Application Interface RTAIというレイヤを使う方法があげられた。この方法は多くの商用linux で使うことができる。カーネルスペースでRTAI Processが動く。しかしLinux kernel の機能はリアルタイムには使えない。  Reource Kernelを使う方法だと、filesystemやXなども時間的制約を保証することが できる。 この項のQ&A: Q. 保証するのはどんな単位で? A. specificationは3つのコンポーネントがある。  ピリオド、実行時間、デッドライン Q. タイムスライスはどこで指定するか? A. タイムスライスはしない。 Q. 資源はいつ、どこで予約するか。 A. アプリケーション自身がAPIで指定、もしくは外からPIDで指定。いつでもどこで  も予約は変えられる。 Q. Resource Kernelのサイズはどのくらいか? A. 40K-50Kbytes。 Q. オーバーヘッドはどのくらいか? A. Resource Kernelの処理にかかる時間という意味では、OSのKernelの処理時間と同  じ理由で、計測しにくい。しかし、Linux kernelをコントロールしてるだけなので  オーバーヘッドは小さいはず。 2.Real-Time Java: 概要:  Real-Time Java Experts GroupとJ Consortiumが、Real-Time Javaを標準化しよう としている。Real-Time Java Experts Groupの提案しているものは、Real-Time Spacification for Java。SunのJava Community Processが運営しており、20社くら いが参加している。仕様は完全だが、実装はまだ完了していない。(来月くらいには できる予定) Real-Time Java Experts Grouo提案の特徴:  ・28以上の優先順位をもつ。  ・JVMを拡張するが、上位互換性がある。  ・同期は、priority inheritanceやceiling emulationを使っており、予測可能性   が高い。  ・スケジューラーインターフェースが、様々なポリシーに対応。  ・ガベージコレクション制御のインターフェースがあり、ガベージコレクションし   ない、なども選択可能。  J Consortiumの方は、Real-Time Core Extensionを作っている。Sunと独立で50のメ ンバーがいる。仕様はできているが、実装がされる見通しがたっていない。 J Consortium提案の特徴:  ・JVMを拡張せずReal-Time Coreを提供  ・128の優先順位  ・priority ceiling emulationを使った同期  ・ガベージコレクションなし  ・不可分な実行ブロック この項のQ&A: Q. JITコンパイラの影響は? A. ここでは仕様を示しているだけなので、実際にどう使うかはまた別問題である。  多くのコンパイラは平均時間は提供するが最大時間は不明なままである。融通性  と予測可能性のトレードオフになる。 Q. なぜJava?他の言語は? A. リアルタイム処理に使われる言語としては、C、C++、Java、Adaしかない。  Adaは今更、という感がある。Cは、ポインタがありものすごく危険なプログラム  が記述できてしまう。C++は(Cより)良くはなっているがポインタがあるので一緒。  Javaはポインタがなく、メモリ管理が簡単なので間違ったことをしない。 Q. Real-Time Java と Real-Time CORBAの関係は? A. 全く関連性はない。運営している組織からして違う。 Q. Real-Time Javaでデバイスドライバがかけるようになるか? A. 非常にいい質問で、興味がある問題だが、現時点ではまだ困難が伴うのではないか。 Q. Real-Time Java Specificationのオーナーは? A. Sun Community Process Group Real-Time CORBA: 概要:  伝統的なCORBAは、C/S型アプリを作るためのミドルウエア。サーバーがどこにあ るかを気にせずに、どんな言語で書いてあるかどんなネットワークを介してかを気 にせずにアプリをかける。しかしCORBAは時間や資源を管理する術がない。 Real-Time CORBA 1.0の概要  ・OMG(Object Management Group)(CORBAとUMLを作ったグループ、  ・800以上の企業などが参加するコンソーシアム)によって制定   RTSig(OMG Real-Time Special Interest Group)  ・分散、場所に依存しない予測可能な分散アプリケーションが書ける。  ・CORBAが提供してる優先順位をそれぞれのOSのそれにマップできる。 Real-Time CORBA RFP(Request for Proposal)は97年9月に公表され、以下を目指し ている。  ・クライアントとサーバーの間の全ての部分で予測可能性を実現すること  ・ランタイムが提供する全てのリソースを制御することができるようにすること  ・従来のORBとも相互運用が可能であるようにすること  従来のCORBAでは、サーバーとクライアントのそれぞれが全くちがう方法で優先 順位を割り当てているため、予測可能性がない。  Real-Time CORBAではクライアントで定義された優先順位がサーバーにも伝播する。 そのためには、予測可能性のある通信路など、色々なものが保証付きでないとうまく いかない。 OSの条件については、POSIXがあれば十分だが必要ではない。 このチュートリアルのまとめ:  ・組み込みシステムでは時間制約をサポートするべき  ・Linux, Java, CORBAは現在ではそれをサポートしていない  ・Linux/RTとReal-Time CORBAはすでに利用可能  ・Real-Time Java はすぐに使えるようになる この項および全体のQ&A: Q. Java Extensionはオープンソースか? A. 基本的にはそうではない。 Q. 次のCORBA3.0ではRT CORBA1.0を含むか? A. 含んではいるが、完全に含むかどうかは選択可能。 Q. Resource KernelのインターフェースをPOSIXみたいなものに標準化する用意は  あるか? A. 現状ではResource Kernelにアクセスするためのhookを標準のLinuxにいれると  いう働きかけを行っており、これが達成されればかなりの前進であると見ている。 Q. Jiniは? A. 個人的には使っていないのでよくわからないがリアルタイム拡張に関する対応は  されていない。 3A以上