• 公開日：2025年09月29日
  • | 更新日：2025年09月30日

AUTOSARの基礎

近年、車両のSDV(Software Defined Vehicle)化の影響で、自動運転などの分野にかかるソフトウェア開発の規模が
大きくなるにつれて、開発にかかる負荷が増大しています。
AUTOSARはソフトウェア開発の負荷を減らすことを目的に導入される事が多いですが、構成が階層別に別れており
各部分で何をやっているか、どこまでがベンダーの提供なのかなど不明な方も多いと思います。

本記事ではAUTOSARの構成について出来る限り分解し基礎的な仕組みについて説明します。

AUTOSARの概要

AUTOSAR（AUTomotive Open System ARchitecture）は、自動車向けソフトウェアの標準規格であり
車載ソフトウェアの統一的な開発基盤を目指して設立された国際的なコンソーシアムです。

2000年代の当初、車には電子制御システム(ECU)が搭載されるようになり、それに伴い
車載ソフトウェアも急速に複雑化しました。
この時期は、メーカーやサプライヤーごとに独自仕様で個別に開発していたため、開発効率、互換性、
保守が困難になるという課題が出ていました。
こうした課題を解決するために、2003年、ドイツの主要な自動車メーカー—BMW、ダイムラー、
フォルクスワーゲン—が中心となり、ボッシュやコンチネンタルなどの大手サプライヤー、さらにはMicrosoftなどの
IT企業と共に、AUTOSARコンソーシアムが設立されました。
目的は「自動車向けの標準化されたソフトウェアアーキテクチャ」を作ること、そしてサプライヤー間の互換性を高めることです。
設立後、まず2004年から2006年にかけてAUTOSAR1.0の初期仕様がまとめられました。
この段階でソフトウェアの基本的なアーキテクチャやコンポーネント化、標準的なインターフェースが整備され始めます。
その後、2007年以降も仕様の拡張は続き、例えば実用的な機能安全や、CAN・Flex Ray・Ethernetなどの通信規格にも対応しました。
加盟企業も世界中に広がり、日本や欧米の自動車・部品メーカーも参加するようになりました。
現在、AUTOSARは世界基準の車載ソフトウェアアーキテクチャとして定着しています。
量産車でもAUTOSAR準拠のECUが使われ、標準仕様のもと効率的な開発・運用が行われています。
今後は、自動運転やコネクテッドサービスの拡大に合わせ、さらに仕様拡張や新分野への対応が進められていく予定です。

AUTOSARの構成

AUTOSARの構成はレイヤードアーキテクチャ(ソフトウェアを機能や責任の異なる複数の層（レイヤー）に分割し、
階層構造で構築する設計手法)となっておりハードウェア依存を排除し、ソフトウェアの再利用性・保守性・移植性を高めるため、Application Layer → Runtime Environment → Basic Softwareという階層で構成されています。

アプリケーション層が車の機能を担当し、BSW層がOSやハードウェアとの連携を担当、RTE層はこれらを橋渡しする役割です。

Basic Software層

次にBSW層の概要を説明します。
BSW(Basic Software)はECU上のOS、通信スタック、ドライバなど、ハードウェアに密接した基礎ソフトウェアです
BSWは主にMCAL、ECU Abstractionレイヤー、サービスレイヤー、コンプレックスデバイスドライバの
モジュールから構成されています。
まず、MCAL（Microcontroller Abstraction Layer）は各種マイコン固有のハードウェアを抽象化し、
上位レイヤーに対してAPIを提供します。
次にECU Abstraction LayerはECUの共通機能（I/Oデバイス等）の抽象化を担当しています。
Services Layerは診断通信、メモリ管理、フラッシュ書き換えといった各種サービスを提供します。
コンプレックスデバイスドライバは既存のBSWの標準APIやレイヤー構造では扱えない特殊なハードウェアや
タイミング制御が必要な場合に対応するためのモジュールです。

MCAL(Microcontroller Abstraction Layer)の具体的な役割

