2.　OSの構成

　現在，使用されているRTOSには，ITRON，VxWorksをはじめとするスレッド系のものと，OS-9やQNXおよびWindowsやLinuxのようなプロセス系のものがある．

　組み込み分野では，プロセス系RTOSのシェアは今のところ数パーセントに過ぎず，ほとんどはスレッド系RTOSが使われている．

　にもかかわらず，新たに開発されるCPUはWindows CEを意識してか，MMUなどのプロセス系RTOS用の機能を搭載している．MMUを有効に利用することで，不当なメモリアクセスをハード的に検出できることから，ソフトに万一バグが含まれていた場合でも最悪の事態を回避することができるのだが，実際にはそれほど利用されてはいない．

　同様に，マルチステートも，たとえばアプリケーションからの特権命令の使用を禁止するなどしてシステムの安全性を確保する技術だが，実際は制御系アプリケーションではパフォーマンスの問題などもあり，シングルステートで使用されることが多い．

　LSIメーカーが提供するITRONの中には，マルチステートに対応したものもあるが，ディープエンベデッド指向のITRONでわざわざマルチステートにする必要はないように思う．マルチステートの場合，システムコールが関数呼び出しではなくトラップ機構を利用するので時間がかかる^注2．また，ライブラリリンクでシステムを構成できず専用のコンフィグレータが必要になる．

　OS-9（V.3より）をはじめとしてQNX，LynxOSなど，プロセス型RTOSのほとんどは，一つのプロセスの中で複数のスレッドを扱うことのできるマルチプロセス/マルチスレッドシステムになっている．このようにすることにより，プロセス型とスレッド型の良いとこ取りを狙っているわけだが，プロセス型RTOSは基本的にマルチステートなので，一般的に純粋なスレッド型RTOSほどのパフォーマンスは出ない．

　従来，組み込みサーバなどのマルチユーザー的なアプリケーション分野では，プロセス型RTOSが使用されてきた．共同で利用するサーバなどのアプリケーションでは，すべてのプログラムが協調して動作する必要はなく，むしろ一つ一つのセッションが独立していることが必要であり，このような場合にはメモリプロテクションが有効である．

　また，同一のプログラムを複数ロードして実行できることもプロセス型RTOSの利点であり，サーバ型アプリケーションに向いている．スレッド型RTOSの場合は，メモリ空間がスレッドごとに独立していないので完全なリエントラント構造にしなければならないが，プロセス型RTOSではその必要がない．

　サーバ分野では，ネットワークにリアルタイム性を保証しないTCP/IPが使われることがほとんどで，したがってOSにそれほどシビアなリアルタイム性を要求しても意味がないため，多少リアルタイム化されたWindowsやLinuxが検討されるケースが増えている．したがってプロセス型RTOSと，これらの組み込みWindowsやNT Embedded，組み込みUNIXなどは，サーバ分野で競合関係にある．

　カーナビなどの組み込み系情報機器で，複合機能を提供し，かつタイムクリティカルな要求を満たす必要がある場合，たとえばFMラジオとDVDとGPSの制御を行うような場合，各制御モジュール間の相互作用はほとんど必要とされないのでプロセス型のメリットが出る．

　また，これらの機器ではタイムクリティカルな要求があるので，Windows CEなどでは対応が難しく，プロセス型RTOSが使われることが多い．一般に，システム全体のコードサイズが数Mバイトになるようなアプリケーションでは，ハード的なプロテクション機構があったほうが信頼性は高まる．

　同様に，サイズはそれほど大きくなくともミッションクリティカルな機器，たとえば軍事とか航空，宇宙分野で使われる機器では，プロセス型RTOSが提供するメモリプロテクション機構は重要視されている．スレッド型のRTOSの中でも，軍事とか航空，宇宙分野でよく使われるVxWorksには，サードパーティからMMUモジュールが提供されている．また，Tornado-�Vからは，同様の機能が純正品としてサポートされるらしい．

　ハード的なメモリプロテクション機能を使用できないRTOSの場合には，ソフト的な作りこみによって安全性を確保する必要がある．昔，自動車のアンチロックブレーキシステムには，走行中に誤動作した場合を考慮して複数のCPUを使った多重系が使われていたが，最近はシングルCPUで構成されているということである．

