Automotive functional safety - hardware safety design

Preface

The following is a mind map of this issue’s content:

1. What is hardware design?

Hardware security design includes the following two parts:

1. Hardware architecture design: all hardware components and their interrelationships with each other

2. Hardware detailed design: At the electrical schematic level, it represents the interconnections between the components that constitute the hardware component.

To develop a single hardware design that meets both hardware safety requirements and all non-safety requirements, in general, safety and non-safety requirements should be handled in the same development process.

2. At what stage is the hardware design completed?

3. Why should hardware security design be done?

1. Design hardware according to system design specifications and hardware security requirements

2. Verify whether the hardware design violates system design specifications and hardware security requirements

Functional safety proposes three indicators for hardware reliability, namely single-point failure measurement, latent failure measurement, and random hardware failure targets . Hardware safety design must first meet these requirements. Only in this way can the product be provided with a high-security, High reliability hardware design.

4. Hardware security design requirements

1. Basic general requirements

• Meet hardware security requirements

• Each hardware component should integrate the highest ASIL level among the hardware safety requirements it performs

• If a hardware element is not assigned an ASIL level or is assigned a different ASIL level, each sub-element shall be treated at the highest ASIL level unless the element coexistence criteria are met.

• Hardware design maintains traceability from top to bottom

2.Hardware architecture design requirements

When designing the hardware architecture, non-functional reasons for the failure of safety-related hardware components should be considered. If applicable, the following influencing factors may be included: temperature, vibration, water, dust, electromagnetic interference, other hardware components from the hardware architecture or their location. Environmental crosstalk.

(PS The definitions of these requirements are easy to understand, so I won’t explain them one by one)

3. Hardware detailed design requirements

• To avoid common design pitfalls, relevant experience should be applied.

• During the detailed design of hardware, non-functional causes of failure of safety-related hardware components should be considered, including, if applicable, the following influencing factors: temperature, vibration, water, dust, electromagnetic interference, noise factors, other hardware components from the hardware component Crosstalk from components or their environment.

• In hardware detailed design, the operating conditions of hardware components should comply with their environmental and operating restriction specifications.

• Robust design principles should be considered. This can be demonstrated using a checklist of quality management methods.

4. Security analysis

1. Safety analysis of hardware design is required to identify the cause of failure and the impact of failure.

Deductive analysis methods include fault tree analysis (FTA), fishbone diagram, and reliability analysis; (just choose one of them, ASILC and ASILD are mandatory)

Inductive analysis methods include failure mode and effects analysis (FMEA), event tree analysis (ETA), and Markov model; (just choose one of them, ASILA, ASILB, ASILC, and ASILD are all mandatory)

The purpose of security analysis is to support hardware design definition and can also be used for hardware design verification. We will mention later that qualitative analysis is sufficient for the purpose of supporting hardware design definition.

2. For each safety-related hardware component or component, the safety analysis should identify the following:

1.Safety failure

2. Single point of failure or residual failure

3. Multiple points of failure (in most cases the analysis can be restricted to two points of failure, but sometimes multiple points of failure of order higher than 2 may appear to be related to technical safety concepts (e.g. when implementing redundant safety mechanisms) rather than The purpose of identifying double points of failure does not require a systematic analysis of every possible combination of two hardware failures, but at least consider combinations derived from technical safety concepts (e.g. combinations of two failures: one failure affects safety-related elements, another failure affects the corresponding safety mechanism required to achieve or maintain a safe state))

3. There should be evidence of the effectiveness of safety mechanisms to avoid single points of failure.

• Evidence should be available to demonstrate the ability of the safety mechanism to maintain a safe state or to safely switch to a safe state (in particular, appropriate failure mitigation capabilities within the fault tolerance interval)

• Diagnostic coverage of residual faults should be evaluated.

4. There should be evidence of the effectiveness of safety mechanisms to avoid latent failures.

• Evidence should be available to prove the ability to complete failure detection of latent faults and alert the driver within an acceptable multi-point fault detection time interval to determine which faults remain latent and which faults no longer remain latent;

• Diagnostic coverage of latent faults should be evaluated.

5. Provide requirements to prove hardware design and its independence

6. If the hardware design introduces new hazards and this hazard is not covered by the existing security goals, they should be subjected to hazard analysis and risk assessment according to the change management process.

5. Hardware design verification

Verify the consistency and completeness of hardware design and hardware security requirements

6. Production, operation, maintenance and scrapping

• If the safety analysis shows that production, operation, maintenance and retirement are safety-related, their safety-related special characteristics should be defined. These special characteristics should include verification measures for production and operation and acceptance criteria for these measures. (For example, a safety analysis of a hardware design that relies on new sensor technology, imaging or radar sensors, can reveal the relationship with the special installation processes required by these sensors. In this case, additional validation measures for these components are necessary. carried out during the production phase)

• If the assembly, disassembly and disposal of safety-relevant hardware elements may affect the technical safety concept, instructions for these operations should be defined.

• Ensure traceability of safety-related hardware elements.

• Maintenance instructions for safety-related hardware elements should be defined if maintenance may affect the technical safety concept.

5. How to design hardware security architecture

Here we give some actual use cases directly

The specific hardware architecture design needs to be determined based on product requirements and product characteristics. It is difficult to unify, so I simply drew a schematic diagram. The basic elements of this part of the architecture are generally universal.

1. The first is the low-voltage power supply, the input filtering and protection of the KL30. Without considering the low-voltage backup, the KL30 is the only power input source for the ECU.

2. CAN transceiver, a CAN transceiver is needed to communicate with other ECUs, because the current vehicle network is still dominated by CAN and CANFD. Some CAN Transceiver chips, especially when using CANFD, need to be configured through SPI.

3. The TLF3558x chip serves as a power management chip and provides an external watchdog function. The voltage output includes a 1.3V chip core voltage, a 3.3V IO voltage, a 5V power supply voltage and ADC and other peripheral operating input voltages. The highest functional safety level is ASIL D, so it is widely used in automotive electronic products.

4. Infineon's Aurix Tricore series Tc39x is a six-core chip architecture that supports 4-core Lockstep. The highest functional safety level ASIL D can meet the application of most traditional products.

5. Other circuits including drive circuits, sampling circuits, sensors, etc. need to be customized for different products, matching and debugging, and there is no way to display them uniformly.

Regarding qualitative and quantitative safety analysis, that is, FTA and FMEA, these two topics are relatively complex and large. I will explain them in detail in subsequent chapters. Content related to SBC and chip pure technology will also be shared slowly in another column (the main focus is a long stream of water)

6. Conclusion

That’s it for today’s sharing about hardware design. Hardware security design itself is still very demanding, especially hardware architecture design and detailed design. Therefore, understanding hardware design only from the perspective of functional safety is still very one-sided, and you still need to calm down. Come, understand and deeply study the characteristics and characteristics of each component, so that it is possible to integrate hardware design and functional safety.