AUTOSAR CP入門（その5）続・BSWが提供するサービスの利用＋AUTOSARは銀の弾丸ではない!?：AUTOSARを使いこなす（28）（3/4 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第28回は、「AUTOSAR CP入門」のその5として、前回に続き「BSWが提供するサービスの利用」について取り上げる。

[櫻井剛，MONOist]

3．SW-Cとその他の要素（RTE、BSW、HW）とのインテグレーション

　これまでは、SW-CやRTE、BSWといった、「ソフトウェアによる機能の実現方法」を中心に説明してまいりました。

　ここからは、上流設計情報のソフトウェアの各要素とハードウェアをインテグレーションし、最終的にECUに仕上げるまでのワークフロー面についてみていきます。

　R19-11になるまではmethodology面でのAPとCPの統合は行われていませんでしたが、R19-11において各ECUをAP／CPのどちらで実現するかを決める前の先行workflowが定義されました（VFB＋Concept、図4）。

図4　AUTOSAR Methodology CP／AP共通部分［クリックで拡大］ 出所：AUTOSAR R21-11 TPS Abstract Platform

　CPで実現することとなったシステム部分については、おおよそ図5のように開発が進められます。

図5　AUTOSAR CP Methodology Overview［クリックで拡大］ 出所：AUTOSAR CP TR Methodology

　CP ECUのインテグレーションの前段階では、以下が行われます 。

• BSW開発：基本機能ブロック群としてのBSWの開発
• SW論理アーキテクチャ定義：クルマ全体（あるいはクルマの外まで含めて）のソフトウェアアーキテクチャの定義。まずはSW-C間のインタフェースから。各ECUへの機能配置をまだ考えなくてよい（なので、「論理アーキテクチャ」）
• 車両システム定義：クルマ全体のE/Eシステムの物理アーキテクチャと、各ECUへの機能割り当て
• SW振る舞い実装：インタフェースで区切られた（boundされた）各SW-Cの振る舞いを実装

　インテグレーションのインプットは、前段階での成果物、つまり、以下となります。

• BSW Package
• ECU Extract：E/Eシステム設計情報のうち、各ECU開発に必要な情報だけを抜き出したもの
• SW-C：Software Component Description（SWCD）、関連ソースコード実装および（忘れられがちですが）後工程となるインテグレーション作業への各種指示および引継ぎ事項の情報伝達

　インテグレーション作業（図6）では、ECU ExtractやSWCDなどのAUTOSAR XMLで記述された上流設計情報によって、RTEやBSWの設定項目のうち自動設定可能な部分が設定されます。さらに、インテグレーターが残りの部分を設定し、コード生成、ビルドして実行する、という流れです

図6　AUTOSAR CP Methodology - ECU Software Integration［クリックで拡大］ 出所：AUTOSAR CP TR Methodology

　ただし、現実はそう甘くなく、上流設計情報の修正依頼をはじめとして幾度もの繰り返しが発生します（表現次第で印象がだいぶ変わりますが、イテレーションあるいは手戻りとも表現されます）。

　なお、今回の想定はあくまで「SW-C開発者」の作業の範囲です。SW-C開発者としては、前述の「SW-C：Software Component Description（SWCD）、関連ソースコード実装および忘れられがちですが）後工程となるインテグレーション作業への各種指示および引継ぎ事項の情報伝達」がアウトプットになること、そして、後工程（インテグレーション）ではおおよそどのようなことが行われるかについて、おおよその理解をお持ちになれれば、ひとまずは何とかなるでしょう。

　ただし、その後に発生する、インテグレーターとの間でのやりとりでは、さまざまな問題／課題に対して、インテグレーターやその他関係者と協力しながら取り組んでいくことが必要になります。ソフトウェア実装だけではなく「ソフトウェア実装以外の側面も含めた各種情報提供やすり合わせ」が発生する可能性がありますが、「これだけやっておけば十分」という情報をここで網羅的にご紹介することは残念ながら到底できません（本が1冊書けるボリュームになります）。実際、筆者のトレーニング資料の中でも、ごく一般的な内容だけでも、40ページ以上を費やしています。責任分担の境界など、状況が少し変わるだけでも、必要とされることを大きく左右する要因はたくさんあります。ですが、責任分担などの「左右する要因」が決まれば決まるほど、どのような課題が出てくるのかについての見通しは立ちやすくなります（境界の決め方次第では、各種意思決定が下流の開発現場で行われるため負担が大きくなったり、上流工程での見逃しや誤りに対する解決責任が押し付けられたりしてしまうような可能性も十分にありますが）。