Classic Platform

Intermediate10 min read

Assumes: 4.1 Why AUTOSAR Exists

TL;DR

AUTOSAR Classic is the platform for MCU-based ECUs: body modules, gateways, engine controllers, ABS. Application logic lives in Software Components (SWCs) connected through the Runtime Environment (RTE) to Basic Software (BSW): COM stack, OS, diagnostics, drivers. Everything is statically configured at build time via ARXML files and code-generated into C. Communication is signal-based. A VehicleSpeed signal on CAN, not a getVehicleSpeed() service call. If you’ve traced a DBC signal or heard “ComSignal,” you’re in Classic territory.

Classic AUTOSAR is the workhorse behind most ECUs on the vehicle network. This page maps the layers you’ll see in architecture diagrams, supplier deliverables, and integration specs, even if your daily job is on the Qualcomm cockpit SoC. Welcome to the most committee-designed software architecture in human history — and somehow, it works.

Target: MCU-Based ECUs

Classic targets microcontrollers with constrained resources:

Characteristic	Typical Classic ECU
Silicon	Infineon Aurix, Renesas RH850, NXP S32K, STM32
RAM	KB to low MB
OS	AUTOSAR OS (OSEK-based) or bare-metal with BSW
Language	C (MISRA-constrained)
Config	Static ARXML → code generation at build time
Communication	CAN, CAN FD, LIN, FlexRay (signal frames)
Lifecycle	Flashed once per variant; runtime changes are rare

These ECUs run one function or a small cluster of related functions. They don’t run Android. They don’t discover services at runtime. They broadcast signals on a schedule.

Think of Classic as constrained: C code, CAN signals, constrained MCU chips.

Layered Architecture

Classic AUTOSAR organizes software in strict horizontal layers. Data flows down through RTE to BSW; interrupts and hardware events flow up.

flowchart TB
    subgraph AppLayer["Application Layer"]
        SWC1["SWC: DoorLock<br/>Runnable entities"]
        SWC2["SWC: MirrorFold<br/>Runnable entities"]
        SWC3["SWC: WindowCtrl<br/>Runnable entities"]
    end

    subgraph RTE_Layer["Runtime Environment (RTE)"]
        RTE["RTE Generator Output<br/>Sender-Receiver · Client-Server ports<br/>Mode switches · Data consistency"]
    end

    subgraph BSW_Layer["Basic Software (BSW)"]
        COM["COM Stack<br/>Signal ↔ PDU mapping<br/>ComSignal · ComIPdu"]
        PDUR["PduR<br/>PDU routing"]
        CAN["CanIf → CanTp → CanSM"]
        DCM["Dcm · Dem · Det<br/>Diagnostics"]
        OS["AUTOSAR OS<br/>Tasks · ISRs · Alarms · Resources"]
        MCAL["MCAL<br/>Adc · Dio · Can · Mcu · Wdg"]
    end

    subgraph HW["Hardware"]
        MCU["MCU + Transceivers<br/>CAN · LIN · GPIO"]
    end

    SWC1 <-->|"RTE API"| RTE
    SWC2 <-->|"RTE API"| RTE
    SWC3 <-->|"RTE API"| RTE
    RTE --> COM
    COM --> PDUR
    PDUR --> CAN
    RTE --> DCM
    OS --> RTE
    OS --> SWC1
    OS --> SWC2
    OS --> SWC3
    CAN --> MCAL
    DCM --> MCAL
    MCAL --> MCU

Application Layer: Software Components (SWCs)

An SWC encapsulates application logic, the “what the ECU does.” Examples: compute filtered wheel speed, control mirror fold motor, implement UDS diagnostic routines.

SWCs expose ports:

• Sender-Receiver (S/R): data signals (e.g., DoorLockStatus)
• Client-Server (C/S): function calls (e.g., ReadNvmBlock())

SWCs contain runnables, functions the OS schedules periodically or on event trigger. You don’t call runnables directly; the RTE and OS invoke them.

