AUTOSAR導入で期待される「再利用」と「自動化」を本当に実現するための条件：AUTOSARを使いこなす（34）（4/4 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第34回は、AUTOSAR導入で期待される「再利用」と「自動化」を本当に実現するための条件について論じる。また、最新リリース「R24-11」の内容を簡単に紹介する。

[櫻井剛，MONOist]

AUTOSAR最新リリース「R24-11」のまとめ

　ここからは、2024年11月27日に発行のAUTOSARの最新リリース「R24-11」（Internal Release Number：R4.10.0）の内容を手短にご紹介いたします（CP：Classic Platform、AP：Adaptive Platform、FO：Foundation）。

1）Concept：Adaptive Platform Machine Configuration（APMC）［AP］

　APでの「設計」「ターゲット設定」の内容はこれまでManifestにひとまとめに放り込まれていましたが、今回、CPでのECU Configurationと同様に「ターゲット設定」に関する部分を「Machine Configuration」のARXMLとして切り出せるようになりました。ただし、従来のManifestを置き換えるのではなく、徐々に移行することとなります。これにより、専用ツールによるconfiguration支援などもより実現／享受しやすくなります。

2）Concept：Automotive API［AP］

　COVESA VSS（Vehicle Signal Specification）にAUTOSARで対応する手段として、模索の末、Functional Cluster（FC）「Automotive API Gateway」が追加されました。

　このアプローチにより、旧バージョンのAPスタック（FC群）を使用していたとしても、Automotive API Gatewayだけ乗せればつなぐことができるようになります（ただし、safetyなどの観点から、これでよいのかどうか疑問はありますが……）。

　なお、このコンセプトを扱うWG-CLD（Cloud）はごく少人数で標準化活動を行っているとのこと。関心をお持ちの方は、ぜひご参加をご検討ください。

3）Concept：Charging Interface［CP］

　R23-11で追加されたCharging Manager（略称：ChrgM）を大幅見直しし、Application Layer SW-Cから利用するためのService Interface定義を追加しました。

　また、このBSW module名も、ISO 15118 Charging（同ISO15118Chrg）に変更されています。

4）Concept：DDS［CP/AP/FO］

　DDSに関するプロトコル仕様文書（PRS）が追加されました。

　また、CP／APともに記述の見直し、詳細化が行われています。

5）Concept：Deterministic Communication with TSN

　R23-11にてIEEE 1722 Transport Layer（IEEE 1722Tp）モジュールとL-SDUs（Link Layer Service Data Units）のルーティングのためのLinklayer SDU Routing（LSduR）が追加されましたが、R24-11では、IEEE 1722 TunnelingへのCANおよびLIN通信スタックでの対応のため、両スタックの見直しが行われました（FlexRayは未対応）。これらの通信スタックでは、IfモジュールとPduRの間にLSduRが入っています。

6）Concept：Feature Graph［FO］

　機能面の変更ではなく、トレーサビリティー改善や、AUTOSAR CPとAPの両プラットフォームが提供する機能（feature）の把握を容易にするためのconceptです。

　「車両やECUにある機能（Feature）」の一部は、CP BSWやAP Functional Cluster（FC）として実現されます。

　しかしながら、AUTOSARの開始は2003年であり、トレーサビリティーが重視されるようになったのはそのだいぶ後になってからだったため、「欲しい機能」「知りたい機能」を、これらトレース情報を基に探すことは容易ではありませんでした。

　そこで、R24-11でそれらを整理しなおし、機能グラフ（feature graph）のマインドマップの形で提供しています。

　なお、従来のSRS文書（Software Requirement Specification）は、これを機に全てRS文書（Requirement Specification）に改称されました。

　また、AUTOSAR文書の個別要件／仕様などの記述（例：SWS文書でのspecification item）も、今回からAUTOSAR XML形式で提供されるようになっています。

　誰もが差分を確認するわけではありませんが、そのような作業を行う方には役立つ改善です。

7）Concept：I2C Driver［CP］

　AUTOSARでは長年I2Cへの対応をしてきませんでしたが、R24-11でようやく対応することとなりました。

　CP BSWの新規MCALとしてI2C Driver（略称：I2C）が追加されました。

8）Concept：Safe API for hardware accelerators［AP］

　High performance computing（HPC）で用いるデバイスの中には、演算高速化のために、あたかも数値演算ライブラリのように動作するハードウェアアクセラレータ（HWA）を搭載するものもあります。

　しかし、そのようなアクセラレータは、高速化に最適化されていても、安全な演算のために使えるとは限りません。

　そこで、APにおける典型的な以下のユースケースに対して、既存のKhronos SYCL 2020 APIを用いた上位APIの導入およびマニフェスト拡張が提案されました。

• データ保持および管理（Data storage and management）
• タスク実行（Tasks execution）
• デバイス管理および監視（Devices management and monitoring）
• 利用可能なHWAリソースのconfiguration情報提供（Runtime configuration）※利用できないHWAリソース利用の防止

　R23-11にて導入開始された本コンセプトに対し、R24-11では、要件を具体化したRS文書（AUTOSAR_AP_RS_SafeHardwareAcceleration）が追加されています。

9）Concept：Vehicle Data Protocol（VDP）［FO］

　車両／ECU内のデータ収集のための新規プロトコルです。サンプリングと送信が分離されており、また、従来使われてきたXCPに比べ、アドレスの直接指定の必要もなくまたセキュリティ対応も可能という特徴があります。

10）AP Stabilization［AP］

　APは、これまで後方互換性（backward compatibility）のない変更がたびたびおこなわれてきましたが、R24-11ではその安定化のための検討が進められてきました（例：callbackを含むthread safety化、exception safety - noexcept化）。

　R25-11でも一部互換性のない変更が入る見込みではありますが（例：Crypto、FC個別のthread safety化など）、安定化に向けて着実に進んでいることは、APに関わる方々には朗報、安心材料だと思います。

11）SAE J1939-76［CP］

　SAE J1939通信での通信保護（J1939-76）への対応のため、E2E LibraryにProfile 76が追加され、また、BSW moduleとしてFunctional Safety Communication Protocol Handler for SAE J1939（J1939Fscp）が追加されています。

次回に続く

　次回は、AUTOSAR Japan Hubとしての活動のご案内をできればと考えています。

筆者プロフィール

櫻井 剛（さくらい つよし）イーソル株式会社 ビジネスマネジメント本部 Solution Architect & Safety/AUTOSAR Senior Expert／AUTOSAR日本事務局（Japan Hub）

自動車分野のECU開発やそのソフトウェアプラットフォーム開発／導入支援に20年以上従事。現在は、システム安全（機能安全、サイバーセキュリティ含む）とAUTOSARを柱とした現場支援活動や研修サービス提供が中心（導入から量産開発、プロセス改善、理論面まで幅広く）。標準化活動にも積極的に参加（JASPAR AUTOSAR標準化WG副主査、AUTOSAR文書執筆責任者の一人）。2024年よりAUTOSAR日本事務局（Japan Hub）も担当。