AUTOSAR Classic Platform

About 1762 wordsAbout 6 min

2026-03-25

Overview

AUTOSAR Classic Platform (CP) is designed for deeply embedded, resource-constrained microcontrollers used in traditional automotive control functions: engine management, transmission control, ABS, airbag, body electronics, and chassis control. It is the dominant automotive software platform globally, deployed in hundreds of millions of ECUs.

Classic Platform characteristics:

MCU-based: Targets 16/32-bit microcontrollers (Infineon Aurix, NXP S32K, Renesas RH850, STM32)
Deterministic, real-time: Preemptive or cooperative RTOS with precise task timing
Static configuration: System topology, task allocation, and network topology defined at build time
Signal-oriented communication: Data exchanged as named signals via the RTE
C language: Primary language for SWC and BSW development
ASIL A–D qualified: Entire BSW stack pre-qualified by vendors

AUTOSAR Classic Architecture Layers

┌─────────────────────────────────────────────────────────────────┐
│                    Application Layer                            │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐  │
│  │  SWC-1    │  │  SWC-2    │  │  SWC-3    │  │  SWC-4    │  │
│  │(Torque Crl)│  │(Speed Mon)│  │(Safety Mgr)│  │(Diagnostics)│ │
│  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘  │
└────────┼──────────────┼──────────────┼──────────────┼──────────┘
         │              │              │              │
┌────────┼──────────────┼──────────────┼──────────────┼──────────┐
│        │    Runtime Environment (RTE)                │          │
│        │    (Generated code — marshals SWC I/O)      │          │
└────────┼──────────────────────────────────────────────────────┘
         │
┌────────┴──────────────────────────────────────────────────────┐
│                      Basic Software (BSW)                     │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │  Service Layer                                           │ │
│  │  OS  WdgM  DiagMgr(DEM)  ComM  NvM  FiM  MemMgr        │ │
│  ├──────────────────────────────────────────────────────────┤ │
│  │  ECU Abstraction Layer (EAL)                             │ │
│  │  IoHwAb  WdgIf  MemIf  ComIf  CryIf                     │ │
│  ├──────────────────────────────────────────────────────────┤ │
│  │  MCAL (Microcontroller Abstraction Layer)                │ │
│  │  AdcDrv  PwmDrv  PortDrv  SpiDrv  CanDrv  LinDrv        │ │
│  │  FlsDrv  EepDrv  WdgDrv  GptDrv  IcuDrv  McuDrv        │ │
└──────────────────────────────────────────────────────────────┘
         │
┌────────┴────────────────────────────────────────────────────┐
│              Microcontroller Hardware / ECU HW               │
│           ADC  PWM  CAN  LIN  SPI  Flash  WDT  ECC          │
└─────────────────────────────────────────────────────────────┘

MCAL — Microcontroller Abstraction Layer

The MCAL provides a hardware-independent API for accessing MCU peripherals. Application software and upper BSW layers call MCAL APIs and are completely isolated from MCU register-level details.

MCAL Modules

Module	Full Name	Provides
ADC	Analog-to-Digital Converter	`Adc_StartGroupConversion()`, `Adc_ReadGroup()`
CAN	CAN Driver	`Can_Write()`, `Can_SetControllerMode()`
DIO	Digital I/O Driver	`Dio_ReadChannel()`, `Dio_WriteChannel()`
ETH	Ethernet Driver	Raw frame send/receive
FLS	Flash Driver	`Fls_Write()`, `Fls_Read()`, `Fls_Erase()`
GPT	General Purpose Timer	Timer start/stop/measurement
ICU	Input Capture Unit	Signal edge capture, pulse width
LIN	LIN Driver	LIN frame send/receive
MCU	MCU Driver	Clock init, reset, power modes
PORT	Port/Pin Direction Config	Pin mux configuration
PWM	PWM Driver	`Pwm_SetDutyCycle()`, `Pwm_SetPeriodAndDuty()`
SPI	SPI Handler/Driver	`Spi_SyncTransmit()`, `Spi_AsyncTransmit()`
WDG	Watchdog Driver	`Wdg_SetMode()`, `Wdg_SetTriggerCondition()`

MCAL Portability

When switching from MCU A (e.g., Renesas RH850) to MCU B (e.g., Infineon TC3xx):