Runtime Environment (RTE)

The RTE is generated code, the glue between SWCs and BSW. It:

• Routes S/R data between SWCs (intra-ECU) and to/from COM (inter-ECU)
• Implements C/S calls locally or via COM serialization
• Enforces data consistency and mode management
• Hides BSW details from application developers

Key insight: Application developers write against RTE APIs, not raw CAN registers or OS calls. The RTE generator produces those APIs from ARXML.

Basic Software (BSW)

BSW provides standardized services below the RTE:

BSW Module	Role
COM	Maps application signals (ComSignal) to protocol PDUs
PduR	Routes PDUs between COM, diagnostics, and bus interfaces
CanIf / CanTp / CanSM	CAN driver abstraction, transport, state management
LinIf / LinSM	LIN stack
Dcm / Dem / Det	UDS diagnostics, event memory, development error tracer
NvM / MemIf / Fee/Fls	Non-volatile memory abstraction
EcuM / BswM	ECU and BSW mode management (startup, shutdown, sleep)
WdgM / WdgIf	Watchdog supervision
OS	Task scheduling, ISRs, resources, alarms
MCAL	Microcontroller drivers (ADC, DIO, CAN, SPI, etc.)

Mental Model

Classic AUTOSAR is a factory assembly line. SWCs are workers at stations doing specific jobs. The RTE is the conveyor belt moving parts (data) between stations. BSW is facilities — power (OS scheduling), shipping (COM/CAN), quality control (diagnostics), and the loading dock (MCAL to hardware). Everything is designed and wired before the factory opens (build-time ARXML). No rearranging the line at runtime.

Mnemonic: SWC rides RTE, RTE rides BSW, BSW rides MCAL — four-deck bus, top to bottom.

Think About It

You change one signal name in the DBC file. Why does the entire BSW need to be regenerated?

Reveal Answer

In Classic AUTOSAR, a DBC signal name propagates through ARXML → code generators into RTE sender-receiver ports, ComSignal definitions, PDU packing, PduR routing, and OS task bindings. A rename breaks the compile-time contract chain linking SWC ports to on-wire bytes — not just a label in a spreadsheet. Regenerating RTE/COM/OS code keeps every layer consistent; skipping regeneration produces a binary that compiles but transmits or decodes garbage on the bus.

Static Configuration via ARXML

Classic AUTOSAR is configuration-driven. Almost nothing is hard-coded. It’s declared in ARXML (AUTOSAR XML) and processed by tooling (EB tresos, DaVinci Configurator, ISOLAR) to generate C source.

What Gets Configured in ARXML

ARXML Element	Configures
EcucModuleConfigurationValues	BSW module parameters (COM, OS, Can, etc.)
SwComponentType / Composition	SWC definitions, ports, runnables
System / Fibex	Network topology, signal definitions, ECU extract
OsTask / OsAlarm / OsEvent	OS scheduling: task periods, priorities
ComSignal / ComIPdu	Signal-to-PDU mapping, byte order, scaling
PduR routing	Which PDUs route to which bus

The workflow:

1. System architect defines signals and ECU topology (often imported from CANoe / network design)
2. ECU integrator configures BSW modules in ARXML
3. Application developer writes SWC code against RTE headers
4. Build runs code generators → RTE, OS, COM config → compiles to flashable binary

Common Gotcha

If you change a ComSignal mapping in Classic without regenerating the full toolchain, the ECU compiles fine but sends garbage on the bus.

Classic changes require: ARXML update → code generation → safety re-analysis → reflash. Runtime signal reconfiguration is not the Classic model — contracts are frozen at integration milestones.

Common Gotcha

Beginner thinks Classic AUTOSAR is just “C code with CAN drivers.”

Reality: it’s a layered stack (SWC → RTE → COM → PduR → CanIf → MCAL) where application developers never touch raw CAN registers. The RTE generator, OS config, and COM mappings are all derived from ARXML — change one layer without the others and the stack silently misbehaves.

