AUTOSAR Adaptive vs Classic — 何が違い、どう共存するのか

AUTOSAR、ここで一度整理しましょう

自動車ソフトウェア開発をしていると、AUTOSARという言葉を避けて通ることはできません。しかし「AUTOSARとは正確に何か」と聞かれると、すっきりと説明するのは簡単ではありません。ClassicがあってAdaptiveがあって、違うことはわかるけれど、具体的に何が違うのか、なぜ2つが別々に存在するのかを正確に知っている人は意外と少ないです。

この記事で一度整理してみましょう。

AUTOSARとは？

AUTOSAR（AUTomotive Open System ARchitecture）は、自動車ソフトウェアの標準アーキテクチャです。2003年にヨーロッパの主要OEMとTier1部品メーカーが共同で設立しました。現在は世界中で350以上のパートナー組織が参加しているグローバルコンソーシアムです。

核心的な目的はシンプルです。自動車のECU（電子制御装置）に搭載されるソフトウェアを標準化し、ハードウェアが変わってもソフトウェアを再利用できるようにすることです。簡単に言えば、「ハードウェアとソフトウェアを分離する」というのがAUTOSARの根本的な哲学です。

しかし、自動車の進化に伴い問題が生じました。初期に作られた標準では自動運転やコネクテッドカーといった新しい要件に対応できなくなったのです。そこで登場したのがAdaptive Platformです。

Classic Platform — 実績のある基本

Classic Platform（CP）はAUTOSARの元祖です。2003年の設立以降着実に発展してきたプラットフォームであり、現在量産車に搭載されているAUTOSARベースのソフトウェアのほとんどはCPで開発されています。

どこで使われるのか？

CPはDeeply Embedded ECUに最適化されています。エンジン制御、トランスミッション制御、ブレーキ（ABS/ESC）、エアバッグ、ボディコントロールといった領域です。これらのECUの共通点は、リアルタイム性が極めて重要であるということです。ブレーキ制御が数ミリ秒でも遅れれば事故につながります。

核心的な特性

CPの最大の特徴は静的構成（Static Configuration）です。ビルド時にすべてが決定されます。どのソフトウェアコンポーネントがどの順序で実行されるか、メモリをどれだけ使うか、通信経路はどうなっているかが、すべてコンパイル時点で確定します。

なぜこれが重要かというと、リアルタイム保証が実現できるからです。マイクロ秒単位のHard Real-Time応答が可能で、ASIL-D（ISO 26262の最高安全等級）にまで対応できます。ランタイムで動的に何かが変わるとタイミング保証が難しくなりますが、CPはそのような不確実性を根本的に排除しています。

通信方式

CPはCAN、LIN、FlexRayといった従来の車載ネットワークを使用します。これらのネットワークは帯域幅は低いものの、リアルタイム伝送が保証されており、自動車業界で数十年にわたって検証された技術です。

Adaptive Platform — 新しい時代の要求

Adaptive Platform（AP）は2017年に最初のリリース（R17-03）が登場しました。CPとは完全に異なる設計哲学を持っています。

なぜ作られたのか？

自動運転（ADAS/AD）、コネクテッドカー、OTA（Over-The-Air）アップデートといった機能を実装するには、高性能コンピューティングが必要です。カメラ、ライダー、レーダーから入ってくる大量のセンサーデータをリアルタイムで処理し、複雑なAIアルゴリズムを実行する必要があります。CPの静的アーキテクチャではこれに対応できません。

APはこのような高性能コンピューティングECUのために設計されました。POSIX互換オペレーティングシステム（通常はLinuxベース）上で動作し、C++14以上の現代的な言語を使用します。

核心的な特性：SOA

APの最も核心的な特性はSOA（Service-Oriented Architecture）、サービス指向アーキテクチャです。CPではソフトウェアコンポーネント間の通信が静的に接続されているのに対し、APではサービスを動的に発見して接続します。

実務ではこのような形です。カメラサービスが「物体認識データを提供できる」とネットワークに通知し（Service Discovery）、自動運転判断モジュールがそのサービスを見つけて動的に接続します。新しいセンサーが追加されたりアルゴリズムが更新されても、システム全体を再ビルドせずに該当サービスだけを交換できます。

ARA — 標準API

APはARA（AUTOSAR Runtime for Adaptive Applications）という標準APIレイヤーを定義しています。アプリケーションはARAを通じてプラットフォームサービスにアクセスします。通信管理（Communication Management）、実行管理（Execution Management）、状態管理（State Management）、診断（Diagnostics）といった機能がARAを通じて提供されます。

核心はこれです。ARA上で開発したアプリケーションは、ARAを実装したどのプラットフォームでも動作できます。ハードウェアやOSが変わっても、アプリケーションコードを変更する必要がありません。

