AUTOSAR Adaptive Platformのアーキテクチャ：AUTOSARを使いこなす（8）（3/3 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第8回では、新たに登場したAUTOSAR Adaptive Platformのアーキテクチャについて説明する。

[櫻井剛，MONOist]

Adaptive Platform Servicesとは

　次に、APにおける基本サービス群である、Adaptive Platform Servicesについて説明します。これらをAAから利用する際には、Communication Management（CM）を介します（Service-based）。

• ara::sm State Management（SM）
  • FCやAAのロード、起動やシャットダウンをつかさどるのがEMですが、そのどれを、いつロードし起動するのか、またシャットダウンするのかをつかさどるのがSMです
  • また、CPでのECUの動作モード管理と位置付けの似た、Machine内の通常動作中の動作モード管理を行うのもSMの主な役目です。APにおけるSMとEMの関係は、しいて言えばCPにおけるBswMとEcuMの関係に似ています

• ara::diag Diagnostics, Diagnostic Management（DM）
  • ISO 14229-1（UDS）による診断通信サービス（CPにおけるDcmに相当）と、イベントメモリ（同Demに相当）を提供します
    • 現時点では、UDSサービスの一部のみの対応であり、また、ISO 15031（OBD）やISO 27145（WWH OBD）には対応していません
  • これにより、当該ECUに対して、診断テスターから各種要求を送り、開発時のECU内部状態の読み出し、ECUの生産における製造日や製造番号などの書き込み、各種テストの自動化、自動車メーカーへの納入後のECUのvariant設定、整備の際の故障コード（DTC）の読み出し、ECU故障や交換要否の判断、ソフトウェアのアップデート（更新データの授受など）や輸送モードの有効化/無効化などが可能になります
    • UCMを用いたアップデートの際にも使われ、当該ECUから車内の他のECUに対して診断リクエストを送ることもできます
  • なお、設定においては、CPと同様にDiagnostic Extract（DEXT）を使用します

• ara::s2s Signal to Service Mapping
  • 同一ネットワーク上のCPベースECUとAPベースECUの間の通信を成り立たせるためには、互いの通信方式の違いを吸収する必要があります
  • このServiceでは、CPでのシグナルベースの通信（signal-based networking）の内容と、APでのサービス指向通信（service oriented communication、SoC）の内容の対応付けを行うことでそれを行います
  • なお、このFCを主にカバーする文書はAP SWS CMですが、実際の動作についてはプラットフォームベンダーによる実装依存となり規定されていません
  • また、CP側でSOME/IPに対応してさえいれば、Comに相当するこのs2sは必要ないのではないかという見方もあります。現時点のs2sには未定義の部分がかなり多いため、AP導入計画立案の際には、s2sの利用を前提とすることにはリスクが伴いますので、注意が必要です

• ara::nm Network Management（NM）
  • NMは、CPのNmやその下位のバス種別固有NMモジュールに相当するものであり、APのSMの動作と連動して通信の開始や終了をつかさどります
  • CPで使われてきたPartial Network（PN）をカバーしていますが、現時点では対応はEthernetのみ（UDP NM, CPのUdpNmと同様）のみの対応となっています

• ara::ucm Update and Config Management（UCM）
  • 自動運転に関して忘れてはならないのが、アップデートです
  • ナビゲーションシステムにおいて、新たな道路が建設されれば地図のアップデートが必要になるということは理解しやすいと思います
  • しかし、それ以外の従来型の制御ECUでも、アップデート機能が搭載されているものは少なくありません。このアップデートは、従来は、量産車両に対する新たな機能の追加や大幅な変更を意図したものというよりも、開発段階での頻繁かつ即座の更新や、量産開始後に改修が必要になった場合に備えるという意味合いが強かったのですが、自動運転ではそれらに加えて、新たな技術が多く導入され各種実現手段（V2X（Vehicle to X）通信により連携する車外の各種システムや、場合によってはセンサーなどのハードウェアの更新に伴うソフトウェアの大幅変更も含めて）や、関連する法規制もどんどん更新されていくことになるでしょうから、各車両が利用されている長い期間にわたりアップデートが可能でなければなりません。また、アップデート実施中に車両が走行できないようでは利便性が著しく低下してしまいますので、工夫も必要になります^※7）
  • これを担うのがUCMです。UCMは、搭載されているソフトウェアのバージョン確認や、ソフトウェア更新データの受信、更新に当たり十分なリソースが残っていることの確認、実際のアップデート処理（ログや進捗情報提供含む）、更新結果の検証、及び必要に応じての更新ロールバックを行います
  • なお、AAのインストールやアップデートの際は、UCMの機能も利用します

※7）なお、開発にあまり関わっていらっしゃらない方々の一部からは、「最初から正しく適切に作ればアップデートなど要らないのでは？」という疑問をいただいたこともあるのですが、そもそも「正しく適切に」という条件自体が時間の経過とともにどんどん変わっていくこと（以前はそれでよいとされていたことが、後にそうではないとされることも現実世界では少なくないということ）をご説明差し上げると、アップデートが必要であることをご理解いただけることが多いようです（他の項目よりも多少解説を多くしましたが、これは、UCMは若干理解しにくい部分とのアドバイスをいただいたためです）。

次回に続く

　アーキテクチャ面の簡単な解説だけでもやはり結構なボリュームになってしまいました。次回は、Adaptive Methodologyについて見ていきましょう。

参考文献

［1］AUTOSAR AP R18-10 EXP Platform Design（Explanation of Adaptive Platform Design）

［2］AUTOSAR FO R1.5.0 TR Release Overview（Foundation Release Overview）

［3］AUTOSAR AP R18-10 TR Release Overview（Adaptive Platform Release Overview）

［4］AUTOSAR FO R1.5.0 PRS LT（Log and Trace Protocol Specification）