2026.08.23 アーキテクチャ

Adaptive AUTOSARとは？Classic Platformとの違いと使い分けを実装目線で解説

Adaptive AUTOSARは、自動運転支援や車載インフォテインメントのように計算量の大きい機能を高性能なECU上で動かすため、AUTOSARが定めたプラットフォーム規格です。正式名称はAUTOSAR Adaptive Platform（AP）。従来のClassic Platform（CP）が前提にした「ビルド時にすべてを固定する」設計から離れ、POSIX系OSの上でC++アプリケーションを走らせます。この記事では公式配布のR25-11仕様書に沿って、定義と機能範囲、CPとの5項目対照、ara::com、UCMによるOTA更新、APとCPの割り当て手順を実装目線でまとめました。採用を見送る条件も示します。

まとめ｜APとCPをECU単位で振り分けるときの判断基準

APとCPは新旧の関係ではありません。公式のAdaptive Platform Design（R25-11）は、APがCPを置き換えず、相互に連携して1つの統合システムを作ると明記しています。判断の軸はそのECUが「決まった周期で決まった信号を出し続ける箱」なのか、「機能を後から足し引きする計算機」なのかという一点です。

前者ならCPです。マイコン上でOSEK系の静的OSが走り、タスクも通信経路もビルド時に確定する。CP側のOS仕様そのものはAUTOSAR OSとは？OSEK由来の仕様とスケーラビリティクラスの選び方を実装目線で解説で整理しています。ブレーキやパワートレインの制御は今後もこちら側に残ります。後者ならAP。マルチコアのSoCにPOSIX準拠OSを載せ、プロセス分離された複数のアプリケーションをOTAで入れ替えます。

閾値はこうです。出荷後の更新計画が無く、ECUのメモリがメガバイト単位に届かないなら、APを選ぶ理由はありません。他社の開発した機能を後から載せる計画があるなら、APの構成管理とOTAが効いてきます。1台のクルマで両方を同居させ、SOME/IPでつなぐのが2026年時点の標準形です。

Adaptive Platformの定義とR25-11が標準化した機能範囲

Adaptive AUTOSARは通称で、規格上の名前はAUTOSAR Adaptive Platformです。CPと同じ年次リリースに乗り、CPのLayered Software Architecture（文書ID 53）もAPのPlatform Design（文書ID 706）も、ともにR25-11という同一の番号を持ちます。

ARAの上でアプリが動く構造とファンクショナルクラスタの分類

APのアプリケーションはAdaptive Application（AA）と呼ばれ、ARA（AUTOSAR Runtime for Adaptive applications）の上で動きます。ARAは単一のライブラリではなく、ファンクショナルクラスタ（FC）と呼ぶ機能単位が提供するインタフェースの集合体です。

FCは4つに分かれます。基盤機能のAdaptive Platform Foundation、標準サービスのAdaptive Platform Services、標準化されたアプリケーションとインタフェース、車両レベル機能のVehicle Servicesです。Platform Design 4.2.2は前者をライブラリ結合型、後者をサービス型と整理している。Execution Management（EM）とCommunication Management（CM）はFoundation、UCMやDiagnosticsはServices側です。

R25-11で入った遠隔永続化とセンサーインタフェースの追加点

R25-11（2025年11月27日付）は、Remote Persistency、Sensor Interfaces、Safe Hardware Accelerationの3つを導入しました。State Management、UCM、Diagnostics、Time Synchronizationも更新され、State ManagementにはSuspend-to-RAMが加わっている。Remote Persistencyは永続データを機外へ広げる仕組み、Safe Hardware AccelerationはGPUやNPUを安全要件のある処理へ組み込む構造で、推論処理を車載側に置く設計へ直接効きます。

