発表日: 2018年10月01日 |
Sven Flake、仮想検証製品エンジニア、dSPACE GmbH
前回の記事ではバーチャル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の最初の公開は2002年のことであり、現時点でAUTOSAR Classic Platformはバージョン4にまで成熟しています。お客様が自動車分野において組込みソフトウェアをコーディングしたり交換したりするためのモジュール型の規格をお探しの場合は、それを使用することをお勧めします。
ただし、自動車業界は業界自ら改革を行っています。自動運転では、ソフトウェアアーキテクチャの要件が根本的に変わってきています。
自動運転車両は以下を行える必要がありますので、ご注意ください。
これをより専門的な言葉で言い換えてみましょう。
これらの項目は、部分的に自動化された自動運転車両に関する検討事項の一例に過ぎません。
これらはソフトウェアの開発で求められる要件に極めて大きな影響を与えます。
ソフトウェアの開発方法を決定する場合は、特定のソフトウェアアーキテクチャについても決定を行う必要があり、これは軽率には行えません。すべてのソフトウェアアーキテクチャはある目的の達成に向けてその役割を果たします。
AUTOSAR Classic Platformでは、ある目標に特化したソフトウェアアーキテクチャの設計が必要となります。つまり、「完全組込み」のソフトウェアです。
これらのいずれを使用しても、上述の自動運転に対する私たちの期待に適うほどの機能は得られません。これら3つの例からだけでも、新しい要件を満たすことが必要になるということが伺えます。
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では、どちらもサポートしています。次回は詳細について説明する予定です。
最新の技術開発動向をつかんで、イノベーションを加速。
メールマガジンの購読希望・変更/配信停止手続き