Overview
AUTOSAR Adaptive is the next-generation platform for high-performance computing ECUs. Unlike Classic's static configuration, Adaptive uses POSIX-based OS, dynamic service discovery, and modern C++14/17 - the skills demanded by every major OEM for SDV programs.
This course covers the full Adaptive stack: ara::com for service-oriented communication, Execution Management for application lifecycle, State Management, Update & Config Management, and Persistency. You'll build real Adaptive applications step by step.
With hands-on projects using real Adaptive middleware stacks, you'll gain the practical experience needed to develop ADAS, autonomous driving, and connected vehicle applications.
Course Modules
1
Adaptive Platform Fundamentals
Adaptive vs Classic - Architecture ComparisonFREE PREVIEW
45 min read
▸ Classic: static ARXML-generated BSW + OS alarms vs. Adaptive: dynamic service discovery, POSIX processes, modern C++14/17
▸ SOA vs. signal-based: why ara::com SOME/IP replaces static ComSignal definitions - trade-offs in latency, flexibility, and toolchain complexity
▸ Functional Cluster overview: Execution Management, Communication Management, State Management, Persistency, Diagnostics, Update & Config Management
▸ Platform selection criteria: Adaptive for compute-intensive (ADAS, gateway, infotainment) vs. Classic for safety-critical real-time (MCAL, motor control, body ECU)
POSIX OS & Execution ModelFREE PREVIEW
40 min read
▸ POSIX process isolation: each Adaptive Application is a separate Linux/QNX process with independent address space - no shared BSS/data with other apps
▸ Scheduling classes: SCHED_FIFO / SCHED_RR for real-time tasks, SCHED_OTHER for background - setting priority via manifest scheduling_policy field
▸ IPC underneath ara::com: UNIX domain sockets for same-machine communication, shared memory for zero-copy event transfer - what the middleware abstracts
▸ Resource management: Linux cgroups for per-process CPU/memory limits, systemd unit integration for startup order and watchdog ping interval
Adaptive Application Structure
50 min read
▸ Deployment unit: executable binary + Application Manifest deployed together as a Software Package - directory layout and expected file names
▸ Entry point pattern: main() → ara::core::Initialize() → OfferService() or FindService() → event loop → ara::core::Deinitialize() - why each call is mandatory
▸ Threading model: std::thread vs. ara::exec worker pools - why blocking calls (I/O, sleep) must not run on the ara::com callback dispatcher thread
▸ Error handling: ara::core::Result<T, E> return type pattern - propagating errors without exceptions in safety-relevant code paths
Manifest Files & Configuration
45 min read
▸ Three manifest types: Application Manifest (process config + startup), Service Instance Manifest (service binding), Machine Manifest (platform-level config)
▸ Application Manifest key fields: startupConfig, schedulingPolicy, resourceGroup, requiredFunctionalClusters - and what happens if a required FC is unavailable
▸ Service Instance Manifest: serviceInterfaceDeployment, networkEndpoint, SOME/IP service ID (16-bit) and instance ID (16-bit) - how they map to ara::com InstanceIdentifier
▸ Deployment workflow: manifest validation with ara-manifest-validator, ARXML↔JSON manifest conversion, OEM extension namespaces and vendor-specific fields
SOME/IP & Service-Oriented Architecture
55 min read
▸ SOME/IP wire format: 8-byte header (Message ID, Length, Request ID, Protocol Version, Interface Version, Message Type, Return Code) - byte-exact layout
▸ Service/Instance ID space: 16-bit service ID + 16-bit instance ID - OEM-managed registry, conflict detection, wildcard 0xFFFF in SD FindService
▸ SOME/IP-SD packet flow: Offer Service / Find Service / Subscribe / Subscribe Ack over UDP multicast (default 239.192.0.1:30490) - SD entry and option format
▸ SOME/IP-TP: segmenting payloads > 1400 bytes - offset field, More Segments Flag, reassembly timeout configuration in Service Instance Manifest
Hands-On: First Adaptive Application
60 min read
▸ Skeleton side: generate ara::com skeleton from ARXML using arxml2cpp, implement OfferService() and periodic Event::Send() in a std::thread loop
▸ Proxy side: FindService() → construct proxy → SetSubscriptionStateChangeHandler → Subscribe() → GetNewSamples() callback processing
▸ Manifest wiring: connecting serviceInterfaceDeployment in Service Instance Manifest to generated skeleton's service/instance IDs - common mismatch errors
▸ Launch via Execution Manager: write Application Manifest with startupConfig, register with EM, observe process state transitions in systemd journal
2
ara::com - Communication Management
Service Interface Definition (ARXML)
50 min read
▸ ServiceInterface ARXML elements: shortName, Events (data type + isReliable), Methods (fire-and-forget vs. request-response + error enumeration), Fields (getter/setter/notifier)
▸ Data type mapping: AUTOSAR ImplementationDataTypes → C++ types - uint8_t arrays, structures, Optional<T>, and namespace generation rules
▸ Version management: serviceInterfaceVersion (Major.Minor) - compatibility rules: same major required, minor backwards-compatible for proxy/skeleton matching
▸ ARXML toolchain: define interface in ISOLAR-EVE or AUTOSAR Workbench → arxml2cpp (Vector/EB) generates typed C++ proxy and skeleton header files
Proxy & Skeleton Pattern
55 min read
▸ Skeleton instantiation: constructor takes InstanceIdentifier, registers with CM during OfferService() - destructor automatically calls StopOfferService()
▸ Proxy construction: ServiceProxy::FindService(InstanceIdentifier) - synchronous single-call vs. StartFindService() with ServiceAvailabilityHandler callback
▸ ara::com::SamplePtr<T>: zero-copy event data ownership - GetNewSamples() callback, maxSampleCount subscription cache, SamplePtr lifetime rules
▸ Method call future: proxy.Method(args) returns ara::core::Future<ReturnType> - then() callback for async continuation vs. get() blocking, cancellation via cancel()
Events, Methods, and Fields
45 min read
▸ Event send: Skeleton::EventName.Send(data) publishes to all current subscribers - SetSubscriptionStateChangeHandler notifies skeleton of subscriber count changes
▸ Method dispatch: skeleton method handler returns ara::core::Future<Output> - CM dispatches on worker thread pool; fire-and-forget methods return void immediately
▸ Field semantics: getter method + setter method + notifier event in one construct - Skeleton::FieldName.Update() pushes value to all field subscribers atomically
▸ QoS configuration: event subscription maxSampleCount (subscriber cache depth), isReliable (TCP) vs. unreliable (UDP) transport selection in Service Instance Manifest
Service Discovery Mechanisms
40 min read
▸ SOME/IP-SD FSM phases: INITIAL_WAIT → REPETITION → MAIN - timing parameters (InitialDelayMin/Max, RepetitionMax, RepetitionBaseDelay) and their effect on startup latency
▸ FindService() vs. StartFindService(): one-shot synchronous lookup vs. continuous monitoring - ServiceAvailabilityHandler callback on offer/stop-offer events
▸ Multi-ECU discovery: SOME/IP-SD UDP multicast group (239.192.0.1:30490), TTL, endpoint option encoding - and configuring unicast fallback for subscriber responses
▸ Instance specifier resolution: shortName path in ARXML maps to SOME/IP service/instance ID via Service Instance Manifest - debugging "service not found" with SD packet capture
End-to-End Protection (E2E)
35 min read
▸ Profile selection: P01 (CRC8/ASIL-B), P04 (CRC32/ASIL-D), P05 (CRC32P4) - selection criteria based on payload size, error detection coverage, and target ASIL
▸ E2E header fields: DataID, Length, SQC (sequence counter), CRC - exact byte position within SOME/IP payload and how DataID provides context-specific protection
▸ Transformer API: E2EXf_Protect() at sender, E2EXf_Check() at receiver - integration with ara::com via transformer binding in Service Instance Manifest
▸ State machine output: E2E_CHECK_OK, E2E_CHECK_WRONGSEQUENCE, E2E_CHECK_ERROR - mapping to ara::com SamplePtr check status and recommended application reaction
Hands-On: Multi-Service Application
65 min read
▸ Provider app: OfferService() for two ServiceInterfaces, send Event at 10 Hz, expose Field for current state, and handle Method requests with async Future
▸ Consumer app: StartFindService() for both providers, subscribe to events, chain method calls with ara::core::Future::then() - avoiding callback nesting
▸ E2E integration: enable E2E Profile 4 on safety event in Service Instance Manifest, verify SamplePtr check status in consumer GetNewSamples() handler
▸ Debugging: capture SOME/IP traffic with Wireshark + SOME/IP dissector, verify SD Offer/Subscribe flow and payload byte layout for each event
3
Execution & State Management
Execution Manager - Process Lifecycle
50 min read
▸ EM role: reads Application Manifests, launches processes via execve(), monitors liveness via ApplicationClient heartbeat, terminates on timeout (SIGTERM → SIGKILL)
▸ Process states: Idle → Initializing → Running → Terminating → Terminated - application reports each via ara::exec::ApplicationClient::ReportApplicationState()
▸ Startup dependencies: startupConfig priority ordering, process interdependency via functionGroupState preconditions - EM blocks dependent apps until prerequisites reach Running
▸ Graceful shutdown: app must call ReportApplicationState(kTerminating) before cleanup - EM sends SIGTERM, waits terminationTimeout, then SIGKILL if not yet exited
Function Groups & Machine States
45 min read
▸ Function Group concept: named set of Adaptive Applications controlled as a unit - e.g., "MachineFG", "DiagFG", "ADASGroup" declared in Machine Manifest
▸ Machine State vs. Function Group State: MachineState is global platform state (Startup, Driving, Shutdown); each FunctionGroup has its own independent states
▸ Transition request: ara::exec::StateClient::SetState(FunctionGroupState) - atomic, EM orchestrates process starts/stops per state, returns Future resolved on completion
▸ Manifest declaration: functionGroup container in Machine Manifest; per-process state mapping (which states the process should run in) in Application Manifest
State Manager - Coordinating Transitions
40 min read
▸ SM application: the single Adaptive Application authorised to call SetState() - subscribes to NM state events, PHM recovery notifications, and vehicle mode signals
▸ Coordination pattern: SM decides target FunctionGroupState based on ComM/NM state, PHM health verdict, and OEM-defined mode logic - implements the vehicle's state machine
▸ Error recovery: PHM recovery actions (restart process / restart FunctionGroup / full machine reset) declared in manifest recoveryTarget - SM receives callback and acts
▸ SM-EM interaction: SetState() is synchronous - EM blocks the SM call until all processes in the FunctionGroup reach target state or terminationTimeout elapses
Platform Health Management (PHM)
45 min read
▸ Supervision types: Alive (periodic checkpoint), Deadline (min/max interval between two checkpoints), Logical (correct graph traversal) - and their ASIL contribution
▸ Checkpoint reporting: ara::phm::SupervisedEntity::ReportCheckpoint(checkpointId) - called in application main loop to prove liveness; missing calls trigger supervision failure
▸ PHM→SM notification: on supervision failure, PHM invokes RecoveryAction on State Manager - action type (restartProcess, restartFunctionGroup, reset) declared in manifest
▸ Hardware watchdog integration: PHM drives external watchdog via WdgM-equivalent periodic token - alive supervision failure stops token → watchdog triggers reset
Hands-On: Multi-Process Orchestration
60 min read
▸ Two Adaptive Apps: Provider (running in ADAS FunctionGroup "Active" state) and Supervisor (State Manager, always Running in MachineFG)
▸ SM implementation: calls SetState("ADAS", "Active") / SetState("ADAS", "Off") based on a received SOME/IP trigger event - observe EM start/stop Provider
▸ PHM alive supervision: Provider reports checkpoint in its event loop; stop the checkpoint → PHM fires RecoveryAction → SM restarts Provider's FunctionGroup
▸ Observability: filter systemd journal with --identifier=ExecutionManager to trace process state transitions and supervision failure recovery sequence
4
Persistency & Update Management
ara::per - Key-Value & File Storage
45 min read
▸ Two storage APIs: KeyValueStorage (typed key-value map) and FileStorage (POSIX-like open/read/write) - declared as portPrototypes in Application Design ARXML
▸ KVS usage pattern: ara::per::OpenKeyValueStorage(shortName) → GetValue<T>(key) → SetValue(key, value) → SyncToStorage() - why SyncToStorage() must be called explicitly
▸ FileStorage usage: OpenFileStorage(shortName) → OpenFileReadWrite("config.json") → read/write bytes → close - file path is logical, not filesystem-absolute
▸ Redundancy modes: REDUNDANT (dual-copy with CRC), REDUNDANT_MEDIATED (voting between three copies), NONE - declared per storage in manifest; trade-offs in storage size
Redundancy & Recovery Strategies
35 min read
▸ CRC integrity checking: CRC32 computed over stored content on write, verified on read - corruption detected triggers RecoveryAction (use redundant copy or reset to init value)
▸ RecoveryHandler registration: ara::per::RegisterRecoveryAction(shortName, handler) - callback receives RecoveryAction enum (kResetToDefaultValue / kReportError)
▸ Rollback design: storing software version as a KVS key alongside config - on version mismatch after OTA, RecoveryHandler detects incompatibility and resets to factory defaults
▸ Storage backend selection: littlefs for raw NOR/NAND flash (wear leveling built-in) vs. ext4 journal on eMMC - impact on write latency and media endurance
UCM - Update & Configuration Manager
50 min read
▸ UCM role: accepts AUTOSAR Software Packages (.swcl zip files containing ARXML manifest, binaries, update scripts), verifies digital signature, orchestrates installation
▸ Update state machine: Idle → Transferring → Processing → Activating → Activated - UCM exposes this as a SOME/IP service consumed by the OTA client application
▸ Integrity verification: package RSA/EC signature check, per-file hash verification against package manifest - rejected packages leave current software untouched
▸ Rollback manifest: software package includes rollback information - UCM can revert binaries if Activate() fails or SM triggers Rollback() after PHM-detected failure
OTA Update Workflows
45 min read
▸ Client-side flow: OTA SOTA module calls UCM.TransferStart(packageSize) → UCM.TransferData(chunk) → UCM.TransferExit() - chunk size and retry logic for unreliable channels
▸ Activation: UCM.Activate() triggers EM to stop affected processes, apply filesystem swap of new binaries, restart processes - zero-downtime design using A/B partitions
▸ Post-activation validation: SM monitors PHM health after restart - if failures detected within validationTimeout, SM calls UCM.Rollback() to restore previous binary set
▸ Security: ara::crypto API used for package signature verification - private key in Hardware Security Module (HSM), public key certificate chain validated against OEM root CA
Hands-On: Persistent Application State
55 min read
▸ KVS implementation: persist an odometer counter - GetValue on startup to restore, SetValue + SyncToStorage on each increment, verified across simulated power cycles
▸ Recovery test: manually corrupt the KVS backing file → observe RecoveryHandler callback, confirm default value restored and error logged via ara::log
▸ UCM integration: package updated application binary as Software Package (.swcl), transfer to UCM via SOME/IP client, trigger Activate(), observe EM restart
▸ Upgrade and rollback path: verify updated app reads KVS value correctly after OTA; trigger Rollback(), confirm previous binary runs and KVS persisted data remains intact
5
Diagnostics & Network Management
ara::diag - Diagnostic Services
50 min read
▸ ara::diag architecture: DiagnosticServer exposes UDS services over DoIP (ISO 13400) - each UDS service handler registered as a typed callback on the server instance
▸ Service $22 (ReadDataByIdentifier): implement GenericUDSService callback returning DID byte vector from KVS or live SWC state - response timing constraints
▸ Service $2E (WriteDataByIdentifier) + $14 (ClearDTCInformation): request-response with SecurityAccess ($27) precondition check - returning NRC 0x33 if not authenticated
▸ DTC reporting: ara::diag::DiagnosticMonitor::ReportMonitorAction(Pass/Fail/Prepassed/Prefailed) - maps to DTC status byte bits, verifiable via $19 02 response
ara::nm - Network Management in Adaptive
40 min read
▸ ara::nm role: coordinates Ethernet link-state - applications call RequestBusCommunication() to keep network up, ReleaseBusCommunication() when done
▸ Network voting: bus released only when all apps have called Release() - prevents one idle app from holding the network awake during sleep phases
▸ SOME/IP-SD integration: SD Offer Service messages only sent while NM reports NetworkMode=REQUESTED - prevents zombie service advertisements to sleeping nodes
▸ Bus-off recovery: EM notifies NM of link-down event → NM transitions to REQUESTED mode, applications receive NetworkStateChangeHandler callback for reconnect logic
Integration with Classic ECUs
45 min read
▸ Adaptive↔Classic gateway: SOME/IP event value mapped to Classic BSW ComSignal via gateway application on same SoC or a dedicated gateway ECU on the vehicle network
▸ Signal routing path: Adaptive provider SOME/IP event → gateway app SOME/IP proxy → gateway app Classic COM API → CAN frame → Classic BSW RTE → SWC port
▸ Diagnostic bridging: DoIP tester (Ethernet) connects to Adaptive ECU's ara::diag server which forwards UDS requests over Classic CAN/LIN to Classic ECU DCM
▸ Timing constraints: gateway introduces latency - E2E Deadline Supervision window and SOME/IP event cycle time must account for gateway processing + CAN frame latency
Hands-On: Diagnostic Server Implementation
60 min read
▸ DiagnosticServer setup: register handlers for $10 (DiagnosticSessionControl), $22 (ReadDID), $2E (WriteDID), $19 02 (ReportDTCByStatusMask)
▸ DoIP transport: set logical address in Machine Manifest, test with UDS tester over Ethernet using Python-doipclient or CAPL script - verify response timing
▸ DTC integration: DiagnosticMonitor reports periodic fault Fail → verify $19 02 response contains correct DTC and status byte (0x08 = testFailed; 0x09 = stored)
▸ SecurityAccess: implement $27 01 seed generation (random + key derivation) and $27 02 key check - confirm $2E returns NRC 0x33 before security access granted
6
Advanced Topics & Real Projects
Multi-Binding Communication (SOME/IP + DDS)
50 min read
▸ Binding concept: same ara::com API, different transport binding selected per deployment in Service Instance Manifest - someip-binding vs. dds-binding, switchable without code change
▸ DDS binding internals: ara::com Events mapped to DDS DataWriter/DataReader (Topics), Methods mapped to DDS Requester/Replier request-reply pattern
▸ SOME/IP vs. DDS selection: SOME/IP suited for cross-ECU vehicle Ethernet (known subscriber set, OEM service registry), DDS for high-throughput intra-SoC publish-subscribe with dynamic QoS
▸ Mixed binding in one application: SomeipBinding for external ECU communication + DdsBinding for internal SoC inter-process - configuring domain ID and network_endpoint per interface
Safety Extensions (ASIL Support)
45 min read
▸ Freedom from Interference (FFI): separate POSIX process address spaces enforce spatial isolation - Adaptive on ASIL-capable OS (QNX RTOS, Linux + ELISA hardening patches)
▸ E2E protection mandatory: ara::com events carrying ASIL-B/D data must use E2E Profile 4 or Profile 5 - profile parameters declared in Service Instance Manifest transformer
▸ PHM Alive/Deadline supervision as ASIL mechanism: supervision failure rate contributes to PFH calculation - supervision periods must meet ISO 26262 diagnostic coverage targets
▸ ara::core::Abort() policy: in ASIL context, terminate-on-error replaces exceptions - ara::core::Result<T> propagation ensures no uncaught exception paths in safety functions
Performance Profiling & Optimization
40 min read
▸ Event delivery latency: POSIX clock_gettime(CLOCK_MONOTONIC) timestamp at Send() and inside GetNewSamples() - measuring jitter distribution (P50/P99) under load
▸ Zero-copy optimization: pre-allocate event sample buffer (Allocate() → fill in-place → Send()) vs. copy-based Send(data) - measured throughput difference for large payloads
▸ SOME/IP serialization cost: perf stat on ara::com Send() - identifying cycles spent in SOME/IP header encoding for high-frequency events, and batch-send mitigation
▸ CPU pinning: sched_setaffinity() for time-critical Adaptive Applications - prevent scheduler migration between cores, combined with SCHED_FIFO for deterministic dispatch
Capstone: Full Adaptive ECU Application
75 min read
▸ Three-app architecture: SensorApp (SOME/IP event producer at 50 Hz), ProcessingApp (consumer + algorithm + Field update), DiagApp (ara::diag UDS server over DoIP)
▸ Full manifest set: Application Manifests for all three, Machine Manifest with FunctionGroups (SensorFG + ProcessFG), Service Instance Manifests for all bindings with E2E enabled
▸ PHM + SM integration: ProcessingApp under Alive Supervision; SM restarts ProcessFG on failure; DiagApp reports processing health DTC via DiagnosticMonitor
▸ OTA simulation: package updated ProcessingApp as UCM Software Package, transfer and activate, verify post-update behavior, trigger rollback and confirm previous version restored
Tools Used
Vector MICROSAR Adaptive
EB corbos
Elektrobit Adaptive Tools
SOME/IP Analyzer
Lauterbach TRACE32
QNX/Linux Target
What You'll Learn
Architect Adaptive applications using service-oriented design
Implement ara::com proxy/skeleton patterns for communication
Configure Execution Management for multi-process applications
Build persistent storage using ara::per APIs
Implement OTA update workflows with UCM
Debug and profile Adaptive applications on Linux targets
Prerequisites
Modern C++ (C++14/17) proficiency
Linux/POSIX fundamentals
Basic AUTOSAR Classic understanding (recommended)
Full Access
Free with Pro
Enroll Now
Browse Modules
This course includes:
30 detailed documentation chapters
Downloadable resources
Searchable text documentation
Code snippets & technical diagrams
Hands-on exercises
Lifetime access
Certificate of completion