AUTOSARは多くのOEMで自動車ECUの開発においてユビキタスになっていますが、新しく、より複雑な自律走行車技術が市場に出てきたとき、AUTOSARはどのような役割を果たすのでしょうか？
自動運転車 - レベル3
自律走行システムの高性能化に伴い、自動車がドライバーのサポートを必要としない時代になりましたが、当面はバックアップとしてドライバーを必要とします（例：SAEレベル3、図1）。レベル3の条件付運転自動化システムは、特定の条件下と特定の場所でのみ作動します。したがって、ほとんどの時間、車両はドライバーによって制御される必要があり、すべての条件が満たされたときにのみ、車両は運転タスクを制御することができます。そのため、走行中は車両とドライバーの間で制御のやり取りをする必要があります。
図1.SAE自動化レベル
SAEレベル3は、自動車メーカーにとって大きな一歩となるでしょう（実証が必要な堅牢性のレベルは、民間航空規格と同様です）。人間は適応力があり、一般に、不十分な制御や指示を回避することができます。しかし、レベル3の車両が完全に制御できるようになると、車両の限界に適応する必要があるのは、もはやドライバーではありません。車両は、ドライバーの限界に適応する必要があります。もし、車両がドライバーに制御を委ねる必要があると判断した場合、それを迅速かつ強固に、そして明確に伝えることができなければなりません。
では、レベル3では、どのようにして車両とドライバーの間で運転タスクの制御を安全に移管しているのでしょうか。
コントロールの移譲には多くの側面がある（図2）：ドライバーから車両へ：
必要な条件を満たし、必要に応じて自律走行が可能であることを運転者に認識させなければならない
ドライバーは、車両に制御を委ねることを伝えなければならない
車両が制御し、制御していることを確実にドライバーに知らせる必要があります。
一旦制御した後は、ドライバーが必要に応じて再制御できるよう、車両は継続的にドライバーを監視しなければなりません。
車両からドライバーへ
車両は、以下の場合、制御権の移譲手続きを開始しなければならない。
車両が制御を維持できなくなった（緊急移送）
ドライバーがドライバーモニタリングシステムに応答していない
システムに必要な条件が満たされなくなった場合
要求があれば、運転手は車両を制御しなければならない
標準的な制御の移行-30-60秒のウィンドウで制御された手順で、実装によって異なる
緊急時の制御移行-緊急事態によりドライバーが制御を行う必要があるが、ほとんどのシステムでは最低5-10秒である。
ドライバーの操作や応答がない場合、車両は安全な状態に戻り、多くの場合、車両は車線上で停止し、緊急通報を開始します。
図2. Transfer of control 出典：sbdautomotive.com（ドライバーおよび車室内のモニタリング - 2022年版、レポート番号: 810)
この制御の伝達は、車両とドライバーの間で、HMI（Human Machine Interface）を使って管理する必要があります。車載HMIシステムには、タッチスクリーン、ディスプレイ、スイッチ、ボタン、オーディオ、音声、ハプティックなどがあります。多くの場合、様々なディスプレイを用いたビジュアルHMI、チャイムや音声コマンドによるオーディオフィードバック、シートやステアリングホイールのアクチュエータによる触覚フィードバック、ドライバー入力用のステアリングホイールのボタンやスイッチなどが組み合わされます（図3）。複数のHMIシステムを使用することで、冗長性を確保し、機能安全要件を高いASIL-D評価から低いASIL-B/Aに分解することが可能になり、個々のシステムに対する設計変更の影響を減らすことができます。
図3. Transfer of control 出典：sbdautomotive.com（ドライバーおよび車室内のモニタリング - 2022年版、レポート番号: 810)
レベル3システムの全体的なシステム設計は、予想されるように、モーションコントロール、ボディ、AV/ADAS 、多くのセンサーやスマートセンサー、ECU、アクチュエーターが組み込まれます。さらに、制御要件の移行により、オーディオやインフォテインメント領域にも影響が及ぶことになります。このため、ASIL-Dの機能安全要件を満たすレベル3の自律走行システムを実現するには、複数のドメインやECU、異なるティア1サプライヤーにまたがる非常に複雑な全体システム設計となります。AUTOSARを使用することで、共通のソフトウェアアーキテクチャフレームワークを提供することができ、開発の頭痛の種を軽減することができます。
もう1つの重要なトレンドは、電子ハードウェアとソフトウェアの性能が向上するにつれて、複数のドメインにまたがる技術が、より複雑で多機能なECUに集約されつつあることです。EEのアーキテクチャは、機能指向のECUからより複雑な機能ドメインコントローラへと移行しつつあり、将来的には集中型アーキテクチャやゾーン型アーキテクチャへと移行する（図4）。これにより、最終的には完全にスケーラブルなサービス指向アーキテクチャが実現され、多くの人が次のように呼んでいます。 ソフトウェア定義車言い換えれば、機能の大半がハードウェアに依存しないソフトウェア・プラットフォーム上に構築された自動車である。このコンセプトにより、メーカーはさまざまなハードウェア構成に依存しないソフトウェアを開発できる一方、更新可能な車両プラットフォームの利点を生産時に享受することができる。これを実現するため、ほとんどのメーカーは、外注パートナーやティア1とは対照的に、車両のソフトウェア製品ロードマップを管理する内部ソフトウェア開発チームの規模を拡大している。
ほとんどの場合、ティア1はハードウェアとソフトウェアのコンポーネントを提供しますが、システムの所有権はOEMにあります。OEMは、複数のサプライヤーからのコンポーネントを使用して、これらの複雑なシステムを統合する必要があります。AUTOSARフレームワークを使用することで、OEMはポータブルなソフトウェアコンポーネントとその間の通信インタフェースを定義することができます。これは、困難なシステム統合やデバッグ作業に役立ち、EEアーキテクチャが進化しても、多くのソフトウェアコンポーネントを再利用できることを意味します。
図4.車載電気系アーキテクチャの進化予測。出典：sbdautomotive.com（EEアーキテクチャ・プラットフォーム - レポート630号）
AUTOSAR（AUTomotive Open System Architecture）は、自動車ECUのためのオープンな標準化ソフトウェアアーキテクチャを構築するために2003年に設立された自動車OEM、ティア1、技術開発者の開発パートナーシップである。このアーキテクチャでは、標準的なソフトウェアモジュールとサービスインターフェースを定義し、ソフトウェアコンポーネントをカプセル化することでハードウェアの独立性を実現しています（図5）。プラットフォームの最初のリリースは2006年5月にさかのぼり、AUTOSAR技術の最初の実装が市場に投入されたのは2008年でした。
図5 AUTOSAR Classicプラットフォーム。出典: https://www.autosar.org/standards/classic-platform/
自動車システムの複雑化に伴い、マイクロコントローラをベースとしたシンプルな単機能ECUから、マイクロプロセッサをベースとしたより複雑な多機能ECUへの移行が進んでいます。このため、接続性、時間同期、サイバーセキュリティ、V2X、SOTAなどの高度な機能をサポートする、より高度なソフトウェアアーキテクチャが必要となります。このような背景からAUTOSARはAdaptiveプラットフォーム（図6）を開発し、マルチコアSoC上で実行できるよう設計されたPOSIXベースのオペレーティングシステムを提供しました。オリジナルのプラットフォームはClassicと改名され、共有された低レベルの要件と仕様がFoundation標準に位置づけられました。
図 6.AUTOSAR Adaptive Platform
Adaptive Platformの最初のリリースは2017年3月で、現在は両プラットフォームが共存し、お互いを補完し合っています。Adaptive PlatformはClassic Platformの代替とは見なされておらず、両者は異なる属性を持ち、異なる実装に適しています。このフレームワークには、システムの検証を可能にするアクセプタンス・テストや、ソフトウェアの再利用と交換性を高めるための定義されたドメイン間の標準アプリケーション・インターフェイスも含まれています（図7）。同一システム内のECUはどちらのプラットフォームでも動作し、AUTOSARの通信機能によって提供されるECUの相互運用性を利用することができます。
図7.AUTOSAR標準規格。出典： https://www.autosar.org/
AUTOSARと自律走行車AUTOSAR Classic Platformは、現在市場に出ている多くのLevel 1およびLevel 2ADAS システムで使用されており、その多くはACC、AEB、LKAなどの単一機能ECUに搭載されています。AUTOSAR Adaptiveは現在、高性能コンピューティングプラットフォームにソフトウェア処理を実装した、より高度なADAS 。多くのOEMは、特にCAN/Flexray/LIN/Ethernetにわたる車両通信ネットワークを管理するために、ECUにAUTOSARを採用することを義務づけています。これは、OEMメーカーが自社のネットワークを所有し、管理する必要性に迫られていることが多いようです。ECUのコンフィギュレーションとメッセージカタログは、多数のTier 1に対して管理された方法でリリースすることが可能で、これを実現するためにAUTOSAR ECU Configuration File（ARXML）の利用が広まっています。ただし、ECUによっては、その機能に完全に適合しない場合は、この要件を免除することができます。自動運転システム を含むより複雑な車両システムに向けて、AUTOSARが多くのOEMで役割を果たすことは明らかです。レベル3自律走行機能を実装するシステムには、多くのドメインにまたがる複数のECUが含まれ、ECUの相互運用性、エンドツーエンド（E2E）機能安全メッセージプロトコル、ソフトウェアの移植性、機能安全機能により、AUTOSARフレームワーク内での開発が当然の選択となります。このことは、従来機能安全でなかったHMIシステムの移行を容易にし、すでにサポートされているAUTOSAR機能を拡張することにより、機能安全要件を満たす制御側面の移行を可能にします。
Adaptive Platformは車両ネットワーキングにおいて独占的な地位を占めていますが、複雑な自律走行機能を実装するための主要な選択肢とはならないかもしれませんし、OpenCL、Robot Operating System（ROS）、Mobileyeなど、独占的あるいはオープンソースのソフトウェアシステムが他にも数多く存在します。開発者やAUTOSARにとって幸いなことに、通信やセーフティクリティカルなフォールバックにはAUTOSARスタックを使用し、他の上位システムとのリンクにはSOME/IPやDDSなどのミドルウェアを使用することで、両者の長所を生かしたシステムを構築できます。現時点では、AV/ADAS やその他の多くの車両内システムのバックボーンはAUTOSARが提供していると言ってよいでしょう。
しかし、AUTOSARは他の多くのソフトウェアシステムを含む進化し続けるエコシステムの一部であり、より高いレベルの自律性がより集中的でゾーンベースのアーキテクチャで発展するにつれ、AUTOSARの正確な役割はまだ決定されていません。
著者についてMartin Howle はSBD Automotive のドメインプリンシプル、EE アーキテクチャ担当です。