AUTOSAR (自動車標準ソフトウェアアーキテクチャ)

1. 概要

A. 定義

AUTOSAR(AUTomotive Open System ARchitecture)とは、車両の電子制御ユニット(ECU)のソフトウェアをハードウェアから分離(decoupling)し、標準化された階層構造・インタフェース・交換フォーマットによって再利用・移植・協業を可能にするオープンな自動車ソフトウェアプラットフォーム標準である。2003年にBMW・Bosch・Continental・Daimler・Ford・GM・PSA・Toyota・Volkswagenらが結成した開発パートナーシップ(development partnership)から出発し、「協力する領域は標準化し、競争する領域は差別化する(Cooperate on standards, compete on implementation)」という哲学を基礎とする。

AUTOSARが登場した背景は、車両の急激な「ソフトウェア化」にある。1990年代まで機械・油圧で実現されていた制動・操舵・駆動機能が電子制御へ移行するにつれ、高級車一台に搭載されるECUは数十〜百数十個、ソフトウェア規模は数千万〜1億行(LoC)規模へと膨張した。ところが各ECUのソフトウェアが特定のマイクロコントローラ・サプライヤに強く結合(tightly coupled)していたため、部品を替えたり機能を他のECUへ移したりするたびにソフトウェアを事実上書き直す非効率が累積した。完成車メーカー(OEM)と一次サプライヤ(Tier-1)、半導体メーカー(Tier-2)がそれぞれ異なる構造で開発したため、統合・検証コストやリコールのリスクも増大した。

したがってAUTOSARの中核的な発想は、「アプリケーションはハードウェアを知らなくてよいようにする」というハードウェア抽象化と、「部品のように組み立て可能なソフトウェアコンポーネント(SWC)」というモジュール化である。アプリケーションロジックを仮想機能バス(VFB)上のコンポーネントとして記述し、その下に標準化されたミドルウェアが通信・メモリ・診断・ネットワークを担うよう分離すれば、同じ機能を別のECU・別の半導体へ再配置してもアプリケーションコードに手を加えず再利用できる。これは単なるコード再利用を超え、OEM-Tier-1-Tier-2間の役割分担と協業契約を標準インタフェースで固定するという産業ガバナンスの意味を持つ。

B. 二世代のプラットフォーム — ClassicとAdaptive

AUTOSARを正確に理解するには、性格の異なる二つのプラットフォームを区別しなければならない。2003年から発展してきたClassic Platform(CP)は、制動・エンジン・エアバッグのように実時間・高信頼が要求される深層組込み(deeply embedded)ECUのための静的(static)構造である。OSEK/VDXベースの実時間OS上であらゆる資源がビルド時点で確定し、決定性(determinism)と機能安全([[iso-26262]])を最優先とする。一方、2017年に発表されたAdaptive Platform(AP)は、自動運転・インフォテインメントのように高性能演算と柔軟性を要する高性能コンピューティング(HPC)ECUのための動的(dynamic)構造で、POSIXベースのOSとC++、サービス指向アーキテクチャ(SOA)を採用して実行中のサービス発見・OTA更新を支援する。

この両者を分ける根本的な理由は、「扱う問題の性格」が異なるためである。車輪を制御するソフトウェアには1ミリ秒単位の予測可能な応答と「決して止まらないこと」が生命線であるため、静的構成と単純な実行モデルが有利である。逆に、カメラ数十個の映像を深層学習で融合し経路を計画するソフトウェアには、マルチコア・GPUを活用する豊かなランタイムと、機能を継続改善する更新能力が必要である。AUTOSARは一つの構造で二つの要求を同時に満たそうとはせず、目的の異なる二つのプラットフォームを共存させつつ共通基盤(Foundation)で相互運用性を保証する道を選んだ。この分離こそAUTOSAR全体構造を理解する出発点である。

2. 全体構造 — Classic・Adaptive・Foundationと方法論

AUTOSAR標準は三つの標準束で構成される。Classic Platform(CP)、Adaptive Platform(AP)、そして両プラットフォームが共有する共通成果物・規約を定義するFoundation(FO)である。これに加え、ソフトウェアをどのように記述・構成・配備するかを定義する方法論(Methodology)と、全成果物を機械可読に交換するXMLフォーマットであるARXML(AUTOSAR XML)が全工程を貫く。すなわちAUTOSARは「実行プラットフォーム」二つと「共通規約」一つ、そしてこれらを束ねる「開発方法論」から成る体系である。

