新機能プレビュー
ここが変わった！T-Kernel 2.0
T-Engineフォーラム
組込みプラットフォーム部会
T-Kernel 2.0 ワーキンググループ
着実な実績を築いたT-Kernel
2002年のT-Engineプロジェクトとともに誕生したT-Kernelは、それまで20年以上の実績を持つITRONをベースとしながらも、大規模な組込み向けソフトウェアの開発効率を大幅に高めることに成功し、数多くの製品に採用されてきた。高機能な組込み機器の制御用リアルタイムOSの分野において、T-Kernel は一定の地位を築いてきたと言えよう。
制御系も情報系も得意なOS
ITRONと比較すると、T-Kernelにはデバイス管理機能やサブシステム管理機能が追加されており、デバイスドライバやミドルウェアの互換性、再利用性が高まっている。さらに、これらの機能を利用して、Linuxなどの情報系OSと同様のプロセスベースのプログラムも実行できるようになっている。
プロセスベースのメリットは、プログラム間のメモリ保護機能により、開発効率が大幅に向上することである。プロセスベースは複雑で高度な情報処理に向いているほか、Linuxとの親和性が高く、Linux用のプログラムも移植しやすい。一方、リアルタイム性を要する制御用のプログラムでは、プロセスベースではなく、T-Kernelを直接使うことによって、リアルタイムOS本来の高速な処理が実現できる。
T-Kernelの大きな特長は、このように、リアルタイム処理を高速に行う制御系OSの性格と、複雑で高度な情報処理を行う情報系OSの性格を合わせ持つことである。そして、この点は昨今の高機能な組込み機器のニーズにも合致している。
たとえば最近のデジタルカメラでは、画像解析による顔やシーンの認識といった複雑で高度な情報処理と、オートフォーカスや手ブレ補正のようなリアルタイム性の高い制御処理の両方を、いずれも効率良く実行する必要がある。ここでLinuxを使うと、画像解析のプログラムは開発しやすいかもしれないが、リアルタイム性の高い制御は難しい。T-Kernelであればどちらの処理も得意であるし、画像解析のプログラムはLinux上で開発したものを移植してもよい。
プリンタやカーナビなど他の組込み機器でも、複雑で高度な情報処理とリアルタイム制御の両方が必要なものが増えている。こうした製品にT-Kernelの採用が多いことは、T-Kernelの開発当初からのねらいどおりであり、T-Kernelの基本的な設計方針やソフトウェア構成、システムコールの仕様、そして実装に至るまでの妥当性を実証するものである。
「100年ソフト」の第二ステージへ
T-Engineプロジェクトでは、T-Kernelを中心としたソフトウェアの強固なインフラを「100年ソフト」と表現し、長期間使い続けることを宣言してきた。その考えは今でもまったく変わらない。従来のT-Kernelのソフトウェア構成や仕様は、堅持していく所存である。
しかしT-Kernelの誕生から8年が経過しており、この間の半導体技術やデバイス技術の進歩による高性能化や高機能化、あるいは大容量化にともなう情勢の変化は極めて大きい。このため、一部の機能や処理対象となるデータの範囲について、追加を行うべき部分が出てきた。
そのような要求を取り入れて、初代のT-Kernel（T-Kernel 1.0）の仕様をバージョンアップし、新しいリアルタイムカーネルの仕様として登場するのが「T-Kernel 2.0」である。T-Engineプロジェクトは、T-Kernel 2.0によって第二ステージへの新たな展開を図る。
T-Kernel 2.0の追加機能
それでは、T-Kernel 2.0で新たに追加される機能を、大きく4つに分けて説明しよう。
1. タイマ関連機能の大幅な強化
T-Kernelはリアルタイム制御用のOSであり、時刻や時間に依存した処理を行う機能は重要である。このため、従来のT-Kernelでも、アプリケーションで定義した処理プログラムを指定の時刻に動作させる周期ハンドラやアラームハンドラの機能、指定の時間だけタスクが待つ機能、待ち解除までの時間の上限値を指定するタイムアウトの機能など、時間を制御する豊富な機能が用意されている。
しかし、T-Kernel 1.0のこれらの機能では、時刻や時間の指定の単位がミリ秒（1000分の1秒）であり、それより短い時間を直接指定することはできない注1）。これは、1980年代の中頃に初代ITRONが開発されて以来の仕様である。その後何度かITRONがバージョンアップされた際にも、互換性の観点から、ミリ秒を単位とする仕様がそのまま引き継がれており、T-Kernel 1.0でもこの点は変わっていない。
一方、最近のハイエンドのマイクロコンピュータを見ると、高性能化が著しく、CPUクロックが数百MHzから1GHzを超えるものもある。これらのマイクロコンピュータでITRONやT-Kernelのシステムコールを実行した場合、条件にもよるが、その実行時間やタスクのディスパッチ（切り替え）の時間は1マイクロ秒（100万分の1秒）未満で済むことも珍しくない。1マイクロ秒は1ミリ秒の1000分の1。すなわち、CPUやOSとしては、1ミリ秒よりもはるかに細かい時間の単位で動ける性能があるにもかかわらず、OSを使う際のシステムコールの仕様としては、それをフルに活かせない状況になっていた。
この課題を解決するために、T-Kernel 2.0では2つの機能を追加する。1つは時間管理に関連した各種の機能に対して、マイクロ秒単位の指定が可能なシステムコールを追加することであり、もう1つは物理タイマ機能を新規に追加することである。
マイクロ秒単位の処理ができるAPIの導入
T-Kernelの扱うデータサイズ（整数を表すINT型のサイズ）は32ビットが基本であり、T-Kernel 1.0における周期処理間隔や相対時間の指定、あるいはタイムアウト時間の指定も、INT型と同じ32ビットを使っている（データタイプRELTIM型、TMO型）。
32ビット符号付き整数でミリ秒単位の時間を表した場合、2の31乗が約20億であるから、20億ミリ秒（＝200万秒）を日数に換算し、最大で約24日間の時間を表現できる。これは、通常の用途における周期処理間隔やタイムアウト時間の指定範囲としては、ほぼ十分だろう。
しかし、同じ32ビットのままで時間の単位をマイクロ秒とすると、表現可能な時間の範囲はミリ秒単位の場合の1000分の1、すなわち、たった35分間になってしまう。こうなると、1時間待つような処理も1つのAPI 注2） では実現できなくなり、通常の利用でも支障が生じる。
そこで、T-Kernel 2.0では64ビットのデータタイプを導入することにより、これを解決する。64ビットあれば、マイクロ秒単位としても、35分間×（2の32乗）の時間を指定でき、表現可能な時間の範囲に関する問題は完全に解消する。
古くからC言語に関わっていると、整数といえば16ビットあるいは32ビットであり、64ビットを構造体ではなく1つの整数として扱えることを意外に感じるかもしれない。しかし、64ビットのデータタイプであるlong long型は、C言語の規格（C99）として正式に仕様化されてからすでに10年以上が経過しており、コンパイラなどの利用環境も十分に整っている。gccをはじめ、T-Kernelで通常利用するコンパイラで64ビット整数が使えないケースはほぼなくなっているため、T-Kernel 2.0も、64ビットのデータタイプを積極的に利用することにした。その代表的な用途がマイクロ秒単位の時間指定である。
T-Kernel 2.0では、64ビットやマイクロ秒に関連して、リスト1のようなデータタイプを追加する。なお、マイクロ秒（μsec）を意味するものは最後に“_u”（uはμの意味）または“_U”が付き、それ以外の64ビット整数を意味するものは最後に“_d”（dはdouble integerの意味）または“_D”が付く。
| リスト1 T-Kernel 2.0で追加される主なデータタイプ |
|
typedef signed long long D; /* 符号付き64ビット整数 */ |
|
typedef long long VD /* 型が一定しない 64ビットのデータ */ |
|
typedef volatile D _D; /* volatile 宣言付 */ |
|
typedef D TMO_U; /* 64ビットでマイクロ秒単位のタイムアウト */ |
このように、T-Kernel 2.0ではマイクロ秒単位の指定が可能になるが、64ビットマイクロ秒指定が不要な用途も少なくないことや、T-Kernel 1.0との互換性の観点から、T-Kernel 1.0で使用されていた32ビットミリ秒単位のAPIはすべてそのまま残す。
結局、T-Kernel 2.0では、64ビットマイクロ秒単位の指定をするAPIを、別の名称で追加したことになる。具体的には、T-Kernel 1.0のAPIの名称の後ろに“_u”（uはμの意味）を付けることにより、64ビットマイクロ秒単位のAPIであることを表す。また、64ビットマイクロ秒単位となった引数については、引数（パラメータ）の名称の後ろにも“_u”を付ける。
たとえば、アラームハンドラの動作開始を示すAPIの場合、T-Kernel 1.0のtk_sta_alm()に対して、T-Kernel 2.0ではtk_sta_alm_u()が追加される（表1、図1）。
| 「アラームハンドラの動作開始」を行うAPI | |
|
T-Kernel 1.0 |
tk_sta_alm( ID almid, RELTIM almtim ); |
|
T-Kernel 2.0 |
tk_sta_alm( ID almid, RELTIM almtim ); |
図1 マイクロ秒単位の時間を指定するアラームハンドラ
64ビットマイクロ秒単位の指定が可能になるのは、周期ハンドラやアラームハンドラなどの時間管理機能における時間指定のほか、タスク遅延（tk_dly_tsk()）での待ち時間指定や、待ちに入るAPIにおけるタイムアウト指定である。また、時間情報を含むタスク状態やハンドラ状態の参照機能においては、64ビットマイクロ秒単位の情報を返すAPIが追加される。T-Kernel 2.0において、マイクロ秒単位の処理を行うために追加されるAPIの一覧を表2に示す。
| 64ビットマイクロ秒単位のタイムアイト指定を行うAPI | |
|
tk_slp_tsk_u tk_wai_tev_u tk_wai_sem_u tk_wai_flg_u tk_rcv_mbx_u tk_loc_mtx_u tk_snd_mbf_u tk_rcv_mbf_u tk_cal_por_u tk_acp_por_u tk_get_mpf_u tk_get_mpl_u tk_rea_dev_du tk_wri_dev_du tk_wai_dev_u MLockTmo_u |
自タスクを起床待ち状態へ移行 タスクイベント待ち セマフォ資源獲得 イベントフラグ待ち メールボックスから受信 ミューテックスのロック メッセージバッファへ送信 メッセージバッファから受信 ランデブポートに対するランデブの呼出し ランデブポートに対するランデブ受付 固定長メモリブロック獲得 可変長メモリブロック獲得 デバイスの読込み開始 デバイスの書込み開始 デバイスの要求完了待ち 高速マルチロックのロック操作 |
| 64ビットマイクロ秒単位の時間指定（タイムアウト以外）を行うAPI | |
|
tk_chg_slt_u |
タスクスライスタイム変更 |
|
tk_set_tim_u |
システム時刻設定 |
| 64ビットマイクロ秒単位の時間情報の取得を行うAPI | |
| tk_inf_tsk_u tk_ref_tsk_u |
タスク統計情報参照 タスク状態参照 |
| tk_get_tim_u tk_get_otm_u tk_ref_cyc_u tk_ref_alm_u |
システム時刻参照 システム稼働時間参照 周期ハンドラ状態参照 アラームハンドラ状態参照 |
| td_ref_tsk_u td_inf_tsk_u td_get_tim_u td_get_otm_u td_ref_cyc_u td_ref_alm_u |
タスク状態参照（デバッグ専用機能） タスク統計情報参照（デバッグ専用機能） システム時刻参照（デバッグ専用機能） システム稼働時間参照（デバッグ専用機能） 周期ハンドラ状態参照（デバッグ専用機能） アラームハンドラ状態参照（デバッグ専用機能） |
なお、周期ハンドラやアラームハンドラの起動、タイムアウトの時間経過による待ち状態の解除など、T-Kernelにおける時間に依存した処理は、一定周期で動作するシステムタイマの割込み処理の中で行われる。このため、マイクロ秒で指定した時間が経過しても、次にシステムタイマの割込みが発生するまでは実際の処理が行われず、周期ハンドラやアラームハンドラも起動されない。すなわち、システムタイマの割込み間隔が、T-Kernelにおける時間関連の処理の実際の時間分解能になっている。タイマ割込み間隔は、システム構成情報（SYSCONFファイルなどで定義）の中で設定され、そのデフォルト値はT-Kernel 1.0でもT-Kernel 2.0でも10ミリ秒である。この設定を短く、たとえば100マイクロ秒にすれば、100マイクロ秒の時間分解能での動作が可能になる。ただし、タイマ割込み間隔が短くなると、タイマ割込みによるシステムのオーバーヘッドが増大することに注意してほしい。
物理タイマ機能の追加
前述の機能は、OSとしての純粋な機能強化によって、従来よりも細かい時間の指定を可能にするものである。一方、別のアプローチとして、機能や数が豊富になったハードウェアタイマ等の物理的な資源をうまく活かすことにより、時間関係の機能を強化する方法もある。これが、T-Kernel 2.0で追加される物理タイマ機能である。
最近の高機能なマイクロコンピュータでは、周辺の入出力デバイスの多くもワンチップ化され、いわゆるSoC（System on Chip）化が進んでいる。ワンチップ化された機能の中には、独立して動作できる複数個（10個以上の場合もある）のハードウェアタイマが含まれている場合が多く、このうちの1個をT-Kernelのシステムタイマとして使うとしても、残りの複数個のタイマはユーザが自由に利用できる。
そこでT-Kernel 2.0では、これらのハードウェアタイマの設定やカウント値の取得、指定時間経過時に起動される割込みハンドラの定義などを行うAPIを標準化して、「物理タイマ機能」と呼ぶ新規の追加機能を提供する。この機能によって、SoCの持つハードウェアタイマを操作するプログラムの開発効率や移植性の向上を目指す。
T-Kernelのユーザから見た場合の物理タイマの動作は、一定の時間間隔で0から1つずつカウント値が単調増加していくハードウェアのカウンタである。カウント値が、物理タイマごとに指定された特定の値（上限値）に達すると、物理タイマごとに指定されたハンドラ（物理タイマハンドラ）を起動するとともに、カウント値が0に戻る。複数の物理タイマが利用できる場合、それらはすべて独立して動作し、1、2、‥‥という物理タイマ番号で区別される（図2）。物理タイマ機能のAPIの一覧を表3に示す。
図2 複数の物理タイマによる複数のハンドラの起動
| StartPhysicalTimer StopPhysicalTimer GetPhysicalTimerCount DefinePhysicalTimerHandler GetPhysicalTimerConfig |
物理タイマの動作開始 物理タイマの動作停止 物理タイマのカウント値取得 物理タイマハンドラ定義 物理タイマのコンフィグレーション情報取得 |
物理タイマや物理タイマハンドラの動作は、一見すると周期ハンドラやアラームハンドラに似ており、機能面でもオーバーラップがある。しかし、物理タイマ機能はT-Kernelのシステムタイマとは独立して動作するため、システムタイマの割込み間隔の影響を受けず、オーバーヘッドを最小限にできるというメリットがある。物理タイマの場合、システムタイマの割込み間隔とは無関係の中途半端な時間を指定しても、ほぼ正確に処理できるし、ハンドラの起動までに余分なタイマ割込みを発生させる必要もない。一方、周期ハンドラやアラームハンドラを使う場合、ハンドラの起動時刻を正確なものとするには、システムタイマの割込み間隔を十分に小さい値に設定する必要があり、タイマ割込みによるオーバーヘッドが増大する。
逆に、周期ハンドラやアラームハンドラのほうが良い点としては、定義可能なハンドラの個数に制約がなく、自由度が高いことである。すなわち、1つのシステムタイマのみを使って、時間に関連した複数の機能（周期ハンドラやアラームハンドラの起動、タイムアウトなど）を同時に実現できるようになっており、その部分はT-Kernelの内部のプログラムできちんと処理している。これに対して、物理タイマ機能の場合は、1つのタイマについて同時に1つの要求しか処理できない。たとえば、3,500マイクロ秒後に物理タイマハンドラAの起動を行う要求と、2,800マイクロ秒後に物理タイマハンドラBの起動を行う要求があった場合、この2つの要求を素直に処理するには、2つの物理タイマを使う必要がある。物理タイマ機能は、ハードウェアタイマの機能をほぼそのまま提供するという点で、抽象度の低い機能であり、それが「物理タイマ（Physical Timer）」という名称の由来にもなっている。ただ、多数のハードウェアタイマが使えるSoCであれば、1つの物理タイマが同時に複数の要求を処理できないことは問題にならないし、抽象度が低いことはオーバーヘッドが小さいというメリットにもつながる。
結局のところ、アラームハンドラや周期ハンドラと物理タイマハンドラでは、上記のような点で特性が異なっている。そのため、ハードウェア構成やアプリケーションに応じて適切なほうを利用できるのがよく、T-Kernel 2.0では、機能面のオーバーラップを承知で両方の機能を導入している。
2. 大容量デバイスへの対応
従来のT-Kernelは32ビットのOSであり、システム時刻など一部のデータに64ビットを使う部分はあるものの、APIの引数やOSの処理するデータの大部分は32ビットである。
しかし、最近の組込み機器の高速化や大容量化の情勢から、32ビットでは現実的に不足の見られる部分が出てきた。そのひとつは、前項で説明したように、時刻や時間の指定をマイクロ秒単位で行う場合である。もうひとつは、ハードディスクなどの大容量デバイスを扱う場合である。
T-Kernel 1.0のAPIは、すべてのデバイスのブロック数を32ビット符号付き整数で表現している。ハードディスクも同様であり、そのブロック数（セクタ数）の最大値は、2の31乗マイナス1で、約20億である。したがって、T-Kernel 1.0の扱えるハードディスク容量の最大値は、1セクタが512バイトの場合、512バイト×20億セクタで約1Tバイトとなる。
つまり、T-Kernel 1.0のデバイス管理のAPIを使って大容量のハードディスクを扱おうとした場合、1Tバイトを超える部分については、直接にはアクセスできないことになる。だが、現在でもPC用のハードディスクであれば1Tバイトを超えるものが珍しくなく、今後は組込み用途でも1Tバイト以上のハードディスクを使うケースが増えてくるだろう。
そこでT-Kernel 2.0では、デバイス管理のAPIの引数の一部にも64ビットのデータタイプを導入した。具体的には、デバイスからの読み込みやデバイスへの書き込みを行うtk_rea_dev()とtk_wri_dev()において、読み込み開始位置や書き込み開始位置（ハードディスクの場合はセクタ番号）を指定するstartの引数を64ビットにした（図3）。
図3 大容量ハードディスクへの書き込み
ただし、大容量デバイス対応が不要な用途やT-Kernel 1.0との互換性を考慮して、T-Kernel 1.0の32ビット用のAPIはそのまま残し、64ビットの指定が可能なAPIを別の名称で追加した。この方針は、マイクロ秒単位の時間指定と同じである。
追加したAPIは、T-Kernel 1.0のAPI名称の後ろに“_d”（dはdouble integerの意味）を付けて区別する。引数（パラメータ）の名称も、64ビットになったものには後ろに“_d”を付ける。startはstart_dとなる。
たとえば、デバイスへの書き込みを行うAPIの場合、T-Kernel 1.0のtk_wri_dev()に対して、T-Kernel 2.0ではtk_wri_dev_du()が追加される（表4）。これは、タイムアウト指定が64ビットマイクロ秒単位になったことを示す“_u”と、書き込み開始位置の指定が64ビットデータになったことを示す“_d”の両方の意味が重なったものである。
| 「デバイスの書込み開始」を行うAPI | |
|
T-Kernel1.0 |
tk_wri_dev（ID dd、INT start、VP buf、INT size、TMO tmout） |
|
T-Kernel2.0 |
tk_wri_dev（ID dd、W start、VP buf、W size、TMO tmout） |
なお、T-Kernel 1.0でINT型だったstartとsizeの引数は、データサイズの明確化のため、T-Kernel 2.0ではW型に変更しているが、INT型もW型も32ビットであり、実質的な仕様の変更はない。
デバイス管理機能の場合、実際にデバイスとの入出力を行うプログラムは、T-Kernel本体には含まれず、デバイスドライバとして別途提供されたり、ユーザが自分で開発する形となる。そのため、64ビットに対応したデバイス入出力の処理を実際に行うには、T-Kernel本体を2.0にバージョンアップするのに加えて、デバイスドライバも64ビット対応版に更新する必要がある。T-Kernelのデバイス管理機能からデバイスドライバに対して入出力要求を送る際の要求パケットについても、T-Kernel 1.0で使用していた32ビット版（T_DEVREQ型）に加えて、64ビット版（T_DEVREQ_D型）の要求パケットが追加される。
ところで、T-Kernel 2.0のデバイス管理機能では、開始位置の指定を64ビットとしたが、読み込みや書き込みを行うデータのサイズ（ブロック数）については32ビットのままである。また、入出力バッファのアドレスの指定なども、一般のポインタ型と同じく32ビットである。一度に入出力を行うデータの量が32ビットで表現できるサイズ（具体的には2Gバイト）を超えることは想定していない。これは、現時点ではまだメモリアドレス空間が32ビットであり、T-Kernelの他の機能はもちろん、ライブラリや開発環境、他のミドルウェアなどにおいても、2Gバイトを超えるサイズのデータを一度に扱うことが現実的ではないためである。T-Kernel 2.0における大容量デバイス対応の意味は、大容量ハードディスクのすべての領域（セクタ番号が2の31乗を超える部分も含めて）にアクセスできるようになった、ということである。
3. システム管理プログラムの互換性強化
T-Kernel 2.0は、キャッシュ制御やMMU（Memory Management Unit）によるメモリアクセス権の設定など、システム全体の制御や管理を行う機能についても、いくつかのAPIを追加した（表5）。これらのAPIは、一般のアプリケーションから使う機会は少ないと考えられるが、システム全体の管理を行うプログラムやデバッグ用のプログラムなどで利用することを想定している。
| GetSpaceInfo SetMemoryAccess SetCacheMode ControlCache |
アドレス空間の各種情報の取得 メモリアクセス権の設定 キャッシュモードの設定 キャッシュの制御 |
キャッシュやMMUに対しては、T-Kernel 1.0でもOS側で適切な設定を行っており、これらの機能が使えないわけではなかった。また、キャッシュ制御などのAPIを、実装依存の仕様として導入している場合もあった。すなわち、従来でも個別の対応はできていた機能である。しかし、T-Kernel 2.0ではシステム管理プログラムなどの互換性をさらに高めるために、これらの機能に関連したAPIについても標準仕様に含めることにした。
4. ユーティリティ機能の追加
T-Kernel上のデバイスドライバ、ミドルウェア、アプリケーションなどを開発する際によく用いられるユーティリティ的な機能の一部を、T-Kernel 2.0の仕様に追加する。これは、標準化の範囲の拡大による開発効率や互換性の向上を目指したものである。
追加するのは、高速ロック・高速マルチロックと呼ばれる排他制御用の機能である（表6）。セマフォなど従来のオブジェクトを使った排他制御と比較して、待ちに入らない場合の処理が高速化される。
| CreateLock DeleteLock Lock Unlock |
高速ロックの生成 高速ロックの削除 高速ロックのロック操作 高速ロックのロック解除操作 |
|
CreateMLock |
高速マルチロックの生成 高速マルチロックの削除 高速マルチロックのロック操作 高速マルチロックのロック操作（タイムアウト指定） 高速マルチロックのロック操作（マイクロ秒のタイムアウト指定） 高速マルチロックのロック解除操作 |
この機能は、従来のT-Kernelでもライブラリとして提供されていた場合が多く、これを使ったデバイスドライバやミドルウェアがすでに開発されている。T-Kernel 2.0では、従来からライブラリとして提供されていた機能を、T-Kernel本体の仕様に取り込んだ形である。
T-Kernel 1.0の上位互換
T-Kernel 2.0の仕様は、T-Kernel 1.0の仕様に対して上位互換性を確保している。そのため、これまでのT-Kernelの実績を活かしつつ、機能強化されたカーネルへの移行をスムーズに進めることができる。さらに、ソース互換のみならず、バイナリ互換も可能である。
たとえば、T-Kernel 1.0をT-Kernel 2.0にバージョンアップした場合でも、T-Kernel上で動いていたデバイスドライバやミドルウェア、アプリケーション等は、再コンパイル不要でそのまま動く。
ただし、T-Kernel 1.0を搭載した既存の組込み機器に対して、途中でわざわざT-Kernel 2.0に変更することを推奨しているわけではない。マイクロ秒単位の時間の指定や大容量デバイスへの対応が必要なければ、従来のT-Kernel 1.0を使い続けても、特に不都合はない。
一般には、新規案件の開発の際、あるいは既存の組込み機器のCPUやハードウェアの更新を行う際に、さらに将来のことを見通しつつT-Kernel 2.0を搭載する、といった使い方になろう。しばらくの間は、T-Kernel 1.0を搭載した従来の機器とT-Kernel 2.0を搭載した新しい機器が混在し、今後数年以上の時間をかけて、後者の割合が次第に増えていくものと考えている。
T-Engineプロジェクトの新しい展開
ここまで、T-Kernel 2.0の技術的な概要や追加機能について説明した。繰り返しになるが、T-Kernel 2.0はT-Kernel 1.0の8年間の実績の上に成り立つOSであり、プロジェクト当初から主張していた「100年ソフト」のコンセプトを守りつつ、組込み機器の高性能化、高機能化、大容量化に配慮して機能を追加したものである。従来のT-Kernelに対しては上位互換性を維持しているので、これまでのユーザも安心してT-Kernel 2.0を使っていただきたい。
T-Kernel 2.0では、OS本体の技術面の強化に加えて、電子的な利用を考慮したXML版の仕様書の提供や、ucodeを使ったトレーサビリティ機能付きの配布ライセンスなど、使いやすさの向上を目的とした新しい取り組みも進んでいる。
さらに、T-Engineプロジェクト全体としては、T-Kernel 2.0の動作するリファレンスボードの開発や、T-Kernel周辺のソフトウェアも含めてT-Engineフォーラムから一括提供するワンストップサービスなど、T-Kernelの利用促進に向けた新しい活動を進めている。
T-Kernel 2.0と合わせて、これらのサービスについてもぜひご活用いただき、今後とも組込み機器の開発にT-Kernelをご利用いただければ幸いである。
注1）ただし、これはタスクの切り替えやOSの処理の進行がミリ秒単位になるという意味ではない。タスクの切り替えやシステムコールの実行を含むOSの処理は、ミリ秒もマイクロ秒も関係なく、CPUの性能を最大限に発揮してリアルタイムに実行される。ITRONやT-Kernel 1.0においても、たとえばハードウェアのタイマを自分で操作してマイクロ秒単位の割込みをかけ、その割込みハンドラの中で処理を行えば、ミリ秒単位という制約とは関係なく、時間に依存した処理を行える。ただ、そのような処理を個別のユーザが行うのは繁雑であるし、標準化や互換性の点からも望ましくないため、T-Kernel 2.0ではタイマ関連機能を大幅に強化することにした。
注2）「API」とは“Application Program Interface”の略であり、ここでは「システムコール」とほぼ同義で使用している。ただし、T-Kernel/SMの一部にはマクロやライブラリで提供される機能があり、これらの機能を呼び出すための関数は、厳密にはシステムコールと呼んでいない。そのため、T-Kernelの各機能を呼び出す関数仕様の総称としては、「システムコール」よりも広い意味で「API」を用いている。
