ISO 26262: The Complete Guide

What is ISO 26262? Why is ISO 26262 needed?

ISO 26262 is an international standard for the 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.

ISO 26262 supports the whole product safety lifecycle: from management, development, and 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 practices 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 the 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 violations 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 the 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 the 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. ISO PAS 21448 (SOTIF) was introduced to complement these gaps. 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 behaviour 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 ISO 26262. It’s used to define the safety requirements necessary to be in accordance with 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, which 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, or in other words, there are no requirements to be assured under ISO 26262.

How to determine the 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 the system-level requirements 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

The 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.

Example:

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 the 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 a simple watchdog (acting as a safety mechanism), as watchdog could be insufficient to cover all relevant failure modes of the microcontroller.

Decomposition threads

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 that, an analysis of dependent failures has to be conducted in accordance with ISO 26262-9:2018, Clause 5.

Another disadvantage is that because of the 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 the number of parts will affect dependability. FIT target of the product can be compromised. In addition, in the 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 the flexibility to meet the highest levels of diagnostic coverage. Taking advantage of decomposition principles 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 also applies to the delivery framework, on which the product has been based. Therefore, for safety-related systems, the whole safety engineering process must be confirmed.

For this purpose, ISO 26262 introduces the Confirmation Measures, which are grouped into three categories:

• Confirmation Review – concerns work product objectives (Functional Safety Concept, Software Architectural Design)
• Audit – covers the implemented process with regard to process objectives (ISO 26262)
• Assessment – delves into an item or the characteristics of an element with regard 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 depending 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 means, however, is 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, the 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 organisational 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 organisation 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 finalised before the project is released 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 to 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 the Spyrosoft Functional Safety team using the form below.

How to conduct a Functional Safety (ISO 26262) Audit for software?

Functional Safety Audit is a formalised examination to identify gaps and anomalies in the established ISO 26262 process. It involves all relevant parties and comes with a specified scope, agenda, templates, checklist and roles.

It starts with determining who is a person responsible for process auditing, with the assertion of an independence level required for a particular confirmation measure that is determined by a specific Automotive Safety Integrity Level (ASIL).

The following organisation independence is required to conduct an ISO 26262 audit:

• For QM and ASIL A, there’s no requirement for performing a functional safety audit.
• ASIL B requires the lowest level of independence (I0) audit to be performed by a person not involved in the creation of any work product outside of the project.
• ASIL C requires that level 2 independence (I2) audit should be performed by a person independent from the team responsible for the creation, e.g., not under the same manager.
• ASIL D requires the highest level of independence (I3) audit to be performed by a person who is independent from the department responsible for creation. Ideally, a separate auditing body from a different company.

Once the independence level is determined, each and every ISO 26262 artefact that’s in the audit scope is evaluated from different perspectives , including:

1. Evaluation of the implemented process against its definitions or specifications in a safety plan.
2. Evaluation of the provided arguments for the process implementation.
3. Evaluation of the work products (across different projects).
4. Improvement recommendations (in case of non-compliance).

Since ISO 26262 doesn’t provide any template or framework for conducting audits, our certified Functional Safety Professionals (CFSE) with expertise to perform and supervise the auditing process can help you make sure that the audit agenda is fully covered and all audit steps are properly followed.

And what to do with the audit results?

Once the audit is finished, the results should be aggregated into an Audit Report that highlights:

• Points of major non-conformity
• Points of minor non-conformity
• Actions to be taken to improve or resolve identified gaps and anomalies.

The improvement recommendations should  be addressed next and possibly resolved by responsible parties.

It’s recommended to conduct a software safety audit regularly because it decreases the probability that an incorrect process implementation will impact different projects or that product inconsistencies will arise later in the Assessment. It also improves safety culture, makes it easier to identify weak points in safety development and limits product liability.

