AUTOSARとは｜規格の全体像とClassic/Adaptiveの違い

AUTOSARとは何か（背景と目的）

結論として、AUTOSARは「ECUごとにバラバラだった車載ソフトの層構造・インタフェース・開発方法論を共通化するための業界標準」です。策定主体はAUTOSAR development partnershipで、OEM・Tier1・半導体・ツールベンダーが参加しています。

策定の背景

1台の車両には数十から100個規模のECUが搭載され、機能ごとに異なるハードウェア・OS・通信スタックで開発されてきました。ECUを跨いだ機能連携やモデルチェンジ時のソフト移植でコストが膨らみ、共通アーキテクチャが必要になった、というのが出発点です。

2000年代半ばにClassic系仕様が整備され、その後Adaptive PlatformとFoundation（両者共通の定義・メタモデル）が追加されて、現在は3ライン体制で整備されています。

何を標準化しているか

AUTOSARが定めているのは主に次の4点です。

• ソフトウェアの層構造（Application／RTE／BSWの分離、あるいはApplication／ara APIsの分離）

• 標準インタフェース（PortとInterface、SWCモデル、ara APIs）

• コンフィグレーション記述形式（ARXMLと呼ばれるXMLメタモデル）

• 開発方法論（Methodology：ECU Extractから生成・ビルドまでの流れ）

裏を返すと、業務ロジックそのものや半導体レベルの実装は標準化していません。「どう繋ぐか」を揃え、「何を作るか」はOEM/Tier1に任せる規格です。

ミニFAQ：AUTOSAR準拠は法的な義務？

義務ではありません。ただし欧州系OEMや大手Tier1が関わる量産開発では、AUTOSAR準拠のBSW／APプラットフォーム採用が前提になるケースが多く、参画時に「AUTOSAR経験の有無」を確認される場面が目立ちます。

AUTOSAR Classic Platform（CP）の構造

結論として、CPは「1つのECUに閉じた制御を、Application／RTE／BSWの3層でモデル化する」プラットフォームです。パワトレ、シャシー制御、ボディ系など、応答時間がミリ秒オーダーで求められる領域を主戦場としています。

Application Layer／RTE／BSWの3層

CPのソフトウェアは大きく3層で構成されます。

Application層のSWCは「どのECUに置くか」を意識せずに設計できるのが特徴です。物理配置は後工程のマッピングで決まり、RTEが自動生成されます。

BSWの内訳

BSWは階層内でもさらに4つのブロックに分かれます。

• Services Layer：OS、通信（COM／PduR／CanIf 等）、診断（Dcm／Dem）、メモリ管理（NvM）などの上位サービス

• ECU Abstraction Layer：ドライバとサービスを繋ぐ抽象化層

• MCAL（Microcontroller Abstraction Layer）：マイコン固有のペリフェラル操作を隠蔽する最下層ドライバ

• Complex Drivers：AUTOSAR標準に収まらない特殊デバイス向けの逃げ道

MCALは半導体ベンダーが供給するのが基本で、上位のBSWコンポーネント（Services／ECU Abstraction）はBSWベンダー（Vector、Elektrobit、ETASなど）から購入し、ARXMLで自プロジェクトに合わせてコンフィグする流れが一般的です。

Virtual Functional Bus（VFB）とSWCモデル

CPを理解するうえで欠かせない概念がVirtual Functional Busです。VFBは「すべてのSWCが1本の仮想バスで繋がっているように見なす」抽象で、物理ネットワーク（CAN・LIN・FlexRay・Automotive Ethernet）の違いを設計時に意識せずに済むようにする仕組みです。

実装では、VFB上のPort間通信がRTEを介したメモリコピーや、CanIf・LinIf経由の物理送信に自動で振り分けられます。ここが「ECUを跨いで機能を再配置しても、SWC側はほとんど変えなくてよい」という再利用性の根拠になっています。

静的コンフィグとリアルタイムOS

CPは基本的に静的コンフィグです。タスク・スケジュール・メモリ配置はビルド時に固定され、動的にプロセスを生成することはありません。安全性・タイミング保証の面で有利な半面、機能追加のたびにコンフィグ再生成とビルドが必要になります。

搭載されるOSはOSEK/VDX由来のAUTOSAR OSで、優先度ベースの固定優先度スケジューリングとリソース保護を提供します。マルチコア対応もCP側の仕様に含まれます。

ミニFAQ：BSWは全部自作するの？

基本的には自作しません。Vector（MICROSAR）、Elektrobit（EB tresos）、ETAS、Continental、KPITなどのAUTOSAR製品を導入してARXMLでコンフィグするのが実務の主流です。自作するのはComplex Drivers相当の特殊ロジックや、上位のSWC実装のみになります。

AUTOSAR Adaptive Platform（AP）の構造

