6. Safe Service oriented Communication
HAD use cases demand dynamic upgrade of software applications throughout the entire vehicle lifecycle and to subsequently add new software functions, for instance via over-the-air software updates. Applications may be developed and tested independent of each other in distributed working groups and then integrated into the overall system at any time. Using Service-oriented communication between the software applications makes this possible.
Service-Oriented Communication (SoC) is the main communication pattern for AA Applications. The concept of service-oriented communication is based on the idea that there are applications that provide a service on the communication system and other applications subscribe to this service. The data will only be sent to the subscribers.
Here is a picture from Autosar Spec on Communication Management that describes SoC is an over-simplified way.
“Communication Management” functional cluster in AA implements SoC. In order to detect failures in communication such as loss, delay or repetition of events, it implements End-to-End (E2E) protection in the events. It uses the E2E library in the Autosar platform to protect the events with a counter and checksum.
In order to have Adaptive Autosar Applications communicate with Classic Autosar applications, the AA platform also provides S2S (Signal to service) mapping that translates the signal based communication to services, though it is not clear if E2E is covered in the scope of this service.
7. Platform health Management (PHM)
Equivalent to the Watchdog Manager in CA, PHM offers safe execution of safety processes in the AA platform. PHM implements safety mechanisms for achieving freedom from interference for timing and executions. It offers features such as:
- Monitoring of the execution frequency of safety applications and services
- Monitoring of the control flow of safety applications and services
- Deadline Monitoring in safety applications and service
Additionally, PHM also implements the monitoring of the foundational functionality components in AA – The State Management and Execution Management. If the state management or execution management fails, PHM triggers a watchdog reset.
8. Safe State Management
State Management, as the name implies, is the functionality of managing the states of operation of the AA platform. It handles the state transitions between various states of the system such as startup, shutdown, diagnostic states, safety safe states, software update states, network management states etc.
The Adaptive platform states that SM has be implemented in compliance to the highest ASIL level of the applications that it is managing. For e.g., if the system has an ASIL A, QM and ASIL D process, then SM must be implemented as ASIL D. Why is this so?
- The State transitions carried out by SM influence the Application processes and several other Platform components. An incorrect state transition performed by SM can cascade to these processes and put them in a wrong state. For e.g., if a software update is ongoing, SM must maintain the right state such that it prevents the system from shutting down during the update.
- SM is responsible for the safe state action if the Platform health management (PHM) detects a failed execution. For e.g., it decides whether the system must be reset, or any application should be notified or any state change must be carried out as safe state action.
9. Time synchronization
Time Synchronization is an extremely important aspect in HAD use cases. For e.g., if a camera provides a front view of the car at time 12.00.05pm, this must reach the path perception applications immediately with this timestamp so that the system can judge that it is the real time information for that time and then decide how to navigate the car. If the camera data reaches the application 10seconds later, then the latter is able to judge that the data is old and accordingly trigger the system to a safe state, for e.g., to stop the car.
Time synchronization is required to correlate different events and to track such events in time or to trigger them at an accurate point in time. Due to the paramount importance of real time information in the context of safe movement of the car, “time synchronization” functional cluster must be implemented at the highest ASIL level of that system.
Time Synchronization functional cluster within the Adaptive Platform is responsible to provide various Time Bases (such as GPS based time, relative time based on Operating hours of the vehicle etc) for the application to read from or to write to.
10. PSE51 compliant OS
Adaptive Platform does not define a new Operating System for AA ECUs. Instead, it leverages the existing POSIX standard to define an OS API standard for Applications.
Any POSIX based Operating system such as Linux or QNX can be used to run Adaptive applications. However, the only pre-requisite is that the OS must provide PSE51 APIs. PSE51 is a specific profile of POSIX that is mainly intended for real time systems. Though the OS itself can be PSE54 compliant, but the only restriction is that applications that run on AA can use only PSE51 APIs.
The OS API (OSI) is part of the AUTOSAR Runtime for Adaptive Applications (ARA) and supports APIs in both C and C++.
AA specifies that the OS shall provide mechanisms to ensure freedom from interference with respect to memory and timing, such as:
- Prevent starvation of ASIL processes
- Ensuring a minimum availability of resources for safety processes
- Spatial isolation of processes so that a QM process does not access the private memory of an ASIL process
- Support System memory budgeting and CPU time budgeting
11. Safe persistent data
Safety critical applications may need to store critical configurations in persistent memory. In order to detect corruption of such data, integrity information such as CRC must be stored along with the data. The Integrity of the data must be verified before an Application uses the data for making crucial decisions. The “Persistency” functional cluster takes the responsibility of ensuring and verifying the integrity of safety-relevant persistent data.