Take in mind, that Functional Safety Audits are most beneficial when performed in the early stage of the project/product development. Since the Functional Safety Audit shall be finalised before the production release, it’s advised to perform it as soon as the process in line with ISO 26262 is established in the company.

It’s also worth noting that, the ISO 26262 audit and Automotive SPICE assessment can be performed in a coordinated manner to avoid duplication of work and inconsistencies. For this purpose, an extended Process Assessment Model (PAM) is introduced.

How to do an ISO 26262 assessment?

When a product is under development in accordance with ISO26262, there always comes the time to assess if functional safety is achieved. ISO26262 gives us various possibilities to check if our design is ASIL-compliant, like verification and confirmation measures. The one which can help to identify gaps and show how to fix them is functional safety assessment.

Organisation of the assessment

One of the questions regarding the assessment is: When should it be performed? We have two aspects here, the first is when it’s required by the ISO. It is recommended starting from ASIL B and obligatory for ASIL C and D. As Functional Safety Assessment is one of the confirmation measures, there is also a required level of independence depending on ASIL.

• For QM and ASIL A, there is no recommendation for and against performing the assessment.
• ASIL B requires I0 independence, so assessment should be performed by a different person who is not involved in the project and work product creation.
• ASIL C requires I2 independence, and then the assessment shall be performed by a person independent from the team responsible for the creation of the work product.
• ASIL D requires I3 independence, which means the assessment shall be performed by a person who is independent regarding management and resources from the department responsible for work product creation, which could be, for instance, an external company.

The next thing to determine is the project development timeline. The assessment shall be performed and finalised in general before the start of production. The good practice and ISO recommendation is to plan the assessment at the beginning of the product development at the system level and progressively perform it during the development, for instance, for each project phase like the design or product validation samples.

Another question that’s important is: Who should plan the assessment? In other words, who is responsible for all activities related to the preparation and organization of the assessment? It’s usually a Functional Safety Manager or person responsible for a safety plan where all safety-relevant work products and activities are scheduled. This person shall also prepare all teams involved in product development to make them aware of what is required for the functional safety assessment and familiarise them with the assessment process.

The next question is: Who can perform the assessment? This question is already partially answered before in the Independence level of assessors part. To carry out a functional safety assessment, at least one person should be appointed. The functional safety assessor may appoint one or more assistants to support him with the assessment activities. Their independence is also defined and shall be at least I1 from the developers. Moreover, the assessors shall be given the authority to perform the assessment including: the scope of the assessment, the information to be made available and necessary support from the persons responsible for specific work products.

Scope of the assessment

The scope of a functional safety assessment shall include:

• The safety plan and all required work products – detail level can be tailored by an assessor; here also functional safety requirement management, including bidirectional traceability, can be verified.
• Functional safety process evaluation.
• The effectiveness of implemented safety measures.
• The arguments from persons responsible for work products why functional safety is achieved.
• Safety case.
• The rationale for the safety anomalies, if any.

The assessment shall also consider planning and results of other confirmation measures applicable for the project including functional safety audit, recommendations and corrective actions from previously performed assessments, for example, for a previous project milestone and results of the assessment activities regarding work products developed by suppliers.

An example of a functional safety agenda can be found in ISO26262-8 ANNEX D.

The result of the assessment

As a result of the functional safety assessment, the report, including the assessment result (accepted, conditionally accepted or rejected), should be created. The report may also include a recommendation for conditional acceptance. In that case, the conditions for acceptance shall be also defined. If the recommendation in a functional safety assessment report is rejected, then appropriate corrective actions (which could also be part of the report) should be planned and performed, and then the functional safety assessment shall be repeated.

To sum up, like in most automotive aspects, a good plan is the key to success. The same applies to the functional safety assessment. When it’s performed for each development phase or project milestone, the potential risks and gaps can be detected and corrected at the very early project stage. It can also help us with proper functional safety management within the project by identifying risks and definition of recommendations for corrective actions, as the assessment is usually performed by persons experienced with engineering and/or ISO-related processes. It’s like baking two roasts on one fire – on the one hand, we are fulfilling ISO26262 required activity, and on the other hand, we have a tool to identify and solve potential incompatibilities.