結論として、APは「POSIX準拠OS上でC++アプリケーションを動的に配置し、サービス指向で連携する」ためのプラットフォームです。ADAS・自動運転、V2X、車載HPC（High Performance Computer）のように、CPU/GPU/DLAが混在し演算量が大きい領域を狙って策定されました。

POSIX準拠OSと動的サービス

APはPOSIX系OS上での実装を前提とし、OSに求められるプロファイル範囲は仕様バージョンや製品実装によって異なります。代表的な実装はAdaptive AUTOSAR対応の商用OS（Elektrobit、Vector、Aptivなどの製品、AUTOSAR Adaptive準拠構成のQNXなど）、あるいは特定プロファイルのLinuxです。CPと違い、プロセスは動的に起動・停止でき、Over-The-Airでのアプリ更新も想定されています。

ara APIs（ara::com／exec／per／log／tsync ほか）

APのアプリケーションはFoundationで定義されたAdaptive Runtime for Applicationsに従い、C++の「ara::」名前空間配下のAPIから機能を呼び出します。主なものは以下です。

CP側の「Port／RTE生成コード」がAP側では「サービス契約とara APIs呼び出し」に置き換わっている、と考えるとイメージしやすいです。

SOA・SOME/IP・DDSとの関係

APはService-Oriented Architecture（SOA）が前提です。ara::comの通信バインディングとしてはSOME/IP（Scalable service-Oriented MiddlewarE over IP）が広く使われ、仕様上はDDSに関する定義もあります。実務上はSOME/IPで組む事例が多く、DDSは特定領域での採用にとどまるのが現状です。

物理層は実務上Automotive Ethernet（100BASE-T1／1000BASE-T1）中心で使われることが多く、CPが主戦場とするCAN／LIN／FlexRayとは通信設計の前提が異なります。

C++バージョンと機能安全との両立

APの参照仕様はC++14をベースにしています（実装によっては新しいC++規格を使うこともあります）。機能安全（ISO 26262）を要求するアプリでは、C++の未定義動作を制限したセーフサブセット（AUTOSAR C++14ガイドラインが吸収されたMISRA C++:2023など）に沿って実装します。

ミニFAQ：APはLinuxが必須？

必須ではありません。要件はPOSIX PSE51準拠であることと、ARA仕様を満たす実装が動くことです。安全クリティカルな領域では、機能安全認証を持つ商用RTOS上でAdaptive AUTOSARが動作する構成が採用されるケースもあります。

CPとAPの違い（比較表と選び方）

結論として、CPとAPは「置き換え」ではなく「使い分け・共存」の関係です。同一車両内にCP ECUとAP ECUが同居する構成が一般的で、両者はAutomotive Ethernet経由でSOME/IP等で連携します。

どちらを選ぶかの判断軸

新規案件で「CPかAPか」に迷ったら、次の3つで整理できます。

• 応答要求がミリ秒オーダーの制御ループなのか、演算主体のパイプラインなのか

• ソフト構成をビルド時に固定してよいか、実行時に差し替えたいか

• CAN／LIN／FlexRayが主要通信路なのか、Ethernet／IP系が主役なのか

前者に寄るならCP、後者に寄るならAPが自然です。判断が割れる場合は「両者を同居させ役割で分ける」ケースが多く、これがSDV／Zonal Architectureの発想に繋がります。

CP＋AP共存とZonal Architecture

近年のE/Eアーキテクチャは、ドメイン別（パワトレ／シャシー／ボディ／ADAS）にECUを束ねるDomain Architectureから、車体位置ごとに束ねるZonal Architecture＋中央HPCへの再編が進んでいます。この構成では、以下のような役割分担が一般的です。

• Zone ECU：CP中心（センサ・アクチュエータの一次処理、CAN／LINゲートウェイ、Ethernet変換）

• Central HPC ECU：AP中心（ADAS認識・判断、車両状態管理、OTA、車両クラウド接続）

Zone側とCentral側はAutomotive EthernetとSOME/IPで結ばれ、CPのSWCから見た「向こう側のサービス」がAPのアプリケーションとして提供される、という設計になります。

AUTOSARと関連規格の関係

結論として、AUTOSARはそれ単体で使うものではなく、機能安全・コーディング規約・サイバーセキュリティ規格と重ねて運用します。

ISO 26262（機能安全）との連携

車載ソフトの機能安全はISO 26262（Road vehicles — Functional safety）に基づき、ASIL A〜Dで整理します。AUTOSAR自体は「機能安全対応の枠組みを外していない」ものの、ASILを保証するのは実装側です。実務では次のような対応関係になります。

• CPのBSW／APのProduct（ara::* 実装）には、機能安全認証取得済み製品が用意されている

• SWC／APアプリケーションの実装は、ASILレベルに応じてSafety Manualに沿った設計と検証が要求される