graph TD
  subgraph STD["AUTOSAR標準体系"]
    FO["Foundation (FO)<br/>共通要求・規約・プロトコル(SOME/IP等)"]
    subgraph CP["Classic Platform (CP)"]
      CPA["深層組込みECU<br/>静的構成・実時間・機能安全"]
    end
    subgraph AP["Adaptive Platform (AP)"]
      APA["高性能コンピューティングECU<br/>動的・SOA・OTA"]
    end
    METH["方法論 & ARXML<br/>モデルベース記述・構成・交換"]
  end
  FO --> CP
  FO --> AP
  METH --> CP
  METH --> AP
  CP -. "SOME/IP・DDSゲートウェイ" .-> AP

上の構造図が示すように、Foundationは両プラットフォームが互いに通信・連携できるよう、共通プロトコルとメタモデルの最小の積集合を定義する。例えばサービス指向通信プロトコルSOME/IPはFoundationに規定され、ClassicとAdaptiveが同じ規約でイーサネット上でサービスをやり取りできるようにする。かつては各プラットフォームが独自に要求を重複定義していたが、Foundationの導入により一度定義した共通規約を双方が参照することになり、重複と不一致を減らしCP↔AP混成アーキテクチャの相互運用性を確保した。

方法論とARXMLの役割も核心である。AUTOSARはコードを直接書く前に、ソフトウェアコンポーネント・ポート・インタフェース・ECU資源をARXML形式のモデルとして先に記述し、このモデルからRTE・通信スタックの構成コードを自動生成する。実際の量産プロジェクトでは、OEMがシステム設計をARXMLでTier-1へ渡し、Tier-1はこれを受けてECU構成(ECU Configuration)を細分化し、半導体メーカーが提供したMCAL設定と合わせて最終バイナリを生成する。このようにARXMLは会社間の設計責任を引き渡す契約文書であり自動化の入力であって、AUTOSARが単なるコード規約ではなく「モデルベース協業方法論」であることを明らかにする。

3. Classic Platform — 階層構造と構成要素

Classic Platformの骨格は徹底した階層化(layered architecture)である。最上段のアプリケーション層(Application Layer)には、制動制御・エンジントルク管理のような機能ロジックがソフトウェアコンポーネント(SWC, Software Component)単位で入る。その下のランタイム環境(RTE, Runtime Environment)がコンポーネント間の通信と下位の基本ソフトウェア呼び出しを中継し、最下段の基本ソフトウェア(BSW, Basic Software)が通信・メモリ・診断・OS・ドライバを提供し、最下層のマイクロコントローラがこれを実行する。

graph TD
  APP["Application Layer<br/>SWC(制動・操舵など機能ロジック)"] --> RTE["RTE (Runtime Environment)<br/>VFB実装・コンポーネント間通信中継"]
  RTE --> SVC["Services Layer<br/>OS・通信・診断・メモリ・NM"]
  SVC --> ECUAL["ECU Abstraction Layer<br/>オンボード機器・ドライバ抽象化"]
  ECUAL --> MCAL["MCAL<br/>Microcontroller Abstraction Layer"]
  RTE -. "直接アクセス" .-> CDD["Complex Device Drivers (CDD)<br/>高速・特殊ハードウェア直接制御"]
  CDD --> MCU
  MCAL --> MCU["Microcontroller (ハードウェア)"]

この構造の核心概念は仮想機能バス(VFB, Virtual Function Bus)である。アプリケーション開発者は、自分のSWCがどのECU・どの通信線(CAN/LIN/FlexRay/Ethernet)に載るかを知らぬまま、「ポート(port)」を通じて他のコンポーネントと論理的にのみ接続すると仮定して設計する。実際の物理的配置が決まると、RTEがVFBを実装(realize)し、同一ECU内なら関数呼び出しで、別ECUなら通信スタックを経たメッセージで自動的に接続する。おかげで「制動力信号を送るコンポーネント」をA ECUからB ECUへ移してもアプリケーションコードは変わらない — これがAUTOSARの掲げる再配置(relocatability)の実体である。

基本ソフトウェア(BSW)はさらに三層と一つの例外に分かれる。最も下のMCAL(Microcontroller Abstraction Layer)は、特定MCUのレジスタ・周辺装置(ADC・PWM・SPI等)を標準APIで包み、上位が半導体の種類を知らぬようにする。その上のECU抽象化層(ECU Abstraction Layer)はボードに実装された外部素子(センサ・トランシーバ等)を抽象化し、最上位のサービス層(Services Layer)はOS・通信管理・診断(UDS)・メモリ(NvM)・ネットワーク管理のようなプラットフォームサービスを提供する。ただし高速カメラや特殊アクチュエータのように標準層の遅延を許容できない場合のため、層を迂回してハードウェアを直接制御する複合デバイスドライバ(CDD, Complex Device Driver)を例外として許容する。この「MCALで半導体を抽象化する」設計のおかげで、OEMは半導体サプライヤをルネサスからインフィニオンへ替えても上位アプリケーションをそのまま維持できる。

