車載アプリケーション・ソフトウェアの移植性を高める通信仕様とその実装　――下位層を意識せずECU間のインターフェイスを実現する「OSEK COM」

2.TOPPERS/OSEKカーネル対応の OSEK COM

　本来，OSEK COM仕様は，OSEK OSの環境下で動作することを想定して策定されています．しかし，アプリケーション開発者はかならずしもOSとCOMの両方の機能を求めているわけではなく，どちらか一方のみを利用したい（あるいはどちらか一方を選択せざるをえない）というケースもあります．

　このような状況の場合，車両制御以外のソフトウェア開発ではOSを使用せず汎用の通信モジュールを利用するというよりも，OSを利用して専用の通信モジュールを新たに開発するというケースが多いように筆者は感じます．

　しかし，車両制御ソフトウェアの開発では，かならずしもOSのほうが通信モジュールよりも多く選択されるとは断定でません．事実，自動車ではOSを利用しないシステムが大半を占めているわりには^注4，通信モジュールであるCOMを使用したいというケースが多くあります．これは，ECUのハードウェア・リソース条件が厳しく，OSと通信モジュールの両方の利用が難しいことと，ECU間の通信機能が必須であるためだと考えられます．

　1台の車には非常に多くのECUが搭載されて高度な機能を実現しています．しかし，それらのECUは異なるメーカから提供されたものであり，たとえ同じ通信規格を用いていても，通信異常時の処理などの細部の仕様は各社各様であり，ECU間の接続の検証は困難を極めています．そのため，厳密な通信規則を守って通信処理を実現するには，統一された仕様が必須となります．このような疎結合のマルチプロセッサ・システム^注5には，通信処理はある意味，制御の要であると言えます．そのため，車両制御ソフトウェアにおいてOSを利用せずにCOMを利用するケースがあると考えられます．

　このような理由から，TOPPERS/OSEKカーネル対応のOSEK COMの実装は，基本的にOSEK OS環境下で動作しますが，OSを利用しない場合の実装も視野に入れています．

 注4；ボディ系ECUの多くはOSを使っていない．制御系ECUにおいても，比較的大きな制御システムを除いて，現状はOSを使用していない．  注5；プロセッサごとにOSが存在し，複数のプロセッサが独立して動作するシステム．