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

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

[櫻井剛，MONOist]

2.3.4 診断サービス（Diagnosticsスタック）

　Diagnosticsスタックも多数のBSWモジュールと関連しますが、主要なものは以下の通りです（図2）。

図2　AUTOSAR CP Diagnostics Stack［クリックで拡大］

• Dcm：診断テスターとの間のClient/Server通信（Protocol：ISO 14229-1 UDS、ISO 15031-5 OBD）。開発時のECU内部状態の読み出し、ECUの生産、製造日や製造番号などの書き込み、各種テストの自動化、自動車メーカーへの納入後のECUのvariant設定、整備でのECU故障有無や交換要否の判断、ソフトウェアのアップデート、輸送モードの有効化／無効化などに使用
• Dem：ECU内部で検出された異常のフィルタリング（debounce）、診断イベントとしての判定、記録、その際の車両／動作状態を含む情報の保持、必要に応じての、車外（診断テスターなど）からの読み出し（テスターからの読み出し要求を受け付けたDcmから、Demに対して情報提供を要求することで実現）
• FiM：Diagnostic Eventの状態とSW-C動作を連動させるメカニズム

　診断テスターからの診断リクエストをECUが受けたとき、Dcmで処理を完結できる部分についてはDcm内で処理します。しかし、完結できない場合には、Dcmから、Service Portを経由して^※6）、SW-CのREが、ClientServerInterface（C/S）のServer側としてtriggerされます（第26回でご紹介した、RTE Eventの1つであるOperationInvokedEvent（OI）を生成）。

　診断リクエスト内に、サービスIDに続いてデータが送られてくる場合（例：SID 0x2E WriteDataByIdentifier）には、RE（Operation“WriteData”相当）に引数で引き渡されたポインタが指すデータ領域に、その内容が格納されています。診断レスポンスを返す場合にデータを設定しなければならない場合（例：SID 0x22 ReadDataByIdentifier）も同様で、RE（Operation“ReadData”相当）の引数で渡されたポインタが指すデータ領域にレスポンス内容を書き込みます。

　また、ECU内部の異常は、BSWやSW-Cで検出し、Demに通知します。BSW単独で検出できるような異常（例：CANバスオフ）については、検出元のBSWからDemに直接通知が行われ、基本的にSW-Cは関与しません。SW-CからDemへの通知には、Operation“SetEventStatus”が使われます。

※6）Service PortのClient側がDcmとなりますので、Server側がSW-Cとなります。当然ながら両者の対応付け（Portの接続／mapping）は必要ですが、これもSW-C開発者ではなくインテグレーターの作業範囲になります。

2.3.5 その他

　I/O制御は、Complex Driver（CDD）で行われることも多いのですが、Service Port経由で、I/O Hardware Abstraction^※7）を通じてMicrocontroller Abstraction Layer（MCAL）の各種ドライバ群を利用する場合もあります。図3に示す通り、MCALはソフトウェアアーキテクチャの最下層にあり、ハードウェアを抽象化します^※8）。

図3　AUTOSAR CP Software Architecture［クリックで拡大］

　セキュリティに関しては、CsmやKeyMの各種サービス（例：鍵管理など）を利用しますが、これもService Portを利用するという点ではこれまで説明した内容と変わりません。

　また、動作モード管理や、Global Time Synchronizationなども同様です。Csm、EcuM、BswMやStbMなどの機能を使用するSW-Cは一部でしょうから、各operationについては皆さんご自身で調べてみてください（調べ方のヒント：前回の「2.3.2 動作監視（Watchdogスタック）」）。

※7）I/O Hardware Abstractionには正式な略称はありません（IoHwAbやIoHwなどと略されているようです）。また、CP SWS I/O Hardware Abstractionのchap．1に記載の通り、モジュール内部のふるまいまで標準化しておらず、あくまでごくごく基本的なガイドラインのみが示されています。

※8）「AUTOSARで規定されたドライバ群の機能（例：Dio: DIO Driver（GPIO制御））、Adc：ADC Driver（A-D入力）、Pwm：PWM Driver（PWM出力）、Icu：ICU Driver（Input Capture Unitによるエッジ発生回数／間隔およびパルス幅測定）以外の、ハードウェア独自のI/O関連のさまざまな機能や改良」を使用するためには、I/O Hardware Abstractionを拡張するか、CDD内で個別に対応することが必要になります。いくらHWやMCALを機能拡張しても、その上位レイヤーにつなげなければ、残念ながら意味はありません。