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で整理してもらいましたので、メモとして残しました。ありがとうございます。