　T-Kernelのロードマップを図4に示す。ロードマップの中心となるのは、T-Kernelそのものである。ただし、T-Kernel自体の機能的なバージョンアップは予定されておらず、今後は品質向上や性能改善の作業のみとなる。T-Kernelの仕様は、ソフトウェアの互換性を保証するため固定されるのである。つまり、OSがバージョンアップしたために、まだ使えるはずのソフトウェアが改変を余儀なくされるようなことはT-Kernelでは起こらない。

図4　T-Kernelのロードマップ

　新たな展開は、現在のT-Kernelが対応していない分野に対して計画されている。まずは、16bit CPUやシングルチップ・マイコンなど資源の少ないシステムへ対応したμT-Kernel。そして、マルチプロセッサへの対応。この2つが大きな流れとなる。最終的には、T-Kernelはユビキタス・ネットワーキング環境の超小型センサーノードから、マルチプロセッサを使用した高機能な情報システムまで、幅広く対応していくことを目標としている。

　T-Kernelのロードマップの中で、現在開発が行われているμT-Kernelと、マルチプロセッサ対応T-Kernelについてもう少し詳しく説明したい。

μT-Kernel

　μT-Kernelは、8/16bit CPUやシングルチップ・マイコンなど、メモリ容量やCPUの処理能力に制約の大きい小規模な組み込みシステムを対象としている。

　T-Kernel自体、決して大きなOSではないが、それでもシングル・ソースコードにてさまざまなCPUに対応し、またサブセットを作らずすべての機能を実装しているため、前述のような小規模なシステムから見れば冗長な部分も存在する。

　μT-Kernelでは、T-Kernelとの互換性を考慮しつつも、OS全体の効率に影響を及ぼす要因が仕様から削られる。例えば、MMU対応機能などはμT-Kernelには存在しない。また、ソースコードもT-Kernelのようにシングルソースとして一元管理されることはない。これは、小規模なシステムではアセンブラの使用も含めた最適化が必要と考えられるからである。

　当然ながらμT-Kernelでは、T-Kernelにおけるソフトウェアの互換性は保証されない。標準化や互換性よりも、最適化や適応化を優先させたものがμT-Kernelだからである。もし、標準化や互換性を重視するのであればT-Kernelを使用すべきである。

　ただし、定められたガイドラインに従って作成されたμT-Kernel上のプログラムは、T-Kernel上でも動くことが考慮されている。デバイスドライバなども移植が容易である。

　μT-Kernelを使用することの利点の1つは、将来そのシステムがより高機能なハードウェアを用いるようになった際に、T-Kernelに容易に移行できることである。もう1つの利点は、シングルチップ・マイコンのシステムから大規模・高機能なシステムまで、同じアーキテクチャのOSを使用することにより、ソフト資産やノウハウを蓄積できることにある。

　これらの利点は、もし小規模システムにITRONを、大規模システムにLinuxを使っていた場合、同じことがいかに困難であるかを想像してみれば良いだろう。

マルチプロセッサ対応

　マルチプロセッサは、サーバやPCの分野ではすでに一般的であるが、組み込みシステムでも近年注目が集まってきている。その背景には、高機能化する組み込みシステムにおいてCPUに対する処理能力の要求が増大し、クロックアップでは限界が見えてきたことがある。また、1つのパッケージに複数のプロセッサコアを集積したマルチコアプロセッサの登場が、組み込みシステムでマルチプロセッサを使用することに現実味を帯びさせた。

　T-Kernelでは、「組み込みシステムに適したマルチプロセッサ対応リアルタイムOS」を目標に、対応に取り組んでいる。

　マルチプロセッサは、「非対称型マルチプロセッサ」（AMP）と「対称型マルチプロセッサ」（SMP）に分けることができる。

　AMPは、個々のプロセッサの役割分担が決まっている機能分散型のマルチプロセッサである。プロセッサごとにOSを含めて異なるプログラムが動作し、お互いに同期・通信して協調動作を行う。AMPは組み込みシステムでは比較的なじみが深い。例えば、携帯電話のベースバンドチップとアプリケーションプロセッサも一種のAMPの構成である。

