AUTOSAR Classic Platform学習ノート：第1章 全体アーキテクチャ
対象プラットフォーム：AUTOSAR Classic Platform
本章ではClassic Platform固有のレイヤードアーキテクチャを扱う。Adaptive Platformのアーキテクチャとは構成が異なる。
キーワード：Application、RTE、BSW、MCAL、Complex Driver
本章の対象範囲
このノートで説明するApplication SWC → RTE → BSW → MCAL → Hardwareは、AUTOSAR Classic Platformの基本構成である。
Adaptive Platformも、アプリケーションの分離、標準インターフェース、サービス指向通信など、AUTOSARとして共通する目的を持つ。ただし、ClassicのRTE、階層型BSW、MCAL、Runnable Entityをそのまま使用する構成ではない。AdaptiveではAdaptive Application、ARA、Functional Cluster、POSIX OS、Processなどを中心とした別のアーキテクチャを採用する。
| 本章で扱うClassicの要素 | Adaptiveでの考え方・代表要素 |
|---|---|
| Application SWC | Adaptive Application |
| Runnable Entity | Process、Thread、Function |
| RTE | ARA API／Functional Cluster |
| Services・ECU Abstraction・MCAL | Adaptive Platform Services、OS・Hardware Abstraction |
| AUTOSAR OS Task | POSIX Process／Thread |
| 静的に設計・生成された構成 | 実行時のサービス探索など、より動的な構成 |
注意： この表は概念を理解するための対比であり、Classicの要素とAdaptiveの要素が一対一で置き換わることを意味しない。
1. この章のゴール
この章では、AUTOSAR Classic Platformを構成する各レイヤーの役割と、アプリケーションからハードウェアまで処理が伝わる仕組みを理解する。
学習後、次の質問に答えられることを目標とする。
- AUTOSARがソフトウェアをレイヤーに分ける理由は何か
- Application、RTE、BSWはそれぞれ何を担当するか
- Runnable Entity（RE）がいつ、どのように実行されるか
- ECU Abstraction LayerとMCALは何が違うか
- SWCからCANフレームが送信されるまでに何が起きるか
- Complex Driverはどのような場合に使用するか
2. まず全体像をつかむ
一言で整理すると
| レイヤー | 一言で表す役割 | 主な関心事 |
|---|---|---|
| Application | 車両機能を実現する | 「何を制御するか」 |
| RTE | SWCと周辺機能をつなぐ | 「誰とどう接続するか」 |
| Services | ECU共通機能を提供する | OS、通信、診断、状態管理 |
| ECU Abstraction | ECU上のデバイス差を隠す | 外付けデバイスやI/O |
| MCAL | マイコン固有の差を隠す | レジスタ、内蔵周辺回路 |
| Complex Driver | 標準構成で扱いにくい処理を担う | 特殊、高速、標準外処理 |
レイヤー化する理由
- ハードウェアが変わっても、上位ソフトウェアへの影響を抑える
- SWCやBSWモジュールを別プロジェクトで再利用しやすくする
- 機能ごとの責任範囲を明確にする
- 複数のサプライヤーが共通インターフェースで開発できるようにする
覚え方： 上位層ほど車両機能に近く、下位層ほどハードウェアに近い。
3. 各レイヤーの役割
3.1 Application Software Layer
Application Software Layerは、車両として実現したい機能や制御ロジックをSoftware Component（SWC）として実装する層である。
Application Software LayerとSWCの関係
1つのECUのApplication Software Layerには、通常、役割の異なる複数のApplication SWCが配置される。さらに、各SWCの内部には1つ以上のRunnable Entity（RE）が定義される。
階層構造として表すと、次のようになる。
Application Software Layer
├── SWC A
│ ├── Runnable Entity A1
│ └── Runnable Entity A2
├── SWC B
│ ├── Runnable Entity B1
│ └── Runnable Entity B2
└── SWC C
└── Runnable Entity C1
| 要素 | 位置づけ | 実行単位か |
|---|---|---|
| Application Software Layer | 複数のApplication SWCを含むレイヤー | いいえ |
| SWC | 機能と通信インターフェースをまとめる設計単位 | いいえ |
| Runnable Entity | SWC内部に定義される処理 | はい |
重要： SWCは機能をまとめる単位であり、それ自体がOS上で実行されるわけではない。実際にOS Taskのコンテキストで実行されるのは、SWC内部のRunnable Entityである。
また、SWC同士は原則として直接関数を呼び合わず、PortとRTEを介して通信する。
主な役割
- センサ値やほかのSWCからの情報を受け取る
- 判定、演算、状態管理などの制御ロジックを実行する
- 制御要求や車両状態をほかのSWCへ出力する
- RTEを介してBSWサービスを利用する
代表例
- ADAS制御
- モータ制御
- バッテリー管理
- ドア・エアコン制御
- 車両状態判定
重要： SWCは、原則としてCANドライバやマイコンレジスタを直接操作しない。
3.2 Runtime Environment（RTE）
RTEはApplication LayerとBSWの間に位置し、SWCの通信と実行を仲介する。
主な役割
- SWC間通信
- SWCとBSWサービス間の通信
- PortとInterfaceの接続
- Eventに基づくRunnableの起動
- ECU内通信とECU間通信の違いの隠蔽
RTEが仲介する範囲
| 通信・連携 | RTEの関与 | 基本的な仕組み |
|---|---|---|
| SWC ↔ SWC（同一ECU） | あり | Port、Interface、RTE API |
| SWC ↔ SWC（別ECU） | あり | RTEからCommunication Stackへ接続 |
| SWC ↔ BSW Service | あり | Service Port、RTE API |
| BSW ↔ BSW | 原則なし | 標準BSW API、Callback、PDU転送など |
SWCから見れば、相手が同じECUにあるか別のECUにあるかにかかわらず、基本的にはPortを通じてデータを送受信する。別ECUへの通信では、RTEの下でCOM、PduR、CanIfなどのCommunication Stackが実際の転送を担う。
Application SWCがNvMなどのBSWサービスを利用する場合も、原則としてService PortとRTEを介する。一方、BSWモジュール同士の連携はRTEを経由せず、AUTOSARで定義されたBSW API、Callback、PDU転送などを使用する。
注意： 「RTEはECU内のすべての通信を中継する共通バス」ではない。RTEは主にApplication SWC側の通信とサービス利用を抽象化する。
覚え方： RTEはSWC専用の「接続・実行基盤」。
3.3 Runnable Entity（RE）
Runnable Entity（RE）は、Application SWC内部でRTEから起動される最小の実行単位である。一般には、単にRunnableとも呼ばれる。
SWCは機能をまとめる設計上の単位であり、SWCそのものが直接実行されるわけではない。実際にCPU上で動作する処理は、SWC内部に定義されたRunnable Entityとして実装される。
SWC、RE、Eventの関係
| 要素 | 意味 | 例 |
|---|---|---|
| SWC | 車両機能をまとめるソフトウェア単位 | 車速監視SWC |
| Runnable Entity | SWC内部で実行される処理単位 | 車速判定処理 |
| RTE Event | REを起動する条件 | 10 ms周期、データ受信 |
| RTE | EventとREを結び、REの実行を仲介する | 生成されたRTEコード |
| OS Task | REが実際に動作する実行コンテキスト | 10 ms Task |
代表的なRTE Event
| Event | 起動タイミング |
|---|---|
| TimingEvent | 指定した周期で起動する |
| DataReceivedEvent | データを受信したときに起動する |
| DataReceiveErrorEvent | データ受信エラーを検出したときに起動する |
| OperationInvokedEvent | ClientからServer Operationが呼ばれたときに起動する |
| InitEvent | ECUまたはSWCの初期化時に起動する |
| ModeSwitchEvent | モードが切り替わったときに起動する |
周期Runnableが実行されるまで
重要： ARXMLでは、REとRTE Eventの関係をSWC Internal Behaviorとして記述する。ECU統合時にREをOS Taskへマッピングし、その設定に基づいてRTEコードが生成される。
REとRTEを混同しない： REは「実行される処理」、RTEは「REの起動や通信を仲介する環境」である。
3.4 Basic Software（BSW）
BSWは、ECUの動作に共通して必要となる基盤機能を提供するソフトウェア群である。主にServices Layer、ECU Abstraction Layer、MCAL、Complex Driversから構成される。
BSWの階層構成
| 上からの順序 | レイヤー | 役割 | ハードウェア依存度 |
|---|---|---|---|
| 1 | Services Layer | ECU共通サービスを提供する | 低い |
| 2 | ECU Abstraction Layer | ECU基板上のデバイス差を隠す | 中程度 |
| 3 | MCAL | MCU内蔵周辺機能とレジスタ差を隠す | 高い |
| 横断的 | Complex Drivers | 標準階層で扱いにくい処理を実現する | 設計によるが高くなりやすい |
図の読み方： 上下の配置は抽象度を示す。必ずすべての呼び出しがServices → ECU Abstraction → MCALの全レイヤーを通過するわけではない。利用する機能に応じて、AUTOSARで定義されたインターフェースを介して必要な下位モジュールへ接続する。
Services Layer
OS、通信、診断、メモリ管理、ECU状態管理など、上位層やほかのBSWが利用する共通サービスを提供する。
| 分野 | 代表モジュール | 主な役割 |
|---|---|---|
| OS | OS | Task、Event、Alarm、割り込み管理 |
| 通信 | COM、PduR、Nm | 信号処理、PDU転送、ネットワーク管理 |
| 診断 | DCM、DEM | 診断要求、故障イベント管理 |
| メモリ | NvM | 不揮発データ管理 |
| ECU管理 | EcuM、BswM | 起動・終了、モード制御 |
| 監視 | WdgM | ソフトウェア実行監視 |
ECU Abstraction Layer
ECU上に搭載された外付けデバイスやI/Oデバイスの違いを上位層から隠蔽する。
対象例
- 外部Flash、EEPROM
- センサ、アクチュエータ
- CANトランシーバ
- Ethernetトランシーバ／PHY
- 各種I/Oデバイス
覚え方： ECU Abstractionは「ECU基板上の部品の違い」を隠す。
Microcontroller Abstraction Layer（MCAL）
MCALは、マイクロコントローラ内蔵の周辺機能やレジスタ操作を標準インターフェースとして提供する。
代表的なドライバ
- Port、Dio、Adc、Pwm
- Spi、Can、Ethernet
- Flash、GPT
覚え方： MCALは「マイコン内部の違い」を隠す。AUTOSARの中でも特にMCU依存性が高い。
ECU AbstractionとMCALの違い
| 比較項目 | ECU Abstraction | MCAL |
|---|---|---|
| 主な対象 | ECU基板上のデバイス | マイコン内蔵周辺機能 |
| 例 | EEPROM、Transceiver、外部センサ | CAN Controller、ADC、SPI、PWM |
| 目的 | デバイス構成の差を隠す | MCU品種・レジスタの差を隠す |
| ハードウェアとの距離 | MCALより上位 | ハードウェアに最も近い標準層 |
Complex Drivers（CDD）
Complex Driverは、標準BSWやMCALだけでは実現しにくい特殊な処理に使用する。
使用例
- 高速な割り込み処理
- 独自ASICや特殊デバイスの制御
- AUTOSAR標準外のハードウェア制御
- 厳しいリアルタイム制約を持つ処理
CDDは柔軟性が高い一方、移植性や標準化を損なう可能性がある。採用時には、標準モジュールで実現できない理由を明確にする必要がある。
4. 処理の流れで理解する
例：SWCからCAN信号を送信する
この例でSWCが知っているのは、PortとRTE APIである。CAN ID、送信メールボックス、レジスタ操作などは下位層が担当する。
| ステップ | 担当 | 処理 |
|---|---|---|
| 1 | SWC / RTE | アプリケーションデータを渡す |
| 2 | COM | SignalをI-PDUに格納する |
| 3 | PduR | PDUを適切な通信経路へ転送する |
| 4 | CanIf | CAN Driverを抽象化して送信を依頼する |
| 5 | Can Driver | CAN Controllerを操作する |
5. 本章の要点
- AUTOSAR Classicは、機能とハードウェア依存部分を分離するためにレイヤー構造を採用する。
- Application Layerでは、車両機能をSWCとして実装する。
- RTEは、Portを通じたSWC間・SWCとBSW間の通信とRunnable実行を仲介する。
- Runnable Entityは、RTE Eventによって起動されるSWC内部の実行単位である。
- ECU統合時には、Runnable Entityを実際に実行するOS Taskへマッピングする。
- Services Layerは、OS、通信、診断、メモリ、ECU管理などの共通機能を提供する。
- ECU Abstraction LayerはECU基板上のデバイス差を隠す。
- MCALはマイコン内蔵周辺機能とレジスタの差を隠す。
- Complex Driverは標準構成で扱えない特殊処理に限定して使用する。
- 上位層ほどハードウェア非依存性が高く、下位層ほどハードウェア依存性が高い。
6. 用語集
| 用語 | 意味 | この章での役割 |
|---|---|---|
| SWC | Software Component | 車両機能・制御ロジックの単位 |
| RTE | Runtime Environment | SWCの通信と実行を仲介する環境 |
| BSW | Basic Software | ECU共通の基盤ソフトウェア |
| RE / Runnable Entity | SWC内部の最小実行単位 | RTE Eventによって起動される処理 |
| RTE Event | REの起動条件 | 周期、データ受信、Operation呼出しなど |
| Port | SWCの通信窓口 | Interfaceに基づいて接続される |
| Event | Runnableの起動条件 | 周期、データ受信、Operation呼出しなど |
| Signal | アプリケーションデータ | COMによってI-PDUへ格納される |
| PDU | 通信データ単位 | 通信スタック内で受け渡される |
| MCAL | Microcontroller Abstraction Layer | MCU固有機能を抽象化する層 |
| CDD | Complex Device Driver | 特殊・高速・標準外処理を担う |
勉強した内容をChatGPTで整理してもらいましたので、メモとして残しました。ありがとうございます。