What is the ISO 26262 Functional Safety Standard?

Updated Mar 5, 2019

Overview
Safety practices are becoming more regulated as industries adopt a standardized set of practices for designing and testing
products. ISO 26262 addresses the needs for an automotive-specific international standard that focuses on safety critical
components. ISO 26262 is a derivative of IEC 61508, the generic functional safety standard for electrical and electronic
(E/E) systems. This paper covers key components of ISO 26262, and qualification of hardware and software. Additionally,
this paper covers ISO 26262 test processes and qualifying tools for ISO 26262 compliance.

Contents
Background
Key Components of ISO 26262
Qualification of Hardware Components
Qualification of Software Components
"Proven in Use" Argument
Applying to Current Processes
Test Tool Qualification
Next Steps

Background
Increasing complexity throughout the automotive industry is resulting in increased efforts to provide safety-compliant
systems. For example, modern automobiles use by-wire systems such as throttle-by-wire. This is when the driver pushes
on the accelerator and a sensor in the pedal sends a signal to an electronic control unit. This control unit analyzes several
factors such as engine speed, vehicle speed, and pedal position. It then relays a command to the throttle body. It is a
challenge of the automotive industry to test and validate systems like throttle-by-wire. The goal of ISO 26262 is to provide a
unifying safety standard for all automotive E/E systems.

The Draft International Standard (DIS) of ISO 26262 was published in June 2009. Since the publication of the draft, ISO
26262 has gained traction in the automotive industry. Because a public draft standard is available, lawyers treat ISO 26262
as the technical state of the art. The technical state of the art is the highest level of development of a device or process at a
particular time. According to German law, car producers are generally liable for damage to a person caused by the
malfunction of a product. If the malfunction could not have been detected by the technical state of the art, the liability is
excluded [German law on product liability (§ 823 Abs. 1 BGB, § 1 ProdHaftG)].

Implementing ISO 26262 allows leveraging a common standard to measure how safe a system will be in service. It also
provides the ability to reference specific parts of your system because of a common vocabulary provided by the standard.
This falls in line with other safety-critical application areas; a common standard provides a way to measure how safe your
system is.

Key Components of ISO 26262

ISO 26262 uses a system of steps to manage functional safety and regulate product development on a system, hardware,
and software level.

The ISO 26262 standard provides regulations and recommendations throughout the product development process, from
conceptual development through decommissioning. It details how to assign an acceptable risk level to a system or
component and document the overall testing process. In general, ISO 26262:

Provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning)
and supports tailoring the necessary activities during these lifecycle phases
Provides an automotive specific risk-based approach for determining risk classes (Automotive Safety Integrity Levels,
ASILs)
Uses ASILs for specifying the item's necessary safety requirements for achieving an acceptable residual risk
Provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety
being achieved
Automotive Safety Lifecycle
Ten volumes make up ISO 26262. It is designed for series production cars, and contains sections specific to automotive.
For instance, section 7 of ISO 26262 gives specific safety requirements for production, operation, service, and
decommission.

The ISO 26262 automotive safety lifecycle describes the entire production lifecycle. This includes the need for a safety
manager, the development of a safety plan, and the definition of confirmation measures including safety review, audit, and
assessment. These requirements are intended to be used for the development of the E/E systems and elements.
This paper mainly focuses on the development section of the lifecycle. The development section of ISO 26262 includes
defining the system, system design, functional safety assessment, and safety validation.

Automotive Safety Integrity Level (ASIL)

The ASIL is a key component for ISO 26262 compliance. The ASIL is determined at the beginning of the development
process. The intended functions of the system are analyzed with respect to possible hazards. The ASIL ask the question, “If
a failure arises, what will happen to the driver and associated road users?"

The estimation of this risk, based on a combination of the probability of exposure, the possible controllability by a driver, and
the possible outcome’s severity if a critical event occurs, leads to the ASIL. The ASIL does not address the technologies
used in the system; it is purely focused on the harm to the driver and other road users.

Each safety requirement is assigned an ASIL of A, B, C, or D, with D having the most safety critical processes and strictest
testing regulations. The ISO 26262 standard specifically identifies the minimum testing requirements depending on the ASIL
of the component. This aids in determining the methods that must be used for test. Once the ASIL is determined, a safety
goal for the system is formulated. This defines the system behavior needed to ensure safety.

