1 Introduction
Modern ECUs contain highly modular embedded software that can consist of untrusted and trusted software components that perform functions at different ASIL levels. In this case we have two different approaches
-
The entire software must be developed in accordance with the highest ASIL.
-
Keep software components with different ASIL levels and ensure that components with higher ASIL levels do not interfere with elements with lower ASIL levels FFI. (Common method) A system often needs to implement multiple functional safety requirements with different ASIL levels at the same time. When these requirements are allocated to software modules, different modules need to meet different ASIL levels, as shown in the figure below.
2 time monitoring
Timing is an important property of embedded systems. Safe behavior requires that the actions and reactions of the system be performed in the correct time. Correct timing can be described by a set of timing constraints that must be satisfied. However, AUTOSAR software components themselves cannot ensure correct timing. It should be ensured somehow, but another independent component is AUTOSAR WdgM. The watchdog manager (WDGM) is located in the service layer of the AUTOSAR stack, as shown in the figure, the watchdog service is distributed in the AUTOSAR layer. It basically includes:
Watchdog Manager (Service Layer) Watchdog Interface (ECU Abstraction Layer) Watchdog Driver (MCAL Layer)
The task of the watchdog manager is to supervise the execution of the software, and if an error or defect in the execution of the software is found, WDGM will take action. SWC uses services provided by WDGM, using a client-server interface. SWC is the client, WDGM is the server
Timed protection and monitoring can be described as monitoring the following properties:
-
Monitoring tasks are scheduled at specified times.
-
consume their execution time budget.
-
Do not monopolize operating system resources. (e.g. heavy CPU load, high interrupt requests) The following timing- and execution-related faults can be considered as causes of interference between software components:
-
execution blocking
-
deadlock
-
livelock
-
Execution time allocated incorrectly
-
Incorrect synchronization between software elements.
-
The execution flow is incorrect. ISO 26262 introduces some software safety mechanisms for error detection. It identifies liveness and deadline supervision as a safety mechanism for temporary protection. And also controls flow monitoring as a mechanism for erroneous execution flows. AUTOSAR provides a convenient solution to implement these mechanisms/services, which is the watchdog manager WdgM.
The main purpose of WdgM is to provide a mechanism to verify the execution and timing constraints of the SWC. Its purpose is to monitor the reliability of application execution considering periodicity and periodic maximum timing constraints.
In order to build generic and extensible modules that can provide all these services, AUTOSAR introduces a new schema to generalize the functionality of WdgM. It declares any named software entity of interest that you want to monitor as a "Regulated Entity SE". The monitoring of SE is by placing some point "API/RTE calls" inside SE to verify whether the target event (scheduling, completion, etc.) has occurred, these points are called checkpoints.
WdgM provides three types of supervision to cover the above services, as shown in the figure. Each SE has its own unique identifier and local state. The whole WdgM has an overall state, called the global state, and according to the supervision type, SE configuration, those local states will affect the global state, which will be described later.
WdgM will take an array of structures containing all SEs and their configurations, perform the required monitoring based on these configurations, and WdgM will update its local state accordingly.
Local state will not cause a reset until WdgM decides to update its global state to stop, which will establish a separate state machine depending on the type of supervision. The figure below contains a flowchart for monitoring and evaluating real-time supervised SE.
