AUTOSAR Adaptive Platformのメソドロジ：AUTOSARを使いこなす（9）（3/3 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第9回では、前回取り上げたAUTOSAR Adaptive Platformのアーキテクチャに続いてメソドロジについて説明する。

[櫻井剛，MONOist]

メソドロジ面でのCPとAPの比較

　APにおけるメソドロジは、コンセプトの観点からはCPにおけるものと基本的に同じです。つまり、おおよその流れは以下のようになります。

1. VFBレベルの論理インタフェースに基づきアプリケーションを開発
   • これは、意図的にECU内、ECU間のインタフェースの違いなど（※）を抽象化した状態で開発することにより、実際のハードウェア構成などが変わったとしても、アプリケーション自体には手を入れずに済ませることで再利用性を確保するためです
     （※）ECU間を接続する際に使用するCANやLIN、イーサネットなどの実際のネットワーク種別だけではなく、複数のECUへの分散配置を行うか否かなども含めて
2. 実際に使用するシステム構成を設計する
   （ECUとネットワークからなるトポロジーなどの物理アーキテクチャ）
3. 各ECUにアプリケーションを割り当てる
4. ECUごとにインテグレーション作業を行う

　しかし、CPでは、アプリケーションに関する変更（追加や削除を含む）があると、BSW（Basic Software）やRTE（Runtime Environment）を含む「全体」のインテグレーションをやり直すことが必要になります。言い換えると、変更箇所だけではなく変更前の全体像、それも、それぞれのアプリケーションだけではなく、BSWやRTE全体についても把握していないと、適切な再インテグレーションができない、と言うこともできます。これが、CPでのインテグレーションを難しくしている真の理由の1つです。

　そこで、APでは、インテグレーション面ではCPと異なるアプローチを採用しています。CPにおけるBSW間のインタフェースに相当するような、ECUの土台部分の内部インタフェースを、必要なものを除いては思い切ってプラットフォームベンダー固有のものとし、大部分がインテグレーション済みの状態でベンダーから提供されるものという前提にしています。

　もちろん、AUTOSAR規格文書による互換性確保の範囲は、APにおけるARA内部の構成要素間の詳細インタフェースには及ばない、ということになります。CPが当初目指したような、複数ベンダーからの土台部分の構成要素を組み合わせて使用するということは考慮されていないのです。しかし、現実にはCPでもインテグレーション済みのものをパッケージとして入手することの方が圧倒的に多いのが実情ですから、問題になることは少ないでしょう。

次回に続く

　次回は、特にリクエストがないようでしたら、2019年3月末のリリース内容（AP R19-03およびFO R1.5.1）についてご紹介していきたいと思います（次回の内容が変更になる可能性もございますが、ご容赦くださいませ）。