Adaptive AUTOSARによる自動運転の実現方法

前回の記事ではバーチャルECUを取り上げ、ソフトウェアの機能を簡単に交換するための基礎として大いにAUTOSARを強調しました。ただし、それはすべて従来のAUTOSAR、より正確にはAUTOSAR Classic Platformについてのことでした。ところが、自動運転の話題になると、誰もがAdaptive AUTOSAR、すなわち AUTOSAR Adaptive Platformについて話をします。

このAdaptive Platformがお客様との会話で初めて話題となる流れは、基本的に次のとおりです。
お客様：「無線でアップデートを行うには、ソフトウェアアーキテクチャに柔軟性が必要です。」
自分：そのためには、どうしようとお考えでしょうか。
お客様：「まだ分かりませんが、Adaptive AUTOSARであればうまくいくでしょう。」

これはAdaptive Platformの最初のリリースの数カ月前のことでした。そのため、私たちの期待は大きくなりました。その期待の大きさは、同僚達がSIL（Software-in-the-Loop）ツールチェーンでの「アダプティブ」のサポートに向けて取り組んだ時の情熱に匹敵するものでした。

もちろん、Adaptive AUTOSARは従来のAUTOSARの後継規格ではないため、置き換えることはできない、ということは誰もが知る必要のある基本的な事実です。ただし、ECUソフトウェアを定義したり、ECUハードウェアや仮想マシンでそれらを実行する方法を定義したりする場合の選択肢となります。

別のAUTOSARプラットフォームが生まれた理由

新しいプラットフォームが考案された理由は何でしょうか。AUTOSARの最初の公開は2002年のことであり、現時点でAUTOSAR Classic Platformはバージョン4にまで成熟しています。お客様が自動車分野において組込みソフトウェアをコーディングしたり交換したりするためのモジュール型の規格をお探しの場合は、それを使用することをお勧めします。

ただし、自動車業界は業界自ら改革を行っています。自動運転では、ソフトウェアアーキテクチャの要件が根本的に変わってきています。

自動運転車両は以下を行える必要がありますので、ご注意ください。

• 周辺との通信
• 多数のセンサを使用した周辺の監視
• このデータを使用して、搭乗者の健康や時には生命にとって極めて重要となる運転に関する数多くの判断を実行

これをより専門的な言葉で言い換えてみましょう。

• 自動車はあらゆるものに接続される、単なるもう1台のデバイスとなります。これにはスマートホームを含める場合もありますが、何よりもまずデータのバックエンド、他の自動車、および交差点周辺の信号機との通信が必要になります。
• このような自動車はメディアストリーミングを使用します。これは、後部座席の子供のためではなく、継続的に環境を読み取り、大量のデータを生成して、高速道路の自動運転や緊急ブレーキの動作を保証するセンサのために使用します。
• 完全に成熟した最先端のニューラルネットワークを動作させることができ、さらにはセンサデータの解釈と正しい判断を行えるだけの十分な処理能力も必要となります。
• 自動車は購入後、最新のソフトウェアで定期的にアップデートする必要があります。工場で点滅するECUに悪戦苦闘するわけにはいきません。

これらの項目は、部分的に自動化された自動運転車両に関する検討事項の一例に過ぎません。

これらはソフトウェアの開発で求められる要件に極めて大きな影響を与えます。

それぞれに独自のソフトウェアアーキテクチャ

ソフトウェアの開発方法を決定する場合は、特定のソフトウェアアーキテクチャについても決定を行う必要があり、これは軽率には行えません。すべてのソフトウェアアーキテクチャはある目的の達成に向けてその役割を果たします。

AUTOSAR Classic Platformでは、ある目標に特化したソフトウェアアーキテクチャの設計が必要となります。つまり、「完全組込み」のソフトウェアです。

• これは、小型の（処理能力の点で）特化したハードウェア上で動作します。
• また、ECU用に設計、作成され、ECUに保存された状態で動作します。変更の必要はありません。
• 通信は（主に）、CANなどの従来の車載バスネットワークを使用した、比較的小さなデータパケットのサイクリックブロードキャストが対象となります。

これらのいずれを使用しても、上述の自動運転に対する私たちの期待に適うほどの機能は得られません。これら3つの例からだけでも、新しい要件を満たすことが必要になるということが伺えます。