Signal-Based COM Stack

Classic communication is signal-centric, not service-centric:

Application:  SWC sends VehicleSpeed via RTE
     ↓
RTE:          Sender-Receiver port → COM API
     ↓
COM:          ComSignal "VehicleSpeed" packed into ComIPdu
     ↓
PduR:         Routes IPDU to CanIf
     ↓
CanIf/CanDrv: Transmits CAN frame 0x123 on Bus 1
     ↓
Physical:     CAN bus → other ECUs decode same signal from DBC/Fibex

On the receiving ECU, the path reverses: CAN frame → ComIPdu → ComSignal → RTE → receiving SWC.

This is the same signal model from Module 3.1. Classic AUTOSAR formalizes it in BSW with generated code instead of ad-hoc parsing.

COM Stack Layers (Receive Path)

Layer	What It Does
Com	Signal ↔ IPDU packing/unpacking, update bits, filters
PduR	Routes IPDUs between COM, DCM (diagnostics), and bus IFs
CanIf	Abstract CAN controller: HOH (Hardware Object Handle) mapping
CanDrv	Low-level CAN register access (often MCAL)

AUTOSAR OS (OSEK-Based)

Classic ECUs run AUTOSAR OS, an extension of OSEK/VDX OS designed for deterministic scheduling:

OSEK/AUTOSAR OS Concept	Purpose
Task	Scheduled execution unit (Basic or Extended)
ISR (Category 1/2)	Interrupt handlers; Cat1 can’t call OS APIs
Alarm	Periodic activation of tasks
Event	Task synchronization and triggering
Resource	Mutex for shared data (priority ceiling protocol)
Schedule Table	Time-triggered task dispatch (like a cron for tasks)

Why Not Linux?

An ABS ECU needs provable worst-case response to a wheel speed pulse. AUTOSAR OS provides:

• Fixed-priority preemptive scheduling with analyzed WCET
• Stack usage analysis per task
• Protection hooks (memory, timing) in safety builds
• Minimal overhead: no MMU page faults, no GC pauses

This connects directly to Module 0.2: Classic ECUs on AUTOSAR OS are hard real-time by design.

Classic vs Adaptive: Side-by-Side

Dimension	Classic	Adaptive
Target	MCU ECUs	HPC SoCs
Language	C	C++14/17
OS	AUTOSAR OS (OSEK)	POSIX (Linux, QNX)
Config	Static ARXML, build-time	Dynamic manifest, runtime
Communication	Signal-based (CAN/LIN)	Service-based (SOME/IP)
Execution unit	OS Tasks / Runnables	Processes
Memory	KB–MB	GB
Update model	Full ECU reflash	Process/container OTA
Your daily touch	DBC signals, gateway routing	ara::com services on cockpit SoC

Where You'll See This

Classic AUTOSAR surfaces in your work even from the cockpit side:

• DBC / ARXML signal names in vehicle integration specs: VehSpd, EngSpd, DoorAjarFrntLe
• Gateway routing tables that forward Classic COM signals to Ethernet/SOME/IP
• UDS diagnostic requests routed to Classic ECUs via DoIP → CAN gateway
• VHAL property mappings that trace back to Classic signal definitions
• Timing requirements (“signal must update within 20 ms”) rooted in Classic OS task periods

When debugging “vehicle speed is wrong in AAOS,” the bug may be three hops away in a Classic ECU’s ComSignal scaling, not in your Android code.

Connect the Dots

Module 3.1 defined signal-based communication; Classic AUTOSAR is the industrial implementation. Module 4.3 covers Adaptive for your HPC world. Module 4.4 shows how Classic signals cross the gateway to Adaptive services on your Qualcomm platform.

What to remember

1. Classic targets MCU ECUs with C code, static ARXML config, and signal-based COM.
2. Layers: SWCs → RTE → BSW (COM, OS, diagnostics, MCAL) → hardware.
3. The RTE is generated glue. Application code never touches raw CAN or OS primitives directly.
4. AUTOSAR OS (OSEK-based) provides deterministic task scheduling for safety-critical ECUs.

