Embedded Systems Series Part 13: AUTOSAR Architecture & EB Tresos

Introduction: Why AUTOSAR?

AUTOSAR (AUTomotive Open System ARchitecture) is the global standard for automotive software architecture. Developed by a partnership of OEMs (BMW, Ford, Toyota), Tier-1 suppliers (Bosch, Continental), and semiconductor companies (NXP, Infineon), AUTOSAR defines a standardized software framework that decouples application software from the underlying hardware.

Modern vehicles contain 70-150 Electronic Control Units (ECUs), each running millions of lines of code. Without a standardized architecture, integrating software from dozens of suppliers across different microcontrollers would be nearly impossible. AUTOSAR solves this by defining clear interfaces between software layers.

AUTOSAR Classic vs Adaptive Platform

AUTOSAR offers two distinct platforms targeting different automotive use cases:

                                    flowchart LR
                                        A[AUTOSAR] --> B[Classic Platform]
                                        A --> C[Adaptive Platform]
                                        B --> D[Real-time MCUs]
                                        B --> E[Static Configuration]
                                        B --> F[Signal-based Comm]
                                        C --> G[High-performance MPUs]
                                        C --> H[Dynamic Runtime]
                                        C --> I[Service-oriented Comm]
                                

AUTOSAR Classic Platform Architecture

The Classic Platform uses a strictly layered architecture that separates application software from hardware through well-defined abstraction layers. This is the foundation of all traditional automotive ECU software.

                                    flowchart TB
                                        SWC1[SWC: Engine Control] --- RTE
                                        SWC2[SWC: Transmission] --- RTE
                                        SWC3[SWC: Diagnostics] --- RTE
                                        RTE[Runtime Environment - RTE] --- BSW
                                        subgraph BSW[Basic Software - BSW]
                                            direction TB
                                            SL[Services Layer
OS, COM, DCM, DEM, NvM]
                                            ECU_AL[ECU Abstraction Layer
CanIf, SpiIf, EepIf]
                                            MCAL_L[MCAL
Can, Spi, Gpt, Dio, Adc, Port, Mcu]
                                        end
                                        BSW --- HW[Microcontroller Hardware]
                                

Application Layer

At the top sit Software Components (SWCs)—the application logic written by OEMs and Tier-1 suppliers. SWCs communicate exclusively through the RTE, never accessing hardware directly. This enforces complete hardware independence.

Runtime Environment (RTE)

The RTE is the communication backbone—an auto-generated middleware layer that routes data between SWCs and between SWCs and BSW modules. It implements the virtual function bus (VFB) concept, making inter-ECU communication transparent to application code.

Microcontroller Abstraction Layer (MCAL)

The MCAL is the lowest software layer, providing direct access to microcontroller peripherals through standardized APIs. Each MCU vendor (NXP, Infineon, Renesas) provides their own MCAL implementation that conforms to the AUTOSAR interface specification.

Example: reading a GPIO pin in bare-metal vs AUTOSAR MCAL:

/* Bare-metal approach: Direct register access (NOT portable) */
#include "S32K148.h"

uint8_t read_gpio_bare_metal(void) {
    /* Directly reading PTA5 via register — tied to S32K148 */
    return (PTA->PDIR >> 5) & 0x01;
}

/* AUTOSAR MCAL approach: Portable across any AUTOSAR-compliant MCU */
#include "Dio.h"

Dio_LevelType read_gpio_autosar(void) {
    /* Channel ID configured in EB Tresos, hardware-independent */
    return Dio_ReadChannel(DioConf_DioChannel_IgnitionSense);
}

ECU Abstraction Layer

Above the MCAL sits the ECU Abstraction Layer, which provides device-level abstractions. For example, CanIf (CAN Interface) abstracts whether the CAN controller is on-chip (MCAL) or external (via SPI transceiver). The Services Layer above it doesn't care about the physical implementation.

Services Layer (BSW)

The top BSW layer provides system services used by all applications:

Software Components (SWC)

SWCs are the building blocks of AUTOSAR application software. Each SWC encapsulates a specific function (e.g., engine torque calculation, brake force distribution) and communicates through ports defined in the component description.

Ports & Interfaces

AUTOSAR defines two primary port types for SWC communication:

