AUTOSARの最新リリース「R23-11」（その1）＋SDVに取り組むための心構え：AUTOSARを使いこなす（31）（3/5 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第31回は、日本におけるAUTOSARの活動状況を報告するとともに、最新改訂版の「AUTOSAR R23-11」を紹介する。加えて、自動車業界で注目を集める「SDV」にどのように取り組むべきかについて論じる。

[櫻井剛，MONOist]

2.1 コンセプト＃1（新規）：Tracing for Adaptive Platform [FO] [AP]

　AUTOSAR Run-Time Interface（ARTI）^※6）を用いて、APベースECU内のアプリケーションの振る舞い（処理の開始／終了やAPIアクセスなど）を、ECU外のツールからトレースできるようにする（デバッガがAP ECUに接続されていなくとも、ECU間通信を利用して内部をのぞき込める）というコンセプトです。

　CPでは、R4.0.1時点ですでにトレース情報を送信するBSWモジュール（Dlt）が存在していましたが、トレース情報の収集を担う部分の導入はR4.4.0で行われました（ARTI対応）。これで、デバッガがCP ECUに接続されていなくとも、ECU間通信を利用して内部をのぞき込めるようになりました。

　そして、今回R23-11では、CPと同様の通信プロトコルを利用し、APでもトレース情報の収集を担う部分の拡張を行うことで、APベースECU内のアプリケーションの振る舞いをトレースできるようにしています。

　なお、OSレベルのタスクやプロセスの振る舞い情報の取得には「OS/ARTI Adapter」と呼ばれるものを使い、それが提供するOS/ARTI APIをAPの基本機能ブロック（Function Cluster、FC）の1つである「Log and Trace」とつなぐ形で今回の拡張が行われています。また併せて、Log and Traceとトレースツールの間のインタフェース（TraceArti）も追加されています。

　OS/ARTI AdapterとOS/ARTI APIについては、今回追加された文書、AP TR OS Tracing Interfaceに記述されています。

※6）なお、AUTOSARの前身の1つであるOSEK/VDXでは、OSEK Runtime Interface（ORTI）と呼ばれるものがARTIに相当していました。

　しかし、ORTIでのアプリケーションの振る舞いトレースの最小単位（粒度）は、OS管轄下の割り込みサービスルーティン（Category 2 ISR）とタスクでしたが、AUTOSAR CPではRTE（Runtime Environment）上のSW-C（Software Component）のRunnableが最小単位となります。ISRやタスクに対してRunnableが複数個割り付けられる場合があるためORTIでは対応できません。また、OSEK/VDXのOS部分（ISO 17356-3:2005）はそもそもシングルコア向けであり、ORTIはマルチコアを考慮したものになっていません。それらのことから、ARTIが開発されたという経緯があります。なお、OSEK/VDX文書をISO 17356化する対象には、ORTIや、MODISTARC（Conformance Test規定）の文書は含まれていません。

　なお、ARTI機能のためにAUTOSARでのECU／System開発ワークフロー（Methodology）やそこで必要となるデータ交換形式（AUTOSAR XML、ARXML）およびHook APIの定義についてはAUTOSARで規定し、主にツール側で必要なデータ交換形式の定義についてはASAMで規定するという標準化アプローチがとられています。先日SDV Alliance設立のアナウンスが「CES 2024」で行われましたが、SDVだの何だのといわれる前から、AUTOSARと他団体との連携は行われています。

2.2 コンセプト＃2（新規）：Secure SOME/IP-ACL [FO] [CP]

　CPでのSOME/IP通信において、あらかじめアクセス許可されている相手との通信のみに限定するような拡張が行われました（ACL：Access Control List）。

　ACL実装は主にService Discovery（Sd）モジュールを拡張することで対応していますが（Subscription Request（FIND）とServer Offer（OFFER）についてはこれで基本的に対応可能）、ClientからのMethod Callに対してはこれまで直接はSdが関与する機会がなかったため、Socket Adapter（SoAd）モジュールからSdに対してACL checkを要求するような拡張も行われています。

2.3 コンセプト＃3（継続）：Firewall in Classic AUTOSAR [FO] [CP]

　Ethernetでの通信内容を、あらかじめ決められたFirewallルールにより検査およびフィルタリングするものです（stateless packet inspection、stateful packet inspectionおよびdeep packet inspectionを、プロトコルにより使い分け）。

　APについては、一足先にR22-11で対応しましたが、今回のR23-11で、CPでもFirewallに対応しました。といっても、追加されたBSW「Firewall」（Fw）の振る舞いは基本的に実装依存であり、他モジュールへの通知などのインタフェース方法と、Configuration方法の規定が主な拡張内容です。

　なお、一般に、リソースがさほど潤沢ではないマイコンベースで実装されているEthernet Switchについては、TCAM（Ternary Content Addressable Memory、3値連想メモリ）で実現可能なstatelessフィルタリング以外、つまり、TCAMでは対応できないようなフィルタリングを行う際には、SwitchにAUTOSAR CP BSWスタックのサブセットを組み込むことで、Configurationの方法や内容を流用するというアプローチを想定しています^※7）。

　今回追加されたCP BSW Fw（Firewall）モジュールで検出した異常検出情報は、R20-11で導入されたIdsM（Intrusion Detection System Manager）に通知が集約されます。

※7）各BSWのモジュールが実現する振る舞いの配置の素直さと、Configuration Dataの配置の素直さは必ずしも両立しませんし、適切なツールの支援があれば、むしろ「Configuration Dataの影響」という観点がより重要な設計原則となります。AUTOSARでの標準化活動で、このようにConfiguration Data設計戦略が変化してきていることは、アーキ屋だけではなくインテグレーターの立場を経験した立場からするとむしろありがたいことだと感じています。ですが、とても地味なことであり、広くご理解いただける内容ではないことも承知しています。ただ、一見そう見えるからといって、「マニアック」などの「一見分かりやすい表現」で、ネガティブな方向への印象操作と見なされかねないことをすぐにしてしまうのは、避けることをお勧めします。本当に「誰にとっても価値がない」と断言できるものでないのなら、いつか未来に、確実に後悔することになりますので……。

2.4 コンセプト＃4（継続）：Service Oriented Vehicle Diagnostics (SOVD) [FO] [AP]

　先のR22-11では、APをASAM SOVD（Service-Oriented Vehicle Diagnostics）に対応させる拡張の第一ステップとして、DTCやCommunication Controlなどのごく基本的なユースケースのみに対応しました^※8）。今回のR23-11では、Software UpdateやBulk Dataの取り扱い、そしてLoggingに対応しています。

※8）本件に限らず何が「基本的なユースケース」なのかは、あくまでコンセプト開発を行うグループ内で決めていきます。「基本的なユースケース」という言葉で皆さまがイメージする内容の全てがカバーされているとは限りません。そこを確実にするためには、コンセプトグループに参加し、そこでの合意形成に積極的に関わる必要があります。「AUTOSARのようなプラットフォーム標準化活動でやってくれるはず」は大枠は正しいですが、「自分が必要なプラットフォームが上げ膳据え膳で用意される」のではありません。自分で確実なものとして仕立て上げていく必要があります。