セッション4A：「リアルタイムOS」会場規模：約100人参加人数：約50人開催時間： 11:00〜12:30 会場の雰囲気など：　活発な質疑応答がおこなわれ、参加者は熱心に耳を傾けていた。とくに「ITRON C++API仕様へのアプローチ」の発表、質疑応答時は、良い意味でくだけた雰囲気で進められた。　「ITRON C++ API仕様へのアプローチ」について、発表というよりも、参加者に意見を求めるという形でおこなわれ、また多くの参加者の興味の対象となる話題でもあったようで、C++ APIの意義について多数の議論が交わされた。以下、発表内容： −−−−− 1.「組み込み用マイクロカーネルOSの設計」　久住憲嗣、森若和雄、中西恒夫、片山徹郎、最所圭三、福田晃（奈良先端大）発表内容：・研究の動機：　組込みシステムの複雑化、製品サイクルの短期化といった背景があり、開発効率の向上が重要な課題である。OS自体の生産性や再利用性、移植性、検証性の向上のためにマイクロカーネル構成の組込み機器向けOSの開発が考察する。・マイクロカーネルの特徴：　利点：　　開発効率、保守性、再利用、検証性の面で有利。　欠点：　　プロセス間通信のオーバヘッド(データコピー、プロセススイッチ)が大きい。　　多量のメモリを必要とする。・上記欠点の改善策：　　サーバのスレッド化　　　　メモリの共有が可能となる。　　　　プロセススイッチのコストが小さく出来る。　　アドレス空間の共有　　　　結合の強いユーザプロセス間、あるいはユーザプロセスとサーバプロセス間　　　でアドレス空間を共有する。　　　　コンパイラ・リンカによる最適化　　　　→単純なRPCを関数呼び出しに置き換える。　　　　　実装はマイクロカーネル構成、実行はモノリシックカーネル。・開発工程と抽象度の関係：　各部品を独立に開発(実行速度低、モジュール独立性高) 　　→開発しやすい環境で開発・テストを行う。この時点で十分に安定させる。　各サーバをスレッド化(実行速度中、モジュール独立性中) 　　→OSが安定した状態。アプリケーションの開発からこの段階に入る。　ユーザプロセスのスレッド化(実行速度中、モジュール独立性中) 　　→アプリケーションが安定した状態。デバッグ段階。　コンパイラ・リンカによる最適化(実行速度高、モジュール独立性最低) 　　→自動モノリシック化を行う。出荷寸前の状態。・このマイクロカーネルのポイント：　実装段階ではマイクロカーネルで開発する。　→開発時には高い抽象度を確保することで開発を容易にする。　出荷時にモノリシックカーネルに変換する。　→実行時(出荷時)に速度を確保する。・その他の特徴：　信用できないプロセスは別空間で実行する保護機構。　各種デバッグインタフェース。　　任意のメモリ空間へのアクセス機能　　プロセス間通信の監視機能　　スレッド等を停止・再開機能・このマイクロカーネルの欠点：　各段階ごとに環境が異なる。　→タイミングに起因する不具合の発見が困難。　ソースとバイナリが大幅に異なる。　→テスト・デバッグが困難。・OS実験環境：　Nゲージと呼ばれる電車模型制御システムを採用。　→リアルタイム性　　パーツの組み合せ方や回路の組み方により様々な環境を作り出せる。　　目で見て分かりやすい。・まとめ：　マイクロカーネル構成の問題点を挙げ、いくつかの解決策を示した。　今後、このOSを実装し、検証する予定である。 [質疑応答] Q:　デバッグしにくいという話があったが、具体的にはどういうことか？ A:　工程の初期段階では各プロセスは独立しているが、最終的にはスレッドとし　て実装するので、微妙なタイミングに起因するバグを発見・デバッグしにくい。　さらに、コンパイラによる最適化を行うので、ソースとバイナリの対応がとり　にくい。 Q:　工程の初期段階で独立したプロセスであるものをカーネルにまとめてしまうという話だが、その際にユーザのタスクを書き換える必要があるか？ A:　必要ない。タスクを書き換えずに、パラメータを指定することでカーネルへの取り込みが可能。 Q:　コンパイラは何を使ってもよいのか？ A:　何でもというわけにはいかない。まだ作っていないが、もしかすると、Cプリ　プロセッサでどうにかなるかもしれない。 gcc のオプティマイザを入れ替えれ　ば使えるかもしれない。 Q:　独立のプロセスとしてに開発したものをひとつのカーネルにまとめると、メモ　リ管理が変わってくると思われるが、どのように考えるているか？ A:　制限が多い独立プロセスで実装したものを制限の少ないカーネルにまとめるの　で、メモリ管理上の問題は発生しないと思われる。もちろん、危険があるところ　は安全側に最適化する。 Q:　マイクロカーネルはもともとUNIXでユーザがいろいろ使いやすくするためで、　組込みで小さく作るというのとは反対の考え方ではないか。「こういうOSが欲　しい」というところからモノリシックなカーネルを生成してくれるツールの開　発でもいいのではないか。狙いが良く見えない。 A:　msecオーダの、タイミング制約がわりとゆるくて大規模なシステムには良い　のではないかと考えている。 Q:　マイクロカーネルは大きくなりがちだが、組込み分野ではコンパクトさが求　められる。その点についてどう考えているか？ A:　開発効率を優先すれば、マイクロカーネルの方がよいと考えている。　　また、ネットワークへの対応などを考えると、モノリシックよりもマイクロ　カーネルの方がよいのではないか。 Q:　対象のプロセッサは？ A:　ARM、68k、SH、x86等を考えている。 Q:　電車模型が動くのはいつか？ A:　設計は本年度中くらいを考えている。 −−−−− 2.「リアルタイムOSにおける実時間同期メカニズムについての考察」石川克己、曽根卓朗（ヤマハ）概要：　リアルタイムOS上の複数のタスクを実時間で同期させて動作させるクロックマネージャというメカニズムについて考察する。これは時系列に沿って記述されたデータの再生機能を実現するために開発された小規模なミドルウェアであり、 MIDIシーケンサ等の演奏制御システムが応用例として挙げられる。想定するデータはマルチトラックであり、時間同期が前提である。クロックオブジェクトとは？：　独自の時間間隔で、あるイベントを定期的に起動することができる動作単位のことで、クロックマネージャ内において複数個生成することができ、それらの継承関係も定義できる。上位の制御系のタスク等からメッセージの発行依頼を受け取ると、クロックオブジェクトを経由してアタッチされたタスクに対して状態遷移等のメッセージを発行できる。実時間同期の問題：　データ表記上はイベント処理時間を0とみなして記述するのが普通であるが、実際には無視できない処理時間があるため、実際の待ち時間は処理時間との差を考慮しなければならない。ITRONなどの時間待ちを使うと処理が厄介で、遅延を吸収するのも難しい。上記問題の解決策＝ dly_clk()：　dly_clk()はタスクを就寝させるためのシステムコールで、処理を開始してからの待ち時間を積算してきた絶対時間を記述する。処理が遅延していれば待たずに抜ける場合もある。処理系の遅延や処理に掛かる時間を吸収することができる。その他のクロック生成、制御用 APIも用意している。　dly_clk()を用いることで、再生系全体の制御は制御APIからのクロックマネージャ経由での指示により、それぞれのタスクが同期して動く。1つ1つのモジュールの形が統一されているため、リエントラントできれいにプログラムが記述できる。考察：　メッセージ通信において、対象タスクの状態に応じてメッセージを受け取るタイミングや処理の挙動が変わってくる。　　1)Waiting状態のタスクにメッセージが届いた場合　　　→タスクを起床する。　　2)Running/Ready状態のタスクにメッセージが届いた場合　　　→即座には処理できない。　　　　次にWaiting状態に入るときに処理。解決策：　メッセージの発行時刻をもとにタスクの挙動を決める。　現状では dly_clk() はメッセージ通信に関して厳重な動作規定をしていない。応用：　・複数のソースクロックをひとつの clock object で制御できないか？　　(現状の clock object はひとつのソースクロックだけをみている）　・分散環境への応用　　複数の機器が接続されている環境下で、これらの機器の同期をとることがで　　きるのではないか？ [質疑応答] Q:　複数のイベントに対する待ちを1つのシステムコールに閉じ込めたいというこ　とか。 A:　それが1つ。それから、複数のタスクが時間的に厳密に同期することを保証し　たい。各タスクはそれを意識しないでいたい。　　dly_clk()を発行していれば、他のタスクとの同期が保たれているの特徴。 Q:　マスタークロックが複数のタスクに同時にイベントを投げれば同じ事ではない　か。例えばイベントフラグの複数のビットに意味を持たせれば同じではないか。 A:　目的としている同期の意味が違う。メッセージブロードキャストでタスク全体　を同期させている部分は、フラグでも同じである。ここでやっている最初の目的　は別で、各イベントがタイミングが全然違うばらばらの処理をしているが、それ　らの時間軸を揃えようとするとイベントフラグではできない。イベントの処理時　間を吸収し、各タスクにそれを意識させないのが第1の目的である。これを作った　ところ、いわゆる普通の同期が難しくなってしまったために、メッセージブロー　ドキャストを使っている。 Q:　精度はどうか。 A:　演奏を対象としているので、数msecから10msec以下の精度である。クリティカ　ルな処理には応用できないかもしれないが、この程度の精度でいいならば、優れ　たマネージャである。 Q:　タスクの最大処理時間はどのくらいか。 A:　10msec前後である。現状では遅延が溜まった場合、dly_clk()は何もせずに一気　に処理が行われる。要求される精度はデバイスによって異なるため、タスク群をデバイスによってグルーピングし、処理時間に応じてプライオリティを変えている。 −−−−− 3.「ITRON C++ API仕様へのアプローチ　　　−C++言語の有用性とオーバヘッドのトレードオフ−」若林隆行, 高田広章（豊橋技科大）発表の趣旨：　ITRON C++ APIの標準化に際し、様々な意見が続出し、存在意義や要求が不透明になってしまったため、仕様に対して再度基礎検討が必要になった。方向性、要求事項、APIの提供方法など、多くの方の意見を聞きたい。背景：　ソフトウェア機器は年々大規模化しているのに対し、開発期間は逆に短縮化しているため、より効率の良い開発環境が必要である。オブジェクト指向プログラミングにより、ソフトウェアの部品化を容易にすることで幅広い場所で恩恵を受けられるため、C++に対する期待は大きい。　ITRONの今後の取り組みに対してC++/Java APIの標準化を要望する声が8.3%ある。 C++言語の特徴：　長所：　　オブジェクト指向言語　　　隠蔽　　　継承　　　ポリモーフィズム　　C の拡張　　　Cソースがそのまま使え、既存の資産を無駄にしない。　　　よくできたプリプロセッサとも言える。　　　(C++ は C に置換ができる) 　短所：　　オーバーヘッドが大きい。 C++言語機能とオーバーヘッド：　オーバヘッドの大きさ機能　-------------------------------------- 　なし　　　　　　　　　名前空間　　　　　　　　　　　　インライン展開　　　　　　　　　　　　オーバーロード　　　　　　　　　　　　オーバーライド　小　　　　　　　　　　クラス生成　　　　　　　　　　　　クラス派生　中　　　　　　　　　　仮想関数　　　　　　　　　　　　多重継承　大　　　　　　　　　　実行時型識別機構　　　　　　　　　　　　例外機構　予測不可能　　　　　　クラステンプレート　　　　　　　　　　　　関数テンプレート ※既存のC言語で記述されたカーネルとのバインドによりオーバヘッドを最小に　する。アタッチクラス：　既存C言語カーネルとのバインドする、オーバーヘッドは小さくするという方向でアタッチクラスというクラスを作った。クラス生成と関数のインライン展開を利用できる。実際には第一パラメータ(ID)の隠蔽化をしており、クラスインスタンスは既存カーネルオブジェクトIDへのポインタのような動作をする。すべてのクラスインスタンスは既存カーネルオブジェクトIDへ割り当てられ、同一IDに複数のインスタンスが存在したり、存在しないオブジェクトへアタッチすることもある。アタッチクラスの仕様案に対するコメント：　批判続出→ 　　C++の利点が生かされていない。　　コンストラクタとデストラクタの意義がない。　　継承しないC++クラス規定はC++APIでない。　オーバーヘッド最小というなら既存C言語カーネルがもっとも最小であるため、意味がない。よりC++言語らしい標準化が求められる。ネイティブクラス：　より多くのC++機能を使ってC++らしいAPIを目指したもので、クラス生成、関数のインライン展開、仮想関数、クラス派生、オーバーロード、オーバーライドを盛り込むことによって、タスクやハンドラは派生で作れ、生成子、消滅子が使える。インスタンスとカーネルオブジェクトは一対一に対応、生存期間が一致といった特徴がある。　また、エラーが発生すると呼び出される、より少ないオーバーヘッドで相当機能を実現可能なエラーハンドラを用意している。しかし、「C++ APIが本当に要るのか？」という意見が出された。なぜC++ APIが必要なのか(現状のITRON APIを再考)：　元からITRONはAPI経由でしかアクセスできないため、隠蔽化は十分できており、隠蔽化が目的ではない。オブジェクトを派生させずに、基本オブジェクトをメンバに持つ新クラスを定義すべきであるため、継承が目的ではない。記述する者はオブジェクトを特定しているはずなので、ポリモーフィズムが使いたいわけでもない。 C++API真の意義：　クラスライブラリ作成時の目安が欲しい。　→標準化しなくてもいいのではないか？最後に：　本当にC++APIが必要なのか、どういう形でC++ APIを提供すべきかが疑問である。たとえば、ITRONクラスライブラリコレクションサイトを作って、そのサイトでの標準基底カーネルAPIとする方法もある。comment@itron.gr.jp までコメントをお寄せ頂ければ幸いである。 [質疑応答] Q:　小規模システムにC++は使えないのではないか。大規模システムならLinuxをい　れてC++を使えば良いし、ITRONを入れてまでC++を使う意味はないのではないか。 A:　確かに意味がないかもしれないが、トロン協会のアンケートによるとプログラ　ミングにC++を使っている人がいるようだ。 A:　軽いノリで始まったのだが、批判がでたため、本格的に始めた。しかし、何を　作ればいいのか要望が聞こえてこない。 Q:　良いアプリケーションモデルのデモをやればいいのではないか。 A:　C++は良いことだと思う。Cが出てきたときには批判がでたが、結局アセンブラ　からCへ移ってきたように、いずれはC++にいくのかも知れない。ITRONは小さい方　向が多いから、C++の要求が出ないのだろう。C++の方がきれいに書けたり、リソー　スを使えるシステムも増えているだろうから、たたかれてもいいから、とりあえ　ず作ってみてはどうか。タスクの継承などはやってみたい。カーネルはCのままで　良いので、インタフェースだけC++、つまりラッパーでいいのではないか。 C:ウェブ上で討論の場などがあればいいのではないか。 Q:　C++やればITRONの問題の7割が解決するのならいいのではないか。 A:　ITRONの問題の上位4つの解決に向けては既に着手していて、その次に来るのが　C++である。この5つをあわせれば7割になるということで、C++自体の要求はそれ　ほど大きくない。 C:　ITRON単体でC++が疑問だという意見があったが、分散環境を考えれば意味があ　ると思う。 Q:　社内でITRON技術者が少ないからC++で書きたいという要求があるのではないか。 A:　それならラッパーでいいのではないか。 4A以上