1
What is the key architectural difference between AUTOSAR Adaptive and Classic?
Answer
AUTOSAR Adaptive uses a POSIX-based operating system (Linux or QNX) with dynamic, service-oriented communication, while Classic uses a static, signal-based architecture with a proprietary OS. Adaptive applications are independent executables with their own address space, whereas Classic SWCs share memory via the RTE. Adaptive supports C++14/17 while Classic primarily uses C.
2
What operating systems are typically used for AUTOSAR Adaptive?
Answer
AUTOSAR Adaptive platforms commonly run on POSIX-compliant operating systems such as Linux (with real-time extensions like PREEMPT_RT), QNX, or other RTOS that support POSIX APIs. The platform requires process isolation, virtual memory, and POSIX thread support. QNX is preferred for safety-critical applications due to its microkernel architecture.
3
What is the role of the Adaptive Application in the AUTOSAR Adaptive architecture?
Answer
An Adaptive Application (AA) is an independent process with its own address space. It communicates via ara:: APIs provided by the Adaptive Platform Foundation and Services. Each AA has a manifest that describes its deployment, execution, and service dependencies. AAs can be dynamically started, stopped, and updated at runtime.
4
What are the main Functional Clusters in AUTOSAR Adaptive?
Answer
The main Functional Clusters are: Communication Management (ara::com), Execution Management (ara::exec), State Management (ara::sm), Persistency (ara::per), Diagnostics (ara::diag), Update and Configuration Management (ara::ucm), Platform Health Management (ara::phm), Network Management (ara::nm), and Identity and Access Management (ara::iam). Each provides a standardized API to applications.
5
What is SOME/IP and how does it relate to AUTOSAR Adaptive?
Answer
SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the primary network binding protocol for AUTOSAR Adaptive. It enables service-oriented communication over Ethernet, supporting request/response methods, event notifications, and field getters/setters. SOME/IP-SD (Service Discovery) handles dynamic service registration and subscription. It is defined in the AUTOSAR standard and used for inter-ECU communication.
6
Explain the concept of Service-Oriented Architecture (SOA) in Adaptive AUTOSAR.
Answer
SOA in Adaptive AUTOSAR means that applications communicate through well-defined services rather than direct signal exchange. Services are described by Service Interfaces (defined in ARXML) containing Methods, Events, and Fields. Services are offered by Skeleton instances and consumed by Proxy instances. Service Discovery allows dynamic finding and binding of services at runtime, enabling loose coupling between components.
7
What is the difference between a Proxy and a Skeleton in ara::com?
Answer
A Skeleton is the server-side abstraction - it provides (offers) a service and implements the business logic for methods, events, and fields. A Proxy is the client-side abstraction - it discovers and connects to offered services, calls methods, subscribes to events, and reads/writes fields. Both are auto-generated from Service Interface descriptions in ARXML.
8
What are the three types of communication elements in an ara::com Service Interface?
Answer
The three types are: Methods - synchronous or asynchronous request/response calls (like RPC); Events - publish/subscribe notifications sent from server to subscribed clients when data changes; and Fields - stateful data elements with optional getter, setter, and notification capabilities. Fields combine the characteristics of methods and events with persistent state.
9
How does AUTOSAR Adaptive handle service versioning?
Answer
Adaptive AUTOSAR supports service versioning through major and minor version numbers in Service Interface definitions. Major version changes indicate breaking API changes while minor versions are backward-compatible. During Service Discovery, version compatibility is checked. The platform supports version negotiation so clients can discover services with compatible versions.
10
What is the Machine Manifest in AUTOSAR Adaptive?
Answer
The Machine Manifest describes the hardware and software platform configuration for a specific ECU (machine). It includes network interface configurations, service instance assignments, process resource limits, and machine state definitions. It is provided as ARXML and is used by the platform during initialization to configure the runtime environment.
11
What is the Execution Manifest?
Answer
The Execution Manifest is an ARXML file that describes how an Adaptive Application should be deployed and executed. It contains the executable path, startup configuration, resource requirements, process-to-Function-Group mapping, dependencies, and scheduling parameters. Execution Management reads this manifest to manage the application lifecycle.
12
What is the Service Instance Manifest?
Answer
The Service Instance Manifest maps service interfaces to specific transport protocol configurations. It defines which network endpoints (IP address, port) a service uses, the protocol binding (SOME/IP, DDS), serialization parameters, and E2E protection settings. It bridges the abstract service interface definition with concrete network deployment.
13
Explain the ara::com FindService mechanism.
Answer
FindService is a Proxy-side API that discovers offered services. It can be called with a StartFindService() for asynchronous continuous discovery with a callback, or FindService() for one-shot synchronous lookup. It returns ServiceHandleContainer with handles for all discovered instances matching the service ID and instance ID. Handles are then used to construct Proxy objects.
14
How does event-based communication work in ara::com?
Answer
On the Skeleton side, events are sent using the Send() method on an Event object, which notifies all subscribed proxies. On the Proxy side, Subscribe() registers interest, and new data can be received via GetNewSamples() with a callback or by polling. Subscription uses SOME/IP-SD Subscribe Eventgroup messages. Events support configurable cache sizes and subscription states.
15
What is the difference between ara::com polling and event-driven reception?
Answer
Polling mode uses GetNewSamples() which processes all received samples in the calling thread's context. Event-driven mode uses SetReceiveHandler() which triggers a callback in a platform thread when new data arrives. Polling gives more control over execution timing, while event-driven provides lower latency. Both can be combined with subscription state callbacks.
16
How are Methods implemented in ara::com?
Answer
On the Skeleton side, methods are registered as handlers using RegisterMethod() or by overriding virtual functions. Methods receive request parameters and return a Future with the response. On the Proxy side, methods are called as function calls that return ara::core::Future objects, supporting both synchronous (get()) and asynchronous (then()) patterns.
17
What is ara::core::Future and how is it used?
Answer
ara::core::Future is the AUTOSAR Adaptive equivalent of std::future, used for asynchronous method call results. It supports get() for blocking retrieval, then() for chaining callbacks, and is_ready() for polling. It wraps ara::core::Result which can hold either a value or an ErrorCode, enabling type-safe error handling for remote method calls.
18
Explain E2E (End-to-End) protection in AUTOSAR Adaptive.
Answer
E2E protection ensures data integrity for safety-critical communication. It adds a CRC and counter/sequence number to serialized data, which the receiver verifies. In Adaptive, E2E is configured in the Service Instance Manifest and applied transparently by the middleware. Supported profiles include Profile 4 and Profile 7. E2E status is accessible via the communication API.
19
What serialization formats does ara::com support?
Answer
ara::com primarily uses SOME/IP serialization which defines byte-order, alignment, and encoding for basic types, structs, arrays, and strings. Alternative bindings like DDS use CDR (Common Data Representation). The serialization is configured in the Service Instance Manifest and handled transparently by the generated code. Custom transformers can also be configured.
20
How does ara::com handle network binding independence?
Answer
ara::com provides an abstract API layer that is independent of the underlying transport protocol. The same service interface code works whether the binding is SOME/IP, DDS, IPC (inter-process), or signal-based. Binding selection is configured in the Service Instance Manifest at deployment time, not in the application code, enabling portability.
21
What is SOME/IP Service Discovery (SOME/IP-SD)?
Answer
SOME/IP-SD is the protocol for dynamic service registration and discovery. Services announce their availability via OfferService messages, and clients find them via FindService. Event subscriptions use SubscribeEventgroup/SubscribeEventgroupAck messages. SD uses UDP multicast for discovery and supports TTL-based expiration and reboot detection.
22
How does ara::com support zero-copy communication?
Answer
ara::com supports zero-copy for intra-machine communication using shared memory. The Allocate() method on event/method objects returns a SampleAllocateePtr that references shared memory. Data is written directly to shared memory and only a pointer is passed to the receiver, avoiding data copying. This significantly improves performance for large payloads like camera frames.
23
What is the difference between InstanceSpecifier and InstanceIdentifier?
Answer
InstanceSpecifier is a human-readable shortname path (like /path/to/port) used in application code to refer to a service instance. InstanceIdentifier is the runtime-resolved identifier that maps to actual network endpoints. The mapping between them is defined in the Execution Manifest. This separation enables deployment flexibility without code changes.
24
How does ara::com handle method error reporting?
Answer
Methods use ara::core::Result<T, ErrorCode> as return type. Application-level errors are defined in the Service Interface as ApApplicationErrors. The Skeleton implementation returns either a value or an error via Promise::set_value() or Promise::SetError(). On the Proxy side, Future::get() either returns the result or throws, and then() receives the Result.
25
What is the role of Execution Management in AUTOSAR Adaptive?
Answer
Execution Management (EM) controls the lifecycle of all Adaptive Applications. It reads Execution Manifests to determine which processes to start, manages startup/shutdown sequences, monitors process health, enforces resource limits, and coordinates with State Management for mode-dependent behavior. It is the first functional cluster initialized.
26
What are Function Groups in AUTOSAR Adaptive?
Answer
Function Groups define logical groupings of applications that share lifecycle behavior. Each Function Group has defined states (e.g., Off, Running, Verify). When a Function Group transitions between states, EM starts or stops the associated applications accordingly. The MachineFG is the top-level group that controls the overall machine state.
27
Explain the startup sequence of an AUTOSAR Adaptive machine.
Answer
On power-up, the OS boots and starts the Execution Manager. EM reads Machine and Execution Manifests, initializes the MachineFG to Startup state, starts platform-level services (logging, com, etc.), then transitions through configured states. Applications are started based on their Function Group associations and state dependencies. The sequence is deterministic and configurable.
28
How does AUTOSAR Adaptive handle process termination?
Answer
EM sends a SIGTERM signal to gracefully terminate processes. Applications register a termination handler that performs cleanup (closing files, releasing resources, reporting state). If the process doesn't terminate within a configured timeout, EM sends SIGKILL for forced termination. EM reports the termination status and manages dependent process shutdown.
29
What is the ReportExecutionState API?
Answer
ReportExecutionState is called by an Adaptive Application to notify Execution Management of its operational state. An application reports kRunning after initialization is complete, indicating it is ready to provide services. This mechanism allows EM to track application readiness and manage startup dependencies between applications.
30
How does Execution Management enforce resource limits?
Answer
EM uses OS-level mechanisms (cgroups on Linux) to enforce resource limits defined in Execution Manifests. Limits include CPU time, memory usage, number of threads, file descriptors, and stack size. If an application exceeds its limits, EM can be configured to terminate it and report to Platform Health Management.
31
What is the role of deterministic execution in Adaptive AUTOSAR?
Answer
Deterministic execution ensures that applications produce the same outputs for the same inputs regardless of timing variations. EM supports DeterministicClient API which provides deterministic activation cycles, synchronized timestamps, and data access. This is critical for ADAS applications requiring reproducible behavior for safety validation.
32
How does the Adaptive Platform support multi-process applications?
Answer
A single Adaptive Application can consist of multiple processes defined in the Execution Manifest. EM manages all processes as a group, coordinating startup order and handling inter-process dependencies. Processes communicate via ara::com IPC binding (shared memory or local sockets). This enables modular design and fault isolation.
33
What is Platform Health Management (PHM)?
Answer
PHM monitors the health of Adaptive Applications using configurable supervision mechanisms: Alive Supervision (periodic heartbeat), Deadline Supervision (timing constraints), and Logical Supervision (execution flow). If supervision fails, PHM takes recovery actions such as restarting the process, transitioning Function Groups, or triggering safe states.
34
How does AUTOSAR Adaptive implement process isolation?
Answer
Each Adaptive Application runs as a separate OS process with its own virtual address space, enforced by the MMU. Applications cannot directly access each other's memory. Inter-process communication occurs only through ara::com APIs. Resource limits are enforced via OS mechanisms. This provides fault containment essential for safety and security.
35
What is State Management in AUTOSAR Adaptive?
Answer
State Management (SM) coordinates system-wide modes and states. It maintains a state machine and triggers Function Group state transitions through Execution Management. SM responds to inputs from diagnostics, network management, and applications to determine the appropriate system state. It is responsible for coordinating vehicle modes like Driving, Parking, and Update.
36
How does Update and Configuration Management (UCM) work?
Answer
UCM manages software updates for Adaptive Applications. It accepts Software Packages, verifies integrity and authenticity, manages the update sequence (backup, install, verify, activate), and supports rollback on failure. UCM Master coordinates updates across multiple ECUs. The API supports both full and differential updates, and integrates with OTA infrastructure.
37
What is the UCM Master concept?
Answer
UCM Master is a central coordination entity that manages vehicle-wide update campaigns. It distributes software packages to individual ECU UCM instances, coordinates the update sequence, manages dependencies between ECU updates, and handles campaign-level rollback. Only one UCM Master exists per vehicle, typically on the central gateway or HPC.
38
How does AUTOSAR Adaptive handle safe state transitions?
Answer
State Management coordinates with Platform Health Management and Execution Management for safe transitions. When a failure is detected, PHM notifies SM, which determines the target safe state. SM requests EM to transition Function Groups to degraded or safe states, ensuring applications are gracefully stopped and safety-critical functions are maintained.
39
Explain the concept of Machine States.
Answer
Machine States define the top-level operational modes of an Adaptive ECU: Startup, Running, Shutdown, and optionally Restart. Machine States are managed by the MachineFG (Machine Function Group) through Execution Management. Additional application-specific states can be defined within subordinate Function Groups.
40
What is the difference between Function Group state and Machine state?
Answer
Machine state is the top-level state of the entire ECU, managed by the MachineFG. Function Group states are independent state machines for logical groups of applications. Multiple Function Groups can be in different states simultaneously. A Machine state change can trigger cascading Function Group transitions, but FGs can also change independently.
41
How does the Adaptive Platform support partial networking?
Answer
Network Management (ara::nm) enables partial networking where only required ECUs and communication channels are active. NM coordinates with State Management to wake up or put to sleep specific Function Groups based on network requests. This reduces power consumption while maintaining necessary functionality.
42
What is the role of Identity and Access Management (IAM)?
Answer
IAM controls which applications can access which platform services and resources. Access policies are defined in manifests and enforced at runtime. IAM verifies application identity, checks permissions for service usage, and prevents unauthorized access to sensitive APIs. This is critical for cybersecurity in multi-application environments.
43
How does AUTOSAR Adaptive handle software package verification?
Answer
UCM verifies software packages through multiple mechanisms: cryptographic signature verification ensures package authenticity, hash checks verify integrity, version checks prevent rollback attacks, and dependency checks ensure compatibility. Verification uses certificates from a trusted chain. Packages are verified before extraction and again after installation.
44
What is the Transfer State Machine in UCM?
Answer
The UCM Transfer State Machine manages the package transfer process: kIdle (no transfer), kTransferring (receiving data blocks), kTransferred (complete, ready to process), kProcessing (installing), kActivating (switching to new version), kActivated (update complete). Each transition has defined conditions and error handling.
45
How does ara::per (Persistency) work?
Answer
ara::per provides two storage abstractions: Key-Value Storage for structured data using OpenKeyValueStorage(), and File Storage for file-based access using OpenFileStorage(). Data is stored in persistent memory mapped to the application's PortPrototype. ara::per handles serialization, redundancy, and access control. Storage locations are configured in the Execution Manifest.
46
What is the difference between Key-Value Storage and File Storage in ara::per?
Answer
Key-Value Storage provides a map-like interface with GetValue/SetValue for structured data, supporting automatic serialization of AUTOSAR data types. File Storage provides file-like access with OpenFile/ReadFile/WriteFile for unstructured or large data. Key-Value is preferred for configuration parameters while File Storage suits logs, calibration data, or binary blobs.
47
How does ara::per handle redundancy and recovery?
Answer
ara::per supports configurable redundancy strategies: Triple Redundant storage with majority voting for safety-critical data, CRC-protected storage for corruption detection, and backup/restore mechanisms. On startup, ara::per performs consistency checks and automatically recovers from detected corruption using redundant copies. Recovery strategy is configured in the manifest.
48
What happens to persistent data during a software update?
Answer
UCM coordinates with ara::per during updates. Persistent data can be configured as: kKeep (preserved across updates), kDelete (removed with old version), or kUpdate (migrated using a transformation function). Data migration functions handle format changes between software versions. Backup is created before update for rollback support.
49
How is persistent data scoped to applications?
Answer
Each Adaptive Application has its own isolated persistent storage namespace, defined in the Execution Manifest. An application can only access its own storage through its configured PortPrototypes. Cross-application data sharing requires explicit service-based communication. This isolation ensures data integrity and security between applications.
50
What is the role of ResetPersistency API?
Answer
ResetPersistency allows an application or a diagnostic service to reset persistent storage to its initial state. This is useful for factory reset scenarios, diagnostic clearing of learned values, or recovery from corrupted data. The API can target specific Key-Value databases or File Storage instances. It restores initial values defined in the manifest.
51
How does ara::diag work in AUTOSAR Adaptive?
Answer
ara::diag provides UDS diagnostic services in the Adaptive platform. Diagnostic Servers register service handlers for UDS services (like ReadDataByIdentifier, RoutineControl). The DiagnosticServerInstance handles transport layer, session management, and security. Conversation objects manage individual tester sessions. It supports both CAN (via gateway) and DoIP transport.
52
How does AUTOSAR Adaptive integrate with Classic ECUs?
Answer
Integration occurs through gateway ECUs that translate between SOME/IP (Adaptive) and signal-based CAN/LIN (Classic) communication. The Signal-to-Service mapping translates Classic signals to Adaptive service events and vice versa. This is typically configured in the gateway ECU's Adaptive or Classic stack. Diagnostics are routed via the diagnostic gateway.
53
What is DoIP and how does it relate to Adaptive AUTOSAR?
Answer
DoIP (Diagnostics over IP, ISO 13400) is the native diagnostic transport for Adaptive ECUs. It enables diagnostic communication over Ethernet using TCP/IP. The Adaptive platform includes a DoIP entity that handles vehicle identification, routing, and diagnostic message transport. It replaces CAN-based diagnostic transport for Ethernet-connected ECUs.
54
How does Network Management work in Adaptive AUTOSAR?
Answer
ara::nm provides network management for Ethernet networks. It coordinates ECU sleep/wake states, handles network requests, and manages partial networking. NM uses SOME/IP-based NM messages for coordination. It integrates with State Management to trigger Function Group transitions based on network state changes.
55
What is the Adaptive Platform's approach to logging?
Answer
The Log and Trace functional cluster (ara::log) provides structured logging with severity levels (Fatal, Error, Warn, Info, Debug, Verbose). Logs use the DLT (Diagnostic Log and Trace) protocol for efficient binary logging and remote access. Applications create LoggingFramework instances and Logger objects. Logs can be streamed to external tools like GENIVI DLT Viewer.
56
How does time synchronization work in Adaptive AUTOSAR?
Answer
Time Synchronization (ara::tsync) provides synchronized time across ECUs using protocols like gPTP (IEEE 802.1AS) or PTP. It provides nanosecond-precision timestamps for deterministic execution and data correlation. Applications access synchronized time through the API. Time masters distribute reference time to time slaves across the Ethernet network.
57
What is the role of DDS in AUTOSAR Adaptive?
Answer
DDS (Data Distribution Service) is an alternative network binding to SOME/IP, offering pub/sub middleware with QoS (Quality of Service) policies. DDS provides automatic discovery, configurable reliability, deadline enforcement, and content filtering. It is preferred for ADAS applications requiring deterministic data delivery. AUTOSAR R22-11+ defines the DDS network binding.
58
How does AUTOSAR Adaptive support safety (ASIL)?
Answer
Adaptive supports safety through: process isolation via MMU, Platform Health Management for supervision, deterministic execution, E2E protection for communication, and safe state management. Safety-critical applications can be deployed in ASIL-rated partitions with Freedom from Interference. Safety extensions define additional requirements for ASIL-B and ASIL-D applications.
59
What are the key differences between SOME/IP and DDS?
Answer
SOME/IP is simpler, uses explicit offer/find for discovery, and is well-suited for automotive request/response patterns. DDS offers richer QoS policies (reliability, durability, deadline), content-based filtering, automatic discovery via DDS-RTPS, and scales better for many-to-many communication. SOME/IP is more common in Classic-to-Adaptive integration, while DDS suits ADAS sensor fusion.
60
How is the Adaptive Platform configured in a production environment?
Answer
Configuration is defined in ARXML manifests: Machine Manifest (platform config), Execution Manifests (per application), and Service Instance Manifests (network bindings). These are generated by AUTOSAR tools (e.g., Vector, Elektrobit) during system design and deployed alongside application binaries. Runtime configuration uses the Persistency functional cluster.
61
What C++ standards and patterns are used in Adaptive AUTOSAR?
Answer
Adaptive AUTOSAR requires C++14 minimum, with C++17 recommended. Key patterns include RAII for resource management, std::future/promise for asynchronous communication, smart pointers for memory safety, move semantics for performance, and type-safe enums. The ara::core library provides Result<T,E>, Future, Span, and other vocabulary types aligned with modern C++ best practices.
62
How does AUTOSAR Adaptive support containerization and cloud-native development?
Answer
While not natively containerized, Adaptive applications can be packaged as OCI containers for cloud-native CI/CD. The platform supports virtual ECU execution on Linux hosts for SIL testing. Software packages can include container images. Eclipse SDV and similar initiatives extend Adaptive concepts with Kubernetes-style orchestration for vehicle software deployment.