/* SWC Runnable: Engine Torque Calculation */
#include "Rte_EngineTorqueSWC.h"

/* This runnable is triggered by a periodic timer (e.g., 10ms) */
void EngineTorqueCalc_10ms(void) {
    /* Read input signals via RTE (Sender-Receiver ports) */
    float throttle_pos = Rte_IRead_EngineTorqueCalc_10ms_ThrottlePosition_value();
    float engine_speed = Rte_IRead_EngineTorqueCalc_10ms_EngineSpeed_value();
    float coolant_temp = Rte_IRead_EngineTorqueCalc_10ms_CoolantTemp_value();

    /* Application logic — hardware independent */
    float base_torque = throttle_pos * 0.85f * engine_speed / 6000.0f;
    
    /* Temperature derating above 105°C */
    float derate_factor = (coolant_temp > 105.0f) ? 
                          (1.0f - (coolant_temp - 105.0f) * 0.02f) : 1.0f;
    
    float target_torque = base_torque * derate_factor;

    /* Write output signal via RTE */
    Rte_IWrite_EngineTorqueCalc_10ms_TargetTorque_value(target_torque);
}

EB Tresos Studio

EB Tresos Studio (by Elektrobit, an Aptiv company) is the industry-standard configuration tool for AUTOSAR Classic BSW. Instead of writing BSW configuration code by hand, engineers use EB Tresos's GUI to configure every module—from MCAL pin assignments to communication routing to diagnostic services.

Configuration Workflow

                                    flowchart LR
                                        A[System Description
ARXML] --> B[EB Tresos Studio
Module Configuration]
                                        B --> C[Validation &
Consistency Check]
                                        C --> D[Code Generation
C Source + Headers]
                                        D --> E[Compile & Link
with SWC Code]
                                        E --> F[Flash to ECU]
                                

Key configuration steps in EB Tresos:

1. Import MCAL plugin for target MCU (e.g., NXP S32K3, S32G, Infineon AURIX TC3xx)
2. Configure Mcu module: Clock tree, PLL settings, reset configuration
3. Configure Port module: Pin multiplexing, direction, pull resistors
4. Configure peripheral drivers: CAN, SPI, ADC, GPT with hardware-specific parameters
5. Configure communication stack: CanIf → PduR → Com signal routing
6. Configure OS: Tasks, ISRs, alarms, schedule tables, counters
7. Configure diagnostics: UDS services, DTC definitions, fault memory
8. Run validation: EB Tresos checks inter-module consistency
9. Generate code: Produces *_Cfg.c, *_Cfg.h, *_PBcfg.c files

ARXML Configuration Files

ARXML (AUTOSAR XML) is the standard exchange format for all AUTOSAR descriptions—system topology, SWC interfaces, BSW configuration, and ECU mapping. Every configuration change in EB Tresos produces ARXML files.

<!-- Example: CAN controller configuration in ARXML -->
<ECUC-MODULE-CONFIGURATION-VALUES>
  <SHORT-NAME>Can</SHORT-NAME>
  <DEFINITION-REF DEST="ECUC-MODULE-DEF">
    /AUTOSAR/EcucDefs/Can
  </DEFINITION-REF>
  <CONTAINERS>
    <ECUC-CONTAINER-VALUE>
      <SHORT-NAME>CanController_0</SHORT-NAME>
      <PARAMETER-VALUES>
        <ECUC-NUMERICAL-PARAM-VALUE>
          <DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">
            /AUTOSAR/EcucDefs/Can/CanController/CanControllerBaudRate
          </DEFINITION-REF>
          <VALUE>500</VALUE> <!-- 500 kbps -->
        </ECUC-NUMERICAL-PARAM-VALUE>
      </PARAMETER-VALUES>
    </ECUC-CONTAINER-VALUE>
  </CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>

MPU & Memory Protection

Memory protection is critical in safety-rated automotive systems. The Memory Protection Unit (MPU) enforces access permissions at hardware level, preventing one software partition from corrupting another. This is mandatory for ISO 26262 ASIL-B and above.

AUTOSAR OS Memory Partitioning

