AUTOSAR

AUTOSAR standardises automotive ECU software. Learn Classic Platform layers (application SWCs, RTE, basic software, MCAL), ports and interfaces, runnables and events, configuration and code generation, the Adaptive Platform for high-performance computers, and CPU-load estimation.

Before AUTOSAR, every supplier wrote its own drivers, OS and communication stacks. AUTOSAR (AUTomotive Open System ARchitecture) defines a layered architecture and standard interfaces so application software can be reused across ECUs and suppliers.

Classic AUTOSAR runs on microcontrollers in engine, brake and body ECUs; Adaptive AUTOSAR runs on powerful processors for ADAS and central computers.

An analogy

AUTOSAR is like standard electrical sockets and plugs for software: applications plug into the RTE without caring which hardware or supplier provides the power behind the wall.

Layered architecture

Application layer (SWCs with the vehicle functions) → RTE (generated communication glue) → Basic software: services (OS, memory/NVM, diagnostics DCM/DEM, communication COM/PduR), ECU abstraction and MCAL drivers (ADC, DIO, CAN, SPI, PWM) → microcontroller.

Components, ports and runnables

SWCs communicate through ports: sender-receiver (data), client-server (function calls), mode switches. Runnables are functions triggered by RTE events (timing, data received, operation invoked) and mapped to OS tasks.

Methodology and tools

System description (ARXML) → ECU extract → configure BSW (Vector DaVinci, EB tresos, ETAS ISOLAR) → generate RTE and BSW code → integrate application code. Model-based development (Simulink/TargetLink) often generates SWC code.

Adaptive AUTOSAR and security

Adaptive Platform runs POSIX-based applications on multi-core SoCs with service-oriented communication (SOME/IP, ara::com), dynamic deployment and OTA updates. Security modules (Crypto stack, SecOC, IdsM) protect communication; safety via partitioning, memory protection and timing supervision (WdgM).

Formulas

Worked example: CPU load of runnables

Given: Runnable A: 0.2 ms every 5 ms; B: 1 ms every 10 ms; C: 3 ms every 100 ms

Find: CPU utilisation.

Answer: 17 % (plus BSW/OS overhead)

Worked example: COM signal scaling

Given: Raw CAN value 0x0BB8 (3000); Factor 0.25 rpm/bit, offset 0

Find: Physical engine speed.

Answer: 750 rpm

A Classic AUTOSAR runnable using RTE APIs (C)

#include "Rte_WiperCtrl.h"

/* Runnable mapped to a 20 ms periodic OS task by the RTE configuration. */
FUNC(void, WiperCtrl_CODE) WiperCtrl_Run20ms(void)
{
    uint8  rainLevel;
    boolean autoMode;

    (void)Rte_Read_RainSensor_Level(&rainLevel);          /* sender-receiver port */
    (void)Rte_Read_StalkSwitch_AutoMode(&autoMode);

    uint8 speed = 0u;
    if (autoMode == TRUE) {
        speed = (rainLevel > 60u) ? 2u : (rainLevel > 20u) ? 1u : 0u;
    }
    (void)Rte_Write_WiperMotor_SpeedRequest(speed);

    if (rainLevel == 0xFFu) {                              /* sensor fault value */
        (void)Rte_Call_Dem_SetEventStatus(DEM_EVENT_RAIN_SENSOR, DEM_EVENT_STATUS_FAILED);
    }
}

The SWC never touches hardware or CAN directly — the generated RTE routes ports to COM signals, other SWCs or I/O drivers.

Common mistakes

Applications

Key takeaways

Going further