Communication Management側にも実装へ響く変更が入りました。イベント・トリガ・メソッド呼び出しに対するインヒビット時間の監視が追加され、SOME/IPのビットフィールド型がサポートされ、エラーコードkNetworkBindingFailureはkCommunicationFailureへ改称されています。既存コードをR25-11へ上げるとき、この改称が最初に当たる箇所です。

Classic Platformとの違いを決める5つの設計前提の対照

両者の差は機能一覧ではなく前提の差です。

OS・言語・通信・配備・安全水準で並べたAPとCPの5項目対照

下表はR25-11の仕様書に基づく対照です。

観点	Classic Platform	Adaptive Platform
OS	OSEK系の静的OS	POSIX準拠（PSE51）
主言語	C	C++（Rust版も追加）
通信	信号ベースが中心	サービス指向のara::com
配備	ビルド時に固定	マニフェストで実行時解決
想定ECU	制御系の小型マイコン	高性能な集約SoC
更新	診断経由の再書き込み	UCMによるOTA

表の右端だけを見て「APのほうが優れている」と読まないでください。CPの静的な性質は制約ではなく、実行時間とメモリ使用量を設計時に確定させる手段です。ミリ秒未満の締切を守る制御には、この確定性のほうが要る。CPの周期タスク設計にはRTOSのスケジューリングと優先度設計がそのまま当てはまります。

静的コンフィグのCPと実行時にサービスを結ぶAPの決定的な差

CPでは、どのECUのどのソフトウェアコンポーネントがどの信号を送るかがビルド時に確定します。生成されたRTEが経路を固定し、実行中に割り当てが変わることはない。

APは3段階の構成モードを持ちます。Platform Design 8.5が挙げるのは、双方が互いを知るfull static configuration、クライアントだけがサーバを知りイベント購読だけが動的になるモード、経路が未定でAPIからサービスインスタンスを選ぶfull service discoveryの3つ。安全要件のある経路は1段目に寄せ、後から機能を足す領域だけ3段目にする使い分けが実務的です。サービス契約バージョニングもあり、後方互換モードなら互換性のある別バージョンへ接続できます。

誤解しやすいのが「動的」の範囲です。実行時に決まる部分の実体は、Application Design・Execution Manifest・Service Instance Manifest・Machine Manifestの4種のモデルファイルにあります。Platform Design 3.3.6はこれをplanned dynamics（計画された動的性）と呼び、動的な振る舞いはExecution Manifestの制約範囲に限ると述べている。任意のバイナリを後から放り込める姿を想像すると設計を外します。

CPのRTEとAPのARAで分かれる生成物と責務の境目の実際

CPのRTEは、ECUごとに個別生成されるコード層です。Layered Software Architecture（R25-11）は、RTEの上でスタイルが階層型からコンポーネント型へ切り替わり、上位インタフェースは完全にECU非依存になると説明しています。BSWはServices Layer、ECU Abstraction Layer、MCALの3層にComplex Driversが並ぶ構成。

APにこの意味でのRTEはありません。相当する役割はARAが担い、通信部分をCMが持つ。生成されるのはRTE一式ではなく、サービスインタフェース定義から作られるプロキシとスケルトンのクラス群だけです。粒度が違うため、CPの開発フローをそのまま持ち込むとビルド構成でつまずきます。CP側のRTEが何を生成し、SWC間の通信をどう実装するかはAUTOSAR RTEとは？生成される実行環境の中身とSWC間通信を実装目線で解説で整理しました。

ara::comのサービス指向通信とPSE51に絞られたOS要件

APの実装で最初に触るのがara::com、Communication Managementのインタフェースです。理解が浅いと、SOA化したつもりで信号ベースの設計を引きずります。

C++バインディングが生成するプロキシとスケルトンの役割分担

CMは上位の言語バインディングと下位のネットワークバインディングに分かれます。言語バインディングはサービスのメソッド・イベント・フィールドを対象言語の識別子へ写す層で、C++では定義から型安全なクラスが生成される。