For example, let us consider a windshield wiper system. The safety analysis will determine the effects that loss of wiper
function can have on the visibility of the driver. The ASIL gives guidance for choosing the adequate methods for reaching a
certain level of integrity of the product. This guidance is meant to complement current safety practices. Current automobiles
are manufactured at a high safety level and ISO 26262 is meant to standardize certain practices throughout the industry.

Qualification of Hardware Components

Hardware qualification has two main objectives: to show how the part fits into the overall system and to assess failure
modes. Basic hardware components can be qualified with standard qualification, but more complex parts require evaluation
through ASIL decomposition and testing. Hardware components are typically qualified by testing the part in a variety of
environmental and operational conditions. The test results are then analyzed with various numerical methods and
presented in a qualification report along with the testing procedure, assumptions, and input criteria.
Qualification of Software Components
Qualifying software components involves activities such as defining functional requirements, resource usage, and predicting
software behavior in failure and overload situations. This process is dramatically simplified by using qualified software
during development of an application. Qualified software components are generally well established products that are re-
used across projects and include libraries, operating systems, databases, and driver software.

To qualify a software component, the standard requires testing under normal operating conditions along with inserting faults
in the system to determine how it reacts to abnormal inputs. Software errors such as runtime and data errors are analyzed
and addressed throughout the design process.

"Proven in Use" Argument

Hardware and software components can comply with ISO 26262 requirements through the “proven in use” argument. This
clause applies when a component has been used in other applications without incident. ISO 26262 also addresses older
systems that have been proven in use. In many circumstances, it does not make sense to apply a standard to a system that
has been previously deployed in millions of vehicles. For instance, many systems in currently manufactured cars were
manufactured to a high level of safety before the publication of ISO 26262. Throughout use in the real world, these safety-
critical components have shown that they can exhibit reliable behavior. Reliable systems that remain unchanged from
previous vehicles are still certifiable with ISO 26262. The combination of certifiable components from similar applications
and from older, widely-deployed applications greatly reduces the overall system complexity.

Applying to Current Processes

One of the main challenges in implementing a new standard like ISO 26262 is applying it to current processes. Typically
with a new standard, pilot projects are used to show the implementation of the standard and the effects that it has on
current processes. The results so far show that ISO 26262 adapts well to current safety concepts in the industry.
Companies are already seeing the benefits of evaluating risk and doing hazard analysis early in the development process
and applying testing throughout.
It is important for companies looking to implement 26262 to understand that the goal is analyze risk early in the
development process, establish the appropriate safety requirements, and fulfill these requirements by testing during
development.

Test Tool Qualification

During ISO 26262 development, test is a critical component. Safety-critical systems must react properly to test scenarios
and stay within specified safety limits when exposed to various human and environmental inputs. Using high quality test
systems can improve a product’s performance, increase quality and reliability, and lower return rates. It is estimated that the
cost of a failure decreases by 10 times when the error is caught in production instead of in the field and decreases 10 times
again if it is caught in design instead of production. By catching these defects and collecting the data to improve a design or
process, test delivers value to your organization. Driving innovation into this process through technology insertion and best-
practice methodologies can generate large efficiency gains and cost reductions. It is easy to look past the tools and think
only about the design of the system, but in reality the tools are very important to the safety of the end user.

ISO 26262 recognizes that using widely accepted software tools simplifies or automates activities and tasks required for the
development of electrical, electronic, and software elements that provide safety-related functions. Before explaining the
details of the tool qualification process, it is important to define an important part of tool qualification, the Tool Confidence
Level.

Tool Confidence Level

From the inputs and outputs of the tool, typical (or reference) use cases are developed. The analysis of these use cases
leads to the determination of the Tool Confidence Level, or TCL. The TCL and ASIL determine the level of qualification
required for the software tool. Two specific areas are evaluated to determine the confidence level:

