FMEDA Fault Injection Validation of SPI Safety Architecture

In recent years, the integration of advanced technologies in electric vehicles (EVs) has been increasing, making it crucial to assess the risks associated with the deployed technologies. Functional safety is necessary for automobiles to ensure human life safety. The Battery Management System (BMS) chip is one of the important components in electric vehicles, using the Serial Peripheral Interface (SPI) to communicate with external ICs to monitor the battery status used in electric vehicles. To obtain functional safety certification for the chip, each module on the chip should have a safety architecture around it and should undergo functional safety validation. This paper performs fault injection based on Failure Mode Effects and Diagnostic Analysis (FMEDA) to validate the SPI safety architecture recommended by ISO 26262. For single point failures in the SPI block, the diagnostic coverage reaches 97.2%, which is sufficient to achieve a single point fault metric (SPFM) of 99% for the entire chip.

As advanced electronic technologies push the automotive industry to new heights, Original Equipment Manufacturers (OEMs) need certified semiconductors for safety. The automation of E/E systems in vehicles is evolving into a complex process, aiming to provide many advanced functions such as electric power steering, ADAS, braking systems, airbags, etc., all of which require safety assurances. As these cutting-edge technologies are integrated into vehicles, manufacturers now need to assess and examine the risks associated with the technologies they wish to use. Functional safety is necessary for automobiles to ensure human life safety. Functional safety (FuSa) refers to the ability of the entire system to continue to operate reliably as intended, even in the event of accidental occurrences. Furthermore, the system ensures that there are no unacceptable risks of personal injury or damage. The functionality of modern vehicles is made possible by the extensive use of electronic products. This has led to a demand for FuSa semiconductor chips in the automotive industry. For System-on-Chips (SoCs), especially as sub-micron designs are entered, sensitivity becomes greater. High levels of safety can make the product stand out and change consumer perceptions.

The BMS is one such SoC used in electric vehicles and must meet functional safety standards. The BMS can control the rechargeable battery environment, protect the battery from exceeding its safe operating parameters, monitor battery conditions, report derived auxiliary data, balance, and verify the battery’s electronic systems. Considering scenarios where some BMS chips do not have the capability to measure current, external ICs that measure current attempt to send current data that needs to be fed to the BMS chip, or monitor battery voltage. To send and/or receive information to each other, these ICs must be able to communicate with each other. Therefore, the communication protocol is crucial for a BMS with multiple ICs to communicate with each other. SPI is a protocol that provides an easy-to-implement and low-cost interface between microcontrollers and their peripherals. The SPI protocol uses a serial clock generated by the master device to synchronize the transmission and reception between the master device and the slave device. One device is regarded as the master device of the bus (in this case, the BMS is the master device), while all other devices (peripheral ICs and even other microcontrollers) are regarded as slave devices.

ISO 26262 requires the calculation of the hazard rate caused by random hardware failures. During the product development phase, hardware and software development essentially attempts to analyze the BMS at the system level first, then at the component level, deriving safety requirements from the functional safety concept, developing the system architecture, and defining safety mechanisms for failure detection and avoidance. FMEDA can identify potential failure modes and the impacts of these failures at multiple system levels, which is often the first step in understanding system safety. Failure is the starting point for analysis, which may later lead to errors and failures. To ensure ISO 26262 safety requirements, safety mechanisms are designed for each function in the BMS. SPI is a peripheral in the BMS, and a safety architecture is designed around it, with safety mechanisms for every failure mode in the functionality. Any safety architecture designed to meet the highest safety standards for various purposes in the automotive industry should be verified using fault injection. By introducing faults into the design and monitoring its response to the faults, fault injection techniques can be used to evaluate the reliability of the design under test. Digital fault injection runs on RTL/GLS (netlist), injecting faults at the input/output ports and internal nodes of each block during top-level verification. Then it checks whether the injected faults can be detected by the safety mechanisms. Diagnostic coverage (DC) is a benchmark for safety measures that detect hazardous failures, and this paper will calculate it for the SPI safety architecture.

The International Electrotechnical Commission (IEC) 61508 is a single standard addressing functional safety for all products and industries. The IEC has published a global standard that outlines the use, design, deployment, and maintenance of safety-related technologies. The functional safety of electrical, electronic, and programmable electronic safety-related systems (E/E/PE or E/E/PES) is the title of this document. IEC 61508 is the fundamental functional safety standard applicable to all fields. Although this standard applies to all industries, each industry has its nuances, which is why many industries have created their own standards based on IEC 61508. The design verified in this paper belongs to the BMS of the automotive industry.

