--- url: /kb/embedded/autosar/classic-platform/index.md --- # AUTOSAR Classic Platform ## 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): 1. Application code: **unchanged** — uses only RTE and service layer APIs 2. BSW configuration: **changed** — generator re-run with new MCU parameters 3. 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 1. **SWC-to-SWC communication**: Marshals data from SWC port to SWC port (intra-ECU) 2. **SWC-to-BSW communication**: Routes SWC calls to BSW service modules (e.g., NvM, DEM) 3. **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_.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_.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 ```