提供側に生成されるのがService Provider Skeleton、利用側がService Requester Proxyです。スケルトンは抽象基底クラスで、サービス実装はこれを継承して中身を書く。プロキシはそのまま使えます。メソッド呼び出しは同期と非同期の両方を持ち、非同期はara::core::Futureで結果を受け取る。サーバが未完成でもクライアント側を書けるよう、生成器がモッククラスを作る設定も許されています。

SOME/IPとDDSを含む5種のネットワークバインディングの選択

ネットワークバインディングは、サービスのデータを実際の通信路へどう載せるかを決めます。R25-11時点でCMがサポートするのは次の5種です。

SOME/IP：車載Ethernet上のサービス指向通信。CP側も取り込んでおり、AP・CP間の橋渡しに使う
DDS：OMG策定の分散データ配信。既存のロボティクス資産と接続する構成で選ばれる
IPC：同一マシン内のプロセス間通信。ネットワークへ出さない経路に使う
Signal PDUとSignal-Based Static：CANのような信号ベースの領域と接続する橋渡し

実務でまず選ぶのはSOME/IPとIPCの2つです。同じコードのまま、配置が同一マシン内か別ECUかでバインディングだけを差し替えられる。信号ベース側と混ぜる設計では、CANのフレーム構造とアービトレーションを踏まえて線引きします。方式そのものの選定は車載ネットワークの方式比較で扱いました。

PSE51に制限されるアプリとプロセス分離が生む実装上の制約

APのOS要件は「Linuxが動けばよい」ではありません。Platform Design 4.1.3は、AAが使えるOSインタフェースをPSE51に限ると定めています。PSE51はIEEE1003.13が定めるPOSIXの単一プロセスプロファイルで、移植性とアプリケーション間の干渉排除を狙って選ばれた。ファンクショナルクラスタ側はPSE51に縛られません。

帰結は具体的です。PSE51はIPC機能を含まないため、AA同士が直接やり取りする手段は規格上ありません。Platform Design 4.1.5は、CMが唯一の明示的インタフェースだと書いています。共有メモリでつなぐ設計は規格の外へ出る。

スケジューリングポリシーの標準はSCHED_FIFOとSCHED_RRの2つです。SCHED_DEADLINEやOS固有のポリシーも許容されますが、AP実装をまたいだ可搬性は失われる。OS側ではプロセスごとにアドレス空間が分離され、CPU時間やメモリの上限が課されます。POSIX準拠かつ安全認証を持つOSの実例がQNXのマイクロカーネル構造と安全認証です。

UCMとV-UCMが担うOTA更新とソフトウェアクラスタの単位

APを選ぶ理由の大半はここに集約されます。出荷後の入れ替えを前提とする構造が規格に組み込まれている点です。

ソフトウェアクラスタ単位で入れ替えるUCMのパッケージ管理方式

UCMは、AP上のソフトウェアの追加・更新・削除と記録を受け持つプラットフォームサービスです。Platform Design 13.1は、その役割をLinuxのdpkgやYUMに近いとしたうえで、安全性と機密性のための機能が加わっていると述べています。

管理の粒度はソフトウェアクラスタです。マシン上で原子的に更新できる単位で、それぞれがUCMの報告するバージョンを持つ。1つのソフトウェアパッケージはちょうど1つのクラスタを対象とし、追加・更新・削除のいずれかを含みます。設計時に決めるべきはこの単位の切り方で、細かく割れば更新は軽くなる一方、依存関係の検証が増える。粗く括れば1行の修正でも大きなパッケージを配ることになります。

V-UCMが車両全体の更新キャンペーンを取りまとめる役割分担

1台のクルマには複数のAPマシンが載ります。それぞれのUCMを個別に叩いていては車両としての整合が取れない。規格はV-UCM（Vehicle UCM）を、車両内の複数UCMへパッケージを配って調整する標準クライアントとして定義しています。