• センサデータの連続ストリームについては、ネットワーク全体にブロードキャストされる小さなパケットとは異なり、2つまたは3つの機能間でやり取りすることが必要。
• 処理能力を向上させて極めて高速に数値を処理し、画像演算処理装置（GPU）もサポートすることが必要。
• ソフトウェアの実行中に交換可能であり、最先端のウェブシステムにも接続でき、（車両にどの通信プロトコルが使用されていても問題とならない）柔軟なソフトウェア。

AUTOSAR Classic Platformは、自動運転専用に設計されたものではありません。そのため、AUTOSARは、まさに新しい要件を念頭に置いて、Adaptive Platformを作成しました。

柔軟性がカギ

Adaptive Platformでは、ソフトウェアの機能間通信をサイクリックバーストで行わなくなったものの、サービス指向の通信となっています。「アダプティブアプリケーション」（Classic Platformでの「ソフトウェアコンポーネント」）では、提供できるデータと必要とするデータを通知します。仲介サービスによって正しく一致するデータが検出され、2つのアプリケーションが直接通信を行います。

さらに、下位レベルの通信はEthernet上で行われます。専用プロトコルを使用するCANや他の従来型車載バスシステムは使用しません。Ethernet通信のほかにも、SOME/IP [http://some-ip.com]は現在、より多くの注目を集めています。SOME/IPはサービス指向のミドルウェアレイヤーとして、アプリケーションによる実際の通信方法を定義しています。たとえば、ここでは、コードの挙動で直接サイクリックトリガの時間を定義する必要はありません。

Classic Platformしか知らない人間である私は、実行中のソフトウェア交換については組込み以外の状況では理解できるのですが、AUTOSARの場合はできません。理由は簡単です。Classic Platformでは、ソフトウェアコンポーネント間の通信は配線で接続され、AUTOSAR Runtime Environment（RTE）によって活性化されることにより、通信がアーキテクチャレベルからECUレベルへと変換されます。これは（バスメッセージにラップする場合など）静的マクロを解決し、それらを適切なベーシックソフトウェアの呼び出しに変換することによって行います。

実行中に交換可能なソフトウェアを使用したい場合、これでは機能しません。しかし、Adaptive Platformでは、サービス指向の通信アーキテクチャを実装することにより、有線通信の短所を克服しています。

その結果、AUTOSAR Runtime Environmentのアダプティブバージョン（ARA、AUTOSAR Runtime for Adaptive Applications）は、実際のアプリケーションとは独立して動作し、仲介サービスのみを提供しています。通信は、それを要求する任意のアプリケーション間で確立されます。

その結果、何が起きるでしょうか。通信はソフトウェアの起動後にのみ自動的に確立されるため、ソフトウェアの実行中でもソフトウェアの追加や交換が可能になります。これはClassic Platformの場合とは異なり、設計段階では決定されません。

プログラミングを続けましょう

柔軟性に関して最後に一言。特にセンサデータ処理の場合において、最先端の自動運転システムの開発はLinuxシステムで行われていることは誰もが知っています。ここでは、柔軟なメモリ割り当てやスレッド処理などを含め、あらゆる柔軟性を提供できるオペレーティングシステムが必要となります。私たちはこの柔軟性を放棄したくはありません。しかも、特殊なECU操作システム用のコードをコンパイルしなければならないため、おそらく放棄することはできません。

このため、Adaptive PlatformではPOSIXインターフェースを使用しています。アプリケーションをアダプティブプラットフォームに展開することにより、開発者は愛用するLinuxのあらゆる利点を活用できるようになりました。

これは大事なことではないでしょうか。

まとめ

私の個人的な結論は、Adaptive PlatformはClassic Platformの妹分であるということです。どちらのプラットフォームも前身は同じであり、高品質な自動車用ソフトウェアを開発するための手法と規格を提供するという全般的な目的も同じです。

両者は補完し合う存在です。Classic Platformが従来の自動車分野の効率的な完全組込み機能に特化している一方、Adaptive Platformは開発途中の自動運転分野を対象としています。優れた柔軟性が必要となるAdaptive Platformの分野においても、当社はソフトウェアアーキテクチャ、通信手段、および処理能力の面でそれらに対応することができます。

そのため、どちらのプラットフォームも必要であり、

dSPACEでは、どちらもサポートしています。次回は詳細について説明する予定です。