「AUTOSAR」とは何か？

はじめに

AUTOSAR (AUTomotive Open System ARchitecture) とは、欧州を中心に2003年頃から提唱された車載ソフトウェア標準化の取り組みです。もともとは車載ソフトウェアの再利用性を高め、効率化を図ることを目的としたフレームワークでしたが、現在では ISO26262 (機能安全) や ISO21434 (サイバーセキュリティ) などの国際規格への準拠を容易にする基盤として広く普及しています。本稿では、AUTOSAR がどのように誕生し、普及し、その理想と現実がどのように乖離しているのかを概観し、今後の動向について考察いたします。

AUTOSAR CPの誕生

AUTOSAR は、車載ソフトウェア開発の複雑化を解消し、効率化を図るために欧州の OEM を中心に設立されたコンソーシアムから生まれました。当初提唱された AUTOSAR Classic Platform (CP) は、ソフトウェアの構造を標準化し、ソフトウェアコンポーネント (SWC) の再利用を促進することでモデルベース開発 (MBD) を推進することを目的としていました。具体的には、RTE (Runtime Environment) を介したコンポーネント間通信の抽象化、標準化された BSW (Basic Software) スタックの提供などがあります。これにより、OEM やサプライヤーは共通プラットフォーム上でアプリケーションを開発・再利用できるようになるという理想が掲げられていました。

AUTOSAR CPの普及のきっかけ

チェロキー事件

2015年、ジープ・チェロキーを遠隔操作で停止させるという衝撃的なハッキング事件が発生し、自動車業界におけるサイバーセキュリティの重要性が広く認知されるようになりました。これをきっかけに、車載ソフトウェアのセキュリティ基準である ISO21434 が策定され、車載 ECU のソフトウェア開発におけるセキュリティ要件への対応が必須となりました。このセキュリティ対応を容易にするため、AUTOSAR CP の標準化された BSW スタックが注目され、一気に業界標準としての地位を確立することとなりました。

ベクターの覇権化

ベクター社 (Vector Informatik) はドイツの老舗ツールベンダーであり、もともとは CAN 解析ツール (CANoe) などを提供していましたが、AUTOSAR の登場により DaVinci Configurator や MICROSAR (BSW スタック) など、AUTOSAR に準拠した開発環境をトータルで提供するようになりました。これが OEM 側から標準開発環境として指定されることで、Tier1 サプライヤーはベクター製品を事実上採用せざるを得なくなり、ベクターが車載ソフトウェア業界における覇権を握ることになりました。

AUTOSAR CPの現実

SOLIDの原則との関係

AUTOSAR CP の理想は SOLID 原則 (単一責任原則や開放閉鎖原則などのオブジェクト指向設計原則) を無視する考えで作られたものではありません。しかし実際の現場では、プロジェクト固有のコードが MICROSAR などの BSW 内部に「ユーザーコード」として埋め込まれ、BSW とアプリケーションの責任境界が曖昧化し、SOLID 原則に反する状態が多発しています。これは、本来であれば分離されるべき CDD (Complex Device Driver) として管理すべき固有コードが、手軽さやライセンス費用の制約により BSW 内に直接埋め込まれてしまっているためです。

MBDの理想と現場の乖離

AUTOSAR CP はもともとモデルベース開発 (MBD) を推進するために構築されました。しかし実務では、複雑なツール (DaVinci Developer) を使った SWC 設計や RTE 生成が敬遠され、BSW スタックのみを使いフルスクラッチで開発されるケースが非常に多いです。その結果、AUTOSAR のメリットである再利用性や抽象化が活かされず、「形式的 AUTOSAR」が増えてしまいました。ISO26262 や ISO21434 への対応をサプライヤー自らで負うコストを委託するために AUTOSAR スタックが利用されるというような、MBD の理念から外れた用いられ方が一般的であるという皮肉な現実が生じています。

AUTOSAR APの誕生

Classic Platform (CP) の抱えた問題に対処するため、Adaptive Platform (AP) が2017年頃に登場しました。AP は、MBD という設計思想を捨て去り、サービス指向アーキテクチャ (SOA) とアジャイル開発を前提とした POSIX ベースのプラットフォームとなりました。RTE による静的構成ではなく、SOME/IP や DDS を使った動的なサービス通信を採用し、再起動やアップデートをアプリケーション単位で可能にしました。AP は CP の反省から、現場での柔軟性と機動力を重視したプラットフォームとして再設計されたのです。

AUTOSARの今後

今後は CP と AP が共存し、用途に応じて使い分けられるハイブリッド構成が主流となることが予測されます。ADAS や自動運転、OTA アップデートなど動的で柔軟な対応が求められる領域は AP が中心となり、従来の車両制御系や安全機能系は引き続き CP が採用されるでしょう。一方で、形式化した CP 開発の課題解消のために、CDD の適切な分離やツールの改良が進む可能性もあります。

まとめ

AUTOSAR はもともとソフトウェア工学の理想に基づいたモデルベース開発のフレームワークとして誕生しました。しかし現実の現場では、ISO 対応やベクターのツール戦略などにより理想とは異なる形で普及してきました。こうした乖離を経て登場した Adaptive Platform は、理想よりも実務に即した設計へと大胆に舵を切りました。今後は、CP と AP それぞれの強みを活かした形で AUTOSAR が発展していくことが期待されます。