Adaptive Platform

The AUTOSAR Adaptive Platform standard specifies a runtime environment for automotive applications on µ-processor systems. 

Known as the AUTOSAR Runtime for Adaptive Applications (ARA), this environment offers standardized interfaces and services, described via the ARXML language. It defines which interfaces an application uses, how it communicates, and under what conditions it is executed. For users, this means applications can be developed independently of the AUTOSAR Classic Platform and deployed regardless of hardware or E/E architecture. 

Since most of the signals and control values in a vehicle are supplied and processed by the AUTOSAR Classic Platform, the AUTOSAR Adaptive Platform provides mechanisms (Signal-to-Service Translation) for connecting and integrating these subsystems. 

In comparison to the AUTOSAR Classic Platform, the service-oriented architecture (SoA) enables applications to dynamically discover and use platform services or establish communication channels with other applications at runtime. This modular approach supports flexible integration and reuse — key for cyber physical systems, automotive systems, and vehicles equipped with ADAS features. It forms the technological foundation for advanced driver assistance systems and future autonomous vehicles. 

Building on this flexible service-oriented design, the platform also supports the implementation of redundant backup functions. For example, a service can be mirrored to a second hardware unit that automatically takes over in case the primary instance fails. This capability is crucial for the realization of fail-operational system designs, which play a key role in supporting various levels of autonomous driving as defined by SAE International. 

Recognizing this need early on, AUTOSAR has developed a platform that not only supports dynamic communication and flexibility, but also provides the robustness necessary for future-proof vehicle architectures. In this context, features such as lane keeping assistance, automatic emergency braking, and steering wheel fallback mechanisms are enabled by real-time capable software components managing critical driving functions in vehicles equipped with ADAS features. 

The Adaptive Platform follows a middleware paradigm, decoupling applications from the infrastructure and connecting them via standardized protocols. This ensures modularity and scalability, both essential in modern automotive systems. 

A key goal was maintaining compatibility with the AUTOSAR Classic Platform. Both platforms can operate side by side, allowing existing investments to be preserved while enabling innovation through Adaptive architecture. 

With the Automotive API (since release R24-11), seamless integration with external systems like the cloud is possible. Combined with over-the-air update capabilities, this supports efficient rollout of software across distributed ECUs—enhancing real-time applications such as braking system optimization, speed limit adaptation, and responses to road users’ behavior. 

Functionally, the Adaptive Platform organizes services into functional clusters, which are located between the operating system and applications. Unlike Classic AUTOSAR’s strict layering, these clusters are logically grouped but not hierarchically stacked—offering greater flexibility for complex, connected vehicle systems. 

For performance reasons, not all functions of the clusters are implemented as standard services, but as a function library with a standardized API. Therefore, the libraries of the functional clusters are available in one instance per (virtual) machine, while services can be distributed in the vehicle network.

The functional clusters are briefly described below. Detailed information on the clusters can be found in the standard documents by clicking on the corresponding boxes in the graphic above. 

The AUTOSAR Adaptive Platform runs on a POSIX-based operating system, which standardizes interfaces for system calls, file handling, process management, and networking—ensuring portability across UNIX-like systems. Maintained by the IEEE (IEEE 1003), POSIX defines multiple profiles tailored to different environments. 

For safety-relevant, real-time embedded systems, AUTOSAR recommends the PSE51 profile, which includes essential features like POSIX Threads, priority-based scheduling, and synchronization mechanisms, while omitting complex memory management to reduce overhead. 

While Linux is a common choice, the platform also supports commercial POSIX variants—ensuring broad compatibility. This flexibility is vital for integrating the platform into cyber physical systems and ADAS-equipped vehicles, where interoperability and timing precision are crucial across the automotive industry.

The Execution Management implementation includes three main components: the ExecutionClient, the StateClient libraries, and the Execution Manager itself. 

ExecutionClient is used by applications to report a successful start (ExecutionState::Running). StateClient enables State Management to trigger Function Group transitions or retrieve errors when a group enters an undefined state. 

The Execution Manager is the first process launched by the operating system. It is responsible for starting and stopping applications—but only at the request of State Management, which handles Function Group states across the platform. 

[[In cyber physical systems, especially in vehicles equipped with real-time automation systems, Execution Management is essential for coordinating safety-critical processes that support the driving task.]] It ensures that applications are correctly launched and terminated. If a failure occurs—such as an unexpected termination—it reports the issue to State Management, which initiates recovery. Execution Manager itself does not perform these actions. 

Internal components like communication channels and serialization logic enable reliable orchestration of distributed software—for example, coordinating braking system behavior or monitoring steering wheel state as part of broader driving functions. 

The Communication Management (CM) cluster is part of the AUTOSAR Runtime for Adaptive Applications. It establishes and monitors communication paths between applications — locally and across different machines. 

CM provides the infrastructure for communication between Adaptive AUTOSAR Applications and other entities, such as Classic AUTOSAR SW-Cs. Paths can be defined at design time, initialized at startup, or dynamically created at runtime. 

The specification defines the API syntax, its relation to the system model, and behavioral semantics via state machines and pre-/postconditions. It intentionally leaves the internal software architecture open, allowing flexibility for different implementations—essential for vehicles equipped with complex automation systems and ADAS features that require high-frequency, real-time data exchange across distributed ECUs. 

In addition, raw-data streaming is possible via a dedicated interface for e.g. reading camara data.

