MICROSAR Adaptive Clusters

Communication Management: provides service-oriented communication (SOC) between applications or components of the MICROSAR Adaptive platform via an abstract C++ API that uses communication protocols such as SOME/IP (Scalable Service-Oriented Middleware over IP), IPC (Inter-Process Communication) or ZC (Zero-Copy).

Diagnostic requests are handled by the Diagnostic Manager (DM) which is an equivalent of the DCM and DEM from the Classic platform. The DM is responsible for all aspects related to diagnostic functionality and provides a self-contained Adaptive Platform Application.

Execution Management: is primarily responsible for starting and stopping Adaptive applications. It is the first process to be started (init) and controls the other processes according to the requested state of the machine. To do this, it works with the operating system (OS) to perform application runtime scheduling.

Measurement & Calibration: provides interfaces for applications to forward logging information to the communication bus, console, or file system. It is used to configure application-wide default log settings and process log messages.

Multi-Purpose Components: provides components for data transfer and decompression.

Network Management: implements the algorithm of the AUTOSAR NM protocol specification and decentrally synchronizes the communication states of all nodes in a network (based on UDP over Ethernet). A user-supplied adaptive application is recommended to interact with the NM, coordinate network requests and releases from other ECU applications, and request networks on the NM interface accordingly.

Operating System: contains Application Layer (OsAl) which provide a common API for the portability of software on higher architectural layers. MICROSAR Adaptive does not contain any hardware-dependent components or drivers, as the hardware dependency is mainly covered by the respective Operating System. Operating Systems have differences in their API and available feature set. All components above the OS layer are using OsAl for OS interaction and are therefore OS independent.

Persistency: is a library-based implementation and offers mechanisms to Adaptive applications to store information persistently in the non-volatile memory. The API specification includes key-value storage as well as plain file access.

Platform Health Management: supervises dedicated Adaptive applications and provides an interface to report Checkpoints of Supervised Entities and Health Statuses of Health Channels. In case of detected failures, the PHM notifies the State Management via Recovery Notifications. PHM monitoring is particularly relevant for functional safety.

Security and Cryptography: provides security functionality that can be used to support security use-case and achieve compliance to cybersecurity regulations. The functionality includes cryptographic operations, certificate management, access control, and intrusion detection.

State Management: provides several building blocks on a higher abstraction to help the integrator build his own State Management. It acts between the Platform APIs and the User Application with Core and Function Group Control functionality on QM level.

Time Synchronization: provides synchronized time for the Adaptive applications within and between the ECUs. It is responsible for managing the time bases and for communication with off-board timesync masters and slaves.

Update and Configuration Management: is responsible for reporting of installed software clusters and apply changes to the installed software clusters by processing software packages. Software clusters are logical entities that correspond to, for example, Adaptive applications, the Adaptive Platform, or the OS itself.