MCALの詳細について説明します。
まず、MCALを実装する目的とその役割についてご説明します。
例えばRenesasのRH850と他社MCUを比較した場合、MCUごとの固有なハードウェア操作…
具体的にはレジスタ制御などを“抽象化”する役割があります。
これによって、MCALが上位層—BSWのサービスやSWCなど—に対して、移植性の高い
API(Application Programming Interface…ソフトウェア部品がプログラム上でやり取りするインターフェース)を提供します。
つまり、上位のソフトウェア層はマイコンの機種による違いを意識せずにプログラムできる、というメリットがあります。
次に、MCALがどんなものを実装しているのか具体的に見ていきます。
まず、各種ドライバの提供です。
例えば、GPIO制御を行うDigital I/O、アナログデジタル変換ドライバのADC、パルス幅変調制御を行うPWM
SPIやUARTなどの通信ドライバ他にタイマ制御やウォッチドッグ制御も含まれます
こうしたドライバをAUTOSARの標準APIに準拠させ、上位層ECUアブストラクションレイヤやサービスレイヤーも含めて、
そのまま利用できるようになっています。

これらのMCALはマイコンベンダー（半導体メーカー）が主に自社マイコンと併せて提供する事が一般的ですが、
その他にElektrobit（エレクトロビット）やETAS（イータス）、dSPACE（ディー・スペース）といったツールベンダーもMCALを提供しています。

 

ここでは、マイコンのGPIO出力を例に、MCALによる抽象化についてご説明します。

マイコンごとに、GPIOの設定方法や制御レジスタは異なります。
例えば、Renesas RH850の場合は特定のレジスタを直接設定する必要がありますが、
それが他社マイコンになった場合ではレジスタの形式やアドレスが違っています。
そのため、マイコンごとの違いを意識した個別実装が必要となり、ソフトウェアの移植性や保守性が課題となります。

MCALは、このようなハードウェア依存の違いを吸収し、
これらの個別の記述を「Dio_WriteChannel(channel, value)」のように標準化しAPIを提供します。
これにより、上位層（例えばECU Abstraction LayerやServices Layer）は、
どのマイコンであっても同一のAPIを使って制御ができるため、アプリケーションのソースコードの共通化・流用が容易になります。

ECU Abstraction Layer(ECU抽象化層)の具体的な役割

次にECU Abstraction Layer(ECU抽象化層)について説明します。

ECU Abstraction Layerを実装する目的についてですが、
ECU Abstraction Layerは、MCALとBSWの上位層、例えばサービス層や通信層などの間を仲介する役割を持っています。
具体的には、ハードウェア依存部分、特定のセンサーやアクチュエーター、あるいはECUごとに固有なデバイスをさらに抽象化し、
上位のサービス層などから機種依存性を排除することを目的としています。

機能面を整理すると、MCALは主にマイコンへのアクセス（レジスタ操作や周辺インターフェース制御）を担当します。
それに対して、ECUはMCALをラップするかたちで機能し、ECUに搭載されている個別のデバイスを、標準化されたAPIとして上位層に提供します。

例えば、外部接続のEEPROMやHブリッジドライバ、特定の通信ハードウェア（RFID、IMUなど）、
あるいは汎用I/Oエクスパンダなどが挙げられます。
これらのデバイスへのアクセスも、ECU Abstraction Layerを介することで標準化され、上位層からは個別デバイスの違いを
意識せずに利用できるようになります。

ECU抽象化層は主にAUTOSARツールベンダー（Vectorなど）が主に提供します。

 

ECU abstraction Layerの主な役割はI/O Hardware Abstraction,External Device Abstraction,
Communication IF Abstractionの3つに別れます。

I/O Hardware Abstractionはデジタル／アナログI/Oの抽象化を担います。
GPIOピンをグループ化し、例えばドアセンサー群やLED群として抽象的に取り扱います。
また、PWM出力やタイマーについても、マイコンごとの実装差・機種差を吸収し、上位層がどの機種でも同じ操作を
行えるようなAPIを提供します。

External Device Abstractionは外部EEPROMや外部Flashなど、ECUに外付けされたメモリやデバイスを抽象化します。
MCALは原則としてマイコン内蔵メモリまでを担当しますが、ECU Abstraction Layerでは車載ネットワーク経由で接続された外部のフラッシュなどにも対応します。
さらに、外部センサーやアクチュエーターについても、車速センサーなど標準化されたインターフェースを介して上位層へ
抽象化APIを提供します。

