An introduction to functional safety and ISO26262 standard

Hi there! Nice to meet you again in the functional safety topic. In my previous posts, I have shared my understanding about functional safety (FUSA) and ISO26262 for each topic in details. However, when I work with many new FUSA engineers and other engineers who work in development team or different design domain, the normal questions which I am asked are normally:

What is functional safety? Why do we need functional safety? or How to understand better ISO26262 and translate its guidelines while practicing ISO26226 in our design, etc

Therefore, I feel that I need to write an article to answer for these basic, but important questions for newbies who just heard about ISO26262 or "functional safety" terminology based on my understanding.

Why we need "functional safety"?

The automotive industry has seen a rapid change in the technologies used inside the vehicles in which software is increasingly used in safety-critical product development. And that software needs to be safe, secure, and reliable. That’s why there are safety standards designed for embedded system developers in several industries – such as, vehicles, automobiles, planes, and medical devices.

Actually, Electrical and/or Electronic (E/E) systems in combination with software, or in other words embedded systems, within a vehicle have been growing in number and complexity. This complexity have been increasing as these systems replace more mechanical systems by introduction of various X-by-wire systems. The trend of complexity of automotive systems is showing in Figure 1:

Safety is a key consideration for the typical consumer when buying a new vehicle. The occupant’s wellbeing is protected more and more by the ability of E/E systems to correctly and reliably sense, interpret, and act. Arguably, safety is also one of the most important quality attributes of a vehicle that needs special attention during all the stages of the life cycle of a vehicle. The overall safety of a vehicle has multiple aspects, such as passive safety, active safety, and functional safety.

Why is functional safety Important? Functional safety is important because lives and reputations are at stake.        

We view safety of automotive systems from two perspectives: product safety and functional safety.

• Product safety tackles hazards such as fire hazard, electrical hazards, etc.
• Functional safety concerns the system behavior in case of failures or faults in the system. Here, a function captures the implementation independent specification of the behavior of the vehicle and its systems.

Functional safety ensures that the risks that could arise from an E/E component malfunction with fall within acceptable ranges. Functional safety is part of the overall safety of a system or piece of equipment that depends on automatic protection. This automatic protection system needs to respond correctly to its inputs. And it should have predictable responses to failure. This includes human errors, hardware failures, and operational/ environmental stress.

The below table shows the safety perspectives to help you understand how different is between "functional safety" and other safety:

Top functional safety considerations in Automotive industry is listed down as follows:

Overview of the ISO26262 standard

The ISO 26262 standard provides the state of the art of functional safety in the automotive industry. Compliance with this standard is the best practice for achieving safety in the automotive domain. Safety assurance and compliance can be subjective and prone to human error due to the inherent internal inconsistencies and possibly vague requirements.

The ISO 26262 standard is an adaptation of IEC 61508, which focuses on Electrical/Electronic (E/E) systems but provides a general design framework for safety related systems. It provides a framework for developing safety-related systems in the automotive domain. It recommends various methods for designing, analyzing, and testing safety-related systems.

Since its first introduction in 2011, ISO 26262 has attracted more and more attention in the automotive domain. The version 2 of ISO26262 was released in 2018, this extents the scope of application of the standard for Truck, Buses and Motorbikes as shown in the below table:

In overview, the ISO 26262 consists of ten parts as shown in Figure 4.

In particular,

• Part 1 - Vocabulary: Here all the words and phrases are explained for ISO26262
• Part 2 - Management of Functional Safety: Management during complete safety lifecycle, safety management during development and safety management activities after release.
• Part 3 - Concept Phase: Item definition, initiation of the safety lifecycle, hazard analysis and risk assessment and functional safety concept.
• Part 4 - Product Development System: Specification of technical safety requirements with respect to preliminary architecture assumptions, technical safety requirement specification and specification of system design and technical safety concept.
• Part 5 - Product Development Hardware: Hardware analysis, design and integration.
• Part 6 - Product Development Software: Software development, safety specification and testing.
• Part 7 - Production and Operation: Production, operation, service and decommissioning.
• Part 8 - Supporting Processes: Overall safety management, configuration, verification, documentation. Someone shall during the process control and document the safety development.
• Part 9 - ASIL-oriented and safety-oriented analyses: Update of architectural information and ASILs. Safety analyses at applied level.
• Part 10 - Guideline on ISO26262: Guideline of the implementation.

In which, Part 3 to Part 7 correspond to the safety lifecycle, while Parts 1, 2, and Part 8 to Part 10 provide the additional information related to the interpretation of the main parts.

The ISO 26262 standard is also structured based upon the V-model.

