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