PR
図1  μITRON4.0がもつ静的APIの記述例<BR>オブジェクトの静的生成に必要な情報を記述するための記法を標準化した。
図1 μITRON4.0がもつ静的APIの記述例<BR>オブジェクトの静的生成に必要な情報を記述するための記法を標準化した。
[画像のクリックで拡大表示]
図2  自動車用リアルタイムOS「OSEK/VDX」の静的APIの記述例&lt;BR&gt;OSEK/VDXでは,静的APIをOIL(OSEK Implementation Language)と呼んでいる。
図2 自動車用リアルタイムOS「OSEK/VDX」の静的APIの記述例<BR>OSEK/VDXでは,静的APIをOIL(OSEK Implementation Language)と呼んでいる。
[画像のクリックで拡大表示]

 いよいよ最終回である。筆者が考える「これぞリアルタイムOSの真髄」をテーマに取り上げたい。リアルタイムOS(RTOS)の特徴について,リアルタイム性を実現する観点からは第2回で解説した。今回は,専用システム向けという観点に立って考える。

 連載の初回で組み込みシステム技術とは,(1)専用化されたシステムであるという特性を生かしながら,(2)リソースの制約が厳しい,(3)高い信頼性が必要,(4)リアルタイム性が求められる,といった制約を満たすためのものだと位置付けた。このことは,リアルタイムOS技術にもあてはまる。以下では,特定のアプリケーションに専用化されたシステムを実現するときに,リアルタイムOSにどのような工夫を施すことができるかを示したい。

専用システムだからこそ可能に

 タスクやセマフォなど,OSの管理する各種のオブジェクトを必要に応じて動的に生成/削除するのではなく,あらかじめ静的に(システム設計時に)生成しておくアプローチがある。このアプローチで作られたOSを「静的OS」と呼ぶ。静的OSという用語は学会や業界で定着している訳ではないが,ある論文で使われているのを数年前に発見した(英語の論文なのでStatic OSだった)。ピッタリくる用語だったので,それ以来,筆者も使わせてもらっている。

 通常のOSで,アプリケーションの用いるタスクやセマフォを生成する処理は,システム起動後の初期化時に実行される。具体的には,制御ブロックの初期化や,それらに必要なメモリーの割り付けが,初期化処理(ブート処理)のなかで動的に行われる。その結果,システムの初期化処理にそれなりの時間がかかることになる。

 専用システムでは,どんなタスクをいくつ使うか,どんなセマフォをいくつ用いるかといった情報は,設計時に決まっていることが多い。それなら,初期化時に時間をかけて動的に生成する必要はない。制御ブロックの初期状態や必要なメモリーの割り付けを,設計時に決めてしまえばよい。そのほうが,システムに必要なメモリー容量(特にRAM容量)を小さくできるし,初期化処理の時間は確実に短くなる。制約の厳しい組み込みシステムにとって,願ったりかなったりだ。

 実際,Linuxを用いた組み込みシステムでは,システム初期化処理の時間をどう短縮するかが重要な課題となっている。筆者の持っているハードディスク・レコーダは,起動に結構時間がかかり,ユーザーとして気になっている。Linuxを用いた携帯電話では,システム初期化後のメモリー・イメージをファイルに保存するといった工夫をしていると聞いたことがある。

μITRON4.0で導入した静的API

 もちろん,制御ブロックの初期状態やメモリー割り付けを手作業で行うのは面倒である。できるだけツール化して,設計者の手間を省きたい。例えば,組み込みシステム設計者がどんなタスクやセマフォを用いるかを記述しておけば,ツールはそれを読み込んで,制御ブロックの生成やメモリーの割り付けを自動的に行うといった仕組みが望ましい。

 μITRON4.0仕様では,オブジェクトの静的な生成に必要な情報を記述するための記法を標準化している。これを静的APIと呼ぶ。静的APIは,μITRON4.0仕様で初めて導入した概念であり,それ以前のμITRON仕様には存在しない。そのため4.0以前は,タスクを初期化するための情報をC言語の構造体の形で記述させるなど,静的APIに対応する機能を実装ごとに決めていた。

 (図1[拡大表示])に静的APIの記述例を示した。最初の行は,ID番号がMAIN_TASKのタスクの生成を表している。具体的には,タスク属性をTA_ ACT,拡張情報を0,タスクのメイン関数をmain_task,初期優先度を10とし,8192バイトのスタック領域を割り付けている(最後のNULLがツールにスタック領域を割り付けさせることを意味する)。さらに,2行目でID番号がVAR1_ LOCKのセマフォを生成し,3行目でハンドラ番号がTIMER_INTNOの割り込みハンドラを定義する。

 こうした記述を読み込んだツールは,必要な初期値を入れたタスクとセマフォの管理ブロックや,割り込みハンドラを設定するための情報を,カーネル構成ファイルに生成する。通常はC言語のソースコードの形をとる。また,生成するタスクやセマフォにID番号を割り付け,MAIN_TASKやVAR1_LOCKといったシンボルにID番号を定義する記述を生成する。例えば,“#define MAIN_TASK (1)”といった記述である。μITRON4.0仕様では,このツールをコンフィギュレータと呼んでいる。

 ちなみにμITRON4.0仕様では,オブジェクトを動的に生成するサービスコールも定義しているが*1,名称やパラメータを静的APIと整合がとれるようにした。これは,静的APIとサービスコールを別個に覚えなくてもよいようにするためである。例えば,タスクを生成するサービスコール「cre_tsk」を用意する。生成するタスクのID番号を第1パラメータ,生成するタスクの情報を入れた構造体へのポインタを第2パラメータにした。図1と比べてもらえば,整合性をとっていることを理解いただけるだろう。

 なお連載の第3回で紹介した,自動車用のリアルタイムOS「OSEK/VDX」は,完全な静的OSの仕様となっている。オブジェクトは静的にしか生成できない。μITRON4.0仕様の静的APIに対応する記法をOIL(OSEK Implementation Language),コンフィギュレータに対応するツールをSG(System Generator)と呼んでいる。(図2[拡大表示])にOILの記述例を示す。

高田 広章 Takada Hiroaki/名古屋大学大学院情報科学研究科 情報システム学専攻

東京大学の坂村健教授の研究室に在籍中からITRONプロジェクトに参画し,ITRON仕様のリアルタイムOSの開発と普及に務める。その後,豊橋技術科学大学を経て,現在は名古屋大学に在籍。研究テーマは,当初のリアルタイムOSから,徐々に組み込みシステム設計開発技術一般に広げている。最近では,ソフトとハードの境界分野に最も興味を持っている。自動車メーカとの共同研究を数年にわたって継続しており,組み込みシステムの適用分野の中では,自動車の制御システムが一番詳しい。