Functional Safety with ISO 26262: Best Practices and Principles
The automotive industry (auto industry) is constantly changing, with new technologies and functionalities continually being released to improve our daily drivers’ comfort, convenience, and safety. Functional safety management is a vital piece of risk assessment in the automotive industry since it helps prevent hazards that could lead to loss of life. It is vital that all these new technologies such as driver assistance are safe and meet stringent functional safety qualifications. This is where ISO 26262 comes into play.
In this post we will look at:
- What is ISO 26262 functional safety
- Is ISO 26262 (Automotive safety integrity level ASIL) mandatory?
- Tool qualification for ISO 26262
- How is the ISO26262 automotive standard being applied today?
- The difference between ISO 26262 and IEC 61508
- How to identify sources of errors during ECU software development lifecycle
- Why ISO 26262 is the most critical for your company
- List of terms found in ISO 26262
What is ISO 26262 functional safety standard?
Technology evolution resulted in a new automotive standard published in 2018. This standard is known as ISO 26262. It is a safety plan and automotive safety integrity level (ASIL). It specifies the requirements/qualifications for functional safety of electrical or electronic systems, mechanical systems, or the software tool that was intended to be deployed in a vehicle to prevent hazards to people’s lives. ISO 26262 standard comes with roles, checklist, templates and agenda.
Compliance with ISO 26262 is vital for any company that wants to supply electrical or electronic products or mechanical systems for use in a vehicle. To achieve ISO 26262 certification, businesses must show that their products meet the required safety level for every application.d. Today ISO 26262 has expanded to cover all road vehicles, including semi-trailers, trailers, buses, trucks, autonomous vehicles, and motorcycles.
Other changes include guidelines for:
- Safety of the intended Functionality (SOTIF)
- Semiconductors
- Cybersecurity
Is ISO 26262 (Automotive safety integrity level ASIL) Mandatory?
Even though ISO 26262 is widely employed in the automotive sector, it is not mandatory. But, widespread compliance shows that it is viewed as a vital standard because following the regulations and best practices defined by ISO 2626 makes the production and development processes more structured and effective. It introduces more effort and limitations in the workflow; however, as a result, you receive well-organized processes, and you ensure that any possible weak points are identified and addressed. This, in turn, gives a safe, high-quality product. OEMs insist that their supplies apply ISO 26262 in their process.
Tool qualification for ISO 26262 automotive functional safety
Tool chains and software tools used in the development of electronic automotive systems should be ideal for safety-intense systems, following ISO 26262. The standard outlines a qualification process, but qualification depends on how the software tool is utilized and what effect it can have on safety. Someone should assign a confidence level to the tool or flow within the tool, estimating the probability that it will cause or insert an error combined with the possibility that the error will be detected during the development process.
Unfortunately, confusion has increased around who assigns confidence levels. Even though solutions or vendors offer their tool conference level (TCL), the business using the tool bears the responsibility of defining the TLC depending on its intended use. The currently-updated standard requires that development software used to create elements for automotive systems should be qualified to operate in a functional safety design environment.
How is the ISO26262 automotive standard being applied today?
This is where the ISO 26262 safety standard comes in. Its purpose is to provide a unifying safety standard for all safety related systems and automotive electronic and electrical systems and avoid unreasonable residual risk. Another goal of functional safety is freedom from unacceptable risk of damage or physical injury to people’s health either directly or indirectly by the proper implementation, documentation automation and validation of one or more automatic protection functions (often called safety functions). It builds on ICE 61508, which is a functional safety standard designed for industrial applications; however, the difference is that it is specifically focused on automotive electronics and electronics software. A vital concept from IEC6508, the Safety Integrity Levels, where 4 levels are defined depending on the average probability of failure on demand, was adapted and enhanced for automotive needs.
For applications with no linked hazards and where safety requirements are not applicable, Automotive Safety Integrity Levels (ASIL) now comprise a 5th level, known as Quality Management (QM). ISO26262 was approved as an international standard in 2011. In contrast, there is no direct legal requirement to comply with this standard; it’s considered “state of the art,” which indicates it is legally highly relevant.
The difference between ISO 26262 and IEC 61508
You can think of ISO 2626 functional safety as an adaptation of the IEC 61508 for automotive needs. Generally, IEC 61508is related to any electronic or electrical system but can be applied in various industries. IEC 61508 is usually recognized as a master functional safety standards from this standpoint. On the other hand, ISO 26262 defines a broad range of automotive safety integrity levels ASIL C, D, B, and ASIL A to help map the required processes, product functional safety mechanisms, and efforts of development of safety to levels of acceptable risk. It also offers an automotive safety lifecycle (decommissioning, service, operation and production).
Development and design of ISO 26262 compliant ECU software
The need for developing safety-critical automotive elements and the increasing demands for complex and innovative automobile applications are ongoing challenges for automotive manufacturers, automotive design engineers, and automobile manufacturers. Typically they have to play the balancing act of catering to increased software complexity while lowering the time-to-market with utmost care. And this is while making sure that no compromise is made on ensuring the safety of the automotive application and software element. The expertise then depends on designing the automotive ECU application by considering every aspect of safety failures that can happen during the product development cycle.
How to identify sources of errors during ECU software development lifecycle
Systematic software failures happen primarily because of human errors during different product development life cycle phases. Failure modes in the ECU software development lifecycle can mostly be traced back to a specific root cause and fixed. Let us look at some cases that usually happen during the software development cycle and which could have a lasting effect on the performance of the final automotive application:
- Coding and system design errors: Considered the second most common source of mistakes, this kind of error usually occurs because of:
- Failed error-handling, lack of self-tests, a fault metric, error in displaying results errors, algorithm errors, syntax errors, incorrect queries, timing errors, and other random errors
- A poorly structured embedded software code or systematic faults
- Communication and functional safety requirements specification: This phase results in one of the biggest sources of errors; it happens when the software tool qualification was misunderstood by the automotive software developer.
Designing a robust and well: Optimized software, keeping in account these errors, can lower systematic failures to a large extent and make the safety management system resilient against common cause failures.
How to achieve ISO 26262 functional safety compliance?
To ensure ISO 26262 compliance, every lament of the system should be checked using Functional Safety principles. The procedure is not limited to products; however, it applies to the delivery framework on which the product has been based. Thus, for a safety-related system, the whole safety engineering process should be confirmed. For this purpose, ISO 26262 introduces the confirmation measures, which are grouped in the following categories:
| Functional safety assessment process | Delves into an element functionality or the characteristics of a compound with regards to process objectives (Body Control Module) |
| Functional safety audits | This covers the adopted process with regards to process objectives (ISO 26262) |
| Confirmation review (Done by ensuring verification review is performed) | Concerns work products objectives (automotive safety standards concept, software, and hardware architectural design) |
Why ISO 26262 is the most critical for your company?
Here is why ISO 26262 is critical for your company:
Identifies the need for management to embrace automotive safety
Cultivating a company-wide safety culture is essential when establishing a functional safety plan within a company. Management must be fully committed to the development of a safety plan, or implementation will not work. Typically functional safety requires commitment, and the start must truly be from the top down to be effective. This commitment may not always be simple since there could be conflicts between functional safety and timing or cost. A proper safety culture necessities the encouragement to stop a project if, for example, a safety violation happens. Similarly, the proper authority should be given to those responsible for upholding the safety measures. Apart from cultivating a company culture that embraces safety, ISO 26262 also presumes sufficient resources are allocated to projects. Ultimately, automotive companies will designate safety as the highest priority.
Spells out the overarching development requirements for electronics systems projects
To run a project, there are project-specific requirements to be integrated within the process. Your business might already have a process set up, in which case it might only need adaptation for ISO 26262’s guidelines. These additional steps will establish the basis needed to execute a functional safety E/E project, whether the development phases for any hardware level, software level, system level or ASIC level. Before a project can effectively get off the ground, the vital step is to make sure the project’s R&R is well defined for all safety-related activities. The procedure should have this built into its structure to prevent project outcome variability.
ISO 26262 outlines in greater detail two critical roles, functional safety managers (SM) and the project manager (PM). Your business shall support the PM and give the role of project responsibility. The PM shall also verify that sufficient resources are applied to a project, made simpler by having the R&R already in place. After the PM is identified, the position is to ensure an SM is in place to protect the safety measures. The SM doesn’t need to complete all safety activities; however, the role is accountable for planning and must ensure the safety activities are stored and completed within the safety case as supporting evidence. Together, these two responsibilities will protect functional safety within the project.
Next, an impact analysis is carried out to determine the best arrangement for the project. It’s important to note what part of the development cycle is impacted to determine whether the impact analysis is at item safety level or element level (or both). If the concept phase, the impact analysis will probably be carried out at the item acceptable level. If within the next parts- hardware, system, and software phases, the safety analysis will probably be at the element level. After the impact is known, safety lifecycle management customizing is necessary. There should be a rationale behind the tailoring to maintain compliance. But, the impact analysis will be the start for justification, whereas the Automotive Safety Integrity Levels (ASIL) rating, established in the HARA, will also evaluate the architectural level. All of this will be modified within the safety plan.
Safety Integrity Levels Decomposition Schemes
ASIL decomposition offers system designers the flexibility to meet the highest levels of diagnostic coverage. Based on the highest safety goal, different ASIL levels decomposition strategies can be deployed by the system considering necessary automobile industry technologies. Development of decomposed elements should be carried out at a minimum following the ASIL requirements after performing decomposition. Generally, target values for evaluation of the hardware architectural metrics and the evaluation of safety goals violations because of random hardware failures should be taken from generic ASIL.
Decomposition has to consider the technical feasibility. For instance, ASIL D requirement allocated to some functionality carried out by ECU cannot be decomposed as ASIL QM(D) for ASIL D(D) and ECU assigned to the simple watchdog since a simple watchdog can be insufficient to cover all relevant failure modes, diagnostics and redundancy of a microcontroller.
List of terms found in ISO 26262
- Tool error detection: This is the confidence in measurers that prevents the software tool from malfunctioning. Generally, the tool confidence level results from the combination of Tool Impact and Tool Error Detection (TD).
- Single point faults metric (SPFM): Single point faults are faults in an element that are not covered by a safety mechanism. SPFM is a hardware architectural metric that shows if the coverage requirements by the safety mechanisms to prevent risk from single point faults in the hardware architecture are adequate.
- Dependent failure analysis: Dependent failures analysis is a detailed analysis to identify the single event causes that could bypass required freedom from interference between given elements and violate a safety goal.
- Traceability: ISO 26262 requires two-way traceability of safety-related requirements and their implementations.
- Failure mode and hazard analysis: This is an inductive approach focusing on individual parts of the system. The analysis starts as faults, which can result in errors and then failures. It can be quantitative analysis or qualitative analysis.
- ASIL decomposition: Also known as Asil tailoring, is the apportioning of requirements of ISO 26262 redundantly to sufficiently independent elements, with the aim of lowering the ASIL of the redundant safety requirements that are allocated to the corresponding elements
- Common Mode Failure is a common cause failure where multiple items fail in the same mode. Analyze it using fault tree analysis.
- AUTOSAR: AUTomotive Open System Architecture (AUTOSAR) – This is not in ISO 26262; this is an open and standardized automotive software architecture.
