Functional Safety — ISO 26262
The term “functional” comes from a branch of systems engineering called requirements engineering.
- Functional requirements — what your system is supposed to do; in other words, the system’s functions.
- Non-functional requirements — how the system should behave: for example, how reliable is the system?
Functional safety looks at what happens when the system does something that it was not supposed to do, which is called a malfunction.
The most generic standard is IEC 61508, which originated from industrial markets. It currently exists as a standard in the IEC/ISO basic safety publication, which covers “general functional safety,” for a number of industries. ISO 26262 specifically applies to automotive passenger vehicle electrical and electronic systems. The ISO 26262 standard is a branch of the IEC 61508 standard.
Do and Don’ts
- Functional safety only looks at the electrical and electronic system malfunction.
- Functional safety does not test for nominal performance.
- If a potential electrical malfunction could cause the battery fire, that could be a part of functional safety analysis. The battery chemicals generally would be part of chemical system safety.
- Autonomous vehicle technology is so new that standards like ISO 26262 do not yet even consider certain issues related to self-driving cars such as machine learning algorithms.
The Basics of Functional Safety
- Identify Hazards
- Evaluate the risk
- Using System Engineering to Lower Risk
ISO 26262
ISO 26262 only covers electronic and electrical malfunctions in passenger vehicle systems.
The standard provides a framework for reducing risks that could harm people’s health.
A big part of functional safety is documenting your work.
The ISO 26262 functional safety standard follows the V model.
- Requirements engineering - Define what the system is going to do
- Designing or modifying a system architecture - Design what the system will look like
- Test the system - to make sure it behaves as expected
- Integrate the system - into larger systems
- Integrate the system into larger systems
Defining a system at the Item level
Specifies which vehicle system is being considered, the system boundaries and background information about the system.
Hazard Analysis and Risk Assessment
This is where we brainstorm to imagine hazards where the system malfunctions and causes injury or harm. Then the risk is calculated for each hazardous scenario.
Functional Safety Concept
The functional safety concept provides a high-level overview of the system. Based on the hazard analysis and risk assessment, you figure out what your system is required to do to stay safe. Then identify what part of the system will need to be adjusted to take into account the new functionality.
Technical Safety Concept at the System Level
The functional safety concept and technical safety concept are similar. While the functional safety concept gives a high-level overview of the system and what it needs to do, the technical safety concept gets into more detail.
Technical Safety Concepts are often divided into a System Level Technical Safety Concept and a SubSystem Level Technical Safety Concept. An electronic control unit, for example, might have its own technical safety concept.
To clarify the above concepts the functional safety concept is implementation independent considering only the functional level architecture. The technical safety concepts consider the implementation level of a system.
V Model
The principles of the V model
- the left side represents product development like specifying requirements and designing a system architecture
- the right side represents prototyping, testing, and integration
- higher up in the V model represents integrated systems
- lower down in the V model represents subsystems
Flattened V Model
Flatten out the V model to see it from a linear perspective helps us to list out the major steps involved in a functional safety project.
System Hierarchy
ISO 26262 labels system hierarchies with typical examples for each part:
Hazard Analysis and Risk Assessment
The goal of Functional Safety it to reduce risk to acceptable levels. The five parts of a Hazard Analysis and Risk Assessment (HARA)were:
- Situational analysis
- Identification of hazards
- Classification according to the severity and probability of occurrence
- Calculating the Automotive Safety Integrity Level( ASIL )
- Deriving safety goals
Functional Safety at Hardware and Software Levels
The V model divides hardware and software into their own mini-Vs.
The general idea represented in each V stays the same; first, specify safety requirements. Allocate these requirements to system architecture. Finally test, integrate, and verify.
In the following diagram, you can see a general outline of what would be involved in a functional safety project. The steps of the V model have been stretched out vertically.
Software safety requirements
The software requirements are much more specific than technical requirements. Software requirements specify variable names, signal paths, and software protocols and mechanisms.
Sources of Software Safety Requirements
Software Robustness and Quality
Software bugs are a very important source of error if not the number one source of error in terms of automotive functional safety.
Freedom from Interference
Failure in one software element should not cause a failure in another software element.
Software is partitioned into separate pieces so that the failures do not spread.
ISO 26262 doesn’t mandate freedom from interference in cases where the software elements have the same ASIL. However, we need to prove freedom from interference when software components with different ASIL ratings communicate with each other or running on the same ECU.
Types of interference
- Spatial interference
- Temporal interference
- Communication interference
Software Safety
Various mechanisms to mitigate software interference were captured in my github.
** Source: Udacity