Communication IF Abstractionは車載ネットワークの物理レイヤー直前、例えばCANやLINのトランシーバ接続、Wakeup制御などのインターフェースも抽象化します。
これにより、ハードウェア違いによる制御手法の変化を上位層から意識せずに済むようになります。

 

ECU abstraction layerの実装例としてVector社の例を挙げます。

Vectorが提供するMICROSARの場合、「EcuAb」と呼ばれるモジュールがこれらの抽象化機能を担当しています。
EcuAbは、ECU構成に応じたカスタマイズや拡張が行えるテンプレートを持ち、Device DriverとService層の間に位置して、
ECUの仕様に合わせたAPI自動生成を行います。

 

センサー制御を例にECU抽象化について説明します。

AUTOSARを実装しない場合

アプリケーション(ソフト)から直接MCUのレジスタにアクセスし、センサー仕様を考慮した上で制御を実行します。
このため車種変更/ECU/MCUメーカーが異なるデバイスを使用した場合、
ポート番号・レジスタ・初期化手順までアプリ側で個別に実装しなければならず、ソフトの流用性が低くなります。

AUTOSARを実装した場合

アプリ層はECU抽象化レイヤ（IoHwAb等）のAPIを呼びます。
呼び出されたECU抽象化レイヤーが、多様なMCU/センサー構成を吸収し、下位ドライバAPIに変換して呼び出します。
この操作によってアプリ層からは常に同じAPIを呼ぶ操作となるため、デバイスを変更した場合でも
RTE・BSWコード差替えのみで対応出来るため、ソフトの流用性が高くなります。

Service Layerの具体的な役割

次にサービスレイヤーについてご説明します。

サービスレイヤーを実装する主な目的は、ECUの運用に必要となる「横断的なサービス」や「汎用機能」、また「運用管理機能」を抽象化し、
上位層、具体的にはSWC（Software Component）やRTE（Runtime Environment）から簡単に利用できるようにすることです。
このサービスレイヤーは、MCALやECU Abstraction Layerよりもさらに上位の層に位置し、アプリケーションから直接呼び出される事の多い標準機能群となっています。
サービスレイヤーで提供される機能としては、通信管理、診断サービス、メモリ管理など、
「車載およびECU運用」に必須となる各種機能パッケージが挙げられます。
これらの機能を自前で一から実装するのは非常に大きな負担となるため、
前述のECU abstraction Layer同様にVectorをはじめとするソフトウェアベンダーが、それぞれパッケージ製品として提供しています。

 

サービスレイヤーの主な担当領域は以下の通りです。

1.Communication Services

Com（Communication Management）
CAN、LIN、FlexRay、Ethernetなど、各種車載通信のメッセージ送受信管理を担います。
ECU間通信を抽象化し、上位層から機種依存性なく利用できます。
PduR（PDU Router）通信データ単位（PDU）のルーティングを制御します。

2.Diagnostic ServicesDcm（Diagnostic Communication Manager）
UDSやISO14229等の車載診断プロトコルを実装し、テスタからの診断要求
（故障診断、ECU制御など）をAPIとして利用可能にします。

3.Memory Services　NvM（Non-volatile memory manager）フラッシュ／EEPROMなどの不揮発性メモリの管理、
読書き、ウェアレベリングの機能を提供します。
Fee／Fls（Flash EEPROM Emulation、Flash管理API）フラッシュメモリのエミュレーションや管理機能も含まれます。

4.設定・管理・運用サービスEcuM（ECU Manager）ECUのスタートアップ、シャットダウン、リセット、
スリープ遷移などの運用管理を行います。
WdgM（Watchdog Manager）システム監視やエラー・ハングアップの検知など、信頼性維持の機能を提供します。

5.OS関連サービス
OS（Operating System）AUTOSAR OSに準拠し、タスクのスケジューリング、割り込み制御、リソース管理を担当します。
SchM（Schedule Manager）BSW関連のスケジューリング管理を行います。

Vector社製品の例として
Vector社のMICROSAR Basicには、これらサービスレイヤーの各種モジュールが網羅的に含まれています。
CAN、LIN、Ethernet、Diagnostics、NvM、Bootloader、OS等、標準機能をプロジェクトの用途に合わせて
パラメータ指定の上、コード自動生成が可能です。
DaVinci DeveloperやDaVinci Configuratorといったツールを用いて、サービスモジュールの組み合わせや設定を
管理することができます。

