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

● COM仕様のねらいはソフト部品の移植性を高めること

　上述したように，OSEK COMは内部通信，外部通信を含めた通信機能を一つの仕様として規定するため，アプリケーション設計者が通信相手との接続方法を意識する必要がありません．このことは，単に設計者が必要とする各種の調査を含めた設計期間を短縮するだけでなく，アプリケーションをほかの環境に移植する場合や接続方法を変更した場合の修正を低減させる効果もあります．

　図6（a）に示すように，COMがない場合はデータの送受信を行う際にタスク設計者がすべてを管理する必要があります．つまり，ほかのタスクと情報を交換したい場合，あらかじめ決めておいた手段に従い，情報を交換します．また，ほかのECUと情報を交換する場合も，そのECUとの接続状況を把握して，タスク設計者が個別に情報交換処理を設計する必要があります．このように，あらゆる情報交換において設計者がすべてのシステム構成を把握しておく必要があり，システム構成が変更された場合などは再設計しなければなりません．このことは，タスクの部品化を阻害するものであり，どんなにほかのタスクと疎結合（独立）になるような設計を行っても，通信相手との情報交換手段が密な開発であれば，単純に移植などできません．

図6　COMの有無によるアプリケーション開発の違い
（a）のCOMなしの場合，タスクA が直接CAN/LINドライバを操作し，タスクB ともなんらかの手段で情報を交換する．つまり，タスクAは，CANドライバ，LINドライバ，タスクBとの間で異なる情報交換手段を用いるため，個別の設計が必要となる．
一方，（b）の場合，タスクAはCANドライバ，LINドライバ，タスクB との通信はすべてCOMを経由する．COMには各種情報の通信手段が静的に指定されているため，識別情報で接続先を自動的に変更し，情報交換手段の差異をCOM内部で隠ぺいする．そのため，通信先を意識してタスクAを設計する必要はなく，それぞれに対して同一APIによる通信が可能となる．