COLUMN
AUTOSARとは？仕組みやメリット、CPとAPの違いまで車載標準をわかりやすく解説
車載システム
AUTOSAR（オートザー）とは？仕組みやメリット、CPとAPの違いまで車載標準をわかりやすく解説
車載ソフトウェアの高度化に伴い、従来の開発手法に限界を感じつつも、AUTOSARの複雑な階層構造や専門用語に戸惑いを覚える方は少なくありません。
この記事では、AUTOSARの基本概念からアーキテクチャ、導入のメリット・デメリット、そしてClassic Platform（CP）とAdaptive Platform（AP）の違いまでを体系的に解説します。読み終える頃には、自社の開発業務やキャリアにおいて、この車載ソフトウェア標準をどのように活用すべきか判断できるようになるでしょう。
この記事でわかること
・ 車載ソフトウェア開発の課題を解決するAUTOSARの目的
・ ソフトウェアの再利用性を実現する階層アーキテクチャの仕組み
・ 用途に応じて使い分ける2つのプラットフォーム（CPとAP）の根本的な違い
AUTOSAR（オートザー）とは？車載ソフトウェア開発を標準化するプラットフォーム
AUTOSAR（AUTomotive Open System ARchitecture）とは、自動車に搭載されるソフトウェアの基盤となるアーキテクチャに関する国際的な標準仕様です。自動車メーカーや部品サプライヤー、ソフトウェアベンダーなどが連携し、車載ソフトウェアの再利用性や相互運用性を高めることを目的に策定されました。この標準化により、ハードウェアに依存しないソフトウェア開発が可能となり、複雑化する車載システムの開発効率と品質の向上が期待されます。
AUTOSARは、自動車業界全体の開発プロセスを変革する共通のプラットフォームとしての役割を担っています。
ソフトウェアの大規模化と複雑化への対応
近年の自動車は、ADAS（先進運転支援システム）や自動運転技術の進化により、搭載されるECU（電子制御ユニット）の数が飛躍的に増加しています。それに伴い、ソフトウェアのコード行数は数億行に達するともいわれ、その規模と複雑性は増し続けています。こうした状況下では、個別の開発手法では品質の担保や開発期間の短縮が困難になります。AUTOSARは、標準化されたアーキテクチャを提供することで、このような大規模で複雑なソフトウェア開発に体系的に対応するための枠組みを提示します。
開発コストの増大と品質低下の防止
ソフトウェアの複雑化は、開発に要する時間と人員の増加を招き、結果として開発コストを押し上げます。また、異なるサプライヤーがそれぞれの仕様でソフトウェアを開発すると、コンポーネント間の連携で不具合が生じやすくなり、車両全体の品質が低下するリスクも高まります。AUTOSARは、共通のインターフェースと開発手法を定義することで、属人性を減らし、手戻りや不具合の発生を抑制します。これにより、無駄な開発コストを削減し、安定した品質を確保する基盤が整います。
ハードウェアとアプリケーションの独立性を確保
従来の車載ソフトウェア開発では、特定の車種やECU向けに個別に最適化して作られることが多く、他のプロジェクトへの流用が困難でした。これに対し、AUTOSARでは、アプリケーション層とハードウェア層を明確に分離する構造を採用しています。これにより、特定のマイコン（マイクロコントローラ）や基板に依存しない設計が可能になるため、将来的なハードウェアの設計変更や代替品への切り替えにも柔軟に対応できるようになります。この独立したレイヤー構造こそが、一度開発したアプリケーションソフトウェア資産の長期的な価値を維持する土台となります。
AUTOSARを構成しているパートナー企業や団体
AUTOSARは、単一の企業が主導する規格ではなく、グローバルなパートナーシップによって推進されています。この標準化活動の中核を担う「コアパートナー」には、BMW、ゼネラルモーターズ、メルセデス・ベンツ、トヨタ自動車、フォルクスワーゲンといった世界有数の自動車メーカーやボッシュ、デンソー、オモビオといった大手サプライヤーが名を連ねています。会員には役割に応じて複数のランクがあり、仕様策定に深く関わるコアパートナーを筆頭に、多くの企業や団体が車載ソフトウェアの未来を形作るために協力し、この標準の普及と発展に貢献しています。
なぜAUTOSARが必要？増大するソフトウェア開発の課題を解決
自動車の進化は、ソフトウェアの進化と言い換えても過言ではありません。近年では、ソフトウェアによって車の機能や価値が更新され続けるSDV（Software Defined Vehicle）への移行が急速に進んでいます。しかし、その裏側でソフトウェアのコード行数は爆発的に増え、ECUの数も一台あたり100個を超えることが珍しくなくなりました。
このような状況は、開発の複雑化、コストの増大、品質管理の困難さといった深刻な課題を生み出しました。
AUTOSARの最大の目的は、このソフトウェア開発の危機的状況を打開することです。ハードウェアとソフトウェアを分離し、コンポーネントの再利用を促進する標準プラットフォームを提供することで、自動車業界全体で持続可能な開発エコシステムを構築することを目指しています。この標準化された基盤があることで、次の技術革新へとスムーズに進むことが可能になります。
AUTOSARの階層構造を解説｜3つの主要レイヤーの役割
AUTOSARのアーキテクチャは、ソフトウェアを機能ごとに明確に分離した「階層構造」で構成されている点が最大の特徴です。この構造は、主に「Application Layer（ASW）」「Runtime Environment（RTE）」「Basic Software（BSW）」という3つの主要なレイヤーに分かれています。この階層化されたアーキテクチャにより、アプリケーション開発者はハードウェアの具体的な仕様を意識することなく、機能開発に集中できます。
一方で、ハードウェアに近い層はハードウェアの差異を吸収する役割を担い、ソフトウェアの移植性や再利用性を高める仕組みを実現しています。
この明確な役割分担こそが、AUTOSARの効率的な開発を支える根幹です。
Application Layer（ASW）：自動車の機能を実装する層
Application Layer（ASW）は、AUTOSARアーキテクチャの最上位に位置し、自動車の具体的なアプリケーション機能を実現するための層です。
例えば、エンジン制御、ブレーキアシスト、パワーウィンドウの開閉といった、ユーザーが直接触れる機能のロジックがここに実装されます。この層のソフトウェアは、「ソフトウェアコンポーネント（SW-C）」という独立した単位で開発されます。各コンポーネントは標準化されたインターフェースを通じて相互に通信するため、特定のハードウェア構成に依存せず、再利用や修正が容易になるという利点があります。
Runtime Environment（RTE）：ASWとBSWをつなぐ通信インターフェース
Runtime Environment（RTE）は、上位のApplication Layer（ASW）と下位のBasic Software（BSW）の間に位置する、仮想的な通信バスとしての役割を担う重要なインターフェースです。ASWに属する各ソフトウェアコンポーネント間の通信や、ASWとBSW間の情報交換はすべてRTEを介して行われます。RTEがこの通信を仲介することにより、アプリケーション開発者は、ソフトウェアがどのECUに配置されるか、どのような通信プロトコルが使われるかを意識する必要がなくなります。これにより、ソフトウェアとハードウェアの完全な分離が実現されます。
Basic Software（BSW）：ハードウェアの違いを吸収する基本ソフトウェア層
Basic Software（BSW）は、ハードウェアに最も近い層であり、マイクロコントローラ（マイコン）などのハードウェア資源を抽象化する役割を担います。このレイヤーが存在することで、上位のアプリケーションソフトウェアは特定のマイコンの仕様に依存することなく動作できます。BSWはさらに、OSや通信、メモリ管理などを担当する「Services Layer」、ECUの機能を抽象化する「ECU Abstraction Layer」、マイコンのドライバ群である「Micro Controller Abstraction Layer（MCAL）」、特殊なハードウェア制御や、超高速なリアルタイム処理を実装するための「Complex Device Drivers（CDD）」といった複数の副層に分かれています。
これにより、ハードウェアの変更があっても、影響範囲をBSW内に限定することが可能です。
全レイヤーをカバーするアイ・エス・ビーのワンストップ開発支援
株式会社アイ・エス・ビーでは、単一レイヤーの受託開発にとどまらず、AUTOSARの全階層を網羅した総合支援を展開しています。具体的には、マイコンメーカー各社のMCAL移植やコンフィグレーション、サードパーティ製BSWツールの組み込みからチューニングまで幅広く対応可能です。さらに、ドメインコントローラ開発に不可欠なCPとAPをまたぐ通信統合など、階層を横断する高度なインテグレーションまで一括で対応します。これにより、お客様は開発ベンダーの分散による管理コストや調整の負担を抑え、プロジェクトを円滑に進められます。
AUTOSARを導入する4つのメリット
AUTOSARを導入することには、単に開発プロセスを標準化する以上の多くのメリットが存在します。品質の安定化から開発効率の劇的な向上、さらにはサプライチェーン全体での協力体制の円滑化、そして高度な安全要求への対応まで、その利点は多岐にわたります。これらのメリットは、複雑化・高度化する一方の現代の自動車開発において、企業が競争力を維持し、革新的な技術を迅速に市場投入するための強力な基盤となります。
ここでは、その中でも特に重要な4つのメリットについて解説します。
メリット1：開発プロセスの標準化による品質の安定
AUTOSARは、ソフトウェアのアーキテクチャだけでなく、開発プロセスそのものについても標準的な手法を定義しています。この標準化された開発フローに従うことで、開発者個人のスキルや経験への依存度が低減され、組織全体として一定水準以上の品質を保ちやすくなります。設計情報が共通のフォーマット（ARXML）で記述されるため、担当者間や企業間での情報共有がスムーズになり、仕様の誤解や手戻りが減少します。
結果として、開発されるソフトウェアの属人性が排除され、安定した品質確保につながります。
メリット2：ソフトウェア資産の再利用による開発効率の向上
AUTOSARの最大のメリットの一つが、ソフトウェアの再利用性の向上です。ハードウェアからアプリケーションを分離するアーキテクチャにより、一度開発したソフトウェアコンポーネントを、異なる車種やプラットフォームへ容易に移植できます。例えば、ある車種向けに開発したエンジン制御ロジックを、次世代の車種開発時にほとんど変更することなく流用することが可能です。
これにより、ゼロから開発する部分が減少し、開発期間の短縮とコストの大幅な削減が実現できます。このメリットは、製品ラインナップが豊富な企業ほど大きな効果を発揮します。
メリット3：サプライヤー間の分業体制の確立が容易に
現代の自動車開発は、自動車メーカーと多数の部品サプライヤーによる協業が不可欠です。AUTOSARは、各ソフトウェアコンポーネントのインターフェースを標準化するため、異なる企業が開発したソフトウェア同士の連携を容易にします。これにより、OEMはシステム全体の仕様を定義し、各サプライヤーは担当するコンポーネントの開発に集中するという、効率的な分業体制を築きやすくなります。各ベンダーの専門性を最大限に活かしつつ、システム全体の統合をスムーズに進めることが可能です。
メリット4：機能安全（ISO 26262）やサイバーセキュリティ（ISO/SAE 21434）への対応
自動運転やコネクテッドカー化が進む中で、自動車の機能安全規格「ISO 26262」やサイバーセキュリティ規格「ISO/SAE 21434」への対応は必須となっています。AUTOSARは、これらの国際規格の要求事項をあらかじめ考慮して設計されている点が特徴です。具体的には、メモリ保護機能やアクセス制御、プログラムの実行順序を監視する仕組みなどが標準で用意されており、高度なセキュリティ・安全要件を満たすシステムを効率的に構築できます。開発者は安全要件への対応をゼロから設計する工数を削減でき、規格に準拠した信頼性の高いソフトウェア開発を迅速に進めることが可能です。
AUTOSAR導入時に考慮すべきデメリットと現場の課題
多くのメリットがある一方で、AUTOSARの導入は容易なことではありません。特に、その仕様の広範さと複雑さは、初学者にとって大きな壁となる可能性があります。
また、効率的な開発を実現するためには専用のツールが不可欠であり、それに伴うコストも無視できません。導入を成功させるためには、これらのデメリットを事前に理解し、十分な準備と計画を立てることが重要です。
ここでは、導入前に必ず考慮すべき2つの課題（学習コスト・ツール費用）と、現場で直面する技術課題への対応策について解説します。
仕様の複雑さによる高い学習コスト
AUTOSARの仕様書は数千ページにも及ぶ膨大なものであり、そのアーキテクチャや概念は非常に複雑です。ソフトウェアコンポーネントの設計方法、RTEの仕組み、BSWの多岐にわたるモジュールの設定など、エンジニアが習得すべき知識は膨大です。そのため、AUTOSARを初めて導入する組織やエンジニアにとっては、膨大な学習時間と教育コストが必要となります。この学習曲線の険しさが、導入の際の大きなハードルの一つとなっています。
専用ツールへの依存とライセンス費用
AUTOSAR準拠の開発を効率化するには、BSWのコンフィグレーションやRTEのコード生成を自動化する専用のソフトウェアツールが事実上不可欠です。これらのツールは専門ベンダーから提供されていますが、導入にはライセンス費用が発生します。また、一度特定のベンダーを選択すると、開発プロセス全体がそのツールに依存し、他社製品への乗り換えが困難になるリスクも考慮しなければなりません。
アイ・エス・ビーは、特定のツールベンダーに固定されない独立系SIerとして、中立的な立場で開発を支援しています。例えば、ベクター社のDaVinciやETAS社のISOLARなど、お客様が既に導入されているツール環境や既存の開発プロセスに合わせた柔軟な受託体制を構築可能です。
特定の製品に縛られることなく、プロジェクトの要件に最適なツール運用を提案できる点がアイ・エス・ビーの強みです。ツール選定のアドバイスから、コンフィグレーションのみのスポット支援まで対応しており、特定ベンダーの制約に縛られず、コストと機能のバランスを最適化した開発環境を実現します。これにより、ライセンス費用や学習コストの負担を最小限に抑えつつ、効率的な開発体制を整えられます。
導入時の技術課題への対応
AUTOSAR導入の現場では、仕様の難解さ以上に実務レベルの技術課題が立ちはだかります。特にMCALの移植やBSWコンフィグレーションにおける試行錯誤、RTE自動生成時のビルドエラー解消などは、多くの開発チームが直面する大きな壁です。他社製BSWと自社ASWの統合不具合や、CPとAP間の通信ゲートウェイ設計の煩雑さなど、現場でのノウハウ要求が高い課題が頻発します。
アイ・エス・ビーは、これらのインテグレーションやMCAL移植、RTE生成における高度なノウハウを長年蓄積してきました。専門エンジニアが実務上のボトルネックを直接解消することで、お客様の開発チームの負荷軽減とプロジェクトの円滑な進行を伴走支援します。
Classic Platform（CP）とAdaptive Platform（AP）の違いを徹底比較
AUTOSARには、その用途や目的に応じて設計された2種類のプラットフォームが存在します。それが「Classic Platform（CP）」と「Adaptive Platform（AP）」です。
これらは単なるバージョンの違いではなく、アーキテクチャの思想から得意とする領域までが大きく異なります。従来型のECU制御を担うCPと、自動運転などの高度な処理を担うAP、この2つのプラットフォームの特徴を理解し、適切に使い分けることが、現代の車載システムを設計する上で不可欠です。
ここでは、それぞれの特徴を比較し、その違いを明確にします。
Classic Platform（CP）の特徴とマイクロコントローラ制御での役割
Classic Platform（CP）は、AUTOSARの黎明期から標準化が進められてきた仕様であり、主に車載制御の核となるマイコン上での動作に最適化されています。最大の特徴は、極めて高いリアルタイム性と動作の確実性です。このプラットフォームは、長年車載OSのデファクトスタンダードであったOSEK/VDXの仕様を継承しています。静的なメモリ割り当てやタスク管理を採用することで、OSのオーバーヘッドを最小限に抑え、ミリ秒単位の処理時間を厳密に保証できる点が強みです。
具体的な適用例としては、ステアリングの操舵力を補助するEPS（電動パワーステアリング）や、燃料噴射を緻密に制御するエンジンECU、車両の挙動を安定させるブレーキ制御（ABS/ESC）などが挙げられます。さらに、ドアロックや照明を管理するボディ制御モジュールなど、高い信頼性と長期間の安定稼働が求められる領域で不可欠な役割を担っています。
Adaptive Platform（AP）の特徴と高性能SoCでの役割
Adaptive Platform（AP）は、自動運転や高度なインフォテインメントシステムなど、膨大なデータ処理と柔軟性が求められる次世代アプリケーションのために開発されました。高性能なSoC上でPOSIX準拠のOSが動作することを前提としており、動的なリソース管理や、SOME/IPなどのプロトコルを活用したサービス指向アーキテクチャ（SOA）を採用しています。大容量通信やアプリケーションの動的な追加・更新（OTA：Over-The-Air）が可能になるため、市場投入後もソフトウェアを最新状態に保ち、継続的に新機能を提供できる体制を構築できます。
主な適用例には、ADAS・自動運転ドメインコントローラやゾーンECU、IVI（インフォテインメント）、ゲートウェイECUなどが挙げられます。高度な演算能力と柔軟なアップデート機能により、SDV（Software Defined Vehicle）の実現を支える中核的な役割を担います。
【比較】目的や用途に応じたCPとAPの最適な使い分け
CPとAPは、役割と特性が異なるため、SDV（Software Defined Vehicle）化が進む次世代車両開発では、適材適所の使い分けと高度な連携設計が求められます。パワートレインやシャーシといった、極めて高いリアルタイム性と機能安全が最優先される領域には、静的なリソース管理を行うCPが最適です。一方で、カメラやLiDARの画像認識、自動運転の判断制御、OTA（Over-The-Air）による機能更新など、高性能な演算と柔軟なアップデートが必要な領域には、POSIX準拠のOS上で動的な処理が可能なAPが適しています。
実際の開発現場では、既存のCP資産を維持しながら、いかに効率よくAPを組み込み、次世代アーキテクチャへ移行するかが大きな課題となっています。アイ・エス・ビーでは、長年のCP開発で培った制御ノウハウに加え、APやLinux/POSIXベースの次世代ECU開発にも早期から着手してきました。これにより、CPとAPが混在する複雑な通信ゲートウェイの設計や、既存システムからのスムーズな移行支援において、実務に即した具体的な解決策を提示できます。プラットフォームをまたぐインテグレーションまで網羅的に対応することで、お客様はアーキテクチャの整合性確保に悩むことなく、高付加価値な機能開発にリソースを集中できます。
AUTOSAR準拠の開発フローとエンジニアに求められるスキル
AUTOSARを導入すると、従来の組込みソフトウェア開発とは異なる特有の開発フローとスキルセットが必要になります。トップダウンのアプローチでシステムを設計し、専用ツールを駆使してソフトウェアを統合していくプロセスは、エンジニアにとって新たな挑戦です。自動車業界ではAUTOSAR準拠の開発案件が増加しており、プロジェクトを成功に導くためには、高度な専門スキルと開発ノウハウを持つパートナー企業の選定が不可欠となっています。
ここでは、AUTOSARにおける一般的な開発の流れと、この分野でキャリアを築くために必要とされる主要なスキルについて解説します。
AUTOSARにおけるECU開発の基本的な流れ
AUTOSAR準拠のECU開発は、まず車両全体のシステム要件を定義することから始まります。次に、その要件をソフトウェアコンポーネント（SW-C）単位に分割し、各コンポーネントのインターフェースを設計します。これらの設計情報は、ARXML（AUTOSAR XML）という標準フォーマットで記述されます。
その後、専用ツールを用いて、各SW-CをどのECUに配置するかを決定し、通信設定などを行うECUコンフィグレーションを実施します。
最終的にツールがRTEやOSを含むBSWのコードを自動生成し、開発者はアプリケーションのロジック実装に集中するという、モデルベース開発に近い流れが一般的です。
求められるスキル①：C/C++での組み込みソフトウェア開発経験
AUTOSARは標準プラットフォームですが、その上で動作するアプリケーションソフトウェアの開発は、依然としてプログラミングスキルが基礎となります。特にCPではC言語が、APではC++が主に使用されます。そのため、これらの言語を用いた組込みソフトウェア開発の経験は不可欠です。
メモリ管理やリアルタイムOSに関する知識、デバッグスキルなど、従来の組込み開発で培った経験は、AUTOSAR準拠の開発においても直接的に役立ちます。
求められるスキル②：AUTOSARの仕様とアーキテクチャの理解
プログラミングスキルに加え、AUTOSAR独自の概念への深い理解が求められます。レイヤードアーキテクチャ、ソフトウェアコンポーネント（SW-C）とポートの概念、RTEの役割、BSWの各モジュールの機能といった、AUTOSARの仕様を体系的に把握している必要があります。また、Vector社のDaVinci Developer/Configurator ProやETAS社のISOLAR-A/Bといった、専用ツールの使用経験も非常に重要です。
これらの知識とスキルを併せ持つことで、AUTOSARプロジェクトの中核を担うエンジニアとして活躍できます。
AUTOSARに関するよくある質問
AUTOSARについて学ぶ中で、多くの方が抱くであろう疑問点をまとめました。ここでは、仕様の複雑さの理由や、2つのプラットフォームの具体的な使い分け、そして学習の進め方といった、よくある質問に簡潔にお答えします。
AUTOSARの仕様はなぜこれほど複雑なのですか？
多様な車種やハードウェアに対応し、極めて高い安全性を確保する必要があるためです。自動車には無数の機能やユースケースが存在し、それらすべてを網羅しようとすると仕様は必然的に膨大になります。また、機能安全規格ISO26262に準拠するための厳格な規定も含まれており、仕様の複雑化の一因となっています。
Classic Platform（CP）とAdaptive Platform（AP）はどのように使い分ければ良いですか？
高いリアルタイム性が求められるエンジンやブレーキなどの従来型制御にはCPを、自動運転やコネクテッド機能など高度な情報処理や柔軟性が必要なシステムにはAPを使います。
CPは確実な応答性、APは高性能・高機能と覚えておくとわかりやすいです。実際の車両では両者が連携して動作することが一般的です。
AUTOSARを学ぶには、何から始めるのがおすすめですか？
まずAUTOSARの全体像と、3つの主要レイヤー（ASW、RTE、BSW）からなるアーキテクチャという基礎を理解することから始めるのがおすすめです。AUTOSAR公式サイトの概要資料を読んだり、入門者向けの書籍やWebサイトを活用したりするのが第一歩です。その後、専門の教育トレーニングを受講すると、より実践的な知識が身につきます。