ISO 26262 Tool Qualification

The Tool Qualification is essential to achieve compliance with ISO 26262. Its aim is to ensure that all tools used in the project are reliable, any malfunctions are identified, and any issues that arise can be handled. It is important to take into consideration all tools involved in the development process, including those that are used indirectly.

How to qualify software tools according to ISO 26262?

The objective of tool qualification is to provide evidence that a software tool is suitable for use in the development of safety-related software according to the ISO26262 standard. Clause 11 of Part-8 comprises methods and guides which facilitate the tool qualification. Nevertheless, it is necessary to determine if the tool needs qualification or not. The answer to that question strongly depends on the use case, project scope and context.

Identify the tool

The usage of software tools can simplify or automate activities and tasks essential for the development of safety-related software. One of the goals of the qualifying process is to demonstrate awareness and broad knowledge concerning the particular tool. The first step on the road to achieving such a purpose is to properly identify the characteristics of the tool. At that stage, it is necessary to deliver information such as version number, vendor, calibration or configuration. It is a good practice to verify the official vulnerability log created by the tool vendor. to compare how the weaknesses of the given tool are affecting the use case in the safety-related project

Evaluate risks

The TCL (Tool Confidence Level) factors are graded from TCL1 up to TCL3. The TCL1, which means that for further steps, qualification methods are not necessarily applicable, so qualification itself is not required. TCL 2 and TCL 3, in those cases, it is assumed that the behaviour of the tool is not fully predictable, and certain qualification methods have to be applied. The Tool Confidence Level results from the combination of Tool Impact (TI) and Tool Error Detection (TD).

Tool Impact – is a coefficient to determine if the tool can introduce or fail to detect errors that may affect the safety-related features of the end product. If a violation of a safety requirement is not possible, ‘TI 1’ should be chosen. Otherwise, the tool impact is ‘TI 2’.

T is divided into three stages. Select ‘TD1’ when the tool owner has high confidence that the tool usage is not involved in safety-related activities, either its usage can not affect the product safety. The ‘TD2’ is a middle coefficient, it should be taken while the confidence level is not sufficiently high to state that the robustness and reliability of the tool cannot introduce unacceptable risk, even if there could be some protection feature in place. The last grade is ‘TD3’, it represents the reverse situation then in the ‘TD1’ case, so it should be chosen if the tool has a low level of confidence that its behaviour is proper in any required safety-related situation.

It is worth remembering that in a lot of cases, the choice between specific grades is strongly subjective and very often, it is difficult or even impossible to reach an unambiguous answer. However, the final result is based on specialist knowledge and experience.

Qualify the tool

ISO 26262 determines four methods that could be applied during the tool qualification. If the overall evaluation result is ‘TCL2’, or ‘TCL3’, the methods are the same, but the recommendation of usage in reference to the ASIL rate is different. The table below lists the possible combinations of the factors.

The first method on the list is ‘Increased Confidence from Use’. The confidence is derived from previous use of the tool under a similar development environment and use cases. But in new projects, the toolchain and the tool versions can change, so even if the use cases are the same, the “Increased Confidence from Use” might be hard to apply.

‘Evaluation of the Development Process’ is the method that requires a detailed analysis of the tool development process. Sometimes the tool vendor provides such qualification evidence along with the tool.

The method ‘Validation of the Software Tool’ is recommended for high ASIL compliance like ASIL C, or D. I basically relies on the development of tests that cover all safety-related use cases of the software tool. According to ISO 26262-8, it can be provided by the tool vendor as well.

The last method, ‘Development in accordance with a safety standard’, unfortunately that method is mostly inapplicable. The embedded software development environment is mostly PC-based, so usually, software tools are not designed to use in accordance with a safety standard.