Monitoring Mechanisms for Functional Safety

Overview

Since test drives required to validate safety-critical functions, especially for driver assistance and autonomous driving, are increasingly carried out with prototype vehicles and in real road traffic, a mature and comprehensive safety concept is crucial so the system can respond immediately and correctly in the event of a fault. To achieve a higher level of monitoring even in early function development phases, all MicroAutoBox III variants provide several monitoring functions in the area of functional safety (FuSa).

To simplify the use of the MicroAutoBox III in these scenarios, the system offers a three-layer functional safety concept based on the EGAS safety concept established in the automotive industry.

1. Function Level

This layer executes the application functionality, such as the control algorithms and the I/O functionality. Layer 1 corresponds to a real-time application without FuSa functionality.

2. Function Monitoring Level

This layer executes safety functions that monitor the functionality of layer 1. You implement the safety functions on the real-time application, such as plausibility checks of the input signals.

3. Controller Monitoring Level

This layer monitors the hardware that executes the functions of layers 1 and 2. The safety functions of layer 3 are less application-specific and are automatically activated when a real-time application uses the FuSa functionality. Furthermore, a background process automatically monitors the FuSa functionality itself. If a safety function detects a FuSa error, it triggers the MicroAutoBox III FuSa unit, which responds to a detected FuSa error and reports it.

The MicroAutoBox III provides monitoring functions, such as memory checks and challenge-response monitors, that detect faults and bring the system into a defined state, which facilitates integration into the overall safety concept of the vehicle. 

Multistage Watchdog Mechanism

The multistage watchdog mechanism consists of an FPGA-based hardware watchdog and configurable software watchdogs that are executed on the real-time processor. They constantly monitor the real-time processor and the correct execution of the real-time application. Each watchdog´s time-out behavior can be configured individually in order to make sure that a task or subsystem is periodically executed within a given timing constraint.

Furthermore, a separate hardware watchdog consisting of a safety CPLD (complex programmable logic device) is integrated. It has an independent power supply and clock. In case of failure, the CPLD ensures that the MicroAutoBox III transitions to a safe state. The device persistenly records information on any failure occurrence.

Any FuSa error detected by the system is reported to the host PC. This information is also available on the web interface on the MicroAutoBox III.

If a FuSa error occurs, the FuSa unit can also respond by opening a relay or lighting a FuSa LED. Opening a relay lets the MicroAutoBox III take action, such as activating a backup ECU, the FuSa LED simply indicates a FuSa fault without initiating further measures. 

Challenge-Response Monitoring

Challenge-response monitoring is implemented on the safety CPLD, which is independent of the real-time processor. This ensures that failures are detected even if the real-time processor has stopped working correctly. In comparison to the watchdog feature, it not only checks if a subsystem responds within a certain time frame, but it also checks whether the calculations of the real-time processor are still executed correctly. The challenge-response monitoring mechanism lets you implement more complex monitoring features, e.g., for supervising the execution order. Individual verification routines including C code and/or S-functions can also be implemented. You can use up to 15 instances of challenge-response monitors with up to 16 challenge-response values each at the same time. Moreover, implicit reverse monitoring is implemented to periodically check whether the monitoring features are still working correctly.

The response triggering mechanism works as a user-configurable software monitor that allows functional safety errors to be triggered directly from within the behavior model. This way, you can easily perform plausibility checks, e.g., on I/O signals, and set an error flag accordingly. Depending on the configuration, the response to such an error can be a simple FuSa log entry, an I/O trigger, or even a shutdown of the whole system.

It is even possible to define delay times between the detection of an error and the triggering of the error response to ensure the system reaches a safe state. 

Memory Integrity Checks

To detect hardware failures or critical bit errors, the MicroAutoBox III executes different memory integrity checks. The initial ROM check mechanism detects memory faults during the start of the real-time application. If a failure is detected, MicroAutoBox III does not execute the program, but instead aborts the start of the real-time application to reach a defined system state. The heap and stack monitoring mechanisms detect memory faults while the real-time application is running. The mechanisms ensure that the heap and stack memory sections are still valid and not overwritten without permission. In addition, single-bit errors that occur while the real-time application is running can be corrected by the ECC RAM. All run-time monitoring mechanisms execute dedicated fault responses (restart, shutdown, interrupt) to set the system to a defined state if a fault is detected.

Supply Voltage Monitoring

To detect critical power supply voltage levels of the MicroAutoBox III, a supply voltage monitoring mechanism is available. This way, the system can intervene before a critical supply voltage level is reached. You can configure the threshold value to easily adapt the supply voltage monitoring mechanism to different vehicle electrical systems and other systems that are used together with the MicroAutoBox III.