ホーム > T-Engineプロジェクトの新たな展開

T-Engineプロジェクトの新たな展開

～ T-Kernel 2.0のリリースと「T2」に向けて～

坂村健

T-Kernelの開発の狙いと実績

T-Kernelの開発を始めたのは、今からちょうど10年ほど前、2000年ごろのことである。当時は、自動車のエンジン制御にITRONを搭載した例が公表されるなど、ITRONの実績が一般にも知られ始めたころであり、デジタルカメラなどのAV機器やコピー複合機などのOA機器にもITRONの採用例が増えていた。ITRONは、この時点でほぼ成熟した技術となっており、研究開発期から普及期に進むところであった。

ITRONはリアルタイム制御用のOSである。コンパクトでかつ性能を高めるため機能を絞りデザインされている。通常はファイル管理やデバイス管理などの機能は必要とされない。しかし、応用の進化とともにこれらの機能をメーカーが独自に追加するケースがいくつか出始めていた。標準化された機能ではないため、ソフトウェアの互換性や再利用性の点で難があり、開発効率を高めにくいことが課題とされていた。

製品の高機能化が進行するに従い、ファイルやネットワークへの対応が不可欠になるとともに、ソフトウェアの開発効率が重要な問題になっていた。高機能マイクロプロセッサの登場とともに情報処理用のOSも検討された。たとえばその頃から普及の始まったLinux。しかしファイル、ネットワークといった機能は利用しやすく、開発効率も高められるものの、高性能なリアルタイム制御ができず、メモリなどのハードウェア資源の消費も大きいという問題があった。高機能な組込み機器のOSとしては、ITRONとLinuxのメリットを合わせ持つようなOSが必要で、そういう試みも多数行われた。

こういった背景から開発されたOSがT-Kernelであり、そのねらいは、高性能なリアルタイム制御とLinuxやWindows並みの高度な情報処理との両立である。T-Kernelでは、ITRONのリアルタイム制御機能をそのまま活かしつつも、サブシステムの機能を導入してOSの拡張性を高め、それを利用して、ファイル管理やプロセス管理の機能を提供する基本ミドルウェア（T-Kernel Standard Extension）を開発した。T-Kernelを搭載した組込み機器では、T-Kernel自身による高性能なリアルタイム制御に加えて、T-Kernel Standard Extensionがいわゆる情報系OSの機能を提供し、LinuxやWindows並みの高度な情報処理を行うことができる。このようなシステム設計により、機能と性能の両方を求められるハイエンドの組込み機器の需要に応えようとしたのがT-Kernelである。

実際、T-Kernelはカーナビ、プリンタ、業務用ハンディ端末など、高度な情報処理を必要とするインテリジェントな組込み機器への採用が進み、当初の基本設計の妥当性が実証されている。組込み機器のインテリジェント化は今後もますます進むと予想され、高性能なリアルタイム制御と高度な情報処理との両立が可能なT-Kernelは、今後も従来以上に多くの機器に搭載されていくであろう。また、T-Kernelの開発から10年近くが経過し、この間にはデバイスドライバやミドルウェアなど、T-Kernel上のソフトウェア資産も増えている。こういった状況から、T-Kernelの基本設計やソフトウェア構成は今後とも不変であるし、OSの基本的な仕様も変わることはない。

時代の要請に応じて用途を広げるT-Kernel 2.0

しかし、T-Kernelの設計当時と現在を比較すると、プロセッサの高性能化や高機能化、高集積化、メモリやディスクの大容量をはじめ、組込み機器のハードウェアやOSの動作環境は大きく変化している。また、T-Kernelの採用製品や開発事例などからの経験をフィードバックする形で、細かい機能追加や標準化の範囲の拡大などの要望も出ている。こういった状況を反映しつつ、T-Kernelの基本部分はそのままに、より使いやすく、高性能化されたハードウェアを活かすOSへとバージョンアップしたものがT-Kernel 2.0である。

T-Kernel 2.0では、マイクロ秒単位での時間制御機能（周期ハンドラやアラームハンドラ、タイムアウトなど）、および64ビットの大容量デバイスへの対応機能などが追加される。いずれも、従来のT-Kernel（T-Kernel 1.0）に対しては上位互換となる追加機能である。その一方で、T-Kernel 1.0との互換性維持のほか、これらの追加機能が不要な用途も少なくないため、T-Kernel 1.0のシステムコールはすべてそのまま残る。たとえば、T-Kernel 1.0にはミリ秒単位で時間を制御するシステムコールや、32ビットでデバイス入出力操作を行うシステムコールがあるが、これらのシステムコールはそのまま残した上で、マイクロ秒単位で時間を制御したり、64ビットでデバイスの入出力操作を行ったりするシステムコールが追加される。このため、T-Kernel 1.0に対しては、バイナリ互換かつソース互換となり、T-Kernel 1.0用の既存のデバイスドライバ、ミドルウェア、アプリケーションなどは、すべて再コンパイル不要でそのまま実行できる。

上記の追加機能のうち、64ビットの大容量デバイスへの対応の要求については、説明の必要もないだろう。ハードディスクなどの記憶容量はますます大容量化が進んでおり、テラバイト程度の容量になると、ブロック番号（セクタ番号）を32ビットで表現することができなくなる。一方、マイクロ秒単位での時間制御機能については、細かい時間の指定が必要なFA用の制御装置、プログラマブルコントローラ（PLC）などに用途がある。このような需要は、まだ多いわけではないが、一部の用途では切実な要求になっている。

