Safety Mechanisms of MicroAutoBox II
Safety-critical prototyping applications, e.g., for highly automated driving, require additional mechanisms that monitor the correct execution of control functions on an ECU. To reach a higher level of monitoring even in early function development phases, all MicroAutoBox II variants, despite being prototyping systems, provide several monitoring functions that are common in series production. These consist of a multistage watchdog and an integrated challenge-response mechanism, various memory integrity checks as well as supply voltage monitoring.
If one of the mechanisms detects a malfunction, a defined system state is reached by shutting down or restarting the system. Additionally, user-defined software routines can be triggered by non-maskable interrupts to save the last parameter set or to record the cause of the malfunction, for example.
The mechanisms can be easily programmed and integrated into Simulink® controller models via the RTI Watchdog Blockset by simply dragging them from the blockset library to a Simulink diagram.
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 in Simulink is periodically executed within a given timing constraint.
The challenge-response monitoring is implemented on a separate hardware component of MicroAutoBox II and is independent of the real-time processor. This ensures that failures are detected even if the real-time processor is no longer working correctly. In comparison to the watchdog feature, it not only checks if a subsystem responds in a certain time but it also checks if the calculations of the real-time processor are still executed correctly. To achieve a higher degree of coverage, the challenge-response monitoring lets you implement more complex monitoring features, e.g., for controlling the execution order. Individual verification routines including C code and/or S-functions can also be implemented. Up to 14 instances of the challenge-response monitoring with up to 16 challenge/response values can be used at the same time. Moreover, an implicit reverse monitoring is implemented to check periodically if the monitoring features are still working correctly.
To detect hardware failures or critical bit errors, different memory integrity checks are available for MicroAutoBox II. The initial ROM check mechanism detects memory faults during the start of the real-time application. If a failure is detected, MicroAutoBox II does not execute the program, but instead aborts the start of the real-time application to reach a defined system state. The heap, stack and ROM monitoring mechanisms detect memory faults during the run time of the real-time application. The mechanisms ensure that the heap and stack memory sections are still valid and not overwritten without permission. In addition, run-time bit errors can be detected with the ROM monitoring mechanism. All run-time monitoring mechanisms execute dedicated failure reactions (restart, shutdown, interrupt) to set the system to a defined state if a failure is detected.
To detect critical power supply voltage levels of MicroAutoBox II, a supply voltage monitoring mechanism is also 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 MicroAutoBox II.
Drive innovation forward. Always on the pulse of technology development.
Subscribe to our expert knowledge. Learn from our successful project examples. Keep up to date on simulation and validation. Subscribe to/manage dSPACE direct and aerospace & defense now.