検索
連載

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

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

Share
Tweet
LINE
Hatena

2.3.4 診断サービス(Diagnosticsスタック)

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

図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
図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を機能拡張しても、その上位レイヤーにつなげなければ、残念ながら意味はありません。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る