• Parts 3 to 7 construct the primary V cycle for the whole system development, The main goals of Part 3 is to identify system hazards and risks through Hazard Analysis and Risk Assessment (HARA), define safety goals, and the Functional Safety Concept (FSC).
• Part 4 focuses on the system level development, integration, and validation. In this part, Technical Safety Requirements (TSRs) are derived based on the FSC.
• Parts 5 and 6 have their own (smaller) V cycles for hardware and software development respectively. In these two parts, more detailed safety requirements are derived from TSRs. These safety requirements are assigned to concrete subsystems or components for implementation.
• Finally, Part 7 covers the release of the system for production.

What is ISO26262 Functional Safety?

Functional safety is easy to understand, but difficult to formally define. ISO26262 defines functional safety as following:

“Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.” - ISO2626:2018 Part 1        

We can agree that this definition is difficult to grasp at first glance! In more details, the author in [2] transformed the above definition as follows:

“Absence of combination of the probability of occurrence of physical injury or damage to the health of people and the severity of that harm, judged to be unacceptable in a certain context according to valid societal moral concepts due to potential sources of harm caused by termination of the ability of an element or an item to perform a function as required or unintended behavior of the item with respect to the design intent for this item of systems that consist of electrical and/or electronic elements, including programmable electric elements.” [2]

In a simplified way, we could say that there shall not be any harm to persons resulting from faults in E/E system or software. In other words, functional safety can understand as: "Operating as intended with fail-safe or fail-operational strategies to prevent hazards." In this understanding, we identify two major strategies for coping with failures:

• fail-safe that means reverting to a safe state which no longer provides the required functionality, and
• fail-operational that means transitioning to a safe state while some variation (which may be a degraded operating mode) of the functionality is still provided.

Note: Though functional safety focuses on E/E systems, it also refers to the operational safety of a vehicle as a whole. Therefore, it must also account for related non-E/E parts.

There are a few vital implications in ISO 26262 definition of functional safety, namely:

1. functional safety depends on the design intent,

2. functional safety tackles (in the scope of ISO 26262) failures of E/E systems, and

3. functional safety is only applicable to hazards that cause harm to people (and not damage to property).

For clarity, an E/E system is NOT a simple mechanical switch or device. Instead, it has:

• Some form of sensing to detect real-world conditions and capture information.
• The capacity (typically via a uC/uP) to make decisions based on the information gained.
• An actuator through which it can take the corresponding action.

These safety standards are designed to eliminate risk. This risk might be physical injury or damage to overall health of people. You’ll need a safety function to mitigate each risk. And you can achieve this by using a safety-related system or safety-related mechanism, made up of different safety functions.

What are Functional Safety Goals?

Failures of the E/E systems are recognized (the focus of functional safety) as the primary cause for hazards. There are various ways for categorization of failures. One genetic way is to classify them into two types: random (hardware) failures and systematic failures.

• Random hardware failures are unpredictable failures that occur during lifetime of a hardware part. These failures are only relevant to hardware parts and do not apply to software units.
• Systematic failures are deterministic and have a certain cause (usually the design of the system). These failures can happen in both software and hardware elements.

Preventing systematic failures implies that the development process of safety-related systems should be carried out in such a way that the human errors (i.e., the primary cause of systematic failures) or other contributing factors do not lead to an unresolved failure. This goal is achieved by defining a predictable process for the development of safety-related systems. The mechanism for ensuring the achievement of this goal includes reviewing work-products, analysis, and testing.

We mitigate random hardware failures during design by analyzing possible failures and using detection and reaction mechanisms known as safety mechanism. The random hardware failures are a probabilistic phenomenon, and they are unpreventable. Hence, there should be mechanisms in the design that detect these failures and act to prevent failures from creating hazards.

The goals of functional safety is to reduce the risks of hazards regarding physical injuries to people, loss of human life, and damage to property or environment. To achieve this goals, we need to do:

1. Preventing systematic failures

2. Mitigating random failures

3. Showing (providing evidence) that the previous goals have been achieved.

These goals are achieved by a combination of controlling the development process, design, verification and validation, and documentation.

Conclusion

In summary, functional safety addresses the hazards that are caused by the malfunctioning of Electrical and Electronic (E/E) systems. Many factors impact functional safety such as the organization and management, the development process, the design of the systems, the system type and technologies used in it, the quality control methods, etc.

Functional Safety deals with functionality of Electrical/Electronic systems, no mechanical components, to answer for 02 below questions:

1. How can they go wrong and lead to harm?

2. How do we avoid that?

When working with Functional Safety, it’s important to consider the vehicle, the traffic situations including other vehicles and road users and the passengers involved.

ISO2626 does not create anything new – many of its concepts have been around for a longtime – but, it consolidates and orchestrates the ideas to establish a common, consistent language and approach. The goal of the ISO26262 standard is to ensure safety throughout the lifecycle of automotive equipment and systems in which specific steps are required in each phase. This ensures safety from the earliest concept to the point when the vehicle is retired.

