MCUs enable automotive functional safety compliance

　　Functional safety requirements

　　Functional safety is concerned with minimizing the hazards caused by system failures. System failures can be caused by hardware/software errors and can be permanent or transient. The following describes the possible reactions when an error occurs:

　　● Failure-hazardous: may be dangerous when a failure occurs;
　　● Failure-inconsistent: the results provided when a failure occurs may be obviously inconsistent;
　　● Failure-stop: completely stop operation when a failure occurs;
　　● Failure-safe: return to or remain in a safe state when a failure occurs;
　　● Failure-operable: continue to work normally when a failure occurs;
　　● Failure-silent: do not disturb anyone when a failure occurs;
　　● Failure-indicate: indicate to the environment that a failure has occurred.

　　Implementing functional safety in a system usually means mapping faults to expected reactions that can be handled by the entire system or opportunistically, thus ensuring that hazards caused by system failures are minimized.

　　The next section discusses the various functional safety implementations of Freescale SoCs that perform such mapping in the event of a system failure.

　　Key functional safety features provided by Freescale MCU designs

　　Now let’s take a closer look at the key safety features of Freescale devices targeted at automotive safety applications.

　　Core lockstep

　　Ensuring that the cores in an SoC are able to operate safely is one of the main requirements for functional safety, as almost all operations are centered around them. In the Qorivva microcontroller MPC574x, safe operation is achieved by using a check core that runs in lockstep with the main core. This means that the check core executes the same instructions as the main core, and the address and data buses of the cores are compared in the check unit to detect operational deviations. Detected errors are reported to the Error Collection and Response module (see below). Due to the lockstep, from the software point of view, the two cores operate as a single core, reducing software implementation. See the block diagram shown in Figure 1 below.　　

 

　　In addition to the core, other safety-related blocks such as eDMA, interrupt controllers, caches, etc. can be replicated in the system. All such replications must be physically separated on the chip so that a common common fault (CCF) does not affect the operation of both instances.

　　End-to-end ECC (E2EECC) protection provided in memory

　　All memory storage operations are protected by ECC (Error Correction Code) and SECDED (Single and Double Error Correction) implemented with a Hamming distance of 4. ECC is implemented on the data and address signals and stored in the memory with the data during a write operation. When a read operation is initiated, the ECC is recalculated on the retrieved data and the requested address and verified with the stored ECC.

　　In Qorivva MPC574x devices, there is no ECC for memory only, but it provides E2EECC, which detects data corruption on all data paths between bus masters and bus clients, providing at least 99% coverage. The mechanism is shown below.

　　1) Data from the master device is encoded using the ECC-SECDED code. The data encoding includes addressing information overlay.

　　2) Each module of the path includes local mechanisms, such as ensuring correct transmission of control data and correct address decoding.

　　The above method ensures that there is no data corruption on the data path. The ECC provided by the master is then used for both RAM and flash, so no additional ECC calculation is required for the memory, and the ECC is passed from one end (bus master) to the other end (memory).

Reference address of this article: http://www.eepw.com.cn/article/143322.htm

　　There is a central memory error management unit in the system, which is responsible for collecting and reporting error events related to the ECC logic used on SRAM, peripheral system RAM and flash memory. Whenever a correctable (single bit) or uncorrectable (multi-bit) error occurs, the MEMU receives an error signal, then records the error address, sets the corresponding error flag and reports it to the FCCU. It can be used when a special correction number is required or when further analyzing such errors in software.

　　Fault Collection and Control Unit (FCCU)

　　The FCCU is a programmable unit that monitors the integrity status of the MCU, provides flexible safety status control, and puts the device in a safe state in a controllable manner when a device fails. The collection and control operations do not require CPU intervention. The FCCU simple block diagram is shown in Figure 2.　　

 

　　The FCCU provides a finite state machine that moves from one state to another based on the errors that occur in the system and the actions/inactions taken on these errors. Depending on the fault configuration, the FCCU may trigger a reset, masked/non-masked interrupt, external fault indication, or no reaction. The SoC also provides two external indication pins (EOUT0/1) that can communicate with the external environment about the faults that occurred in the system and follow various static or switching protocols.

　　Self-test control unit

　　This is a self-diagnostic measure for the device that runs at startup/shutdown to ensure that the device does not have a delay/sleep failure that would corrupt its operation while the application is running. Typically, the self-test is performed on the embedded memory (called MBIST) based on the digital logic (called LBIST) with sufficient coverage to meet the required system safety integrity level (SIL).