Check Your Understanding

1. In Classic AUTOSAR, what is the primary role of the RTE?

Recall

A. Run the Android Vehicle HAL for exposing vehicle property data to appsB. Generate SOME/IP service manifests dynamically at application runtimeC. Replace the OSEK OS scheduler for high-performance computing workloadsD. Glue SWCs to BSW — route data between application ports and COM stack

2. How is Classic AUTOSAR software primarily configured?

Recall

A. Static ARXML files processed at build time by code generatorsB. Dynamic JSON manifests loaded and parsed by the application at runtimeC. Kernel command-line parameters passed to the bootloader at startupD. Android-style resource XML files bundled inside an installable APK

3. Classic AUTOSAR communication is best described as:

Applied

A. Signal-based with ComSignal-to-PDU mapping over CAN/LIN/FlexRay busesB. gRPC with protobuf serialization over TCP connections between HPC processesC. Service-based with dynamic discovery via SOME/IP-SD multicast on EthernetD. Shared memory regions between POSIX processes on the same Linux kernel

4. An ABS ECU must respond to a wheel-speed pulse within a provable worst-case deadline. Why does Classic use AUTOSAR OS (OSEK-based) instead of Linux?

Applied

A. Linux lacks any C compiler toolchain supporting MISRA-constrained source codeB. OSEK OS includes native SOME/IP-SD service discovery for real-time domainsC. Linux kernel cannot access CAN transceiver hardware on MCU target platformsD. OSEK provides fixed-priority preemptive scheduling with provable WCET bounds

5. Using the factory assembly line mental model, data flows from an SWC sending VehicleSpeed down through RTE to COM, PduR, and CanIf. Which layer sits directly above MCAL and below application SWCs?

Synthesis

Connects to: Module 0 — Real-Time Constraints

A. BSW (COM, OS, diagnostics) with RTE as generated glue to application SWCsB. ara::com proxy binding connected to SOME/IP-SD for dynamic service lookupC. The Android VHAL property cache exposed through Car Service binder callsD. Adaptive Execution Manager reading machine manifests and starting processes

6. A body ECU SWC developer needs to publish DoorLockStatus on CAN. They write against RTE sender-receiver APIs — never touching CanIf registers. After a DBC signal rename, what is the correct Classic integration workflow?

Synthesis

Connects to: Module 8 — Build, Flash & Update

A. Modify the Linux device tree on the cockpit SoC and rebuild the BSP imageB. Push an OTA capsule update via Adaptive UCM directly to the MCU targetC. Update ARXML → regenerate RTE/COM/OS code → re-run safety analysis → reflashD. Edit the SWC C file only — COM mappings resolve at runtime via SOME/IP-SD

Further Reading

• AUTOSAR Classic Platform — Official specification portal for the SWC/RTE/BSW layered architecture, virtual functional bus, and signal-based COM stack covered on this page.
• AUTOSAR Methodology and Templates — Defines the ARXML workflow, work products, and integration process that Classic ECU development follows from system design through code generation.
• Elektrobit — EB tresos — Commercial Classic AUTOSAR tooling for BSW configuration, RTE generation, and MCAL integration — a reference implementation of the ARXML-driven workflow.
• Vector — MICROSAR Classic — Widely deployed Classic BSW stack (COM, OS, diagnostics, MCAL) that implements the layered architecture and OSEK-based scheduling described here.
• Vector — AUTOSAR Communication Know-How — Deep-dive articles on the COM stack, PduR routing, and signal-to-PDU mapping that mirror the receive-path layers in this page’s diagram.
• AUTOSAR Classic Platform Working Groups — Working group structure for RTE, MCAL, and BSW modules, useful for understanding which specification owns each layer in the stack.
• ISO 11898-1 — Controller Area Network (CAN) — The physical and data-link standard underlying Classic signal transport on CAN buses referenced throughout the COM stack discussion.