　コストダウンが目的かもしれないが，それを可能にしたのは作り込みの技術が向上したからだろう．Javaのサンドボックスやカード用OSのインタプリタなど，ソフト的に安全性を確保することが民生品では主流になっていくのかもしれない．ハード的に不当なメモリアクセスだけを検出しても安全なわけではなく，インタプリタによってガードしたほうが，ソフト的なバグや攻撃には強いかもしれない．しかし，ハード的な誤動作には対応できない場合が多い．

　作り込みに関しては，オブジェクト指向をベースとした仕様抽出，さらにモデリングから自動コード生成，テスティングなどの一貫した方法論で対応することが提案^4）されている．これらの設計手法を用いた場合，並列処理の粒度が小さくなる傾向があり，タスク数が増えるのでプロセス型RTOSよりはスレッド型RTOSが向いている．プロセス型では，多数のタスクが密に協調して作業をするような設計ではパフォーマンスが出ない．

　余談だが，ラショナルソフトウェアによれば，同社の米国における売り上げの約4割は組み込み関連ということである．つまり，現在日本ではあまり使われていないが^注3，米国である程度の実績があることから，時間的制約をもった組み込みアプリケーションに対しても，これらのツール群が有効であると思われる．

　一時，マイクロカーネルが流行ったが，研究レベルのプロトタイプを除いてあまり実用にはならなかったようである．OSの機能アップをする際に，追加機能をOSプリミティブとしてカーネル内に実装していったのではカーネルが肥大化してしまい，いずれ機能の拡張や変更が不可能になる．

　マイクロカーネルは，これを回避するためにOSをマイクロカーネルとその上のOSサーバに分けて実装しようとしたものである．ChorusOSなど，いくつかの商用RTOSに採用されている．しかし，事例が少なくどの程度有効なのかの判断材料が乏しい．

　ChorusOS（図9）の場合，OSサーバとしては，いわゆるタスク間通信や同期機構などのシステムコールモジュールのほかに，スケジューラやメモリ管理，仮想記憶管理などがある．使用しないシステムコールモジュールをリンクしない方法はマイクロカーネルでなくとも可能だが，マイクロカーネルであればスケジューラなどの基本部分も選別できる．

　このほかにも，新しい考え方に基づくRTOSがいくつかある．たとえば，OSE（図10）というRTOSは，ダイレクトメッセージパッシングによるタスク間通信，同期を行い，メールボックスやセマフォを使わない．このことで，分散システムにおける移植性や透過性を向上させている．

　しかし，このようなモダンなカーネルがあっても，実際に使われているのはITRONやVxWorksなどの枯れた古典的なカーネルである．分散システムなどの応用が今まであまりなかったために，モダンな機能に対する需要がないこと，古典的RTOSでさえ使いこなすエンジニアが不足しているのに，さらに高度なRTOSは使えないと思われていること^注4などが考えられる．

　また，一般にモダンなRTOSはRAMの使用量が多いため，組み込みに向かない場合が多い．しかし，もっとも大きな理由は，実績を重視するためではないだろうか．どれだけ多くの製品で使われているかが，採用するときの大きな判断材料になる．同一のRTOSを使うことで，一種のコミュニティ^注5が形成される．コミュニティが大きいほうが，プログラミングのノウハウなどの蓄積も大きく，そして入手もしやすい．人手不足のときは，コミュニティから人材を調達できるという可能性もある．

　価格が重要と述べたが，コミュニティはより重要かもしれない．eCosは無料でダウンロードできるが，コミュニティが乏しいためそれほど利用されていない．Linuxなどは，実績よりもコミュニティが先行している感がある．コミュニティが存在すれば，実績のない分野でも評価対象となりうるのである．

　RTOSを選択するということは，自社の技術基盤をどこに求めるかにも関わる問題である．新し物好きで，人と違うことをしたがる行動パターンは，OSの選択ではあまり見られない．

10月号特集トップページへ戻る

Copyright 2000 藤倉　俊幸