PR

アプリの都合にOSを合わせる新発想

 専用化されたシステムという特性を生かす観点からは,アプリケーションごとに専用のリアルタイムOSを用いるのが,ある意味で理想だといえよう。しかし開発コストを考えると,現実的ではない。そこで組み込みシステム向けのリアルタイムOSは,共通の特性を持ったアプリケーションをドメインとしてくくり,それを狙って開発されるのが通例である。

 一つのリアルタイムOSで,なるべく広範なアプリケーションをカバーするアプローチとして,構成可能な(configurable)OSがある。アプリケーションごとの要求にあわせて構成を変え,最適化できるOSのことである。どのようなOSでも,ある程度の構成変更はできるようになっている。しかしここで言う構成可能なOSとは,アプリケーションの特性をより積極的に活用し,オーバーヘッドの低減やメモリー使用量の削減を狙ったOSを指している。

 通常のOSの場合でも,カーネルに組み込む機能を選択したり,プロセステーブルの数といったパラメータを変更する仕組みを備えているが,仕様をアプリケーションの都合にあわせるとか,内部のアルゴリズムの最適化までは考えていない。

 例えば,優先度ベースのタスク・スケジューリングを選ぶ場合を考える。優先度が同じタスクがあるときに,実行可能になった順に処理するFCFS方式とラウンドロビン方式がある(第2回を参照)が,OS仕様を定める際には,どちらの方式にするかを決めなければならない。しかし,どちらが望ましいかはアプリケーションによって異なる。OSがどのようなアプリケーションに使われるかわからない段階では決めづらい。そこで構成可能なOSでは両方式のプログラムを用意しておき,アプリケーションが決まった時点で適切な方式を設計者に選ばせる。もちろん,両方式を動的に選べるようにする方法も考えられるが,オーバーヘッドやメモリー使用量が増加するのは避けられない。

 別の例を挙げると,スケジューリング処理で最も優先度の高いタスクを選ぶための最適なアルゴリズムは,タスクの数や優先度の段階数によって異なる。タスクの数が少ないなら,複雑なデータ構造を使うよりも,単純にサーチするほうが効率がよい。タスク数が多くても,優先度の段階数が少ないなら,優先度ごとにキューを持つ方法が効率的である。いずれにせよ,アプリケーションが決まらない段階でOSを実装するときには,どれを用いるか悩むところである。そこで,複数のアルゴリズムを実装しておいて,アプリケーションが決まった時点で,適切なほうをOSに組み込むアプローチが有力になる。

 構成可能なリアルタイムOSの例として,eCosを挙げることができる。eCosは米RedHat社が中心になって開発したオープンソースのリアルタイムOSである*。eCosのソースコードには,数多くの条件コンパイル指定(#ifdef)が含まれており,非常に細かい粒度でOSの構成を決定することができる。上に例で挙げた最も優先度の高いタスクを選ぶためのアルゴリズムも,コンパイル条件によって,複数のなかから一つを選べる。また,コンパイル条件を決めるためのGUIツールが用意されている。

構成可能OS,検証性に落とし穴

 このようにリアルタイムOSを構成可能にすることは,アプリケーションの特性に合致したOSを提供できるという点でメリットは大きいが,逆に落とし穴もある。それは検証性の問題である。

 ソースコード中に2種類の構成が可能なポイント(典型的には#ifdef)が2カ所あったとする。取り得る構成の数は4通りになる。2カ所の構成内容が独立でない限り,この4通りの構成すべてに対して動作テストを実施しなければならない。つまり構成できるポイントの数の増加に対して,検証コストは指数関数的に高くなる可能性がある。

 そもそも高い信頼性を要求される組み込みシステムでは,検証は開発コストの大きな部分を占めると言われている。例えば,ITRON仕様OSを開発するメーカーの技術者によると,開発コストの50~80%が検証にかかるという。そうすると検証の負担増は,開発コストの上昇に直結する。実際ITRON仕様OSの多くは,構成可能性を絞る方向で実装されている。

 先に紹介したeCosは,検証方法について興味深いアプローチを採る。eCosは,リアルタイムOSのソースコードを配付するのと同時に,テストスイートも配っている。テストスイートに含まれる各テスト・プログラムには,どのような構成のときに有効かが書いてある。リアルタイムOSの構成を決定したら,このテストスイートを用いてOSのテストを行うようになっている。つまり,天文学的な数になるすべての構成の組み合わせではなく,実際に構成を決めた後にターゲットを絞って検証するという立場をとっているわけである。

 とは言え,いろいろな構成でのテストをしなくてもよいわけではない。eCosの開発チームに聞いた話では,社内の空いているパソコンでランダムな構成を生成し,テストスイートを流しているということだった。

 まとめると,構成可能なOSは組み込みシステムには有力な方法だが,検証コストを考えずに,やみくもに構成できる要素を増やすと,メリットを失うおそれがある。ソースコード中に条件コンパイル指定を数多く入れると,保守性が下がることも忘れてはならない。


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

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