このようにサービスレイヤーは、ECUの幅広い運用機能を標準化し、効率的な開発や運用管理を実現しています。

COD(Complex Driver)の具体的な役割

Complex Driverは、AUTOSAR Basic Software（BSW）の中でも特別なモジュールで、
標準的なBSWモジュール（例えばMCALやECU Abstraction Layer）では対応できない、
特定のハードウェア機能や独自要件の実装を担います。
主な役割は、低レベルでの制御や特殊なデバイスアクセス、
さらに厳密なタイミング管理が必要な場合の処理など、拡張性の高い対応を可能にすることです。

利用ケース例としては車載独自ハードウェアのような
特殊なセンサーやカスタム通信モジュールなど、一般的なドライバでは対応できないデバイス
厳密なリアルタイム制御や高速対応が必要な機能
例えば、高速ADC、特殊なPWM制御といった、タイミングやレスポンス要求が高い機能
標準ドライバ（MCAL）でサポートしていない特殊機能に対応する場合が挙げられます。
コンプレックスドライバはVectorのようなツールベンダーが提供するほか、
OEMやTier1サプライヤーなどが自ら開発することもあります。

より具体的にコンプレックスドライバの担当領域について説明します。

1.独自デバイスの制御
Complex Driverは、MCALやECU Abstraction Layerで抽象化できない、特殊なデバイスの制御を担います。
例えば、カスタムI/O拡張基板や専用センサーなど、独自設計されたハードウェアに対応します。
レジスタへの直接アクセスや、デバイス固有プロトコルの実装
デバイスの初期化や状態管理、デバイスと上位レイヤ（例えばRTE）とのデータの送受信処理が挙げられます。

2.高速・リアルタイム処理
AUTOSAR標準のBSWでは応答速度やタイミング精度が足りないケースに、Complex Driverが有効です。
外部信号検出などの割り込みハンドリング機能、専用タイマーによる制御やタイミング管理、リングバッファ等を用いて、
高速なデータ収集や処理の実現をします。

3.独自通信プロトコルの実装
一般的なCAN、LIN、Ethernetなどの標準通信方式以外にも、Complex Driverは特殊な通信プロトコルへの対応に利用されます。
独自SPI通信やI2Cの特殊プロトコルの実装GPIOなどを活用した独自物理層へのアクセス手法を実施します。

4.上位層とのインターフェース提供
Application LayerやRTEと連携するためのインターフェースもComplex Driverの重要な役割です。
CDD APIを設計・提供し、アプリケーション層から制御可能にするイベント通知やコールバックによる柔軟な連携機能も持っています。
このように、Complex Driverは標準BSWで対応できない特殊なハードウェア制御や高度なリアルタイム応答、独自通信、
そして上位層との連携を担うことで、車載ECUの柔軟な機能拡張を実現しています。

RTE(Run Time Environment)の具体的な役割

次にRTEについて説明します。AUTOSARにおけるRTE、すなわちRuntime Environmentは、
アプリケーション層（SWC：Software Component…AUTOSARの中で機能単位として
設計・配置されるソフトウェアの部品）とBasic Software（BSW）の間に位置するミドルウェアです。
このRTEが両者を連携させることで、システム全体の柔軟性・再利用性を高めています。

主な役割として1つめはSWC同士の通信仕様の解決です。
RTEはアプリケーションを構成する複数のSWC間の通信手順を調整・管理します。
2つめはSWCとBSW間の通信の抽象化です。
SWCを、下位のECUドライバやOSなどのBSWから切り離し、両者が直接依存しないように連携をサポートします。
3つめはECU固有差異の吸収／アプリケーション再利用性向上です。
ECUごとに異なるハードウェア仕様の違いを、RTEが吸収することで、同じアプリケーションをさまざまなECUで
再利用できるようにします。
最後にインターフェース管理です。SWC同士、およびSWCとBSW間でのポート、イベント、データのやり取りを担当し、
システム全体の連携を円滑にします。

 

ここではいくつか例を挙げてRTE層の動作を説明します。

