AUTOSARの最新リリース「R23-11」（その2）：AUTOSARを使いこなす（32）（3/3 ページ）

[櫻井剛，MONOist]

2.7 コンセプト＃7（新規）：Charging Interface [CP]

　バッテリー電気自動車（BEV）の充電用通信規格ISO 15118-2で規定されるメッセージの通信に対応するために、Charging Manager（ChrgM）BSWモジュールが追加されました。

2.8 コンセプト＃8（継続）：DDS Support on CP [CP]

　CPでのDDS対応の続編です。今回は、システムレベル設計情報（System Template）でDDSに関する設定情報を扱えるような拡張が行われました。また、SWアーキテクチャレベルでもPduRとの接続についての見直しが行われ、送受信キュー制御が追加されました。

2.9 コンセプト＃9（新規）：Service Discovery Control for Application Software [CP]

　CPでのSOME/IPのService Discoveryの制御は、これまでECU起動時に自動的に行われるoffer / subscribeと、BswMによる制御の2通りの方法で行われてきました。今回は、これらの制御をより緻密にApplication Layerから行うことができるような拡張（Service Interfaceの追加）が行われています。

2.10 コンセプト＃10（継続）：MACsec [AP]

　R22-11から継続して進められている、AUTOSARでのMACsec（IEEE 802.1AE）による通信保護対応ですが、R23-11では、AP EXP MACsec and MKA（MACsec Key Agreement protocol、IEEE-802.1X）Protocolという文書の形で、MACsecをどのようにAPで使用するのかについてガイドラインを提示しています。

　一般にMACsec動作自体はハードウェアにより実現されます。それを動かすには通常OSカーネルを介してMKAの処理が必要になります。このコンセプトでは、APスタック実装者とインテグレーターが連携しながら、APベースのECU上のMKAとMACsecの設定をできるようにするために、ハード、OSカーネルやスタック実装における各種前提の整理を行っています。

2.11 コンセプト＃11（新規）：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リソース利用の防止

3．その他

　APのFunction Cluster（FC）の増減もありました。

　また、従来はFCの分類グループが以下のリストにある最初の2つだけでしたが、R23-11で再編整理され、さらに2つのグループが追加されています。

• Platform Foundation FCs
• Platform Service FCs
• Standardized Application Interface FCs
• Vehicle Service FCs

　現在のアーキテクチャを図2に示します。

• ara::iam Identity and Access Managementを削除（SWS文書を、EXP文書の位置付けに変更）
• ara::rds Raw Data Streamを追加
• ara::shwa Safe HW. Accelerator後のリリースのために略称を追加（Reserved）（「2.11 コンセプト11参照」）
• ara::nm Network Management: Platform Service FCからPlatform Foundation FCに位置付けを変更
• ara::vucm Vehicle Update and Configuration Managementを追加（UCMから分離）

図2　AUTOSAR Adaptive Platform ソフトウェアアーキテクチャ（論理ビュー）［クリックで拡大］

まとめ

　前回から2回に分けて、R23-11での新規機能追加などの変更内容をご紹介いたしました。また、AUTOSAR導入について考えることで見えてくるSDVの正体や規範的なものとなり得るもののごく一部についても、連載第30回から私見を述べさせていただきました。

　私が申し上げるまでもなく今は大変革期であり、「変えなければ失うものはほぼない」「主流であれば安泰」という状況ではありません。「変えたいこととその理由」「変えたくないこと、変えられないこととその理由」を、それぞれの立場で見直し表明していくことが求められるでしょう。

　先にご紹介したAUTOSAR Open Conference（AOC）は、講演者として登壇し発信する機会でもありますし（既に申し込み締め切り済み）、参加者として各種講演聴講やQ&A、そしてネットワーキングイベント（これらはまだ間に合います）のような機会は、「見直し」のためのインプットを得るための、そして、ご自身の理解や考えを他の方と交換して確証を深めるための、絶好の機会だと思います。

筆者プロフィール

櫻井 剛（さくらい つよし）イーソル株式会社 ソフトウェア事業部 エンジニアリング本部 エンジニアリング管理部 Safety/Security シニア・エキスパート／AUTOSAR Regional Hub in Japan（Japan Hub）

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