What is the ISO 26262 Functional Safety Standard?

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.

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.

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.

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.

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.

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.

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.

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.

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 a webinar on getting started with ISO 26262 qualification