BSW層	役割	代表モジュール・例	抽象化対象
Services Layer	プラットフォームサービス提供	OS, Com, Dcm/Dem(診断), NvM, NM	ハードウェア独立サービス
ECU Abstraction	オンボード機器の抽象化	ドライバ上位ラッパー, I/Oハンドラ	ボード実装の外部素子
MCAL	マイクロコントローラの抽象化	ADC・PWM・CAN・SPIドライバ	MCU内部周辺装置
CDD(例外)	標準層を迂回し直接制御	高速センサ・特殊アクチュエータ	遅延に敏感なハードウェア

Classic Platformの実行モデルは、OSEK/VDXに由来する静的・優先度ベースの実時間OSである。タスク・イベント・資源がビルド時点で固定され、動的メモリ割当を避け、メモリ保護(MPU)でASIL混在時の干渉を防ぐ。こうした静的性格は自動運転のような柔軟性とは相反するが、「何があっても10ミリ秒以内に制動命令が出なければならない」という決定性・安全性の要求には最適である。実際、乗用車のほぼすべてのパワートレイン・シャシ・ボディECUが今もClassic Platform上で動作する。

4. Adaptive Platform — サービス指向アーキテクチャと動的実行

Adaptive PlatformはClassicの限界、すなわち「静的・単一目的・更新困難」を正面から覆す。中核の実行環境はARA(AUTOSAR Runtime for Adaptive Applications)であり、POSIX(PSE51プロファイル)ベースのOS上でC++で書かれたアプリケーションが、機能クラスタ(Functional Cluster)が提供する標準APIを呼び出して動作する。マルチコア・仮想メモリ・動的ロードを前提とするため、カメラ・ライダ融合や高精細インフォテインメントのように演算量の大きな作業を扱える。

graph LR
  subgraph APP["Adaptiveアプリケーション (C++)"]
    A1["知覚(Perception)"]
    A2["経路計画(Planning)"]
  end
  subgraph ARA["ARA: 機能クラスタ"]
    COM["ara::com<br/>サービス指向通信"]
    EXEC["ara::exec<br/>実行管理・状態"]
    UCM["ara::ucm<br/>OTA更新"]
    DIAG["ara::diag / per / crypto"]
  end
  OS["POSIX OS (PSE51)"]
  A1 --> COM
  A2 --> COM
  A1 --> EXEC
  COM -->|"SOME/IP · DDS"| NET["車両イーサネットバックボーン"]
  EXEC --> OS
  UCM --> OS
  DIAG --> OS

Adaptiveの最大のパラダイム転換はサービス指向通信(ara::com)である。Classicが「信号(signal)」を固定された経路で周期送信する方式であるのに対し、Adaptiveはサービス提供者がサービスを登録し、消費者が実行中にこれを発見(service discovery)して接続する方式である。伝送層としてはFoundationが規定したSOME/IP(Scalable service-Oriented MiddlewarE over IP)やDDS(Data Distribution Service)を用いる。この動的結合のおかげで、例えば新規センサ融合サービスをOTAで追加すれば、既存の消費者が再コンパイルなしにそのサービスを発見・購読できる。すなわち「配線のように固定された通信」から「インターネットサービスのように緩く結合された通信」への転換がAdaptiveの本質である。

実行管理(ara::exec)と更新管理(ara::ucm)もClassicにはなかった能力である。ara::execはアプリケーションの開始・終了・状態遷移(Machine State・Function Group)を管理し、走行中でも必要な機能集合のみを積載・切替できるようにする。ara::ucmは無線更新(OTA)を標準化し、テスラが示した「車両機能の継続改善」モデルを従来のOEMも実装できるようにする。実際、フォルクスワーゲンのソフトウェア子会社CARIAD、BMW・メルセデスの次世代OS、現代自動車グループのSDV戦略はいずれもAdaptive Platform(またはその変種)を高性能ゾーン(zonal)・中央コンピューティングアーキテクチャの基盤として採用している。

