AUTOSARの最新リリース「R20-11」に盛り込まれた新コンセプト（後編）：AUTOSARを使いこなす（18）（3/3 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第18回では、前回に引き続き、2020年12月に一般公開されたAUTOSARの最新リリース「R20-11」について紹介する。

[櫻井剛，MONOist]

Concept #11：Integration of IAM

　APのIAM（Identity and Access Management）によるアクセス制御の、COM以外のFCへの適用が始まりました。といっても、今回はPHM（Platform Health Management）のみが対象であり、他のFCは今後のリリースで対応されていきます。

Concept #12：Crypto API

　APで暗号処理や鍵管理、証明書のハンドリングを行うFCであるCryptography（ara::crypto）のインタフェースが用意され、ようやく他のFCやAdaptive Application（AA）から利用可能になりました。Cryptoの基本サービスは以下の通りです。

• 暗号関連演算（Cryptographic Operations）
  • Hash計算
  • MAC生成/検証
  • 暗号化/復号（Cipher）
  • 署名生成/検証（Signature）
  • 乱数生成（Random）
• 暗号鍵管理（Key Management）
  • 鍵設定、鍵抽出、鍵複製、鍵生成
  • 秘密鍵導出（KDF）、秘密鍵交換
• 証明書（Certificate Handling）※X.509、ただし制限あり

Concept #13：AD Sensor Interfaces

　CPでのConcept #10：Vehicle Motion Control Interface（VMCI）とはまた別のI／F部分の定義が、APの「ara::adi::sensoritf」として追加されました（R20-11ではAPのみです、CPのAI文書には反映されていません）。

　これは、ISO 23150 Road vehicles - Data communication between sensors and data fusion unit for automated driving functions - Logical interfaceで定義される、自動運転用センサー（レーダー、LiDAR、カメラ、超音波センサー）とデータフュージョンユニット間のサービスインタフェース定義を提供しています。

　なお、ISO 23150は、2020年11月30日時点ではDIS（国際規格案）段階でしたが、2020年12月2日にステージコードが50.00（FDIS（最終国際規格案）公開の直前段階）に進んでいます。

Concept #14：Deterministic Synchronization

　演算冗長化の際の演算同期機能が追加されました。なお、Software Lockstep動作の詳細は、少なくとも現時点でのAPでの標準化範囲外です。

Concept #15：Static Configuration of Remote ECU Identity and Access Management（SCREIAM）

　通信を行うAPベースのECUにセキュリティ侵害が発生してしまった場合の影響を抑制するためのものです。送信側の識別情報と事前に設定されるポリシーに基づき、受信側でのアクセス制御を行います。

Concept #16：ara Communication Groups

　複数のプロセスによる同期動作を実現するためのものです。

その他の変更点

　これらの新規コンセプトは、「validation」と呼ばれるプロセスを経るまではドラフト（draft）扱いとなります。R20-11のリリースではvalidation作業にも重点が置かれており、過去に導入されたコンセプトの幾つかに対して完了し、draftの文字が取れました。

• AUTOSAR Run Time Interface、ARTI（FO R1.5.0/CP R4.4.0で導入）※なお、ARTIは、ASAMでさらなる標準化が進められています
• BSW Multicore Distribution（CP R19-11で導入）※マルチコアECU上でのBSW分散配置
• DoIP Extension（FO/CP R19-11で導入）※Ethernet経由での診断通信プロトコルDiagnostics over IP（DoIP）の標準規格 ISO 13400-2の2019年版への対応（車両内に設置される内部テスター（internal tester）とECUとの間の診断通信もカバー）
• Signal Service Translation（FO/CP R19-11で導入）※APのサービス指向通信とCPのシグナルベース通信の接続
• Non-Volatile Data Handling Enhancements（CP R19-11で導入）※不揮発メモリのアクセス自由度向上と利用効率改善。なお、ここで追加されたBulk NvData Manager（BndM）は、NVRAM Manager（NvM）への統合も示唆されていたのですが、R20-11時点では統合は行われていません
• Firmware over the Air、FOTA（CP R19-11で導入）※車両に搭載されるECU上の各種データを含むソフトウェアの更新
• Socket Network Binding for ara::com（AP R19-11で導入）※AD／ADAS関連のセンサーからの生データのような、長大なデータストリームをApplicationで直接操作しなければならない場合のために、Communication ManagementにRawDataStreamsのインタフェースを追加

　なお、FOTAにも関連のあるコンセプトであるUCM Master（R19-11で導入、R20-11でもdraft状態）に関しては、AP SWS UCMに、AP以外のECU（CP ECUを含む）の書き換えに関するセクションがひっそりと追加されました。そこには、ISO 22900-2：2017 Road vehicles - Modular vehicle communication interface（MVCI）- Part 2：Diagnostic protocol data unit（D-PDU API）に従うべき（should comply）と書かれています。

　また、幾つかの文書の追加や移動が、コンセプト以外にも行われています。代表的なものは以下の通りです。

• FO PRS SecOC：追加 ※従来はCPだけに用意されていたSecOC（Secure Onboard Communication）は、APでも必要になりますので、Protocol Specificationとして文書のプロトコル部分が切り出されFOに追加されました
• AP EXP SW Architectural Decisions：追加 ※標準化の議論の過程で浮き彫りとなった「共通認識とする必要がある事柄」をまとめた文書です。SM（State Management）, EM（Execution Management）およびPHMの位置付けの見直し結果（Recovery ActionをPHMからSMに移管するという決定）もここに記載されています
• AP EXP SW Architecture：追加 ※APアーキテクチャを、ISO/IEC 42010の観点で改めて書き出したもの。なお、従来のEXP Platform Designも残っています
• 従来CPに入っていた、本来は多数のCP／AP共通文書（例：TPS Generic Structure Template, TPS Standardization Template, TR Predefined Namesなど）：R20-11で、FOへの移管が行われました

　CPでは機能削減も行われています。

• CP CAN Driver（Can）：Intelligent Communication Controller（ICOM）によるPretended Networking機能を削除 ※Pretended Networkingは、Partial Networking（PN）と似た機能ですが、PN対応のCAN transceiverによるselective wakeup動作を、CAN controllerで行うというものでした。前回も書きましたが、AUTOSAR CP仕様は十分に複雑で、メンテには苦労しています。使われていない機能は削除される、という例の1つです。

---

　次回のテーマですが、現時点では未定のため、またしばらく間を開けさせていただきます。次回はおそらく2021年3月開催のAUTOSAR Open Conference後の見込みです。