まず初めにSWC間の通信処理です。
RTEは、複数のSWCがあるとき、その間の「ポート」や「コネクタ」の通信経路を動的に生成/管理します。
ここでの例としてはアプリケーション層のセンサーコンポーネントからセンサー情報を入手し、同じくアプリケーション層にある
制御コンポーネントへのデータの受け渡しについて説明します。
具体的な処理例はセンサーコンポーネントがRTEにある「RTE_Write()」APIでデータ送信し
RTEがそのデータを制御コンポーネントの「RTE_Read()」バッファへコピーします。
また、必要に応じて、データの変換や同期処理（タスク間メモリコピー、排他制御）を実装します。

次にSWCとBSW間の通信ブリッジについて説明します。
RTEは、アプリケーションからBSW（例：ドライバ、OS）へのアクセス窓口も担います。
例えばアプリケーションがCAN送信要求した場合、RTE経由でCOM StackやCANドライバにリクエスト伝達を行います。
上図ではSWCからBSW層にある各レイヤーのAPIを呼び出す際の動作、APIの例を示しています。

Application Layerの具体的な役割

最後にAUTOSAR構成の最上位層であるApplication層の説明をします。

AUTOSAR構造におけるApplication層は、
車載ECU上でユーザ機能—例えば車両の制御、情報処理や安全機能など—を実現するためのソフトウェア部品
（SWC：Software Component）が集まった最上位層です。

ここには、車載システムが必要とする各種機能、たとえばエンジン制御、ブレーキ制御、インフォテインメント、
セーフティ機能などのロジックやアルゴリズムが集約されています。
アプリケーション層の各SWCは、RTE（Runtime Environment）を介して、他のSWCやBSW（Basic Software）ドライバ層と通信します。
各SWCは、システム機能の部品となっており、それぞれ1つまたは複数のRunnable Entity
（Runnable：実際に動く関数や処理単位）を持っています。
Runnable単位で、特定機能の計算や処理、センサー値からの制御ロジックの実行などが行われています。

 

*1 ルネサスエレクトロニクス社製 IPS2550 高速モーターの回転制御向け誘導型位置センサー（車載用）

アプリケーション層の処理の例としてアクチュエーター制御、他ECUとの通信について説明します。
まず。ステアリングを代表としたモーター制御では、車外にある角度センサーからモーターの角度情報の値を取得します
取得した情報はセンサーBSWドライバからRTE経由で値を受け取ります
値を受け取ってからアプリケーション層でフィルタ・補正処理（ノイズ除去、単位変換など）を行います。
その後、受け取った情報を基に制御アルゴリズムを実行します
具体的にはフィードバック制御/ロジック実装等が挙げられ、目標値に対して制御量を計算します
また、状態遷移・安全判定・故障診断など、車両制御に必要な計算、処理をアプリケーション層で実行します。
計算結果をRTE経由でBSWに渡すことで、最終的にアクチュエーター制御（モーター、バルブ、ランプ点灯等）を行います。
その他にも他ECUとの通信などもRTEを経由してCAN、LIN、Ethernetなどで送受信を行います。
このようにアプリケーション層はBSW、RTEを経由して得た情報を受け取り、最終的には車のアクチュエーター、
通信などを制御する役割を担っています。

 

まとめ

  • AUTOSARは車載ソフトウェア開発の負荷低減を目的としたソフトウェアの規格です。
  • AUTOSARはApplication Layer/Runtime Environment/Basic Software
    (MCAL/ECU Abstraction Layer/Service Layer/Complex Driver)から構成されています。
  • MCALはMCUの抽象化、ECU Abstraction LayerはECUの抽象化、Service Layerは
    個々のアプリやECUではなく、車載ソフト全体の汎用機能を担当し、Complex DriverはMCALや
    ECU Abstraction Layerで対応できない特殊なデバイスや独自通信・高速リアルタイム処理が
    必要な場合に実装されます。
  • Application Layerは車の制御を行い、Runtime EnvironmentはAPPとBSW間の通信を担当しています。

最後に、Renesas製品はAUTOSARに対応したMCALをMCUと共に提供しています。
最新版の情報やAUTOSARの導入を検討されている方は是非弊社にご連絡お願い致します。

関連記事