Overview
This expert-level course bridges the gap between AUTOSAR knowledge and production mastery. Designed for engineers who already understand AUTOSAR Classic and Adaptive fundamentals, it focuses on the advanced topics that define senior engineers and system architects.
You'll tackle multi-core AUTOSAR on real hardware, implement safety mechanisms per ISO 26262 requirements, optimize runtime and memory footprint, and architect hybrid Classic+Adaptive systems.
Case studies from real OEM projects illustrate common pitfalls and proven solutions for large-scale AUTOSAR deployments involving 50+ ECUs.
Course Modules
1
Multi-Core AUTOSAR
Multi-Core OS ConfigurationFREE PREVIEW
50 min read
▸ OsCore objects: OsCoreId assignment, OsCoreIsStartedByStartupCode (BSP-launched vs. Os_StartCore()-launched secondary core) - sequencing implications
▸ Task-to-core binding: OsTaskCoreRef - every Task and ISR must have exactly one core assignment; no core = default Core 0; common misconfiguration causing priority inversion
▸ Per-core OS objects: each OsCore has own OsApplications, schedule tables, alarms, and OsCounters - objects are never shared across cores
▸ Startup sequence: Os_InitMemory() → Os_Init() on master core → slave cores released via Os_StartCore() - BootBarrier synchronisation pattern before BSW init on secondary core
Inter-Core Communication (IOC)
45 min read
▸ IOC role: AUTOSAR standard API for data exchange between RTE ports on different OsCores - RTE generator creates Ioc_Send/Ioc_Receive wrappers from IWrite/IRead calls
▸ IOC modes: N:1 queue (FIFO, OsIocCommunication with OsIocQueueLength) vs. 1:1 last-is-best (non-queued) - overrun handling per mode: oldest-dropped vs. overwrite
▸ Configuration: OsIocCommunication container - sender OsApplication, receiver OsApplication, data type, queue depth, and data consistency mechanism
▸ IOC internals: uses OsSpinlock internally to protect shared memory ring buffer - application code never calls spinlocks directly; no busy-wait in application layer
Core Partitioning Strategies
55 min read
▸ ASIL decomposition by core: safety SWCs on dedicated OsCore with isolated OsApplication + MPU; QM SWCs on separate core - spatial separation satisfies FFI per ISO 26262-6
▸ Peripheral ownership rules: MCAL drivers access hardware registers - CanDrv/CanIf on Core 0, EthDrv/EthIf on Core 1; concurrent register access requires explicit HW arbitration
▸ BSW singleton vs. distributed: NvM and DEM always on Core 0 (master); COM and PduR distributable per network cluster - init order implications for multi-core EcuM
▸ Load analysis input: Timing Architects TA Tool Suite models task WCET per core, identifies schedule infeasibility before hardware availability - early partitioning validation
Spinlocks & Shared Resource Management
45 min read
▸ OsSpinlock configuration: OsSpinlockSuccessor defines mandatory acquisition order - all code paths must always acquire spinlock A before spinlock B to prevent deadlock
▸ Spinlock API: GetSpinlock(SpinlockIdType) busy-waits until acquired; TryToGetSpinlock() returns immediately with E_OK or E_OS_INTERFERENCE - use try-variant for bounded execution
▸ OS restrictions: spinlocks must not be held across OS service calls (ActivateTask, WaitEvent, ChainTask) - holding too long starves other cores; TRACE32 spinlock trace reveals contention
▸ Alternatives: IOC for asynchronous data sharing (no explicit spinlock); SchM exclusive areas for BSW-internal mutual exclusion on core-local shared data - prefer IOC over spinlocks where latency permits
Performance Analysis & Load Balancing
50 min read
▸ TRACE32 OS-aware runtime statistics: per-task net time, gross time, preemption chain analysis - identifying which BSW main function dominates the 1ms task on each core
▸ Imbalance identification: Core 0 at 90% load, Core 1 at 40% - task migration feasibility analysis (IOC overhead + spinlock contention added vs. load reduction gained)
▸ CAN Rx ISR load: CanIf_RxIndication ISR consuming 15% on Core 0 → deferred processing pattern: ISR sets IOC flag, Core 1 task processes notification in next cycle
▸ Period tuning: relaxing Dem_MainFunction from 5ms to 10ms on overloaded core - AUTOSAR specification permits up to 10ms; validate with updated TA analysis before finalising
Hands-On: Dual-Core ECU Project
70 min read
▸ OsCore setup: Core 0 (ASIL-B - safety SWC + EcuM + BswM), Core 1 (QM - COM + PduR + CanIf) - separate OsApplication per core with OsTaskCoreRef bindings
▸ IOC channel: safety SWC on Core 0 consumes sensor data produced by CAN receive task on Core 1 - N:1 queue with 4-element depth; overrun rate verified under peak CAN load
▸ Spinlock protection: shared NvM write-request flag accessed from both cores - OsSpinlock with fixed acquisition order; TRACE32 spinlock trace confirms zero contention deadlock
▸ Validation: TRACE32 multi-core timeline showing both cores active, IOC transfer timing < 500 µs, per-core stack watermarks, no OsProtectionHook calls
2
Safety Mechanisms in AUTOSAR
Memory Partitioning & Protection (MPU)
55 min read
▸ OsApplication memory regions: each OsApplication has dedicated .data, .bss, .stack regions - AUTOSAR OS configures Cortex-M MPU region registers per OsApplication on context switch
▸ Trusted vs. non-trusted OsApplication: trusted runs in privileged mode with full memory access; non-trusted restricted to own regions - violation triggers OsProtectionHook(E_OS_PROTECTION_MEMORY)
▸ Stack overflow guard: dedicated MPU region (MIN_SIZE = 32 bytes) placed below each task stack - faults on overflow before adjacent data is corrupted; detected via OsProtectionHook
▸ MPU region budget: Cortex-M supports 8–16 regions total - with many OsApplications, AUTOSAR OS uses hardware region pooling; too many OsApplications causes context-switch overhead
Timing Protection & Watchdogs
45 min read
▸ OsTaskTimeFrame: configures per-task execution budget - exceeding budget calls OsProtectionHook(E_OS_PROTECTION_TIME); used as ISO 26262 temporal interference prevention measure
▸ OsInterruptTimeFrame: ISR execution budget preventing a single CAN Rx ISR from consuming an entire task timeslice under peak bus load - separate budget from task timing protection
▸ WdgM supervision: Alive (CheckpointReached() every WdgMAliveCycleTime), Deadline (StartToDeadlineTimeout between two checkpoints), Logical (graph traversal) - all feed WdgM_MainFunction
▸ Hardware watchdog chain: WdgM_MainFunction calls WdgIf → Wdg driver → hardware register trigger - TriggerReferenceCycle, TriggerWindowStart/End, initial timeout configured per platform
E2E Protection Library
50 min read
▸ Profile P01 (CRC8, 16-bit DataID): for ASIL-B PDUs ≤ 32 bytes - CRC8 polynomial 0x1D, DataID prevents incorrect-routing errors; overhead: 1-byte header per PDU
▸ Profile P04 (CRC32, 32-bit DataID): for ASIL-D PDUs up to 4 KB - CRC32P4 polynomial, 4-byte header, counter width 256 - standard for powertrain and chassis signals
▸ Integration with COM: E2E_P04Protect() wraps data before Com_SendSignal(); E2E_P04Check() validates after Com_ReceiveSignal() - placed in SWC wrapper, not inside BSW
▸ E2E state machine: WRONGSEQUENCE → FIM inhibit of downstream function; ERROR → SWC enters safe output state - per-data-element state persists across receive cycles
Safe BSW Module Configuration
40 min read
▸ DevErrorDetect = FALSE per module in production: DET errors waste ROM and can cause unintended side effects - CI build gate verifies no DET-enabled module in release binary
▸ WdgM ASIL configuration: WdgMSupervisedEntity ASIL attribute, WdgMAliveCycleTime aligned with task period - cycle time > task period causes spurious resets; too short causes false-positive supervision failures
▸ DEM production tuning: DemEventMemoryEntryStorageTrigger = CONFIRMED (not FAILED), DemDebounceCounterBasedStepSize tuned to filter transient noise - prevents DTC flooding on noisy hardware
▸ RTE safety extension: RteUsageOfInitValues = TRUE initialises all unconnected ports to type default - prevents uninitialised Rte_IRead() return on first cycle of ASIL-decomposed SWCs
Freedom from Interference Patterns
50 min read
▸ Spatial FFI: MPU OsApplication boundaries prevent SWC A from corrupting SWC B's .data - verified by injected wild-pointer test triggering OsProtectionHook with zero false OsApplication escapes
▸ Temporal FFI: OsTaskTimeFrame on safety task prevents QM task overrun from starving safety runnable - demonstrated with injected while(1) in QM task, TRACE32 trace confirms safety task unaffected
▸ Communication FFI: E2E covers all three ISO 26262 communication fault models - data corruption (CRC), stale data (SQC counter), and wrong data (DataID misrouting)
▸ Safety plan documentation: FFI argument table per interface - which mechanism (MPU/OsTimingProtection/E2E Profile) satisfies which ISO 26262-6 requirement, with ASIL level and evidence reference
Hands-On: ASIL-D ECU Configuration
65 min read
▸ MPU setup: configure OsApplication with .data read-write, .code read-only, and stack guard page for ASIL-D SWC - inject wild-pointer access, confirm OsProtectionHook fires
▸ WdgM alive supervision: add CheckpointReached() to ASIL-D runnable, simulate 3 consecutive misses → observe WdgM_MainFunction stops watchdog trigger → hardware reset captured in TRACE32
▸ E2E Profile 4: wrap Rte_IWrite with E2E_P04Protect(), inject single bit-flip in test harness → verify SWC transitions to safe output state on E2E_CHECK_ERROR within one task cycle
▸ Final audit: DET = FALSE confirmed in all modules, OsProtectionHook call count = 0, DEM DTC for E2E fault confirmed via $19 02 - production readiness checklist complete
3
Production Optimization
ROM/RAM Optimization Techniques
45 min read
▸ Linker map analysis: arm-none-eabi-nm + size output per module - identifying COM signal tables and OS stack allocations as top ROM consumers on a typical 256 KB ECU
▸ BSW variant trimming: ComIPduEnabled = FALSE removes unused PDUs from ROM; disabling unused DEM events removes EventMemory slots - measured savings 20–40 KB
▸ Post-build configuration: moving PduR routing tables and COM signal definitions to PBcfg section → pre-compile ROM shrinks, post-build binary updatable without full BSW recompile
▸ Stack right-sizing: TRACE32 stack watermark (0xAA paint pattern) per task - cutting over-allocated 2 KB BSW stacks to 512 bytes; retaining 20% safety margin per AUTOSAR guideline
Startup Time Optimization
40 min read
▸ EcuM startup profiling: TRACE32 timestamp at each DriverInitList callback - identifying longest init functions (Flash driver: 120 ms, NvM ReadAll: 80 ms) in the startup sequence
▸ Early COM activation: NvMBswMMultiBlockJobStatusInformation lets BswM start COM PDU transmission before NvM ReadAll completes - apps start with ROM defaults, overwritten when NvM finishes
▸ SWC startup stagger: defer non-critical RunnableEntitys to post-FULL_RUN activation - reduces task load during EcuM startup where MCAL and BswM compete for the scheduler
▸ Parallel multi-core init: Core 1 MCAL peripherals (ETH, LIN) initialised in parallel with Core 0 BSW stack - BootBarrier blocks EcuM FULL_RUN until both cores complete init
Runtime Performance Profiling
50 min read
▸ TRACE32 OS-aware function profiling: per-function cycle count inside a task - Dem_EventDebounce consuming 40% of Dem_MainFunction identified as optimisation target
▸ Preemption chain analysis: TRACE32 task interaction view - QM task at 2ms period preempts ASIL task 8 times per 10ms window, increasing gross time without changing net time
▸ Generated code efficiency: DaVinci COM signal getter wrappers may be non-inline - verifying with objdump that critical signal reads compile to direct struct field access, not function call overhead
▸ Data cache optimisation: arrange COM signal buffers and PduR routing tables in same 32-byte cache line using linker script section ordering - reduces L1 cache misses on Cortex-R5
Reducing Configuration Complexity
35 min read
▸ OEM BSW configuration layer: named parameter profiles hide variant-specific DaVinci values behind a semantic abstraction - 50+ ECU variants share profiles, not duplicated configs
▸ ARXML variant management: predefined variants in DaVinci Configurator Pro switch hardware-specific values (crystal frequency, flash sector size) without duplicating entire config set
▸ CI consistency checks: DaVinci Python API validation scripts in Jenkins - catching PduR routing holes, unmatched ComSignal allocations, and SchM main-function period mismatches on every commit
▸ Signal routing matrix: spreadsheet-based ComSignal → PduR → CanIf linkage synced with ARXML export - detects "silent missing signal" (ComIPduEnabled = FALSE accidentally disables production signal)
Hands-On: Production Build Pipeline
55 min read
▸ Pipeline stages: ARXML commit → DaVinci CLI headless code generation → MISRA-C:2012 Polyspace analysis → cross-compile → map file ROM budget gate → flash to bench
▸ Map file parser: Python script failing build if any BSW partition exceeds its ROM budget (e.g., COM partition > 64 KB) - enforces memory budget as a merge gate
▸ Post-build binary pipeline: PBcfg.c compiled separately and linked as a dedicated flash section - verified by updating a PduR route and loading PBcfg without full BSW recompile
▸ Release gate: automated CAN trace comparison (expected DBC-defined signal cycle times vs. captured) - test must pass green before build artifact is promoted to integration test bench
4
Cross-Platform Integration
Classic ↔ Adaptive Gateway Design
55 min read
▸ On-SoC gateway topology: Classic BSW and Adaptive Platform on same SoC (Renesas R-Car, NXP S32G) - shared memory IPC bridge with defined write/read ownership per domain
▸ Data path: Classic SWC → Rte_IWrite → COM → gateway Classic-side reads Com_ReceiveSignal → serialises to SOME/IP payload → Adaptive provider event Send()
▸ Latency budget: Classic task period (5ms) + gateway BSW-to-SOME/IP processing + SOME/IP-SD latency + Adaptive GetNewSamples() = end-to-end budget; trade-off with SOME/IP event cycle time
▸ Error propagation: Classic DEM gateway timeout event → gateway marks signal invalid → Adaptive consumer SamplePtr E2E check fails → Adaptive SWC safe output state
SOME/IP to Classic Signal Mapping
45 min read
▸ SOME/IP payload deserialization: byte-by-byte extraction using SOME/IP serialisation rules (endianness, struct alignment) → mapped to Classic ComSignal value via explicit bit/byte position
▸ Gateway application role: SOME/IP proxy on Adaptive side + BSW SWC on Classic side in same process - calls Com_SendSignal() with deserialized value after each GetNewSamples() callback
▸ Update rate mismatch: SOME/IP event at 20ms, Classic COM at 10ms - gateway uses last-is-best buffering; 10ms COM cycle sends same value until next SOME/IP event arrives
▸ Signal validity propagation: E2E check status of received SOME/IP event → mapped to Classic ComSignal invalid flag via Com_InvalidateSignal() - downstream SWCs react via FIM inhibit
Hybrid Architecture Patterns
50 min read
▸ Domain split: Adaptive Platform for ADAS / connectivity / OTA (high-compute); Classic ECUs for body / powertrain / chassis (hard real-time ASIL) - communicate via automotive Ethernet backbone
▸ Zonal ECU architecture: zone controller SoC runs Classic BSW (actuator control, MCAL) on Cortex-R cores and Adaptive Platform (service orchestration) on Cortex-A cores concurrently
▸ Diagnostic topology: single DoIP entry on Adaptive ECU - tester connects via Ethernet, ara::diag server routes UDS $22/$2E forwards to Classic DCM via CAN/LIN physical forwarding
▸ Security boundary: TrustZone partition between Adaptive (Normal World) and Classic Secure OS (Secure World) - AUTOSAR Crypto key material lives in Secure World, shared via key handle API
Hands-On: Cross-Platform Vehicle Function
65 min read
▸ Vehicle function: speed-dependent audio volume - Classic VehicleSpeed ComSignal → gateway → SOME/IP SpeedService → Adaptive ProcessingApp → audio Field update
▸ Classic side: VehicleSpeed ComSignal configured in DaVinci, CAN ID assigned in DBC, gateway app Classic port reads via Com_ReceiveSignal() and serialises to SOME/IP event payload
▸ Adaptive side: SpeedService proxy subscribed to event → ProcessingApp algorithm adjusts volume Field value → AudioSkeleton Field Update() pushed to subscriber
▸ Test: inject VehicleSpeed CAN frame with Vector CANoe, verify Adaptive ProcessingApp receives correct value and adjusts Field within 50ms - validate with SOME/IP Wireshark capture
5
Enterprise Architecture
Large-Scale ECU Variant Management
50 min read
▸ DaVinci Configuration Variant feature: hardware targets ECU-A/B/C share one DaVinci project - variant-switched parameters (crystal frequency, PDU set, NvM blocks) per target
▸ Mandatory vs. optional feature sets: pre-processor macros generated per variant control ComIPduEnabled, DEM event set, and NvM block set - CI builds all variants in a build matrix
▸ ECU extract management: ISOLAR-AB generates a separate ECU extract ARXML per hardware variant - stored independently in version control, not merged into one file
▸ Variant validation: automated CI script checks each variant's ComSignal set matches its corresponding DBC file - prevents CAN ID conflicts across the variant set in the same vehicle
Supplier BSW Integration Strategies
45 min read
▸ Delivery format: supplier provides pre-compiled libraries + BSWMD (meta-model descriptor) + DaVinci plugin - integrator imports plugin, DaVinci validates config against supplier's BSWMD
▸ Conflict resolution: two BSW modules from different suppliers sharing MemMap.h section names or Std_Types.h typedefs - resolved with vendor compatibility shim header included last
▸ Supplier change management: BSW update triggers DaVinci re-validation, code regeneration, MISRA re-analysis, and regression test suite - impact assessed via DaVinci module dependency graph
▸ Contract testing: OEM-defined BSW interface test suite (callout stubs, boundary-value inputs) run against each new delivery - detects API regressions before full ECU integration build
AUTOSAR CI/CD & DevOps
40 min read
▸ ARXML in Git: custom XML merge driver for DaVinci ARXML files - any .arxml change triggers DaVinci CLI headless re-validation (-validate flag) as a mandatory CI gate
▸ Automated code generation: Jenkins pipeline runs DaVinci Configurator CLI (-gen) on every ARXML commit - failure (validation error or changed output) blocks merge to integration branch
▸ Static analysis gate: Polyspace or LDRA on all generated + handwritten code - MISRA-C:2012 Rule violations fail build unless listed in the approved project deviation record
▸ HIL smoke test: CI green build automatically flashed to HIL bench - CAN traffic sanity test (message presence, cycle time, signal value range) run as post-flash quality gate
Migration Planning: Classic → Adaptive
45 min read
▸ Migration triggers: function requires dynamic service discovery, OTA update, or ML inference - do not migrate: hard real-time ASIL-D actuator control, MCAL-dependent BSW modules
▸ Staged approach: Classic ECU keeps running; gateway bridges Classic signals to SOME/IP services; Adaptive counterpart developed and validated in parallel before Classic decommission
▸ Toolchain investment: Adaptive requires C++14/17 compiler, POSIX OS target, manifest tooling (arxml2cpp), AUTOSAR Adaptive middleware - new toolchain safety qualification not required for Classic continuation
▸ Risk mitigation: incremental migration (one function at a time) with Classic fallback ECU retained in vehicle architecture until Adaptive function passes full vehicle validation
Tools Used
What You'll Learn
Configure multi-core AUTOSAR systems with proper synchronization
Implement ASIL-D safety mechanisms per ISO 26262
Optimize AUTOSAR stacks for production ROM/RAM/timing constraints
Architect hybrid Classic+Adaptive vehicle platforms
Manage large-scale AUTOSAR variant configurations
Lead AUTOSAR architecture decisions for OEM programs
Prerequisites
AUTOSAR Classic BSW course (or equivalent experience)
AUTOSAR Adaptive Platform course (recommended)
2+ years AUTOSAR development experience
Full Access
Free with Pro
Enroll Now
Browse Modules
This course includes:
25 detailed documentation chapters
Downloadable resources
Searchable text documentation
Code snippets & technical diagrams
Hands-on exercises
Lifetime access
Certificate of completion