Application code: unchanged — uses only RTE and service layer APIs
BSW configuration: changed — generator re-run with new MCU parameters
MCAL: swapped — silicon vendor provides new MCAL for TC3xx; API is identical

Runtime Environment (RTE)

The RTE is generated code — not a pre-compiled library. It is generated by the AUTOSAR configuration tool (DaVinci, tresos) from the ARXML system description.

RTE Functions

SWC-to-SWC communication: Marshals data from SWC port to SWC port (intra-ECU)
SWC-to-BSW communication: Routes SWC calls to BSW service modules (e.g., NvM, DEM)
Inter-ECU communication buffer: Data received from CAN/Ethernet is placed into RTE buffers; SWC reads from buffer (decoupled from network timing)

Communication Patterns

Pattern	AUTOSAR Name	Description
Sender-Receiver (S/R)	Data Exchange	Producer writes to a port; consumer reads from it
Client-Server (C/S)	Service	Client calls a function; server executes and returns
Mode-Switch	Mode Management	Mode manager declares modes; SWCs get notified
Trigger	Event	Hardware or SW triggers an event that activates a runnable

Runnable Entities

A Runnable is the unit of schedulable code within an SWC. Each runnable is mapped to exactly one AUTOSAR OS task by the RTE/OS configuration:

Example SWC with two runnables:

SWC: TorqueMonitor
  Runnable: TorqMon_Init
    Trigger: ApplicationStart
    Maps to: OS Task INIT_Task (priority 10, runs once at startup)
    
  Runnable: TorqMon_Check
    Trigger: TimingEvent, period = 5ms
    Maps to: OS Task PERIODIC_Task_5ms (priority 50, every 5ms)
    
  Ports:
    RequiredPort: TorqueSensor_If  (reads torque sensor value from RTE buffer)
    ProvidedPort: FaultFlag_If     (writes fault flag to RTE buffer)
    RequiredPort: Calibration_If   (reads calibration parameters from RTE)

AUTOSAR OS

The AUTOSAR OS is based on OSEK/VDX OS — the predecessor automotive RTOS standard. It is a statically configured, preemptive or cooperative priority-based scheduler with deterministic behavior.

Key OS Concepts

Conformance Classes

AUTOSAR OS defines conformance classes (CC) based on supported features:

Class	Task Types	Activations	Events
BCC1	Basic tasks only	Max 1 pending activation	—
BCC2	Basic tasks only	Multiple activations	—
ECC1	Basic + Extended tasks	Max 1 pending activation	Extended tasks only
ECC2	Basic + Extended tasks	Multiple activations	All tasks

Task Types

Basic Task: Runs to completion; cannot wait for events; lower overhead
Extended Task: Can wait for OS events (WaitEvent()); used for tasks that synchronize on I/O or other tasks

OS Scheduling Algorithm

Preemptive full priority:
  - Highest-priority ready task always runs
  - Lower-priority task preempted when higher-priority task becomes ready
  - Deterministic worst-case response time (WCRT) analysis possible

Non-preemptive scheduling (OSEK cooperative):
  - Task runs to completion before OS switches
  - No preemption overhead; used for short, simple tasks

Mixed preemptive:
  - Some tasks non-preemptive (within group)
  - Other tasks fully preemptive

OS Application (Safety Partitioning)

An OS Application groups tasks and ISRs into a protected execution context:

OS Application "Safety_OsApp" (ASIL D, Trusted):
  Tasks: TASK_TorqueMonitor_5ms, TASK_SafetyManager_1ms
  ISRs:  ISR_WdgTrigger
  
OS Application "QM_OsApp" (QM, Non-Trusted):
  Tasks: TASK_Diagnostics_100ms, TASK_Infotainment_50ms
  ISRs:  ISR_UartReceive

Protection:
  - MPU enforced: QM_OsApp cannot read/write Safety_OsApp memory regions
  - Time protection: each task has a WCET budget; overrun → ProtectionHook
  - Service protection: QM tasks cannot call OS EcuM or safety services directly

Communication Stack (ComStack)

The communication stack handles all vehicle network communication. It is the most complex part of Classic BSW.

CAN Communication Stack

