AUTOSARの仮想機能バス―― 自動車業界に見る組み込みソフト開発効率化の取り組み（3）

　連載第3回目はこれまでに説明したアーキテクチャのソフトウェアがどうやって現実のECU構成やプロトコルで実現されるか，およびその核となる仮想機能バス（VFB：Virtual Function Bus）について説明します．

●仮想機能バスで複数ECUを制御する

　AUTOSARは，前回までに説明したようにソフトウェアを階層に分けたアーキテクチャを持ちます．そして，それぞれを標準化したインターフェースでつなぐことにより，その中のソフトウェアのポータビリティ（移植性）を向上させていました．実際にはECUが一つということはないので，ソフトウェアを階層に分けても車への実装は図1のようになります．

［図1］ 複数ECUへの実装（赤線はデータのやり取り）

　このままでは，機能をどのECUに割り当てるのかを開発者が考える必要があります．AUTOSARでは，複数ECUのソフトウェア開発に対して「仮想機能バス」という考え方を導入して，生産性と品質を上げています．仮想機能バスは，車全体のソフトウェア・コンポーネントの内部接続を提供し，いわば車が一つのマイコンで制御されているような環境を仮想的に作ります．

［図2］ 仮想機能バス（VFB）上のソフトウェア・コンポーネント（SW-C)

　図2は仮想機能バス上にソフトウェア・コンポーネントを実装した図です．この実装では，下位のECUのハードウェアやネットワーク・プロトコルを使用するかなど，意識する必要がなく，いわゆるテクノロジに依存しない抽象的な接続表現となっています．この段階で市販の仮想機能バス・シミュレータなどを使って機能を実現し，検証が行えるので，早い段階ソフトウェア・コンポーネント間の接続や動作確認を行えることがAUTOSARの利点の一つとなっています．

　なお，ソフトウェア・コンポーネントはXMLで記述されています^注．

注；XMLで記述されるのは骨格部分のみで，実際の動作はCコードなどで提供される.

●現実のソフトウェア構成への変換

　仮想機能バス上で所定の動作が確認されたら，その仮想機能バス上に実装したソフトウェア・コンポーネントに対して，実際のECUの構成や個数，プロトコルなどの情報を加えて，現実のソフトウェア構成へと変換します．ここで与える情報にはECU記述とシステム制約があります（図3）．これらは先ほどのソフトウェア・コンポーネントと同じようににXMLで記述されています．

　ECU記述とシステム制約の内容は以下の通りです．

• ECU記述――プロセッサの仕様や周辺機能の種類，メモリなどのリソース，入出力の種類，アクチュエータなどのECU固有のデータを記述する．ECU記述は，使用するECUの種類だけ存在する．
• システム制約――プロトコル（LIN，CAN，FlexRay）や，ECUがどのように接続されているかを示すトポロジ情報などが記述される．

［図3］ ソフトウェア・コンポーネント（SW-C)の複数ECUへの展開

　ECU記述とシステム制約の情報を基にソフトウェア・コンポーネントを現実の複数のECUへマッピングし，実際の車載ソフトウェアを構築していきます．マッピングでは，必要とする機能のパラメータ類を設定し，最終的にターゲットとなる複数のECUに機能を割り当てていきます．
　
　これまで見てきたように関連ファイルはXMLで記述されています．これらの工程の処理を人手で行うのは不可能に近く，開発ツール・ベンダから提供される各種ツールを使います．

　なお，AUTOSARにはそのメソドロジ（方法論）を定義したドキュメントも用意されており，各社のツールはそれに従う形で作られています．