Key Considerations for Qualifying Dependent Failure Analysis in ISO 26262

Independence between elements is primarily determined by demonstrating the absence of dependent failures. In simpler terms, the failure of one element should not lead to the failure of another. This is especially critical in the automotive industry where safety is paramount. Independence can be mandated based on the safety concept, supporting concepts like ASIL (Automotive Safety Integrity Level) decomposition.

To identify cascading and common cause failures, ISO 26262 introduces classes of coupling factors that can be utilized as checklists across various levels of abstraction. These levels include the system, software, hardware, and semiconductor levels. By applying these coupling factors, potential vulnerabilities and interdependencies can be uncovered, leading to a more comprehensive analysis of the system's safety.

Classes of Coupling Factors in ISO 26262

The classes of coupling factors provided in ISO 26262 can be applied to different levels, and Table C.1 illustrates examples at the system, hardware, software, and semiconductor levels. Let's delve into these classes:

1. Shared Resource:

• Examples at the System Level: Power supply, wiring harness, data and communication buses.
• Examples at the Hardware Level: Sockets, plug connectors, clock, powerstage.
• Examples at the Software Level: Libraries, I/O routines, drivers, software components.
• Examples at the Semiconductor Level: Hardware resources shared by multiple software elements.

2. Shared Information Input:

• Examples at the System Level: External messages, physical signals.
• Examples at the Hardware Level: Readings from sensors, connection to signal sources.
• Examples at the Software Level: Data or parameter arguments shared by multiple functions.
• Examples at the Semiconductor Level: Input information for semiconductor elements.

3. Environmental Coupling:

• Examples at the System Level: Mechanical coupling, flammable material, sensitivity to electrical effects.
• Examples at the Hardware Level: Proximity of hardware elements, shared housing.
• Examples at the Software Level: Environmental influences considered at the system and hardware levels.

4. Systematic Coupling:

• Examples at the System Level: Identical production and repair processes.
• Examples at the Hardware Level: Same software tools, programming language, compiler/linker.
• Examples at the Software Level: Shared development tools, languages, and processes.

5. Components of Identical Type:

• Examples at the System Level: Same type of actuators, sensors, hardware parts.
• Examples at the Hardware Level: Identical ICs, microcontrollers, ASICs.
• Examples at the Software Level: Instances of the same source code.

6. Communication:

• Examples at the System Level: CAN connection between ECUs, communication between microcontrollers.
• Examples at the Hardware Level: Electrical connection between hardware elements.
• Examples at the Software Level: Data flow via global variables, messaging, function calls.

7. Unintended Interface:

• Examples at the System Level: One functionality overruling another, proximity of hardware elements.
• Examples at the Hardware Level: Crosstalk between signal lines, shared memory space.
• Examples at the Software Level: Potential for wrong memory allocation or leaks.

To sum up, according to ISO 26262, a key component of attaining functional safety in automotive systems is guaranteeing elemental independence. With the help of the offered classes of coupling factors, possible vulnerabilities and interdependencies may be systematically identified, facilitating a more thorough safety analysis at various abstraction levels. Automotive systems can be made more resilient to malfunctions and increase road safety by including these ideas into their design and maintaining procedures.

#Safety #FunctionalSafety #ISO26262 #SW #HW