The Diagnostic Management (DM) cluster provides a diagnostic server that supports both Unified Diagnostic Services (UDS) per ISO 14229-1 and Service Oriented Vehicle Diagnostics (SOVD) as defined by ASAM 1.0.0. UDS communication can use DoIP (ISO 13400-2) or custom transport layers, while SOVD relies on HTTP and REST services. 

From the application side, DM instantiates one diagnostic server per software cluster. Each cluster defines its own configurations for the Diagnostic Event Management (DEM) and Diagnostic Communication Management (DCM). The DCM ensures that every cluster can be addressed via its own diagnostic endpoint. 

This architecture supports scalable diagnostics in vehicles equipped with complex ADAS features and is key for maintaining safety and reliability—especially in the context of autonomous vehicles and systems adhering to guidelines set by the Society of Automotive Engineers across different levels of autonomous driving. 

AUTOSAR is designed to support software development for safety critical applications. Therefore, we are considering the following aspects: 

Development process: 

• Assurance of consistency and unambiguity of requirements,
• Considerations of code restrictions (e.g. MISRA),
• Assurance of compiler correctness (e.g. C++Institute, TÜV Süd) 

Programming principles and features: 

• traceability, repeatability, separation of concerns, encapsulation
• E2E supervision (Link), memory, and data protection (Link),
• Checksums (Link) 
• platform health monitoring (Link) 

Verification: 

AUTOSAR is maintaining an exemplary implementation of the adaptive platform. It contains also some unit- and integration tests. It is used to make sure that the specification is implementable.

AUTOSAR supports the following three basic security functions:

• Identity and access management (IAM) (Link) 
• Intrusion detection system manager (IdsM) (Link) 
• Firewall (Link) 

Further it supports means to secure communication protocols like 

• MACsec (Link) 
• IPsec (Link) 
• DDS security (Link) 
• Cryptography (see below or follow the Link) 
• Refer to the respective links for further information. 

The Cryptography Functional Cluster (FC Crypto) provides a standardized API (CryptoAPI) for cryptographic and related operations within the AUTOSAR Adaptive Platform Foundation. 

It supports both public-key and symmetric-key cryptography, offering functionality for encryption, decryption, authentication, key management, and certificate handling. FC Crypto handles the implementation, configuration, and operation brokering for these services across applications and clusters. 

These mechanisms ensure data integrity and secure communication in vehicles equipped with ADAS features and connected to cloud services—meeting cybersecurity standards aligned with the Society of Automotive Engineers.

This specification describes the functionality, API and the configuration for the AUTOSAR functional cluster Vehicle Update and Configuration Management which belongs to the AUTOSAR Adaptive Platform Services. One of the declared goals of the AUTOSAR Adaptive Platform is the ability to flexibly update the software and its configuration through local (“tester-based”) or remote (“over-the-air”) updates. V-UCM provides services for updating the software and its configuration in a vehicle. V-UCM is coordinating an update campaign within the vehicle. 

Therefore, this document includes requirements on the following functionalities: 

• Interact with Backend to: 
  • Identify Software Clusters that could be updated, installed, or removed. 
  • Authenticate Vehicle Package 
  • Confirm dependencies between Software Clusters within vehicle before starting campaign. 
  • Inform Backend of needed Software Packages, receives them and dispatch them to targeted ECUs. 
• Interact with Vehicle State Manager: 
  • Inform which safety conditions that need to be applied according to Vehicle Package. 
  • Share the computed vehicle state to other Applications or Functional Clusters involved in the update campaign. 
• Interact with Human Driver about update campaign: 
  • Provides campaign state to trigger interaction with Human during update campaign. 
  • Get vehicle modification approval or consent from Human when configured in Vehicle Package. 
• Provide information of installed software in vehicle. 
• Provide information of update campaigns history. 
• Recovery in case of failure. 

The Persistency Functional Cluster provides Adaptive Applications and other clusters with standardized access to non-volatile memory, ensuring data is retained across boot and ignition cycles. Typically implemented as a library running within an Adaptive Application process, Persistency allows storing critical runtime data—essential for consistent behavior in vehicles equipped with AD/ADAS systems. 

In this context, applications and functional clusters using Persistency are referred to as “Persistency users.” For simplicity, daemon-based implementations are also treated as Adaptive Applications.

The Adaptive Applications (AA), or just Applications run on top of ARA, AUTOSAR Runtime for Adaptive applications. ARA consists of application interfaces provided by the Functional Clusters (FCs) which belong to either Adaptive Platform Foundation, Adaptive Platform Services, Standard Application-Interfaces or Vehicle Services. 

The AUTOSAR Adaptive Platform is designed to support Applications which require:   

• highly complex and computing resource demanding software, 
• strict integrity and security requirements, 
• integration of the vehicle into external backend and infrastructure systems, 
• higher bandwidth and with switched networks, transfer of long messages, point-to-point communications, and the like as well as 
• tremendously grown processor performance. 

To tackle them, the AUTOSAR Adaptive Platform employs various proven technologies traditionally not fully exploited by ECUs, while allowing maximum freedom in the AP implementation to leverage the innovative technologies.  

For more information, please refer to the Platform Design Document for the AUTOSAR Adaptive 

Contains the following information: 

• Become a partner to actively co-develop the Adaptive Platform 
• Have implementation demonstrated 
• Implement contact options