A. ISO 26262

ISO 26262 is a global standard focused on safety-critical systems in the automotive industry, primarily derived from IEC 61508. It is used for E/E systems in vehicles, including hardware and software components. It outlines the safety-related functions of the system and the requirements that the processes, techniques, and tools used during development must meet. As the automotive industry becomes increasingly complex, more effort must be made to provide systems that meet safety requirements. The goal of ISO 26262 is to provide a single safety standard for all E/E systems in vehicles. The functional safety of products is systematically managed by ISO 26262 at the system, hardware, and software levels during the development process. It has an automotive safety lifecycle that outlines each stage of production, from management to development to production to operation to service to decommissioning. Automotive Safety Integrity Level (ASIL) is used to establish applicable standards for ISO 26262 to reduce unacceptable residual risks and further serves as a unique risk-based approach to identify risk categories in the automotive industry. The specifications for defining architecture, design development, verification, integration, and confirmation processes to ensure acceptable safety levels.

B. Automotive Safety Integrity Levels

ASIL is a crucial component of ISO 26262 compliance. The design and development of systems must comply with ASIL, which is determined at the beginning of the chip development phase. The planned functions of the system are checked against any potential hazards. The estimation of the risk is based on the probability of exposure, the driver’s possible controllability, and the severity of the possible outcomes when critical events occur, leading to the derivation of ASIL. Regardless of the technology used in the system, ASIL entirely depends on the potential harm to the driver and other road users. Any safety requirements are assigned an ASIL level of A, B, C, or D. Systems marked with “D” are considered the most safety-critical and are subject to the strictest testing standards, while processes marked with “A” are considered the least safe. The minimum testing standards outlined in the ISO 26262 standard simplify the selection of testing methods. Based on ASIL levels, the single point fault metric (SPFM), latent fault metric (LFM), and hardware failure probability metric (PMHF) should be calculated and further satisfied, as shown in Table 1.

A. SPI Safety Architecture

Single master communication protocol is called SPI. This means that only one device initiates communication with other slave devices. It is a high-speed synchronous serial IO port that shifts the length of serial bit streams (data) and transmits or receives them at a programmed bit transmission rate. When the SPI master device wants to send data to the slave device, the serial clock is activated at a clock frequency that both the master and slave devices can control. The slave device is selected by pulling down the corresponding slave select line. SPI can support duplex communication between the master device and its peripherals, as the master device generates data on the MOSI line while sampling the MISO line. It is important to remember that for communication to work correctly, the master and slave devices must use the same set of parameters, such as SCLK frequency, CPOL, and CPHA. Status, control, and data registers, shifter logic, baud rate generators, master/slave control logic, and port control logic make up most of the SPI design. The design of SPI is very similar to that detailed in the SPI module guide from Motorola Inc.

In the safety concept, functional safety requirements for the SPI design will be defined at the system level. The functional safety requirements for SPI provide data loss protection through the SPI path (sending and receiving), which requires functional safety and prevents faults. Data streams can flow from external ICs to the BMS SPI or flow from the BMS internal storage to external ICs through the BMS SPI. Any faults in the SPI path that may lead to functional failure and violate functional safety requirements are mentioned in the FMEDA. Any faults in SPI, its configuration/mode selection, and I/O pins may lead to data integrity, authenticity, and timeliness issues (e.g., initiation and completion of data transmission) and configuration errors. Furthermore, any faults in interrupt generation, identification, and servicing may manifest as unrecognized events and modify signal flows, leading to failures in data acquisition, transmission, and processing. Therefore, safety mechanisms should be designed to protect the defined functional safety requirements.

B. SPI FMEDA

First, FMEDA is executed by posing the question, “What do we want to avoid?” and “How can it happen?” and also adding a “diagnostic” section by asking, “What potential problems can arise?” FMEDA includes diagnostic coverage analysis to identify failure modes that could violate safety goals in the absence of safety mechanisms, and then identifies safety mechanisms that prevent these failure modes from violating safety goals. Once the netlist is available, block-level FMEDA is completed, aiding in implementing these mechanisms to detect all underlying failure modes. The goal is to calculate the coverage of failure modes that violate safety goals. Functional analysis forms the basis of FMEDA.

A. Safety Mechanisms