ただしこの柔軟性は機能安全・決定性との緊張を生む。POSIXの動的スケジューリングと仮想メモリは、Classicの静的決定性ほど「最悪実行時間(WCET)」を保証しにくい。そこでAdaptiveはASIL Bレベルまでの安全を目標としつつ、決定的イーサネット([[tsn]])・安全認証ハイパーバイザ・実行隔離で不足分を補う。要するにAdaptiveは「性能と柔軟性を得る代わりに決定性証明という新たな宿題を抱えた」プラットフォームであり、だからこそ当面は制動・操舵のような最高安全等級機能はClassicが、認知・計画・HMIはAdaptiveが担う役割分担型の共存が現実的な解法である。

5. Classic vs Adaptiveの比較と開発方法論

両プラットフォームの違いは単なる技術選択ではなく、「どの安全・性能・ライフサイクル要求に応えるか」の違いから生じる。以下の比較は項目の羅列ではなく、各差異がなぜ生じるかとあわせて読むべきである。

区分	Classic Platform(CP)	Adaptive Platform(AP)	差異が生じる理由
対象ECU	深層組込み(数百KB〜MB)	高性能コンピューティング(GB級メモリ)	制御 vs 認知・演算
OS	OSEKベースRTOS	POSIX(PSE51)	決定性 vs 豊かなランタイム
言語	主にC	C++(14以上)	モジュール性・オブジェクト指向の要求
構成時点	静的(ビルド時固定)	動的(実行時ロード・発見)	安全性 vs 柔軟性
通信	信号ベース(CAN/LIN/FlexRay)	サービス指向(SOME/IP・DDS)	固定経路 vs 緩い結合
更新	全体フラッシング(整備工場)	OTA(ara::ucm)	閉鎖系 vs 継続改善
安全等級	ASIL Dまで	主にASIL B(補完設計で引上げ)	決定性確保の難易度

この比較で最も実務的含意が大きい点は、更新モデルと通信方式である。Classicの全体フラッシングは「検証済みバイナリを丸ごと交換」するため安全だが、小さなバグ一つを直すにも整備工場への入庫が必要で、数百万台のリコール費用につながる。一方、AdaptiveのOTAは機能を遠隔で改善しリコールをソフトウェアパッチに置き換えるが、改竄されたファームウェアが安全機能を損なわないよう[[secure-boot]]・署名検証・ロールバックのようなセキュリティ設計が必ず伴わなければならない。すなわち柔軟性とセキュリティ責任が共に大きくなる。

開発方法論の面でAUTOSARはモデルベース・役割分担ワークフローを標準化した。概略として、OEMがシステムレベルでSWC・ポート・インタフェースを設計しARXMLで配布すると、Tier-1がこれをECUにマッピング(SWC-to-ECU mapping)しBSWを構成し、RTE生成器が通信接着コードを自動生成する。実際の量産では、Vector(DaVinci・MICROSAR)、ETAS、EB(Elektrobit)のような商用ツールチェーンがこのARXMLモデルを入力に数千個のBSWパラメータを構成しコードを生成する。このように「モデルを交換しコードを生成する」方式は、数十個のECU・数十社のサプライヤが絡む大規模プロジェクトで一貫性・追跡性・自動化を確保する唯一現実的な方法であり、同時にARXML相互運用性・ツール依存という新たな管理課題を残す。

6. 深化 — 最新動向(SDV時代のAUTOSAR)

AUTOSARは毎年11月に「Rxx-11」形式で定期リリースを出す。最新のR25-11(2025年末公開)はClassic・Adaptive・Foundationの三標準にわたり約1,900件の反映作業を含み、公開発表では車両データプロトコル(Vehicle Data Protocol)、セキュリティ強化、Classic PlatformのDDS対応、Classic PlatformへのRust適用展望、共通Adaptive実装(CAPI, Common Adaptive Platform Implementation)などが主要テーマとして扱われた(詳細な変更は公式リリース概要文書を参照)。直前のR24-11(2024)が約2,400件の作業と35万行以上のAdaptiveコードを反映したのと比較すると、近年のリリースは機能追加よりもセキュリティ・メモリ安全・プラットフォーム統合の内実化へ重心が移動していることが読み取れる。

最も注目すべき動向はソフトウェア定義車両(SDV, Software Defined Vehicle)との結合である。数十個のECUに分散していた機能が少数の高性能中央・ゾーン(zonal)コントローラへ統合されるにつれ、一つのハードウェア上でASIL D制御とQM級インフォテインメントが共存する混成重要度(mixed-criticality)環境が一般化している。ここでAUTOSARはAdaptiveで高性能領域を、Classicで安全領域を担わせつつ、ハイパーバイザと[[tsn]]のような決定的ネットワークで二つの世界を隔離・接続するハイブリッドアーキテクチャを提示する。実際、CAPIのような共通実装イニシアチブはOEMごとに異なっていたAdaptive実装を収斂させ、車両ソフトウェアの「アンドロイド式共通基盤」を志向する。