ISO26262 can be seen as a "cookbook on how to develop safe functions on the vehicle level" that to some degree are implemented in electronic and software. By following this cookbook, the result is a harmonized safety level across the industry and this level is seen as acceptable.

P/S: I hope that this article can help those people who just jumped in to work as FUSA engineer or the people who are interested in functional safety to know overview and key points about ISO26262 before studying more detailed in this challenging, but interesting area.

References

[1] ISO26262:2018 standard documents

[2] Khabbaz Saberi, A. (2020) "Functional Safety: A New Architecture Perspective: Model-Based Safety Engineering for Automated Driving Systems." [PhD Thesis 1 (Research TU/e / Graduation TU/e), Mathematics and Computer Science]. Eindhoven University of Technology.

[3] Design and Safety Assessment of Critical Systems (Marco Bozzano, 2011)

Other Papers for further reading

[1] Y. Luo, A. Khabbaz Saberi, and M. G. J. van den Brand. “Safety-Driven Development and ISO 26262,” in Automotive Systems and Software Engineering, Springer International Publishing, 2019

[2] A. Khabbaz Saberi, E. Barbier, F. Benders and M. G. J. van den Brand, “On functional safety methods: A system of systems approach,” 12th Annual IEEE International Systems Conference (SysCon 2018) April 2017, Montreal, Quebec, Canada,p. 261-267

[3] A. Khabbaz Saberi, D. van den Brand, and M. G. J. van den Brand “Towards compliance assurance for automotive safety-related development: a model-based approach,” in the Poster Session of the 6th International Symposium on ModelBased Safety and Assessment (IMBSA 2019), 2019

[4] Y. Luo, A. Khabbaz Saberi, T. Bijlsma, J. J. Lukkien and M. G. J. van den Brand, “An architecture pattern for safety critical automated driving applications: design and analysis,” 11th Annual IEEE International Systems Conference (SysCon2017), 24-27 April 2017, Montreal, Quebec, Canada. p. 261-267

[5] A. Khabbaz Saberi, J. Vissers, F. P. A. Benders, “On the Impact of Early Design Decisions on Quality Attributes of Automated Driving Systems,” 8 Apr 2017, 13thAnnual IEEE International Systems Conference (SysCon 2019), April 2019, Orlando, Florida, USA.

[6] A. Khabbaz Saberi, F. Benders, R. Koch, J. J. Lukkien, and M. G. J. van den Brand, “A method for quantitative measurement of safety culture based on ISO26262,” Evolution of System Safety: Proceedings of the Twenty-Sixth safety related Systems Symposium, 6-8 February 2018, York, United Kingdom, p. 203-218, 2018

[7] A. Amroush, “Design Patterns for Safety-Critical Embedded Systems”, Ph.D. dissertation, Aachen University, 2010, p. 384, ISBN: 9781856177078

[8] Audi, BMW, Daimler, Porsche, and VW, “Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units”, Tech. Rep., 2013.

[9] P. Bishop and R. Bloomfield, “A Methodology for Safety Case Development”, Industrial Perspectives of Safety-critical Systems, P194-203, 1998, Cited by 201.

[10] M. Born, J. Favaro, and O. Kath, “Application of ISO DIS 26262 in practice”, in Proceedings of the 1stWorkshop on Critical Automotive Applications: Robustness & Safety, CARS ’10, Valencia, Spain: ACM,2010, pp. 3–6

[11] A. Knoll, C. Buckl, K.-J. Kuhn, and G. Spiegelberg, “The RACE Project: An Informatics-Driven Greenfield Approach to Future E/E Architectures for Cars”, in Automotive Systems and Software Engineering,Y. Dajsuren and M. van den Brand, Eds., Springer International Publishing, 2019

[12] P. Mauborgne, S. Deniaud, E. Levrat, E. Bonjour, J. Micaelli, and D. Loise, “Operational and System Hazard Analysis in a Safe Systems Requirement Engineering Process - Application to automotive industry”, Safety Science, vol. 87, pp. 256–268, 2016

[13] P. Mauborgne, S. Deniaud, E. Levrat, ′ E. Bonjour, J.-p. Mica ′ elli, and D. Loise, “The Determination ¨of Functional Safety Concept coupled with the definition of coupled with the definition of Logical Architecture : a framework of analysis from the automotive industry”, in 20th IFAC World Congress,IFAC 2017, Toulouse, France, 2017, pp. 7549–7554.

[14] R. Weissnegger, “Design and Verification Process for Safety-Critical Embedded Systems in the Automotive Domain”, Ph.D. dissertation, Graz University of Technology, 2017.