ITRON（API）からT-Engine（インフラ）へ：組み込み向けリアルタイムOS最新動向（2/4 ページ）

ITRONの成功

　ITRONが成功したポイントはいくつかあるが、デザインの筋の良さやバランスなど、技術的なメリットに加えて、「誰でも自由に使える」「誰でも自由に作れる」という自由度の高さや大らかさが、非常に大きく貢献したと考えられる。

ITRONの「弱い標準化」

　ITRON仕様では、タスク管理や同期通信機能など、リアルタイムOSの基本機能に関するシステムコールの仕様（API：Application Program Interface）を標準化している。しかし、その実装方法、すなわちプログラムの中身は規定されていなかった。また、仕様の一部はガイドライン的な扱いになっており、機能のサブセット化もかなり自由に行うことができた。従って、設計の自由度が高く、適応化やチューニングの余地が大きいため、組み込み製品の開発者は、自分に都合の良いITRONを自ら開発して利用することができたのである。

　CPUなどの実行用ハードウェアに関しても、ITRONでは特に規定されていなかった。CPUのbit幅も8bitから32bitまでの自由度があり、デバイスドライバ、ミドルウェア、開発環境、ライブラリなどの周辺環境も標準化されなかった。このように、標準化の程度や範囲を広げず、必要最小限の標準化やガイドラインの提供のみ行うという方針は、「弱い標準化」と呼ばれ、TRONプロジェクトの基本的な考え方であった。

　これに加えて、ITRONではマシンの仮想化を行わず、ハードウェアの性能を最大限に引き出すという設計方針もうたっていた。現在よりもはるかに低性能な1980年代当時のマイクロコンピュータ上にリアルタイムOSを実装して実用的に動かすには、現実問題として「弱い標準化」を行うのが精いっぱいであった。

ライバルは「OSを利用しないシステム」

　「ハードウェアの性能を最大限に引き出そう」とは、いい方を換えると「標準化や仮想化によるオーバーヘッドを最小限にとどめよう」ということであり、OSの導入による標準化とは相反する方針である。にもかかわらず、このような主張でITRONのメリットを説明したのは、当時のITRONの最大のライバルが、決してほかのリアルタイムOSではなく、「OSを利用していない組み込みシステム」だったからである。

　ITRONの導入によるシステム構成の標準化により、ソフトウェアの互換性や保守性の向上というメリットが生まれるものの、OS導入によるオーバーヘッドはゼロではない。ソフトウェアの互換性や保守性の面でのメリットが、このオーバーヘッドによるデメリットを上回ると判断されない限り、ITRONは導入してもらえない。こういった観点からの説得材料としては、標準化による効果が十分でなくても、まずはオーバーヘッドが最小限であることを主張する必要があった。「弱い標準化」というITRONの基本方針は、これまでOSとは無縁の、ベタのプログラムで開発されていた組み込みシステムに対して、リアルタイムOSを使ってもらうための方便だったともいえる。

　ITRONの「弱い標準化」という方針が支持された背景として、組み込みシステム全体のソフトウェアの規模がまだ小さく、ソフトウェアの互換性が問題になるケースが少なかったという面もある。ITRONが生まれた1980年代当時の状況を考えると、ミドルウェアという言葉もまだポピュラーではなく、デバイスドライバは自分で開発するのが当たり前の時代である。これらの周辺機能が標準化されないことについて、それほどの違和感はなかった。TCP/IPはすでに存在していたが、TCP/IPを使うには数百万円以上のワークステーションが必要であり、組み込みシステムとTCP/IPはまだあまり縁がなかった。TCP/IPなどのミドルウェアが必要なかったり、デバイスドライバやミドルウェアも含めて自分で全部開発するのであれば、APIを標準仕様に合わせる必然性はない。

　ITRONが普及した時代は、ソフトウェアの重要性が叫ばれつつも、組み込みシステムの世界ではまだソフトウェア全体の規模が小さく、互換性の問題が深刻ではなかった時代であるともいえるのである。

　「弱い標準化」というITRONの基本方針は、前述のようにまずは性能面からの制約から来たものであったが、ミドルウェアの流通がそれほど重要ではなかった時代（1980年代から1990年代）においては、組み込みシステムの標準化の枠組みとしてバランスの良いものであった。特に、開発を担当する技術者にとっては、OSの制約に縛られる部分が少なく、自分の裁量で決められる部分が多いため、とっつきやすく、利用しやすいものであったのではないかと思われる。若干観念的な議論になってしまうが、必要以上に設計の自由度を奪うことは、開発者のやる気という面ではマイナスであり、開発者の工夫やアイデアの余地を残すことも重要であろう。ITRONの場合、「弱い標準化」という方針をアピールすることによって、かなり自由に開発できるような雰囲気を残したことは、ITRONの普及に大きく貢献したのではないかと考えられる。