• Freedom From Interference（FFI）を確保するため、CPではMemory ProtectionとTiming Protectionを、APではProcess分離やCPU分離を用いる

MISRA CとAUTOSAR C++ガイドライン

CPのC実装ではMISRA C（MISRA C:2012など）に準拠したコーディングが一般的です。AP側はAUTOSAR C++14 Coding Guidelinesが定義されており、この内容は現在MISRA C++:2023に統合されています。案件参画時は「どのバージョンに準拠するか」を最初に確認しておくと後戻りが減ります。

ISO/SAE 21434（サイバーセキュリティ）

車載サイバーセキュリティはISO/SAE 21434（Road vehicles — Cybersecurity engineering）でプロセスが定められ、UNECE WP.29のR155（CSMS）と連動します。AUTOSAR側ではCPのSecOC、AP側の ara::crypto などがセキュア通信・鍵管理の実装枠を提供しますが、脅威分析（TARA）や運用プロセスは規格側の要求です。

ミニFAQ：ASILレベルの決定はAUTOSARが決めてくれる？

決めてくれません。ASILはHARA（Hazard Analysis and Risk Assessment）を実施してアイテム定義から導きます。AUTOSARはASILに応じた分離手段を提供するだけです。

開発方法論（Methodology）とツールチェーン

結論として、量産車向けAUTOSARの実務は「ARXMLと呼ばれるXML形式の設計データを、専用ツールで編集・生成・ビルドする」フローが中心です。ソースコードを直接書く前後に、コンフィグと生成のステップが多数入ります。

ARXMLとメタモデル

ARXML（AUTOSAR XML）は、SWC・Port・Interface・ECU構成・BSWコンフィグ・スケジューリング設定などを記述する共通データ形式です。Foundationのメタモデルに従って構造化されているため、ツール間の交換ができます。

代表的なツール

量産車向けの開発では、CP／APともに商用ツールチェーンが主流です。

• Vector：CP向けMICROSAR、AP向けMICROSAR Adaptive、開発ツールDaVinci Developer／Configurator

• Elektrobit：CP向けEB tresos、AP向けEB corbos

• ETAS：ISOLAR、RTA-BSW

• KPIT／HighTec／Green Hills：ツール・コンパイラ・OSの周辺群

学習用途ではArctic Coreのようなオープンソース実装や、大学研究向けの参考実装も存在します。ただし本番プロジェクトの大半は商用ツールが前提です。

標準ワークフロー（概略）

1. System Design：車両機能をSWCに分解、Port／Interfaceを定義（ARXML）

2. ECU Extract：機能をECUに配置し、ECU単位のARXMLを切り出す

3. BSW Configuration：Services／Communication／Diagnostic／Memory等をコンフィグ

4. Code Generation：RTE／BSWのCコードを生成

5. Application Implementation：SWC本体（Cソース）を実装

6. Build／Flash／Test：クロスコンパイル→ECUに書き込み→HIL／SILで検証

AP側では手順3〜4が「Manifestの記述とara実装向けサービス契約の定義」に置き換わり、実装言語もC++に切り替わります。

実務での使いどころ・ケース別

結論として、CP／APの使い分けはECUの役割で概ね決まります。案件動向や単価レンジまで踏み込みたい場合は、専用記事に切り分けています。

パワトレ／ボディ系ECU

伝統的なエンジン制御・変速機制御・ボディ電装は、いずれもCP中心です。応答時間、Freedom From Interference、CAN／LIN／FlexRay対応が要件になるためで、単一マイコン上でCPを走らせる構成が多く採用されます。

ADAS／自動運転

センサフュージョン・経路計画・制御指令の統合を1つのECUで担うため、AP中心の設計になります。GPU／DLAとの連携、C++での実装、SOME/IPによる他ECU連携が定番です。

IVI／インフォテインメント

車載ディスプレイ、ナビ、音声アシスタントはAndroid Automotive OSやQNX上のGENIVI／IVI用スタックを採用する例が多く、AUTOSAR APと並走することはあっても、必ずしもAP前提ではありません。IVIとADASのHPCが同居する構成では、Hypervisor上でAndroidとAdaptive AUTOSARを分離することもあります。

SDV（Software Defined Vehicle）時代の位置づけ

SDV文脈では、ハードウェアからソフトウェアを分離する主戦場がAP／HPCに移り、OTAでの機能追加と車両クラウド連携が前提になります。CPは制御の一次要素として残り、Zone配置で数を絞りつつ役割は保つ、という進み方が現実的です。

案件・単価・SDV動向・職種別の入り方を体系的に知りたい場合は、「自動車ソフトウェアエンジニアのフリーランス案件｜職種・単価・SDV動向を解説」で単価レンジ・技術スタック・案件の取り方を整理しています。組込全般の単価感は「組込・制御エンジニアのフリーランス単価相場｜SDV・IoT案件動向」も参考になります。

