ここからは、16の新規コンセプトの残り8つ、Concept #9〜16をご紹介してまいります。
10BASE-T1S(IEEE 802.3cg)に対応しました。
10BASE-T1Sは、シングルペアのEthernetであり、最長15mまでの配線長を想定したものです。CAN同様の、調停を必要とするバス型ネットワークとしての利用が想定されています(multidrop/PLCA:他のEthernetのようなネットワークスイッチを用いたものに限定されるのではありません)。
通信コントローラー(MAC)レベルでの対応パターンが多様なため、それらに対応するための記述が追加されています(SWSを見ただけでは少々分かりにくいのですが)。R20-11では、standalone PHYのユースケースのみへの対応であり、Ethernet Switch Driver(EthSwt)を用いるユースケースには対応していません。
また、ネットワークを介した時間同期でのpDelayの動的測定には対応せず、代わりに固定値を設定するようになっています。
久々に、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の以下の部分ばかりが注目されてきたと思います。
しかし、AUTOSARの標準化範囲はそれだけではありません。SW-C同士を「意味」の面で接続できるようにするための論理インタフェースである「Application Interface」は、あまり注目されてこなかったものの1つです※1、2)。
その理由は幾つか考えられますが、既存のネットワーク設計との互換性の問題(レガシー問題)は決して小さくない要因でしょう。SW-C同士の論理インタフェースを変えるということは、当然ネットワーク上に流れるデータ種別や表現にも影響が及びますし、送信側と受信側双方の変更をもたらします(新旧車種用のECUの共用化/設計の再利用の妨げにもなります)。ネットワーク設計がいったん確立した後で、「AUTOSARに合わせて」変更したときに、「ばく大な工数がかかる上、その時点ではできることは変わらない、合わせた後で新たに得られる効果も定かではない」というのでは、見合わないという判断がなされて当然です※3)。
しかし、高度運転支援や自動運転では新たな技術的な要素が追加されており、それらの多くは新たなインタフェースを必要とします。インタフェースは、業界内での垂直方向での分担や再利用のための境界線にも深く関係してきますし、また、自動運転では従来とは桁違いの規模のテストが必要になるわけですので、シミュレーションの積極的な採用のカギにもなっていくでしょう。
※1)AUTOSAR CP R19-11までは、AIの対象ドメインとして以下が用意されていました。ADAS/AD本格導入以前のものが中心です。
※2)他の重要な要素はメソドロジー(Methodology、データ形式やワークフローを定めたもの)です。さまざまな立場の開発者が、さまざまなツールを用いて共同作業できるようにするために必要なものであり、AUTOSARでもTPS(Template Specification)文書など、重要な位置を占めています。
※3)国内でのAUTOSAR導入は、欧米に比べて遅めです。「AUTOSARを導入したらAIも導入しなければならない」という誤解が、そこに影響しなかったことを切に祈ります。トレーニングなどでAIについて説明するたびに、否定的な反応が多かったのも事実でして、その都度「AIは、EXP AI User Guide chap. 2に述べられているように、例であり採否は自由」とお答えしてきたのですが……。
Copyright © ITmedia, Inc. All Rights Reserved.