通信方式

APは主にAutomotive Ethernetを使用し、SOME/IP（Scalable service-Oriented MiddlewarE over IP）プロトコルで通信します。SOME/IPはサービスディスカバリー、イベントサブスクリプション、リモートプロシージャコールといったSOA通信パターンをサポートします。イーサネットベースのためCANの数十〜数百倍の帯域幅を提供します。

CP vs AP — 核心的な違いのまとめ

設計哲学

• CP：静的構成、ビルド時にすべてが決定
• AP：動的構成、ランタイムでサービス発見および接続

対象ECU

• CP：Deeply Embedded ECU（エンジン、トランスミッション、ブレーキ、エアバッグ）
• AP：High-Performance Computing ECU（ADAS/AD、インフォテインメント、セントラルゲートウェイ）

リアルタイム性

• CP：Hard Real-Time（マイクロ秒単位）、ASIL-D対応
• AP：Soft Real-Time、高性能データ処理に最適化

オペレーティングシステム

• CP：AUTOSAR OS（OSEKベース、専用RTOS）
• AP：POSIX互換OS（Linuxベース）

開発言語

• CP：C
• AP：C++14以上

通信

• CP：CAN、LIN、FlexRay
• AP：Automotive Ethernet、SOME/IP

アップデート

• CP：全体リフラッシュが必要
• AP：個別サービス単位のアップデートが可能（OTA対応）

競合ではなく共存

ここで必ず押さえておくべきことがあります。APはCPを代替するものではありません。両者は共存し、互いに協力します。

現実的に考えれば当然です。ブレーキ制御をLinuxベースのAPに移す理由はありません。マイクロ秒単位のHard Real-Timeが必要な安全クリティカルな機能は、CPがすでに完璧に処理しています。一方で、自動運転の認知・判断アルゴリズムをCPの限られたリソースで実行することもできません。

実際の車両では、CP ECUとAP ECUがゲートウェイECUを介して接続されます。例えば、APベースのADAS ECUが「緊急制動が必要」と判断すると、ゲートウェイを通じてCPベースのブレーキECUに制動命令が伝達されます。APはEthernetで、CPはCANで通信し、ゲートウェイがプロトコルを変換します。

2019年のR19-11リリースからCPとAPは毎年同時にリリースされています。最新のリリースは2024年12月のR24-11です。このリリースではVISS（Vehicle Information Service Specification）プロトコルベースのAutomotive API Gatewayが新たに導入され、車両内外のサービス間接続がさらに拡張されました。

SDV時代、Adaptiveの役割はさらに大きくなる

SDV（Software-Defined Vehicle）時代に移行するにつれて、車両アーキテクチャが変化しています。従来は機能ごとにECUが分散していましたが、現在はセントラルコンピューティングユニット（Central Computing Unit）が複数の機能を統合管理する方向に進んでいます。

このセントラルコンピューティングユニットでAdaptive Platformが核心的な役割を果たします。SOAアーキテクチャのおかげで、機能をサービス単位で管理し、OTAでアップデートし、新しいサービスを追加できます。スマートフォンでアプリをインストールしてアップデートするのと同様の概念が車両にも適用されるのです。

だからといってCPがなくなるわけではありません。安全クリティカルな機能、リアルタイム制御、低消費電力ECUでは依然としてCPが核心であり、ASPICEプロセス品質基準もCPとAPの両方に適用されます。今後もしばらくはCP + AP共存構造が維持されるでしょう。

PopcornSARのAdaptive AUTOSARソリューション

PopcornSARはAdaptive AUTOSAR専門企業として、APベースの開発に必要なソリューションを提供しています。

PARAはPopcornSARが開発したAdaptive AUTOSARミドルウェアプラットフォームです。ARA仕様を実装しており、PARA上で開発したアプリケーションは標準的なAdaptive AUTOSAR環境で動作します。通信管理、実行管理、診断などAPの核心サービスを提供します。

PAIOはAIベースのAUTOSAR設計ツールで、Network TopologyからBSW設定までARXMLを自動生成します。自然言語で要件を入力するだけで設計作業を自動化し、開発時間を大幅に短縮します。

AutoSAR.ioはARXML設計ツールで、CPとAPの両方をサポートします。システムアーキテクチャの設計とARXMLの管理に使用されます。

これらをまとめたのがAdaptive AUTOSAR Tool Kitです。設計（PAIO / AutoSAR.io）→ ランタイム（PARA）を1つのソリューションとして提供し、Adaptive AUTOSAR開発の全工程をカバーします。

各製品の詳細はPARA製品ページとPAIO製品ページでご確認いただけます。導入検討や技術的なお問い合わせはお問い合わせからお気軽にご連絡ください。