Application / RTE
      │
   COM (Communication Module)
      │  Packs/unpacks signals from/to PDUs (Protocol Data Units)
      │  Signal gateway (route signals between networks)
      │
   IPDUM (I-PDU Multiplexer) [optional]
      │  Multiplexes multiple logical PDUs into one physical PDU
      │
   PDUR (PDU Router)
      │  Routes PDUs between transport protocols and interface modules
      │
   CanIF (CAN Interface)
      │  Abstracts CAN controller from upper layers
      │  Provides PDU-level send/receive to PDUR
      │
   CanDrv (CAN Driver — MCAL)
      │  Hardware-level CAN frame send/receive
      │
   CAN Controller Hardware (Bosch M_CAN or similar)

LIN Communication Stack

Similar structure with LinIf and LinDrv; adds LIN schedule table management.

Ethernet Communication Stack

Application / RTE
      │
   SomeIpXf   JsonXf   E2EXf   Com  (serialization transformers)
      │
   SomeIpTp (SOME/IP Transport Protocol) [for large PDUs only]
      │
   PDUR
      │
   SoAd (Socket Adaptor)
      │  Adapts PDUR PDU interface to UDP/TCP socket interface
      │
   TcpIp (TCP/IP Stack — AUTOSAR or OS/network stack)
      │
   EthIf (Ethernet Interface)
      │
   EthDrv (Ethernet Driver — MCAL)
      │
   Ethernet MAC Hardware

AUTOSAR Classic Diagnostic Stack

Diagnostics in AUTOSAR Classic is handled by three main modules:

Module	Full Name	Function
DEM	Diagnostic Event Manager	Manages fault events; stores DTCs; controls fault behavior
DCM	Diagnostic Communication Manager	Handles UDS (ISO 14229) and OBD (ISO 15031) protocols
DET	Default Error Tracer	Development-time assertion reporting (not for production)
FiM	Function Inhibition Manager	Inhibits SWC functions based on DEM fault status

DEM (Diagnostic Event Manager)

DEM event lifecycle:

FAILED ──[heal conditions met]──► PASSED ──[aging counter expired]──► AGED
  │
  ├── DTC stored in primary/secondary memory (configurable)
  ├── FiM notified → functions depending on this event may be inhibited
  ├── MIL (Malfunction Indicator Light) activation
  └── Freeze frame captured (snapshot of signal values at fault occurrence)

DEM configuration:
  - Each fault has a DTC number (3-byte, typically J1979 or manufacturer-specific)
  - Debounce algorithm: counter-based or time-based
    Counter: fault confirmed after N consecutive failed calls
    Time-based: fault confirmed after T ms of continuous failure
  - Storage conditions: DTC only stored if DTC storage enabled, not inhibited by FiM
  - OBD readiness monitoring

DCM (Diagnostic Communication Manager)

DCM implements UDS (Unified Diagnostic Services — ISO 14229) services:

Common UDS Services used via DCM:

Service 0x10 (DiagnosticSessionControl):
  Default session (0x01) → Programming session (0x02) → Extended session (0x03)

Service 0x11 (ECUReset):
  HardReset (0x01) → Reset ECU immediately
  SoftReset (0x03) → Reset application, keep BSW state

Service 0x14 (ClearDiagnosticInformation):
  Clear all DTCs in DEM memory

Service 0x19 (ReadDTCInformation):
  0x02: Report DTCs by status mask
  0x04: Report DTC freeze frame
  0x06: Report DTC extended data record

Service 0x22 (ReadDataByIdentifier):
  Read calibration values, ECU serial number, SW version, sensor values

Service 0x2E (WriteDataByIdentifier):
  Write VIN, calibration data

Service 0x27 (SecurityAccess):
  Seed-key challenge-response; must be passed before 0x2E

Service 0x31 (RoutineControl):
  Start / stop / request result of a diagnostic routine
  (e.g., "activate pump test", "run actuator self-test")

Service 0x34/0x35/0x36/0x37 (Flash Programming):
  RequestDownload → TransferData → RequestTransferExit
  Used for OTA firmware update via UDS

Software Component (SWC) Design

SWC Types in AUTOSAR Classic

SWC Type	Description	Example
Application SW Component	Core application logic	TorqueControl, SpeedCalculation
Sensor-Actuator SWC	Interfaces to physical I/O via IoHwAb	TorqueSensorDriver, MotorActuator
Service SWC	Provides BSW services to application	NvM wrapper, DEM reporting SWC
Composition SWC	Groups multiple SWCs into a logical module	EPS subsystem composition
Parameter SWC	Holds calibration data	TorqueCalibration
ECU-Internal Behavior	Models cal data and inter-SWC connections	Full ECU model