V-UCMの周辺には標準化されたアプリケーションが並びます。バックエンドと通信するOTAクライアント、運転者へ確認するVehicle Driver Interface、車両状態を判断するVehicle State Manager、Classic AUTOSARのECUへ書き込むFlashing Adapterの4つ。CP側のECUはこのFlashing Adapter経由で更新され、AP側のOTA基盤にCPがぶら下がる形です。

キャリブレーションとバリアントコーディングが外れる制約の影響

ここは公式が明確に線を引いている箇所です。Platform Design 13.1は、UCMが更新と構成管理を1つのパッケージ管理インタフェースへ統合しており、設定値を1つ変えるだけでもソフトウェアパッケージを作る必要があると述べている。結果として新しいクラスタのバージョンが生まれます。

そのうえで、ソフトウェアバージョンを変えないのが通例であるキャリブレーションやバリアントコーディングのような用途はサポートされない、と明記されています。仕向け地設定や個体ごとのパラメータ調整をUCMに載せる前提で設計すると規格の外へ出る。この種の用途は診断サービス側か、アプリケーション独自の永続化データへ寄せてください。

SDV前提でAPとCPを同居させるE/E構成とECU割り当て手順

ソフトウェア定義車両（SDV）と呼ばれる構成の実体は、「集約ECUにAPを置き、末端にCPを残してEthernetでつなぐ」E/E構成の再編です。

高性能ECUにAPを置き末端の制御はCPへ残す割り当ての基準

出発点は機能ではなくハードウェアの制約です。APはマルチプロセス対応のPOSIX系OSを要求し、プロセスごとに独立したアドレス空間とリソース上限を与える。MMUを持つプロセッサと相応のRAM・ストレージが前提です。MMUを持たないマイコンの制御はCPの領域で、ボディ系やエンジン・ブレーキは今後もCPで書かれ続けます。

SOME/IPで両プラットフォームをつなぐゲートウェイの設計

APとCPの接続点は多くの場合SOME/IPです。CPは既にSOME/IPを取り込み、AP側のCMもこれを持つため、両者は同じサービスの語彙で会話できる。

CANやLINしか持たない末端ECUとつなぐ場合は、Signal PDUかSignal-Based Staticのバインディングを使い、信号とサービスの変換をどこで行うかを決めます。変換をAP側のアプリケーションで書くか、ゲートウェイECUのCP側へ閉じるかで保守負荷が変わる。目安は、その信号がOTAで意味を変え得るかどうかです。変わるならAP側、車両の一生を通じて固定ならCP側に置きます。

安全水準と締切時間から配置先を判定する4条件と適用の優先順位

次の順で判定すると迷いが減ります。1つでも該当したらCP側に置いてください。

締切がミリ秒未満で、超過が即座に危険側へ働く制御か
対象プロセッサがMMUを持たず、RAMがメガバイト単位に届かないか
車両の一生を通じて仕様が固定で、出荷後の更新計画が無いか
既存のCP資産をそのまま流用でき、書き換えの投資回収が見込めないか

4条件のいずれにも当てはまらず、計算量が大きいか後から機能を足す前提がある場合にだけAPを選びます。AP側の安全要件は、E2E保護とPlatform Health Managementの監視で受け止める設計です。

Adaptive AUTOSARを採用しない条件と受託開発で引き受ける範囲

他の解説記事が触れない部分なので、条件を示して言い切ります。APは強力ですが、投資対象としては重い。

量産台数と更新頻度が閾値に届かない案件でAPを見送る3つの条件

次の3つが揃う案件では、APを採用しません。第1に、量産台数が数千台規模に留まり、AP実装ベンダのライセンス費とツールチェーン費を台数で割れないこと。第2に、出荷後のソフトウェア更新が年1回未満、あるいは計画自体が無いこと。第3に、社内にC++とPOSIXの実務経験を持つ技術者がおらず、外部から継続的に確保する目処も立たないことです。

