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

Concept #9〜16

　ここからは、16の新規コンセプトの残り8つ、Concept #9〜16をご紹介してまいります。

Concept #9：10BASE-T1S

　10BASE-T1S（IEEE 802.3cg）に対応しました。

　10BASE-T1Sは、シングルペアのEthernetであり、最長15mまでの配線長を想定したものです。CAN同様の、調停を必要とするバス型ネットワークとしての利用が想定されています（multidrop／PLCA：他のEthernetのようなネットワークスイッチを用いたものに限定されるのではありません）。

　通信コントローラー（MAC）レベルでの対応パターンが多様なため、それらに対応するための記述が追加されています（SWSを見ただけでは少々分かりにくいのですが）。R20-11では、standalone PHYのユースケースのみへの対応であり、Ethernet Switch Driver（EthSwt）を用いるユースケースには対応していません。

　また、ネットワークを介した時間同期でのpDelayの動的測定には対応せず、代わりに固定値を設定するようになっています。

Concept #10：Vehicle Motion Control Interface（VMCI）

　久々に、AUTOSAR CPのApplication Interface（AI）部分に大きな動きがありました。JasPar 車両制御I／F WGからの提案で、AD／ADAS（自動運転や先進運転支援システム）向けの、シャシードメインでの新たなインタフェースのひな型を定義した文書が追加されています。

　これは、一般公開されている、JasParのAD／ADAS車両制御インタフェース仕様書Ver.1.0（ST-AVI-1、2020-03-13）に基づいており、各種センサーの情報の統合（Fusion）の結果を受け取ってから、車両挙動の制御のためにアクチュエータに指示を行うまでの部分の各種インタフェースを例示しています。なお、現時点ではCPのみへの導入です（APには導入されておらず、Concept #13：AD Sensor Interfacesの「ara::adi::sensoritf」のようなFCインタフェース定義はまだありませんが、いずれは「ara::adi::vmcitf」などが定義されるのでしょうか？）。

　従来、特に国内では、AUTOSARの以下の部分ばかりが注目されてきたと思います。

• SW-Cを動作させる土台部分（BSWやRTE）の機能
• 土台部分の内部インタフェース（BSWやRTE間のインタフェース）
• 土台部分とSW-Cとの間のRTEインタフェース（SW-CをRTEと接続するためのインタフェース）

　しかし、AUTOSARの標準化範囲はそれだけではありません。SW-C同士を「意味」の面で接続できるようにするための論理インタフェースである「Application Interface」は、あまり注目されてこなかったものの1つです^※1、2）。

　その理由は幾つか考えられますが、既存のネットワーク設計との互換性の問題（レガシー問題）は決して小さくない要因でしょう。SW-C同士の論理インタフェースを変えるということは、当然ネットワーク上に流れるデータ種別や表現にも影響が及びますし、送信側と受信側双方の変更をもたらします（新旧車種用のECUの共用化／設計の再利用の妨げにもなります）。ネットワーク設計がいったん確立した後で、「AUTOSARに合わせて」変更したときに、「ばく大な工数がかかる上、その時点ではできることは変わらない、合わせた後で新たに得られる効果も定かではない」というのでは、見合わないという判断がなされて当然です^※3）。

　しかし、高度運転支援や自動運転では新たな技術的な要素が追加されており、それらの多くは新たなインタフェースを必要とします。インタフェースは、業界内での垂直方向での分担や再利用のための境界線にも深く関係してきますし、また、自動運転では従来とは桁違いの規模のテストが必要になるわけですので、シミュレーションの積極的な採用のカギにもなっていくでしょう。