ちなみに、T-Kernel 1.0で指定可能な1ミリ秒（msec）というのは、毎分6000回転（6000rpm）のエンジンやモーターであれば、36度だけ回転する時間である。これが1マイクロ秒（μsec）になると、この1000分の1、すなわち0.036度だけ回転する時間である。機械の制御という意味では、これだけ細かい分解能が必要な場面はまだ多くない。とはいえ、エンジンやモーターを制御する場合、1ミリ秒に対する36度単位の制御では粗すぎる可能性がある。1マイクロ秒の分解能は必要ないとしても、3.6度の回転角に相当する100マイクロ秒単位での制御は必要な可能性があり、その場合はT-Kernel 2.0の追加機能が有効である。

一方、たとえば通信関係を見ると、100Mビット/秒のネットワークであれば1ミリ秒あたり100Kビット（10Kバイト）、1マイクロ秒あたりでも100ビット（10バイト）のデータの転送が可能であり、この程度の時間粒度で制御を行いたいケースは、今後増えてくる可能性がある。また、最近の高性能なマイクロプロセッサを使えば、T-Kernelのシステムコールやタスク切り替え（ディスパッチ）の処理時間が1マイクロ秒未満となる場合もある。そうなると、たとえばタスクを生成して、いくつかのシステムコールの実行を含む何らかの処理を行ってから終了したとしても、全部で100マイクロ秒以下の時間ですんでしまう。このような処理が複数存在し、時間を見ながらそれらを効率よく制御しようとすれば、ミリ秒の単位では粗すぎる場合が出てくる。

T-Kernel 2.0の追加機能の詳細については、別稿をご覧いただきたい。

図1　T-Kernelロードマップ

すぐに使えるワンストップサービスの提供

T-Kernel 2.0では、カーネル本体の強化に加えて、その周辺の「お膳立て」に相当する部分についても、大幅な追加や改善を行う。具体的には、オープンソースとして公開するソフトウェアの範囲の拡大とワンパッケージ化を行い、使いやすさを向上する。

T-Kernel本体のソースは従来から公開していたが、T-Kernelの利用に不可欠なT-Monitor注1）については、ハードウェアへの依存性が強いという理由により、仕様のみを公開し、実装（プログラム）は提供していなかった。また、デバイスドライバの一部や開発環境についても、サンプル的に提供しているものはあったものの、T-Kernel用としての正式な提供ではなく、T-Kernelを使うためには別途自分で開発環境を入手したり、デバイスドライバを開発したりする必要があった。

T-Kernel 2.0のリリース時には、この点について大幅に改善し、開発に必要なすべてのソフトウェアをまとめて提供する。すなわち、T-Kernel、T-Monitor、デバイスドライバ、開発環境を1つのパッケージの中にすべて含めてしまい、Linuxのディストリビューションのように、このパッケージをダウンロードするだけでT-Kernelのソフトウェア開発を始められるようにする。これをワンストップサービスと呼ぶ。

このうち、T-Monitorやデバイスドライバはハードウェア依存であるし、T-Kernelの一部にもCPUやハードウェアに依存する部分がある。そこで、これらのハードウェア依存部は、技術情報の公開が可能な特定のボード（T-Engineリファレンスボードと呼ぶ）を対象としたプログラムとし、そのボードやCPUのハードウェア情報もプログラムと合わせて公開する。T-Kernelを機器に組み込むメーカーの立場から見ると、移植元となるハードウェアの技術情報と、そのボード上で動くプログラムが公開されているので、移植元と移植先のハードウェア技術情報を比較し、両者の差分に相当するプログラムの移植や修正を行えばよい。

T-Engineリファレンスボードは、T-Engineフォーラムで当面1種類を提供するほか、今後の追加を予定している。T-Engineリファレンスボードの要件として重要な点は、T-Kernel 2.0やそれ用のデバイスドライバが動作すること、および関連する技術情報が公開できることであり、標準T-EngineボードやμT-Engineボードのような、基板サイズやコネクタ位置に関しては規定しない。

パッケージに含めて公開する開発環境は、従来と同じくgccベースのものであるが、コンパイラやリンカ、デバッガ（gdb）に加えて、GUIベースの統合開発環境「Eclipse」や、PC上で動作するシミュレータも合わせて提供し、従来よりもはるかに利便性の高いものとする。

このほか、T-Kernelの仕様書についても大幅な改善を行う。従来は、印刷を想定したPDF形式による仕様書の提供を行っていたが、T-Kernel 2.0では、仕様の電子的な利用に配慮し、XML形式の仕様書を電子的なドキュメントとして提供する。XML形式の電子的な仕様書は、HTML形式に変換して必要箇所をブラウザで閲覧できるほか、印刷向けのPDF形式、UNIXのmanコマンド用の形式、開発環境上でシステムコールを入力する際のヘルプとして使える形式など、必要に応じて形式を変換することができ、仕様書自体の再利用性が高まる。

さらに、T-Kernelのバージョンや改変などの履歴を系統的に管理できるように、ソースコードにucodeを付与し、ソースコードのトレーサビリティシステムを導入する。本システムにより、万一のバグの発生に対しても、その影響範囲の把握が容易になり、迅速な対応が可能となる。

T-Enigneの第二ステージ「T2」に向けて

T-Engineプロジェクトは、まもなく10年を迎えるにあたり、その内容を大幅に刷新し、さらなる使いやすさの向上や用途の拡大を目指す。これを「T2」と呼んでおり、その詳細をTRONSHOW2011で発表した。「T2」の最初の成果がT-Kernel 2.0とワンストップサービスであるが、その後もT-Kernel Standard Extensionの強化やミドルウェアの充実など、さらなるステップアップを予定している。

第2ステージの「T2」に向けてT-Engineプロジェクト第2章が今始まったのである。

図2　T-Kernelファミリ