AUTOSAR OS supports OS-Applications that group tasks, ISRs, and resources into isolated partitions. Each partition has defined memory access rights enforced by the MPU:

                                    flowchart TB
                                        subgraph TP[Trusted Partition - ASIL-D]
                                            T1[Brake Control Task]
                                            T2[Steering Assist Task]
                                        end
                                        subgraph NTP1[Non-Trusted Partition 1 - ASIL-B]
                                            N1[Engine Management Task]
                                            N2[Transmission Task]
                                        end
                                        subgraph NTP2[Non-Trusted Partition 2 - QM]
                                            Q1[Climate Control Task]
                                            Q2[Lighting Task]
                                        end
                                        MPU[MPU Hardware] --> TP
                                        MPU --> NTP1
                                        MPU --> NTP2
                                

NXP S32G MPU Configuration

The NXP S32G vehicle network processor features ARM Cortex-M7 cores (for real-time) and Cortex-A53 cores (for application processing). The Cortex-M7 includes an ARMv7-M MPU with 16 configurable regions.

In EB Tresos, memory protection is configured through the Os module:

/* EB Tresos generates MPU configuration for each OS-Application */
/* Example: Generated Os_Cfg.c for S32G Cortex-M7 MPU regions */

/* Trusted partition: Full access to all memory */
const Os_MpuRegionConfigType Os_TrustedPartition_MpuConfig[] = {
    { /* Region 0: Flash - Execute + Read */
        .baseAddress = 0x00400000U,
        .sizeAndEnable = OS_MPU_REGION_SIZE_2M | OS_MPU_REGION_ENABLE,
        .accessPermission = OS_MPU_AP_PRIV_RO_USER_RO,
        .typeExtension = OS_MPU_TEX_NORMAL_WT
    },
    { /* Region 1: RAM - Read + Write */
        .baseAddress = 0x20000000U,
        .sizeAndEnable = OS_MPU_REGION_SIZE_512K | OS_MPU_REGION_ENABLE,
        .accessPermission = OS_MPU_AP_PRIV_RW_USER_RW,
        .typeExtension = OS_MPU_TEX_NORMAL_WB
    },
    { /* Region 2: Peripheral registers */
        .baseAddress = 0x40000000U,
        .sizeAndEnable = OS_MPU_REGION_SIZE_512M | OS_MPU_REGION_ENABLE,
        .accessPermission = OS_MPU_AP_PRIV_RW_USER_RW,
        .typeExtension = OS_MPU_TEX_DEVICE_SHARED
    }
};

/* Non-trusted partition: Restricted to own RAM section only */
const Os_MpuRegionConfigType Os_ClimateCtrl_MpuConfig[] = {
    { /* Region 0: Own flash section only */
        .baseAddress = 0x00480000U,
        .sizeAndEnable = OS_MPU_REGION_SIZE_64K | OS_MPU_REGION_ENABLE,
        .accessPermission = OS_MPU_AP_PRIV_RO_USER_RO,
        .typeExtension = OS_MPU_TEX_NORMAL_WT
    },
    { /* Region 1: Own RAM section only — cannot access brake/steering RAM */
        .baseAddress = 0x20040000U,
        .sizeAndEnable = OS_MPU_REGION_SIZE_16K | OS_MPU_REGION_ENABLE,
        .accessPermission = OS_MPU_AP_PRIV_RW_USER_RW,
        .typeExtension = OS_MPU_TEX_NORMAL_WB
    }
    /* No peripheral region — must use trusted function calls for I/O */
};

/* Protection hook — called by AUTOSAR OS on MPU violation */
#include "Os.h"

ProtectionReturnType ProtectionHook(StatusType FatalError) {
    /* Log the violating OS-Application */
    Os_ApplicationType faultApp = GetApplicationID();
    
    switch (FatalError) {
        case E_OS_PROTECTION_MEMORY:
            /* MPU violation: terminate the offending partition */
            /* Safety-critical partitions continue running */
            return PRO_TERMINATEAPPL_RESTART;
            
        case E_OS_PROTECTION_TIME:
            /* Task exceeded its execution time budget */
            return PRO_TERMINATETASKISR;
            
        case E_OS_PROTECTION_ARRIVAL:
            /* Task activated too frequently */
            return PRO_IGNORE;
            
        default:
            /* Unknown error: shutdown ECU safely */
            return PRO_SHUTDOWN;
    }
}

