What is ISO 26262? Why is ISO 26262 needed?
ISO 26262 is an international standard for functional safety of electrical and electronic systems in all road vehicles, except for mopeds.
The ISO 26262 standard was the first international norm addressing the safety of electrical/electronic/programmable systems. It was announced in 2011 by the International Organisation of Standardisation (ISO), but it is rooted in the IEC 61508 standard, released in 1998.
The aim of ISO 26262 is to minimise the risks associated with product design and development so as to prevent hazards and potential human health and life-threatening failures. The goal is to achieve acceptable residual risk.
The ISO 26262 supports the whole product safety lifecycle: from management, development, production to service. Throughout the development process, the standard covers all safety-related aspects on a very detailed level, including requirement specification, design, implementation, integration, verification, validation, configuration, production, services, operation and decommissioning. ISO 26262 also describes the framework for functional safety to assist the development of the safety-related system.
For more information about this standard, check our guidelines to ISO 26262.
What is the difference between IEC 61508 and ISO 26262?
You can think of ISO 26262 as an adaptation of the IEC 61508 for automotive needs. IEC 61508 is related to any electronic or electrical system but can be applied in various industries. From this point of view IEC 61508 is often recognised as a master functional safety standard.
Is ISO 26262 mandatory?
Although ISO 26262 is widely used in the automotive sector, it is not mandatory. However, widespread compliance shows that it is viewed as an essential standard, because following the rules and best practice defined by ISO 26262 makes the development and production processes more effective and structured. It introduces more effort and restriction in the workflow, but as a result, you receive well organised processes, and you make sure that any possible weak points are identified and addressed. This in turn, gives you a safe, high quality product. For this reason alone, OEMs will insist that their own suppliers apply ISO 26262 in their process.
Parts of ISO 26262
ISO 26262 standard consists of twelve parts, each referring to a different level of the product lifecycle:
Part 1: Vocabulary
This part specifies commonly used vocabulary, definitions, and abbreviations to maintain cohesion and prevent misunderstandings.
Part 2: Management of Functional Safety
This section describes the appropriate functional safety management methodology for automotive applications. It includes overall safety management and project-specific information related to management activities throughout various phases of safety lifecycle.
Part 3: Concept Phase
Part 3 is applied in the early product development phase. It requires performing a Hazard and Risk Assessment (HARA) based on Item Definition. It also includes defining Functional Safety Requirements, which are then given to the System Team. From this point onwards, the Safety Goals in the project should be defined.
Part 4: Product Development at the system level
Part 4 covers development issues on the system level. It describes specifications that need to be initiated for technical safety, such as the technical safety concept, system architectural design, item integration and testing.
Part 5: Product Development at the hardware level
Part 5 covers basic topics, such as hardware design, or evaluation of architectural hardware metrics. Under this section it is also required to evaluate safety goal violation caused by random failures.
Part 6: Product development at the software level
This part contains specifications for software safety, software architectural design, software unit design and verification, software integration and testing embedded software. At this point qualitative analyses, such as Failure Tree Analysis (FTA) and Failure Mode and Effect Analysis (FMEA) are often implemented.
Part 7: Production, operation, service, decommissioning
This part describes how to develop and maintain a production process for safety-related elements and items that are intended to be installed in road vehicles. It also includes information about operations, services and decommissioning for users which interface with safety-related items.
Part 8: Supporting processes
This part applies to all phases of product’s safety lifecycle. Some of the matters it covers are how to correctly proceed to verification, how to perform tool qualification, or how to introduce proven in-use arguments.
Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses
Part 9 covers ASIL decomposition, criteria for coexistence of elements, analysis of dependent failures, and safety analyses.
Part 10: Guidelines on ISO 26262
Part 10 is an overview of ISO 26262 extended with additional information. The goal is to improve the understanding of other parts and ISO 26262 in general.
Part 11: Guidelines on applying the standard to semiconductors
Part 11 provides detailed information to support semiconductor manufacturers and silicon intellectual property (IP). Its goal is to address how IP suppliers and integrators should work cooperate.
Part 12: Adaptation of ISO 26262 to motorcycles
The last part is an overview of the adaptation of the ISO 26262 standards for motorcycles. It describes safety culture, confirmation measures, hazard analysis and risk assessment, vehicle integration and testing, as well as safety validation.
ISO 26262 vs ISO PAS 21448 (SOTIF)
ISO 26262 doesn’t cover all the areas of functional safety. It lacks sections devoted for example to missuses, or automated driving. To complement these gaps ISO PAS 21448 (SOTIF) was introduced. There was a plan to include it in ISO 26262 as a fourteenth section, but finally it was released as a separate document.
SOTIF addresses some aspects of autonomous driving, where safety is not violated by the failure itself, but by the unspecified behavior of the vehicle. In other words, SOTIF is taking a more holistic look at the usage of the product than ISO 26262.
What is ASIL?
The Automotive Safety Integrity Level (ASIL) is a risk classification system introduced and defined by the ISO 26262. It’s used to define the safety requirements necessary to be in accordance with the ISO 26262. The classification criteria include several factors, such as the likelihood of an injury and its potential severity. Based on this information, the product can be then certified and considered fail-proof in terms of safety-critical functions.
There are four ASIL levels of hazard: A, B, C and D. There’s also the fifth one, MQ that is a non-hazardous level. ASIL from A to D means that there is some level of non-acceptable risk in the system and particular FUSA efforts are needed to raise the controllability of unwanted situations.
ASIL D is the highest degree of automotive hazard, which means that the product must meet the strictest safety requirements because it poses the highest risk of injury in case of malfunction. If a product is certified to pass the ASIL D requirements it is also compliant with any lower ASIL.
On the other side of the risk level spectrum, there’s QM, which stands for “Quality Management”. It represents the lowest risk level, which means there’s no automotive hazard, so in other words, there are no requirements to be assured under the ISO 26262.
How to determine ASIL level for automotive software?
The ASIL is determined through a Hazard and Risk Assessment (HARA), which includes assessing the Severity, Exposure and Controllability of the vehicle operating scenario.
Is it worth doing ASIL decomposition?
ASIL decomposition is a method of ASIL tailoring during the concept and development phases. It can be applied to the functional, technical, hardware or software safety requirements of an item or an element.
Following a list of safety goals, safety requirements are derived and refined. When the safety requirements are allocated to respective architectural elements, benefits can be obtained from assigning potentially lower ASIL to architectural components by using redundant solutions. By using decomposition of system-level requirement into multiple redundant sub-requirements allocated to different components, you get to a point where each sub-requirement (component) directly supports achieving the system-level requirement.
Decomposition schemes according to ISO26262
Decomposition strategy is described in ISO 2626-9:2018 Clause 5. Depending on the highest safety goal different ASIL decomposition strategies can be applied by the architect to design the system taking into consideration necessary technologies and best practices.
ASIL C decomposition schemas according to ISO26262-9:2018, 5.4.9
Development of decomposed elements should be done, as a minimum, in accordance with the ASIL requirements after performed decomposition. However, there is one exception regarding hardware level. Target values for evaluation of the hardware architectural metrics and the evaluation of safety goal violations due to random hardware failures should be taken from generic ASIL (before decomposition (ISO26262-9:2018, 5.4.11))
Decomposition has to take into account the technical feasibility. For example, an ASIL D requirement allocated to some functionality performed by ECU, cannot be decomposed as ASIL QM(D) for ECU and ASIL D(D) assigned to simple watchdog (acting as safety mechanism), as watchdog could be insufficient to cover all relevant failure modes of the microcontroller.
Decomposition is inherently connected with an effort of additional safety requirement creation. Of course, all these requirements have to be assigned with safety attributes as well as implementation and verification rules.
Secondly, decomposition will not take place if sufficient independence is not guaranteed. Meaning no common cause failures exist and freedom from interference is ensured between the decomposed elements. To ensure this, an analysis of dependent failures has to be conducted in accordance with ISO 26262-9:2018, Clause 5.
Another disadvantage is that because of different development and verification methods required for different ASILs, the development team could potentially no longer be able to keep track of the safety process requirements and as a result acceptance of the ISO26262 methods could be threatened.
Moreover, regarding hardware architecture design, additional hardware parts or components may be needed to implement redundancy. The increase in a number of parts will affect dependability. FIT target of the product can be compromised. In addition, in case of homogenous redundancy, there will be no argumentation on systematic failures avoidance.
Opportunities arising from ASIL decomposition
Risk reduction resulting from implementing redundancy is for sure one of the top advantages of performing decomposition.
Sometimes decomposition is the only way to meet highly demanding project requirements, due to lack of available technology.
Moreover, significant cost savings can be achieved when using decomposition. Especially when the ASIL decomposition is performed so that the majority of the software is classified as QM (Quality Managed) or ASIL A/B instead of ASIL C or D. The advantage will increase further when the part of the software that is subject to frequent changes will have low ASIL. Good safety architecture is characterised by the fact that only a small part of the software, which is not frequently modified, is developed according to high ASIL levels.
ASIL decomposition gives designers flexibility to meet the highest levels of diagnostic coverage. Taking advantage of decomposition principles, it enables the use of lower ASIL rated components while still meeting the needs of the highest ASIL systems. As a result, the decomposition adds the most value when it is done on the system level. Additionally, when decomposed elements are implemented as two completely independent channels, the system can be made resilient against common cause failures. However, it goes with the price of additional work mostly regarding process management.
How to achieve ISO 26262 compliance?
To ensure compliance with ISO 26262, each element of the system must be checked using Functional Safety principles. The process is not limited to products, but applies also to the delivery framework, which the product has been based on. Therefore, for safety-related systems, the whole safety engineering process must be confirmed.
For this purpose, ISO 26262 introduces the Confirmation Measures. These are grouped into three categories:
- Confirmation Review – concerns work product objectives (Functional Safety Concept, Software Architectural Design)
- Audit – covers the implemented process with regards to process objectives (ISO 26262)
- Assessment – delves into an item or the characteristics of an element with regards to process objectives (Body Control Module)
How to perform a confirmation review under ISO 26262?
When developing a product according to ISO 26262, additional activities have to be taken into consideration to meet the standard requirements. One of them is a clearly defined verification process, which characteristic differs dependent on the assigned ASIL. A specific form of review known as a confirmation review is introduced by the standard to diminish the risk. How to do it, at which stage, and by what mean is, however, not that clear and depends on different factors like the project’s ASIL. A specific form of review known as a confirmation review is also required in the automotive industry where functional safety is implemented.
Confirmation Review (CR) in its specification is very similar to verification review yet it is not exactly the same, what makes it even more interesting is that it requires a degree of organizational independence. The smaller the organization is, the bigger challenge is introduced.
Why is a confirmation review done?
The main goal of a confirmation review is to ensure compliance with ISO 26262 standard. It has to be performed for work products which are considered crucial during the safety lifecycle of the product, so don’t worry - not every single work product has to be independently confirmed. Given the respective independence of the reviewer, it enables validation of all the possible assumptions about selected methods, principles and evidence used to fulfil the standard requirements.
What is a confirmation review?
The definition included in the standard is straightforward:
“Confirmation that a safety-relevant work product provides sufficient and convincing evidence of their contribution to the achievement of functional safety considering the corresponding objectives and requirements of ISO 26262”
However, matters such as: what is meant by “sufficient and convincing evidence”, who performs such a review, and for which work product it is necessary, are not explained in the definition and that is yet another challenge in the achievement of functional safety.
What makes CRs unique is the required independence. ISO 26262 describes four levels of independence that are described below:
How is the confirmation review done?
If you would like to perform a confirmation review, here is a quick list of activities and respective aspects, prepared by our Functional Safety Engineer, Piotr Peret, that should be considered beforehand.
Identify which work products need confirmation review
For the answer, you should refer to ISO 26262 part 2. What must be highlighted again, is that the answer to that question depends on the highest ASIL in the given project but is also limited by the scope of the project. For example, Functional Safety Concept is usually out of scope for Software Projects developed as Safety Element out of Context (SEooC).
The table below lists the work products that should have a confirmation review and the required level of organizational independence for each.
Identify who shall be responsible for the confirmation review
A person or a group responsible for the confirmation review shall be appointed. The organization shall ensure that the person has the authority, competence and qualification to carry out CR. One or more assistants may be appointed to support the performance of the confirmation review. Such persons may lack independence from the developers of the corresponding item, elements or work products, but their independence shall be at least I1, as defined in Table 1, and the reviewer shall appraise their input to ensure an unbiased opinion is given.
Establish what shall be the evidence of the confirmation review
The above-mentioned person responsible for CR shall provide a report that contains a judgement of the achieved contribution to functional safety by the respective work product. To increase confidence in the achievement of the review objectives, the reviewer checks the correctness, completeness, consistency, adequacy and contents of the work product against the corresponding requirements of the ISO 26262 series of standards.
Plan when to perform the confirmation review
The main rule is that the confirmation reviews shall be finalized before the project release for production. Obviously, the sooner, the better. Having a plan prior to the development surely helps to establish a deadline. The confirmation review, even though time-consuming, might bring a finding relevant for the functional safety of the product, when there is still time to redesign the system. Late confirmation review might result in a situation where a resolution to an identified issue impacts the schedule of an entire project.
If the time schedule does not allow for separate confirmation reviews, a confirmation review and a verification review may be combined. However, to consider it a confirmation review it has to be ensured that the verification review is performed with sufficient independence.
If you would like to know more about other confirmation measures, or you have trouble achieving sufficient independence in your project, contact Spyrosoft Functional Safety team using the form below.