学習ロードマップ

結論として、AUTOSARは「規格ドキュメントを読み、ツール操作を体験し、機能安全の観点を後から乗せる」の順で押さえるのが最短です。

最短で押さえるべき概念

• Layered Software Architecture（Application／RTE／BSW）

• SWCとPort、Sender/Receiver・Client/Server通信

• ARXMLとECU Extractの流れ

• CPとAPの違い、SOAの意味

• ASILとFreedom From Interference

公式ドキュメント・書籍・ツール体験

• AUTOSAR公式Standards：Classic／Adaptive／Foundationの各リリース仕様と公開範囲を確認できる（公開条件は改定されることがある）

• Vector・Elektrobit公式のホワイトペーパー：概念解説が実務目線でまとまっている

• 商用ツール体験版：DaVinci Developer／EB tresosは評価版で最小構成のARXML編集を体験できる

• コミュニティ実装：Arctic Coreなど。ただし本番はほぼ商用と割り切ってよい

よくある失敗と対策

実務では、「参画前確認」の不足が立ち上がりの失敗要因になりやすいです。着手前にCP／APどちらか、Version、ASIL、使用ツールを確定させると事故が減ります。

CP前提でAP案件に応募

CPの実務経験しかない状態でAP案件に入り、C++・POSIX・SOA・SOME/IP・ara APIsの理解が足りずキャッチアップに時間を取られるケースです。書類段階で「AP経験の年数・ara APIsの実装経験」を確認しましょう。

BSWコンフィグ経験なしで参画

CP案件でも、SWC実装だけの経験でBSWコンフィグ（DaVinci Configurator等）が未経験だと、パラメータの意味と生成物の関係が分からずデバッグに時間が掛かります。参画前に「BSWのどのモジュールを触るか」を確認しておくと安全です。

機能安全記載を軽視

ASIL C／D領域では、コーディング規約準拠だけでなく、Safety Analysis（FMEDA／DFA）・Safety Manual準拠のレビュー記録・Tool Qualificationが必須です。「動けばOK」で書くと差し戻しが増えます。

実践チェックリスト（参画前確認）

案件参画前に、次の項目を必ず確認しましょう。

• CP／APどちらの案件か（両方の場合は各々の担当範囲）

• 対象AUTOSAR Version（Classic R21-11／R22-11／R23-11など）

• ASILレベル（QM／A／B／C／D）

• 使用ツールチェーン（Vector／Elektrobit／ETAS ほか）

• 使用マイコン（AURIX／RH850／S32／MPC5xxx など）／HPC SoC

• 通信スタック（CAN／CAN FD／FlexRay／Automotive Ethernet／SOME/IP）

• コーディング規約（MISRA C:2012／AUTOSAR C++14／MISRA C++:2023）

• 開発プロセス（V字／Agile／Safety Case作成の有無）

• 対象領域（パワトレ／シャシー／ボディ／ADAS／IVI）

• 自分の担当範囲（SWC実装／BSWコンフィグ／APアプリ実装／システム設計）

まとめ

AUTOSARは、車載ECUのソフトウェアを共通の層構造・データ形式・開発方法論で標準化するアーキテクチャ規格で、制御向けのClassic Platformと高性能演算向けのAdaptive Platformの2系統を使い分けます。SDV時代は両者が同一車両に共存し、Zone ECU（CP）＋Central HPC（AP）＋Automotive EthernetというE/E構成が現実解になっています。

• 規格の主眼は「層構造」「標準インタフェース」「ARXMLメタモデル」「開発方法論」の4点で、業務ロジックそのものは標準化しない

• CPは3層構造・静的コンフィグ・OSEK系OSで制御主体、APはPOSIX・C++・ara APIs・SOAで演算主体

• 機能安全（ISO 26262）、コーディング規約（MISRA C／MISRA C++:2023）、サイバーセキュリティ（ISO/SAE 21434）と組み合わせて運用する

• 案件参画前は「CP／AP／Version／ASIL／ツール／通信スタック」を必ず確認する

• 案件動向・単価は「自動車ソフトウェアエンジニアのフリーランス案件」「組込・制御エンジニアのフリーランス単価相場」で確認し、周辺キャリアは「組込・制御エンジニアとは？仕事内容やスキル、年収について解説」「製造業のフリーランスエンジニア案件｜単価相場・職種・組み込み系の動向を解説」も参考にできる

• 車載HubのローカルSIer活用や地域案件を見たい場合は「名古屋のフリーランス案件｜車載・製造業DXの単価相場と探し方」、Unity／組込視点は「C#フリーランスの単価相場｜業務系・Unity・組込の経験別レンジ」が入り口になる

規格の中身を押さえたうえで実務のスコープを決めると、案件マッチの精度が上がり、参画後のキャッチアップコストも下げられます。