仮想機能バスを用いたアプリケーションの開発検証 ―― 自動車業界に見る組み込みソフト開発効率化の取り組み（4）

　本コラムの第2回と第3回でAUTOSARの階層アーキテクチャや仮想機能バスについて解説しました．今回は，仮想機能バス上でアプリケーションがいかに構成されるか，階層アーキテクチャに変換されたあとシミュレーションで検証できるかを見ていきます．

●仮想機能バス上でのアプリケーション検証

　仮想機能バスを用いた開発では，ECU構成やネットワークなどを決める前にアプリケーションの検証が行えます．仮想機能バスは，階層アーキテクチャの中ではアプリケーション層と基本ソフトウェアの間にあるランタイム環境に相当します．

　仮想機能バス上での開発・検証は以下のステップで行います．

１） ソフトウェア・コンポーネントの配置結線

　アプリケーションは，通常複数のソフトウェア・コンポーネントにより構成されます．ソフトウェア・コンポーネントはXMLで提供されており，人手で直接扱うことはほぼ不可能です．従って，AUTOSARの規格に準拠したXML対応のソフトウェア開発ツールを用います．開発ツールにおいてソフトウェア・コンポーネントを配置し，コンポーネント間の接続を行います．仮想機能バスとはこのソフトウェア・コンポーネント間の接続のことを言います．

　図１はGeensys社のAUTOSAR準拠ソフトウェア開発ツール「AUTOSAR Builder」で，XMLのソフトウェア・コンポーネントをグラフィカルに表示して，配置配線している例です．

［図1］ XMLを使用したソフトウェア・コンポーネントのグラフィカルな表示

　コンポーネント間の通信については，AUTOSARインターフェースでは基本通信パターンとして以下の2種類をサポートします（図2）．

1. クライアント・サーバ型――クラアントが要求したサービスをサーバが提供する通信


2. センダ・レシーバ型――情報を送信するのみの通信

［図2］ AUTOSARインターフェースにおける2種類の通信パターン

　この段階で開発ツールの多くはコンフォーマンス（適合性）チェックの機能を持ち，ポートの使い方や使用するデータ・タイプ（変数の型など），AUTOSARもしくは自社のスタイル・ガイドラインの命名則の確認が行えます．単純な設計ミスはこの時点で修正されます．

2） RTEの生成（RTEコントラクト・フェーズ）

　次に配置，結線されたソフトウェア・コンポーネント群を実際に動かすために，ランタイム環境を開発ツールにより生成します（図3）．

［図3］ 仮想機能バスの階層アーキテクチャにおける表現

　RTEの生成とは，ソフトウェア・コンポーネント間の通信パターンやデータ・タイプなどを考慮しながら結線情報を生成することを言います．

　RTEの実体は，

1. ソフトウェア・コンポーネントそのものの動作記述――通常Cコードとしてコンポーネントの開発者が別途提供


2. XMLで書かれていたインターフェースをCコードに変換したもの――この変換は開発ツールが通常持つ機能

　の二つを仮想機能バス上で接続した構成のCプログラムです．

　また，OSやネットワークなどの階層アーキテクチャで，RTEより下位の基本ソフトウェアがない状態でRTEを生成することを，「RTEのコントラクト・フェーズ生成」と言います．

3） 仮想機能バス上のシミュレーション

　生成されたRTEとソフトウェア・コンポーネントはC言語のプログラムです．コンパイルし，実行形式に変換し，仮想機能バス・シミュレータを用いてシミュレーションすることが可能です．

　図4はGeensys社のAUTOSARシミュレータ「ASim」の画面です．この例では，実際のECUやネットワークなどの定義がない状態でそれぞれのソフトウェア・コンポーネントの動作を確認できます．

［図4］仮想機能バス・レベルのシミュレーションの例

　繰り返しになりますが，このRTEコントラクト・フェーズではどのECUを使うか，どのようなプロトコルのネットワーク（例えばFlexRay, CAN, LINなど）を使うかなどはまだ定義していません．この段階で全体の機能の動作確認ができることはAUTOSARの大きな利点です．

　次回は仮想機能バス上で開発，検証された設計がどのように複数のECU構成のシステムに展開されていくかを解説します．