Classic Platform

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.

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.

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

“We’ll just change the signal in software”: in Classic, changing a ComSignal mapping usually means regenerating code, re-running safety analysis, and reflashing. Runtime signal reconfiguration is not the Classic model. That’s why signal contracts are negotiated early and frozen in integration milestones.

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?

A. Replace the OS scheduler for HPC workloadsB. Glue SWCs to BSW — route data between application ports and the COM stackC. Generate SOME/IP service manifests at runtimeD. Run the Android HAL for vehicle properties

2. How is Classic AUTOSAR software primarily configured?

A. Dynamic JSON manifests loaded at runtimeB. Static ARXML files processed at build time by code generatorsC. Android-style resource XML in the APKD. Kernel command-line parameters

3. Classic AUTOSAR communication is best described as:

A. Service-based with dynamic discovery via SOME/IPB. Signal-based with ComSignal-to-PDU mapping over CAN/LINC. gRPC/protobuf over TCPD. Shared memory between POSIX processes