Application of ZC.MuNiu WdgM in Functional Safety
Application of ZC.MuNiu WdgM in Functional Safety
Watchdog, the Chinese name for the watchdog, is to realize the unattended equipment in the case of system anomalies can automatically complete the system reset operation to ensure that the entire function of the continued use.
Why is the watchdog necessary? The reason is that the software running in the hardware world will be affected by a variety of external factors, such as: many parts and components used in the car, in view of the harsh environment of the car, all types of ECU software may be subjected to such as external electromagnetic interference, high temperature and other environmental factors, which leads to the program “fly” or “dead” phenomenon, at this time, if the existence of the watchdog can actively trigger the system reset mechanism to ensure that it can be used normally again, rather than just watch being watched. “crash” phenomenon, at this time if the existence of the watchdog, you can take the initiative to trigger the system reset mechanism to ensure that it can be used normally again.
Translated with DeepL.com (free version)
Watchdog in use when the software must be in the specified time interval to send a specific signal, this behavior is figuratively known as “feed the dog”, so as to avoid watchdog timeout triggered by the system reboot. Hardware watchdog is generally a specialized chip, which monitors the circuit voltage and current and other indicators to determine whether the system is operating normally. In the following figure is a NXP SBC chip, the chip provides the watchdog function, when using the MCU through the SPI watchdog initialization and feed the dog operation:
In automotive electronic systems, the core objective of Functional Safety is to prevent personal injury or property damage due to electrical and electronic system failures through systematic design and safety mechanisms. WdgM (Watchdog Manager), as a key safety module in the AUTOSAR standard, is designed in strict compliance with the ISO 26262 standard and meets the requirements of different ASIL (Automotive Safety Integrity Level) through multi-layered monitoring, fault tolerance and recovery mechanisms. The WdgM (Watchdog Manager), as a key safety module in the AUTOSAR standard, is designed in strict compliance with ISO 26262 and meets the requirements of different ASIL (Automotive Safety Integrity Level) through multi-level monitoring, fault tolerance and recovery mechanisms.
The main parts of WdgM are the Supervised Entity (SE) and CheckPoint (CP).
l SE: Each SE can have three forms of supervision: Alive, deadline, and Logical [Logical Supervision is divided into two types, program flow supervision within the same SE and program flow supervision within different SEs]. A SE can be an algorithm, a function, a task.
l Check Point : Used as a way to differentiate between different monitoring methods and can belong to one or more of the following types of monitoring methods.
Program Flow Monitoring: The external watchdog implements the WdgM module's Alive Supervision monitoring mechanism to monitor periodic Tasks; the WdgM module calculates the number of checkpoints that occur while the program is running and compares it with the expected value (configuration information), if it is out of tolerance, it is considered as a violation of the program flow, and will be recorded as a Checkpoint Fault by the WdgM module. The WdgM module records this as a checkpoint fault.
AEB模块Task的Alive Supervision举例:
Example of Alive Supervision for the AEB module Task:
The call cycle of WdgM is 20ms and the cycle of AEB module Task is 25ms, as shown in Figure 6.21, the monitoring cycle is configured to be 100ms, i.e., the number of CheckPoint arrivals in the interval of 5 WdgM_MainFunction is 3-5 as normal. If the number of occurrences is not between 3-5, the WdgM module will consider that the cycle of AEB module Task is detected abnormally, and at the same time, it will transmit the request of not feeding the dog to the PMIC module through the dog feeder data stream shown in Fig. 6.20, and the PMIC module will stop feeding the dog, wait for the timeout of watchdog dog feeder (timeout time of 64ms*3), and then trigger the reset.
Deadline Supervision is concerned with how long a program is running, whether it is too long or too short indicates that the program is executing abnormally. The abstraction is to monitor the running time between two Check Points. The algorithm is as follows: Configure the Start Check Point, End Check Point, Minimum Time Threshold and Maximum Time Threshold of Deadline Supervision in WdgM. Start Deadline Supervision at the Start Check Point, get the system time, and at the End Check Point, get the system time, and calculate whether the runtime is within the reasonable range.
Note: Two CPs belong to the same SE and two CPs cannot be the same.
Logical Supervision is mainly used to monitor whether the running order of the application is correct or not, including the checking of the local running paths of each SE, and the checking of the global paths between SEs.
Let's say the program runs in the order: 1 -> 2 -> 3 -> 4. When the program reaches 1, it checks to see if it is the first point it should run to, and when it reaches 2, it checks to see if the previous check point reached is 1. In turn, the program checks to see if the actual running order between the two neighboring points matches the running order between the configurations. When the program is run in the order of 1 -> 2 -> 4, a program error is checked at run 4, and the SE status of the Logical Supervison is changed.
ZC MuNiu configuration tool is based on the latest ARTOP architecture, supports the latest AUTOSAR R21-11 standard provided by the basic platform, according to the ECU configuration steps defined in the AUTOSAR development methodology, realizes the ECU configuration from the configuration, validation to the code generation of the whole process of the function. The main advantages can be summarized in the following aspects: the realization of the whole process of configuration, verification and code generation has completely realized the development requirements of the ECU configuration stage in the AUTOSAR development methodology.
The following will briefly describe the process of WdgM module configuration using ZC MuNiu:
You can add monitoring instances related to Alive monitoring through the WdgMMode interface.
Multiple SE punch points can be added under the corresponding monitoring instance configuration page.
In addition, you can set the execution order of punch points in the WdgMInternalTransition page as a way to implement the logic monitoring function.
Under the WdgMAliveSupervision0 page, you can configure the relevant parameters needed for Alive monitoring, such as the monitoring period, the limit of the number of punches that can be tolerated, the monitoring target, and so on.
WdgM related configuration code can be generated after all functions are configured.
The ZC MuNiu configuration tool provides a user-friendly HMI for ECU controller software development. It supports the configuration of standard AUTOSAR basic software code modules as well as the development of configuration interfaces for complex drivers. Currently, it is mainly used in the following scenarios:
Ø ZC MuNiu Basic Software Platform Standard AUTOSAR Module Configuration
Ø ZC MuNiu Basic Software Platform Complex Driver Module Configuration
u SAFETY FRAME
u CRYPTO LIBRARY
u BCCIC
u SBC
Ø Collaboration with chip companies to provide configuration tools for MCU MCALs