The possibility of a malfunctioning software tool and its erroneous output can lead to the violation of any safety
requirement allocated to the safety-related item or element to be developed
The probability of preventing or detecting such errors in its output
The Tool Confidence Level is determined to be TCL1, TCL2, TCL3, or TCL4, with TCL4 being the highest level of
confidence and TCL1 being the lowest level of confidence.
The Tool Qualification Process
In order to qualify a tool under ISO 26262, there are many requirements. For instance, the ASIL must already be
determined. The tool must have a user manual, a unique identification and version number, a description of the features,
installation process, and environment (to name a few). ISO 26262 requires the following tool qualification work products:

Software Tool Qualification Plan

Software Tool Documentation
Software Tool Classification Analysis
Software Tool Qualification Report
Software Tool Qualification Plan
The Software tool Qualification Plan (STQP) is created early in the development life cycle of the safety-related item. It
focuses on two areas: planning for the qualification of a software tool, and listing the use-cases that demonstrate the tool is
classified with the required level of confidence.

The STQP must include items such as a unique identification and version number of the software tool, use cases, the
environment, description, user manual, and the pre-defined ASIL.

Software Tool Classification Analysis

The main purpose of the Software Tool Classification Analysis (STCA) is to determine the Tool Confidence Level. There are
two main components that determine the TCL. The first is the Tool Impact (TI). The second is the Tool Error Detection
(TD). Based on these two components, the appropriate TCL is chosen.

TI1 or TI2 are the two classes of Tool Impact. TI1 is chosen when there is an argument that there is no possibility that the
malfunctioning software tool can violate a safety requirement. For all other cases, TI2 is chosen.

For example, let us say that a tool produces a typo in the documentation for a particular software function. This can be
considered a nuisance only, and does not violate the safety requirement under test. This would results in a tool impact of
TI1. If the tool produces an error that could change the behavior of the system in any way, then TI2 will be chosen.

The Tool Error Detection is classified as TD1 through TD3. TD1 is chosen if there is a high degree of confidence in the
tool's ability to detect an error where TD3 is chosen for a very low degree of confidence, often when it is determined that the
error can only be detected randomly.

For example, a software tool might check a design model for errors. In this case, static analysis of the model is performed.
While static analysis is good, it cannot check all possible violations in the model. It is also important to note that this does
not necessarily imply that the model is incorrect; it simply means that additional testing is needed. This scenario results in a
‘medium’ degree of confidence, or TD2.

Tool Error Detection

 TD1 TD2 TD3

Tool TI1 TCL1 TCL1 TCL

Impact
TI2 TCL1 TCL2 TCL
Once the Tool Impact (TI) and Tool Error Detection (TD) are determined, a value of TCL 1 to TCL 3 is given, depending on
required level of confidence. Sometimes multiple use cases can result in multiple TCLs. In this case, the highest TCL is
used. For each software tool, the user needs to carry out the tool classification.

Software Tool Documentation

Several pieces of information must be provided to ensure proper usage of the software tool.

Description of features
Description of the installation process
User manual
Operating environment
Expected behavior in abnormal conditions
Software Tool Qualification Report
The Software Tool Qualification Report contains the results and evidence that the tool qualification was completed and
requirements fulfilled. Any malfunctions or erroneous outputs during validation should be analyzed and documented here.

Increased Confidence from use

An important aspect of tool qualification is the concept of increased confidence from use. If the qualification requirements
can already be demonstrated for a given tool, then further qualification is no longer needed. This can dramatically save cost
and time throughout the development process. However, qualification requirements must be demonstrated for each safety-
related item or element before used in development of that item. In order to demonstrate this, the tool must demonstrate
that:

It has been used previously for the same purpose with comparable use-cases
The specification of the tool is unchanged
There has not been a violation of safety requirements allocated to the previously developed safety-related item.
For example, let us say that test tool A was used for validating requirements for car X’s ECU (Engine Control Unit). If test
tool A has not violated any safety requirements and remains unchanged, then it can be used to validate car Y’s ECU given
that car Y’s ECU is being used in similar manner as car X's ECU.

Next Steps
To see how National Instrument’s test tools can be used for testing safety-related items, take a look at NI’s Best Practices
for Testing Safety Compliant Systems. It covers techniques like model-in-the-loop testing and hardware-in-the-loop testing
throughout the entire development process. Additionally, it discussed the advantages and efficiency gains of component re-
use.
Additional Resources
NI Best Practices for Testing Safety Compliant Systems

Watch an introductory webcast on ISO 26262 qualification