AUTOSAR Adaptive Platform

The Adaptive Platform targets high-performance ECUs running ADAS, autonomous driving, and connected vehicle functions. Unlike Classic's static architecture, Adaptive uses service-oriented architecture (SOA) with dynamic service discovery and POSIX-compliant OS (typically Linux-based).

ARA API — Application Interface

Adaptive applications use the ARA (AUTOSAR Runtime for Adaptive) API, a C++14/17 interface:

/* Adaptive Platform: Service-oriented radar data provider */
/* Uses ara::com for SOME/IP service communication */

#include <ara/com/sample/radar_service.h>
#include <ara/exec/execution_client.h>
#include <ara/log/logging.h>

int main() {
    /* Report execution state to Execution Manager */
    ara::exec::ExecutionClient exec_client;
    exec_client.ReportExecutionState(
        ara::exec::ExecutionState::kRunning);

    /* Create service instance (auto-discovered via SOME/IP-SD) */
    auto radar_skeleton = RadarServiceSkeleton::Create(
        ara::com::InstanceIdentifier("FrontRadar_1"));

    /* Offer service to network */
    radar_skeleton->OfferService();

    ara::log::Logger& logger = ara::log::CreateLogger("RADAR", "Radar Service");
    logger.LogInfo() << "Radar service offered on SOME/IP";

    /* Main processing loop */
    while (true) {
        RadarData data = ReadRadarHardware();
        
        /* Send event to all subscribed consumers (e.g., ADAS fusion SWC) */
        radar_skeleton->RadarDetectionEvent.Send(data);
    }

    return 0;
}

ISO 26262 Functional Safety Integration

ISO 26262 is the functional safety standard for automotive electrical/electronic systems. AUTOSAR provides built-in mechanisms to achieve compliance from ASIL-A (lowest) to ASIL-D (highest).

ASIL Classification

Safety Mechanisms in AUTOSAR

Communication Stacks

AUTOSAR provides complete, pre-integrated communication stacks for all major automotive bus systems. The stacks follow a layered model mirroring the OSI reference model:

                                    flowchart TB
                                        COM[Com - Signal Layer
Signal packing/unpacking] --> PDUR[PduR - PDU Router
Routes PDUs between stacks]
                                        PDUR --> CANTP[CanTp - Transport Protocol
Segmentation for diagnostics]
                                        PDUR --> CANIF[CanIf - CAN Interface
Hardware abstraction]
                                        CANTP --> CANIF
                                        CANIF --> CAN[Can Driver - MCAL
Hardware register access]
                                        CAN --> HW[CAN Transceiver + Bus]
                                

AUTOSAR supports multiple bus systems through parallel stacks:

• CAN/CAN-FD: Can → CanIf → PduR → Com (up to 8 Mbps with CAN-FD)
• LIN: Lin → LinIf → LinSM → Com (low-cost sub-bus, up to 20 kbps)
• FlexRay: Fr → FrIf → FrTp → PduR → Com (deterministic, up to 10 Mbps)
• Automotive Ethernet: Eth → EthIf → SoAd → PduR (SOME/IP, DoIP, up to 10 Gbps)

Development Workflow

A typical AUTOSAR project follows this workflow from system design to ECU deployment:

                                    flowchart TB
                                        A[1. System Design
Define SWCs, interfaces, mapping] --> B[2. ECU Extract
Generate ECU-specific ARXML]
                                        B --> C[3. BSW Configuration
EB Tresos: MCAL, OS, COM, Diag]
                                        C --> D[4. RTE Generation
Auto-generate communication code]
                                        D --> E[5. SWC Development
Write application code in C]
                                        E --> F[6. Integration & Build
Compile all layers together]
                                        F --> G[7. Testing
HIL, SIL, unit tests, E2E]
                                        G --> H[8. Calibration
Tune parameters via XCP/CCP]
                                        H --> I[9. Flash & Validate
Deploy to target ECU]
                                

Conclusion & Next Steps

AUTOSAR is the backbone of modern automotive software engineering. Understanding its layered architecture, configuration-driven development (EB Tresos), and safety mechanisms (MPU partitioning, WdgM, E2E) is essential for any embedded engineer working in the automotive domain.