この3条件に当てはまる案件で無理にAPを入れると、規格の学習と認証対応にコストが吸われ、機能へ回る工数が痩せる。台数の限られる建機や農機の制御系が該当しやすい。CPで組むか、AUTOSARを使わずPOSIX系RTOS上に自前のミドルウェアを載せる構成のほうが総額を説明できます。もう1つ見送るのは「SOA化したいから」だけでAPを選ぶ場合。サービス指向の設計自体はAPが無くても実現でき、APの固有価値は標準化されたOTA更新の単位とマニフェストによる配備制御にあります。

AP案件で受託側が引き受けやすい層と手を出さない層の線の引き方

受託開発として関われる層は、下に行くほど参入障壁が上がります。引き受けやすいのは、ARAの上に載るアプリケーション開発、SOME/IPで公開するサービスインタフェースの設計、バックエンド側のOTA配信基盤、車両データを機外で処理するシステム。AP実装そのもの（FCの実装や安全認証の取得）は専業ベンダの領域で、既製スタックを調達する前提で見積もります。開発工程とツールチェーンの組み立て方はAUTOSAR開発の工程とは？ARXMLの受け渡しとツールチェーンを実装目線で解説で整理しています。

当社が引き受けるのは、車両から上がったデータをクラウド側で処理する層と、センサーを含む機器側のソフトウェア開発です。車載機と機外システムの境界を含めて設計する案件は、AI・IoTソリューション開発として相談を受け付けています。ASIL認証が必要な制御ソフトウェアは対象外です。

よくある質問

実装者から出やすい質問を、R25-11時点の仕様に基づいて整理しました。

Adaptive AUTOSARとClassic AUTOSARはどちらが新しい規格ですか？

Adaptive Platformのほうが後発ですが、Classic Platformの後継ではありません。両者は同じ年次リリースで並行更新され、R25-11でもCPのLayered Software Architecture（文書ID 53）とAPのPlatform Design（文書ID 706）がともに2025年11月27日付で出ています。公式はAPがCPを置き換えないと明記しており、制御系のECUは今後もCPで作られます。

Adaptive Platformを動かすにはLinuxが必要ですか？

Linuxである必要はありません。規格が要求するのは、マルチプロセス対応のPOSIX互換OSと、アプリケーションへPSE51（IEEE1003.13の単一プロセスプロファイル）を提供することです。仕様書はPOSIX準拠OSの例としてLinuxを挙げるにとどめ、限定はしていない。安全認証が要る構成では認証実績のある商用RTOSが選ばれます。

Adaptive AUTOSARの開発言語はC++だけですか？

基本はC++です。ARAのインタフェースはC++で定義され、規約としてAUTOSAR C++14（ISO/IEC 14882:2014に対するガイドライン）が使われてきました。この規約は2019年にMISRA側との統合が発表され、MISRA C++:2023へ取り込まれている。加えてRustで書く説明文書（文書ID 1079）がR23-11から収録され、R25-11ではRust実装コードの公開が案内されました。

ara::comとSOME/IPは何が違うのですか？

層が違います。ara::comはCMがアプリケーションへ見せるC++のAPIで、サービスのメソッド・イベント・フィールドを型付きのプロキシとスケルトンとして扱う。SOME/IPは、そのデータをネットワーク上でどう表現するかを決めるバインディングの1つです。R25-11ではDDS、IPC、Signal PDU、Signal-Based Staticも選べ、コードを変えずに差し替えられます。

AUTOSARの仕様書はどこから入手できますか？

autosar.orgの標準ページから、リリース番号ごとにPDFを直接ダウンロードできます。会員登録や有償契約は不要です。最初に読むべきなのは、全体像のExplanation of Adaptive Platform Design（文書ID 706）と、技術アーキテクチャを扱うExplanation of Adaptive Platform Software Architectureの2本。各機能の詳細はSWS系の文書に分かれています。