Port Interface Types

Interface Type	Use Case	Data Exchange
SenderReceiverInterface	Periodic signal exchange	Signal data values
ClientServerInterface	Request-response computation	Function call with return value
ModeSwitchInterface	Mode management	Discrete mode states
ParameterInterface	Calibration parameter access	Non-volatile calibration values
TriggerInterface	Event-based activation	Trigger signal (no data)
NvDataInterface	Non-volatile data storage	Persistent data blocks

Non-Volatile Memory (NvM)

The NvM module manages persistent data storage (EEPROM, Flash-emulated EEPROM, NVRAM) with a clean, standardized API.

NvM block types:
  ├── NVRAM_BLOCK_NATIVE: Standard single-write block
  ├── NVRAM_BLOCK_REDUNDANT: Two copies written; CRC check on read
  └── NVRAM_BLOCK_DATASET: Multiple versions (for calibration variants)

Typical usage:
  /* Write request (asynchronous) */
  NvM_WriteBlock(NVM_BLOCK_TORQUE_CALIBRATION, &calibration_data);
  
  /* Callback on completion (in SWC) */
  void Rte_CbkTorqueCalib_WriteCompleted(void) {
      /* Check NvM_GetErrorStatus() */
  }

  /* Read at startup */
  NvM_ReadBlock(NVM_BLOCK_TORQUE_CALIBRATION, &calibration_data);

ECU State Management (EcuM)

The ECU State Manager controls ECU startup, shutdown, and sleep/wake sequences:

EcuM State Machine:

  STARTUP ──────────────────────────────────────────────────► RUN
   Boot (MCU init)                                              │
   BSW init (MCAL, Memory, OS)                                  │
   SchM init (scheduler)                                        │
   Application init                                            │
                                                               │
  RUN ────────────────────────────────────────────────────► SHUTDOWN
   Normal operation                                             │
   All tasks running                                            │
   Ignition off detected → request shutdown                     │
                                                               ▼
  SHUTDOWN ──────────────────────────────────────────── POST_RUN
   Flush NvM (save all dirty blocks to EEPROM/Flash)           │
   Execute shutdown hooks                                       │
   Stop OS                                                      │
                                                               ▼
  OFF ◄─────────────────────────────────────────── POST_RUN ──►SLEEP
   Power off                                                  (optional)

AUTOSAR Classic Build System and Configuration Flow

AUTOSAR Classic development flow:

Step 1: System design (ARXML)
  ├── Define SWC interfaces in DaVinci Developer / SystemDesk
  ├── Define composition: which SWCs connect to which
  └── Export system ARXML file

Step 2: BSW configuration (ARXML)
  ├── Import system ARXML into DaVinci Configurator / tresos Studio
  ├── Configure each BSW module (OS tasks, CAN baud rates, NvM blocks, etc.)
  └── Validate configuration (consistency checks)

Step 3: Code generation
  ├── RTE generator: produces Rte.c, Rte.h, Rte_<SWC>.h per SWC
  ├── OS generator: produces Os_Cfg.c, Os_Cfg.h (task table, ISR vectors)
  ├── COM generator: produces Com_Cfg.c (PDU/signal tables)
  └── All other BSW module generators

Step 4: Application development
  ├── Developer writes SWC implementation files (.c) against generated Rte_<SWC>.h
  ├── MISRA C compliance required for ASIL modules
  └── Unit tests against generated stubs

Step 5: Integration and build
  ├── All generated + application + BSW library files compiled together
  ├── Linker script from MCU/BSW config
  └── Final ECU firmware image (.elf, .hex, .s19)

Step 6: ECU testing
  ├── Hardware-in-Loop (HIL) test
  ├── CAN/ETH network simulation (CANoe, CANalyzer)
  └── UDS diagnostic verification

VAD

ASR

TTS

llama-swap

llama.cpp

EDK2-UEFI

U-Boot

Yocto

QEMU

QNX

AUTOSAR Adaptive

MISRA C++

ASIL

ASPICE

Conan

Artifactory

Jenkins

AUTOSAR Classic Platform