Safety mechanisms are on-chip functionalities that can detect and mitigate or make the design fault-tolerant, reporting these faults when detected. These mechanisms can be purely hardware, purely software, or a combination. The safety mechanisms proposed to protect SPI from the impact of failures are purely software safety mechanisms. After block-level FMEDA is executed, these mechanisms will be implemented to detect all underlying failure modes. These must be implemented in parallel when SPI operations occur. The proposed safety mechanisms are:

1. CRC Check for Data: CRC provides error codes. It detects faults that lead to mismatched expected data.

2. Interrupt Count and Timeliness Check: Detects any lost or spurious interrupts, leading to random failures in interrupt generation.

3. Register Switching Validation: Detects faults that lead to incorrect configuration and data transmission errors.

B. Simulation-Based Fault Injection

To support functional safety verification, the Cadence vManager safety client is used to automate fault injection activities using a defined process. By using input files, one can drive the safety client and the internal core engine running within the client, namely the Xcelium fault simulator. The input files are configuration files that define overall parameters, lists of faults that identify fault detection targets, lists of faults that identify fault diagnosis targets, a test list specifying one or more tests to run in a single session, and other script files necessary for running activities.

The vManager safety client supports various types of activity flows, using serial flows and concurrent flows. In serial: one fault is injected during the fault simulation run (i.e., the next fault can be injected after closing and reopening the run). The number of fault simulations equals the number of faults to be injected, which is a drawback of this process, and consumes more CPU memory due to the large number of simulations. In concurrent flow, multiple faults are injected for each fault simulation session each time it runs. The advantage of this process is that it is a throughput solution where multiple faults are injected and simulated together, and normal functionality and fault simulation are also simulated simultaneously. The tool retains a list of error values and good values for each node in the circuit. The drawback of this process is that overly active faults leading to a large number of simulation events do not propagate to their respective observation points. Such faults are marked as non-simulatable (NS) in the fault database of concurrent simulation. Additionally, if the erroneous simulation does not converge within the time calculated for good simulation values, the error will be reported as DU.

For the SPI module, all functional outputs are defined as functional gate pulses—MISO, MOSI, SCLK, SS, and corresponding input and output enables. All safety mechanism outputs are defined as checker gate pulses—CRC checks, timeliness checks, register switching configuration checks, and interrupt count and timing checks. All test cases are implemented for various SPI operation modes with safety mechanisms. The fault detection of SA0 and SA1 fault types at all unit ports in the SPI netlist is injected 80ns after the simulation starts, with a timeout factor of 10, meaning the fault simulation should execute up to 10 times the good simulation time.

A. Concurrent Runs

Concurrent simulation was completed with a group size of 2000, indicating that multiple faults injected and simulated are limited to each group of 2000. A total of 9702 faults were detectable in the design, with 119 reported as safe after structural analysis, and 9583 were testable, of which 6264 were primary faults. After completing the fault simulation, a session report was generated, achieving 83.84% DC.

Based on FMEDA, safety mechanisms are implemented, and simulation-based digital fault injection is executed using the vManager safety client for safety mechanism (diagnostic) verification. Here, permanent faults at each unit port of the injected netlist define a set of functional and checker gate pulses, classifying faults as DD, DU, UD, UU, and safe. Using the tool-supported serial and concurrent flows, a diagnostic coverage of 93.5% is achieved for a total of 9702 instrumented faults, with 6047 reported as DD and 414 reported as DU. To achieve the target ASIL D, by performing detailed DU analysis, moving them to the DD category by identifying detection mechanisms or moving them to the safe category by analyzing fault impacts, a diagnostic coverage of 97.2% for single point faults in the SPI block is achieved, making the entire chip sufficient to achieve 99% SPFM.

Based on the challenges faced in completing functional safety verification more quickly, there are several ways to achieve the same results in a shorter time and provide recommendations for other designs.

1. Execute concurrent runs and then extract the fault list to run serial runs, which requires more time to create and execute setups. Therefore, a hybrid process can be created by requiring tool vendors to run concurrent and serial activities simultaneously through a single setup, extracting the fault lists for serial runs internally as faults are reported as NS and DU in concurrent runs. Then generate a merged data report, saving significant execution time.

2. For more complex designs with >40000 faults, injecting faults for all possible faults is not a good approach; a sampling method should be used where the tool randomly injects faults of specified values into the design. Then analyze the results of fewer faults and modify test cases to achieve the DC required for this set of faults. Performing 2 to 3 iterations usually results in the DC values converging.

3. To execute DU analysis more quickly, formal methods can be used to understand which injected faults can be detected or classified as safe.