二つ目の動向はメモリ安全とRustの台頭である。Classic Platformが数十年にわたりCに依存してきた結果、メモリ誤り([[memory-safety]])による潜在的欠陥が累積してきた。R25-11でClassic PlatformへのRust適用展望が公式議題として扱われたことは、自動車産業が安全・セキュリティの根本的手段としてメモリ安全言語を真剣に検討し始めたことを示す。三つ目はセキュリティ-安全の共同設計で、コネクテッドカーでサイバー攻撃が即ち安全脅威となるにつれ、ISO/SAE 21434(サイバーセキュリティ)・UNECE WP.29 R155/R156(CSMS/SUMS)とAUTOSARの暗号・セキュリティモジュール(ara::crypto, SecOC)が有機的に結合している。予想出題方向としては、「SDV移行期のClassic・Adaptiveハイブリッドアーキテクチャの設計方策」「AUTOSARベースOTAの機能安全・サイバーセキュリティ統合戦略」のような融合型論題が有力である。

7. 考慮事項および示唆点

適用戦略 — プラットフォーム混成と漸進的移行: 今すぐすべての機能をAdaptiveへ移すのは非現実的である。制動・操舵などのASIL D機能は検証済みのClassicに維持し、認知・計画・HMI・OTAのように柔軟性が必要な領域からAdaptiveを導入する役割分担型ハイブリッド移行が現実的である。技術士は機能別の安全等級・実時間要求・更新周期を軸に、どの機能をどのプラットフォームに配置するか(mapping)を設計する眼識を備えなければならない。
トレードオフ — 標準化の利得 vs 複雑性・ツール依存のコスト: AUTOSARは再利用・協業・追跡性という大きな利得を与えるが、数千個のBSWパラメータ構成、ARXMLモデル管理、商用ツールチェーン(Vector・ETAS・EB)依存、急な学習曲線というコストを伴う。小規模・単純なECUにはむしろ過大なオーバーヘッドになりうるため、導入規模と組織能力に合わせた費用対効果の判断が必要である。
展望 — SDV・中央集中アーキテクチャへの収斂: 車両が「車輪のついたコンピュータ」へ進化するにつれ、AUTOSARは分散ECU標準から中央コンピューティング・ゾーンアーキテクチャのソフトウェア基盤へと役割を拡張している。OTA・サービス指向通信・共通実装(CAPI)が一般化すれば、ハードウェアライフサイクルとソフトウェアライフサイクルが分離され、「出荷後も改善し続ける車」が標準となるであろう。
連携技術 — 安全・セキュリティ・ネットワークの統合: AUTOSARは単独では完結しない。[[iso-26262]]・[[sotif-iso-21448]]の機能安全、ISO/SAE 21434のサイバーセキュリティ、[[tsn]]の決定的ネットワーク、[[secure-boot]]・[[memory-safety]]のセキュリティ基盤と有機的に結合して初めて安全なSDVが成立する。技術士はAUTOSARを個別技術ではなく、これらの標準を織り合わせる統合アーキテクチャの中心軸として捉えるべきである。
組織・ガバナンス — サプライチェーン協業とモデル管理体系: AUTOSARの真価はOEM-Tier-1-Tier-2がARXMLで設計責任をやり取りする協業ガバナンスから生まれる。インタフェース変更管理、モデル構成管理、ツールバージョン・リリース互換性管理が裏付けられなければ、標準化の利得が統合の混乱で相殺される。したがって技術士は技術規格の理解を超え、多者協業を支えるプロセス・構成管理・契約ガバナンスまで設計・運営する観点を備えなければならない。

参考資料

AUTOSAR, "AUTOSAR Official Website": https://www.autosar.org/
AUTOSAR, "About AUTOSAR — History": https://www.autosar.org/about/history
AUTOSAR, "Release R25-11 is Now Available": https://www.autosar.org/news-events/detail/release-r25-11-is-now-available
AUTOSAR, "Classic Platform": https://www.autosar.org/standards/classic-platform
AUTOSAR, "Adaptive Platform": https://www.autosar.org/standards/adaptive-platform

一言まとめ: AUTOSARは車両SWをハードウェアから分離し再利用・協業・移植を可能にするオープンな自動車SW標準であり、静的・実時間のClassic Platformと動的・サービス指向のAdaptive PlatformをFoundation・ARXML方法論で束ねて共存させ、SDV・OTA・セキュリティ-安全統合の流れの中で中央集中アーキテクチャのソフトウェア基盤へ拡張している。