　SMPは、各プロセッサが同等の立場で処理を分担する負荷分散型のマルチプロセッサである。1つのOSがプロセッサ間の処理の調停を行い、上位のプログラムからはマルチプロセッサが意識されることはない。つまり、アプリケーションを変更することなく、プロセッサを高速化する代わりにマルチプロセッサに置き換えることが可能となる。SMPはいままでサーバやPCにおいて主に使用されてきたが、今後は組み込みシステムでも使われていくと思われる。

　AMPとSMPはどちらが優れているというものではなく、用途に応じて使い分けられていくものである。T-Kernelでは、AMPとSMP双方に対応していく。

T-KernelのAMP対応

　AMPのシステムでは、T-Kernelは個々のプロセッサごとに独立して動作し、またプロセッサごとにタスクのスケジューリングが行われる。

　AMP対応のT-Kernelは、従来のT-Kernelとの互換性を重視し、ソフトウェア資産やノウハウの流用が容易であるよう設計されている。各プロセッサ間の同期・通信は、特別な同期・通信オブジェクトを設けるのではなく、従来のT-Kernelの機能を拡張して用いる。また機能拡張に当たって、従来のT-KernelとのAPIの互換性を可能な限り保持する方針で設計されている。

　例えば、あるタスクがセマフォを操作しようとした場合、そのセマフォが同一のプロセッサ上にあっても異なるプロセッサ上にあっても、同じシステムコールで操作できる。T-Kernelがシステムコールの操作対象を判断し、ほかのプロセッサ上であればプロセッサ間通信を行って操作を実現する。

図5　AMP対応T-Kernelの概念図。注：タスクAから同一プロセッサ上のセマフォAへのアクセスも、ほかのプロセッサ上のセマフォBへのアクセスも、同じシステムコールで実行できる

　注意しなくてはならないのは、タスクのスケジューリングがプロセッサごとに行われる点である。優先度やディスパッチ禁止による排他制御はプロセッサ間では無効となる。マルチプロセッサの環境では、排他制御はセマフォやイベントフラグなど同期オブジェクトを使用しなくてはならない。これさえ守っていれば、シングルプロセッサでもAMPでも区別なく動作するプログラムを作成することも可能であろう。

T-KernelのSMP対応

　SMPではアプリケーションからはOS、つまりT-Kernelは1つに見える。タスクなど各種オブジェクトは自動的にプロセッサに割り当てられ、マルチプロセッサを意識することはない。これがSMPの利点でもあるが、組み込みシステムにおいては、この単純なSMPのモデルはいくつかの問題点がある。

　まず、オブジェクトが自動的に割り当てられることにより、リアルタイム性がどこまで保証できるかが問題となる。高いリアルタイム性が要求される処理には、AMPのようにプロセッサを意識することが必要となってくる場合も考え得る。

　また、シングルプロセッサで開発されたプログラムを単純にSMPの環境に移行した場合、期待したパフォーマンスが得られない可能性もある。現在SMPに対応しているLinuxなどの情報系OSは、ラウンドロビン方式によるスケジューリングを基本としている。もともとタスク（プロセス）を平等に扱うこの方式は、SMPとは相性が良い。ただし、本稿の始めに述べたように、リアルタイム処理には向いているとはいえない。T-KernelなどのリアルタイムOSは絶対優先度によりスケジューリングを行っている。これを単純にSMPで動かすと次のような問題が生じる。

　例えば、本来の絶対優先度のスケジューリングでは優先度の高いタスクの動作中に、そのタスクより優先度の低いタスクが動くことはない。同一優先度のタスクであれば、各プロセッサで同時に動かすこともできるが、優先度の高いタスクが1つだけしか存在しない場合、いくらプロセッサが空いていても使えないことになる。

　このように組み込みシステムでSMPを使用するには、SMPでもプロセッサを意識したAMP的な手法の導入や、プログラムモデル自体の検討を行わなくてはならない。T-Kernelでは以上の点を踏まえて、組み込みシステムに適したSMP対応リアルタイムOSとして開発を行っていく。

　T-Kernelは一般公開より2年を経て、いまさまざまな製品で採用され成果を出し始めた。一般公開間近のT-Kernel/SEもすでに製品への採用検討や試作が行われている。

　さらに2006年は、μT-Kernelやマルチプロセッサ版T-Kernelといった新しい技術の発表も控えている。T-Kernelをすでに使われている人たちはもちろん、いままでT-Kernelに触れたことのなかった人たちも、ぜひ注目していただきたい。