　　1. After an STCU reset event, the SSCM detects that the device self-test has not been run.
　　2. The SSCM reads the self-test parameters from the non-volatile flash memory (NVM).
　　3. The SSCM loads the self-test parameters into the STCU and transfers control to the STCU.
　　4. The STCU manages the MBIST and updates its internal state.
　　5. The STCU manages the LBIST and updates its internal state (there may be other LBISTs and MBISTs executed sequentially or in parallel).
　　6. If a failure is detected, the STCU reports the test failure to the FCCU or resets the device.
　　7. After completing the self-test, the STCU signals the reset module and the boot sequence advances to the next stage. [page]　　

 

　　Clock monitoring and auxiliary clocks

　　In order to detect failures of the internal and external clock circuits during safe operation, the main clock is monitored (see below) based on an auxiliary clock. This auxiliary clock is provided by the internal RC oscillator and is available whenever the device is reset. With the auxiliary clock, even if the internal PLL fails for some reason, the system is guaranteed to have a clock to run many safety mechanisms to ensure continued operation. This IRC oscillator can be fine-tuned to keep the clock consistent under different PVT (process, voltage and temperature).

　　Clock Monitoring Unit

　　The CMU is a module that monitors the system PLL output frequency and will indicate a fault, reset, or interrupt if a clock loss occurs or the monitored clock exceeds the low or high frequency boundary. The CMU monitors the clock using the auxiliary clock (see above) as a reference and monitors the auxiliary clock based on an external crystal oscillator. A simplified block diagram of the CMU is shown in Figure 4.

 

　　As shown in Figure 4, if an oscillator clock loss event or a low frequency/high frequency event on the monitored clock occurs, the CMU provides signals to the reset and FCCU modules. The reset module path is activated only if the FCCU does not respond for a period of time. Therefore, the reset and FCCU signal paths form redundant fault indication paths within the MCU to ensure that a failure of the FCCU does not prevent all fault reports. The configuration of the FCCU module determines whether an event will cause an interrupt or a reset.

Reference address of this article: http://www.eepw.com.cn/article/143322.htm

　　Power Management Controller

　　The PMC provided by Qorivva MCUs employs voltage monitoring circuits and BIST. There are two voltage supervisors, low voltage detection (LVD) and high voltage detection (HVD) supervisors. All safety-related voltages are internally monitored to prevent voltages from exceeding these ranges.

　　The BIST implemented in the PMC detects critical bandgap voltage/other functions in the PMC at boot-up or through software.

　　Since a safety-related voltage fault may cause the MCU fault indication mechanism (e.g. FCCU and error output board) to shut down before reacting, its voltage error indication will directly cause the device to jump to the fail-safe state (perform a reset) without the need for FCCU intervention.　　

 

　　Freescale SafeAssure Program

　　Freescale's SafeAssure functional safety program is designed to help system manufacturers more easily comply with the International Standards Organization (ISO) 26262 and International Electrotechnical Commission (IEC) 61508 functional safety standards. The program emphasizes Freescale solutions (hardware and software) that optimize designs to support functional safety implementations while integrating rich support. Freescale's solutions include four areas of support that enable customers to significantly reduce product launch cycles. These four areas are shown below.

　　1) Safe Hardware: The various major functional safety features implemented in hardware as discussed in the above sections are a major element of the SafeAssure program.
　　2) Safety Support: This section ensures full documentation support including safety application notes, safety manuals and FMEA/FMEDA analysis for the product. In addition to providing support, Freescale also provides an option for system developers to work closely with regional safety experts to accelerate their development efforts.
　　3) Safety Software: Software support for safety products includes driver development, porting of operating systems and self-test software to ensure the proper functioning of the device throughout its lifecycle.
　　4) Safety Process: The subsequent processes within Freescale ensure safety compliance from requirements management to design implementation, as well as functional coverage during the verification/validation/production phases. This is achieved by maintaining a comprehensive traceability matrix and constitutes the fourth element of the “SafeAssure” program.

　　These four aspects are critical for system developers to ensure smooth product functional safety compliance certification.

　　Summarize

　　Implementing functional safety features in devices requires redundancy in the MCU, which may increase power consumption and chip size. However, if connected with a powerful hardware system (the MCU can provide fail-safe, fail-silent or fail-indicating status), the benefits are numerous, especially in reducing software complexity. This article discusses the various safety designs implemented in Freescale's Qorivva MCU. Implementing these safety features in the device is one of the four elements of Freescale's SafeAssure program, enabling customers' applications to comply with ASIL/SILx.