What is ISO 26262 Functional Safety Standard?

What is an Item in ISO 26262 Automotive Functional Safety

It is the adaptation of IEC 61 580, which is applied to electronic or electrical safety related systems. These systems are made up of software and hardware components in vehicles. You can reach out to functional safety experts to help you navigate the risk-based safety standard it provides. This is key because functional safety is crucial in the development of safety-critical automotive systems. You will need a functional safety team, one that has an unparalleled track in functional safety testing. This does not apply to autonomous vehicles as the assumption is that someone is driving.

Increasing complexity throughout the automotive industry results in increased efforts to provide safety-compliant systems. For instance, modern automobiles utilize by-wire systems such as throttle-by-wire. The driver applies pressure on the accelerator, and a sensor in the pedal relays a signal to an electronic control unit. This control system analyzes vehicle speed, pedal position, and engine speed. It then communicates a command to the throttle body. The automotive industry’s challenge is testing and validating systems such as throttle-by-wire. The goal of ISO 26262 is to offer unifying safety standards for all automotive E/E systems and help in your functional safety management. You increase your levels of safety by strengthening any passive safety systems or control systematic failure that may occur. 

The DIS – Draft International Standard of ISO 26262 was published in June 2009. From the moment of the publication of the draft, ISO 26262 has gotten more traction in the automotive industry. Due to a public draft standard being available, lawyers treat ISO 26262 as the technical safety state of the art. The technical condition of the art is the highest level of development of a process or device at a particular time. As outlined by German law, car producers are generally liable for damage to a person caused by the malfunctioning of a product. If the current technical equipment could not have detected the malfunction, the liability is not included [German law on product liability (§ 823 Abs. 1 BGB, § 1 ProdHaftG)].

Putting into practice ISO 26262 permits leveraging a usual standard to measure how safe a system will be in service. It also gives you the ability to reference particular parts of your system due to a common vocabulary presented by the standard. This is similar to other safety-critical application areas; a common standard offers a way to measure how safe your system is.

This system does not deal with safety hazards that are related to release of energy, fires, corrosion, toxicity, flammability, smoke, reactivity, or electric shock. 

 Table of Content:

1. Critical Features of ISO 26262
2. Qualification of Hardware Components
3. Qualification of Software Components
4. “Proven in Use” Argument
5. Applying to Current Processes
6. Test Tool Qualification
7. Evolution of ISO 26262

Critical Features of ISO 26262

ISO 26262 utilizes a system of techniques of management of functional safety and regulates automotive product development on a system, hardware, and software level.

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

• It gives an automotive safety lifecycle (service, operation, development, management, production, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases.
• It facilitates an automotive-specific risk-based approach for discovering risk classes, ASILs.
• It utilizes Automotive Safety Integrity Levels (ASILs) for specifying the item’s necessary safety requirements for achieving an acceptable level of residual risk.
• It offers the criteria for validation and confirmation safety measures to ensure a sufficient and acceptable system level of safety is achieved.

Automotive Safety Lifecycle

Ten volumes make ISO 26262. It is created for series production cars and holds sections specific to automotive. For instance, section 7 of ISO 26262 specifies safety requirements for production, operation, service, and decommissioning. The ISO 26262 automotive safety life cycles recount the whole product lifecycle. This includes developing a safety plan, the need for a safety manager as well as the definition of confirmation measures, such as audit, safety review, and risk assessment. These requirements are intended to develop the electric and electronic E/E systems and elements. This paper mainly discusses the development section of the lifecycle. The development section of ISO 26262 comprises defining the system, functional safety assessment, safety validation, and system design.

Automotive Safety Integrity Level (ASIL)

The Automotive Safety Integrity Level is a crucial element for ISO 26262 compliance. The ASIL is identified at the start of the entire development process (concept phase). The planned functions of the system are analyzed concerning possible safety hazards (safety risks) and expected safety goals. The Safety Integrity Level asks, “If a failure arises, what will happen to the driver and associated road users?” This review looks at specifications, evaluation of software analysis, and design analysis. 

The estimation of this risk, based on the probability of exposure, the possible controllability by a driver, and the potential outcome’s severity if a critical event occurs, leads to ASIL. Technologies used in the system are not addressed by the Safety Integrity Level; it is solely anchored on the damage/injury to the driver and other road users.

All safety requirements are assigned an Automotive Safety Integrity Level of ASIL A, B, C, or D, with D having the highest number of safety-critical processes and stringent testing regulations. The ISO 26262 standard distinctly identifies the minimum testing requirements depending on the ASIL of the component. This is beneficial when determining the methods you must use for the vehicle test. Once the Safety Integrity Level is selected, a safety aim for the system is formulated. This outlines the system behavior needed to ensure safety.

For instance, let us consider a windshield wiper system. The safety analysis will discover the effects of doing away with the wiper function on the driver’s visibility. The ASIL guides choosing the adequate methods for reaching a certain level of product integrity. This instruction is meant to complement current safety practices. Recent automobiles are manufactured at a high safety level, and ISO 26262 is intended to standardize certain practices. Automotive Safety Integrity Level can also be utilized in safety oriented analysis for unique E/E safety-related systems alongside special purpose vehicles like modern vehicles that are designed for drivers with disabilities. 

Qualification of Hardware Components

Hardware qualification has two main goals: to show how the part fits into the overall system and assess random hardware failure modes. Hardware components are usually prepared by testing the function in various environmental and operational conditions. The evaluation of the hardware level is followed by the test results being analyzed with multiple numerical techniques and presented in a qualification report along with the input criteria, assumptions, and testing procedure. You can qualify essential hardware components with standard qualifications, but more complex features require evaluation through ASIL decomposition and testing.

Qualification of Software Components

Capable software components are generally well-established products re-used across projects and include libraries, operating systems, databases, and driver software. Qualifying software components involves defining resource usage and functional requirements and predicting software behavior in overload and failure situations. This process is dramatically made easier by using qualified software during the development of an application software. To qualify a software component, the standard needs testing under normal operating conditions and the insertion of faults in the system to identify how it reacts to abnormal inputs. Software errors such as data and runtime are analyzed and addressed throughout the design process.

“Proven in Use” Argument

Using the ” proven in use ” argument, hardware and software components can follow ISO 26262 requirements and the “proven in use” argument. This clause applies when a feature has been utilized in other applications with no incidents occurring. ISO 26262 also deals with older systems that have been proven in use. In numerous circumstances, it is not logical to apply a standard to a system that has been previously deployed in millions of vehicles (road vehicles or special vehicles). For example, several systems in currently manufactured cars were manufactured to a high level of safety before ISO 26262. When used in the real world, these safety-critical components have indicated that they can exhibit reliable behavior. Reliable systems unchanged from previous vehicles are still certifiable with ISO 26262. Combining certifiable features from similar applications and older, widely-deployed applications dramatically reduces system complexity.

You can get a provider who offers you: GAP analysis assessment – suitable for the safety development processes such as risk assessment (HARA), independent safety assessments, and systems safety assessments (FTA, FMEA, among others). FMEA – Failure mode effect and diagnostic analysis (FMEDA). Failure Tree Analysis (FTA) Certification. 

Applying to Current Processes

One of the main issues faced when implementing a new standard such as ISO 26262 is applying it to contemporary processes. Usually, with a new standard, pilot projects are utilized to show the implementation of the standard and its effects on existing processes. Companies already see the benefits of evaluating risk and doing hazard analysis early in the development process and applying to test throughout. The results show that ISO 26262 adapts well to current safety concepts in the industry.

It is crucial for companies looking to implement 26262 to understand that the goal is to analyze risk early on in the development process, indicate the appropriate safety requirements, and fulfill these requirements through testing in the course of development.

Test Tool Qualification

During ISO 26262 development, the test is a key component. When exposed to varying human and environmental inputs, safety-critical systems like electronic systems in vehicles or motorcycles, mopeds must react adequately to test scenarios and stay within specified safety limits. Using high-quality test systems can improve a product’s performance, lower return rates, and increase quality management and reliability. It is estimated that the price of failure diminishes by ten times when the error is identified in production instead of in the field and drops ten times again if it is seen in design instead of production—detecting these defects and collecting the data to improve a technique or process. Driving innovation into this process through best-practice methodologies and technology insertion can generate significant cost reductions and efficiency gains. It is easy to ignore the tools and consider only the system’s design, but in reality, the tools are essential to the end user’s safety.

ISO 26262 recognizes that utilizing widely accepted software tools simplifies or automates activities and tasks required to develop electrical, software, and electronic components that offer safety-related functions. Before explaining the particulars of the tool qualification process, it is crucial to define an essential element of tool qualification, the Tool Confidence Level.

The Tool Confidence Level

The Automotive Safety Integrity Level and TCL determine the level of qualification required for the software development tool. Typical (or reference) use cases are developed from the inputs and outputs of the tool. The gap analysis of these utilized cases leads to the determination of the TCL or Tool Confidence Level. Two particular areas are evaluated to establish the confidence level:

• The probability of a malfunctioning software tool and its erroneous output can violate any safety requirement allocated to the safety-related element or item to be developed by safety engineers.
• The likelihood of preventing or detecting such errors in its output

The Tool Confidence Level is identified as TCL1, TCL2, TCL3, or TCL4, with TCL1 being the lowest level of confidence and TCL4 being the highest level of confidence.

The Tool Qualification Process

To qualify a tool under the ISO 26262, there are many conditions. For example, the Automotive Safety Integrity Level must already be determined. The device must have a unique identification, user manual, version number, a description of the features, environment, and installation process (to name a few). ISO 26262 needs the tool qualification work products listed below:

1. Software Tool Qualification Plan
2. Software Tool Documentation
3. Software Tool Classification Analysis
4. Software Tool Qualification Report

Software Tool Qualification Plan

The STQP Software tool Qualification Plan is created early in the development life cycle of the safety-related item. It focuses on planning for the qualification of a software tool and listing the use-cases that demonstrate the device is classified with the required level of confidence. The STQP must include a version number and a unique identification of the software tool, use cases, the description, environment, user manual, and the pre-defined ASIL.

Software Tool Classification Analysis

The primary purpose of the Software Tool Classification Analysis (STCA) is to determine the Tool Confidence Level. Two main components determine the TCL. The first is the Tool Impact (TI). The second is Tool Error Detection (TD). Based on these two elements, a suitable TCL is picked. The two classes of Tool Impact are TI1 or TI2. TI1 is used when there is an argument that there is no possibility that the malfunctioning software tool can break a safety requirement. For all other cases, TI2 is picked.

For instance, let us say that a tool produces a typo in the documentation for a specific software function. This can be thought about as a nuisance only and does not break the safety requirement under test. This would result in a tool impact of TI1. If the tool churns out an error that could change the system’s behavior, then TI2 will be picked.

The Tool Error Detection is categorized as TD1 through TD3. TD1 is picked if there is a high level of confidence in the tool’s ability to detect an error, where TD3 is selected for a meager degree of certainty, frequently when it is concluded that the error can only be found randomly.

For instance, a software tool might check a design model for errors. In this case, a static analysis of the model is performed. While static analysis is good, it cannot review all possible violations in the model. It is vital to note that this does not necessarily imply that the model is wrong; it simply means that more testing is required. This situation results in a ‘medium’ degree of confidence, or TD2.

Tool Error Detection

TD1

TD2

TD3

Tool Impact

TI1

TCL1

TCL1

TCL1

TI2

TCL1

TCL2

TCL3

The user needs to perform the tool classification for each software tool. Once the Tool Error Detection (TD) and Tool Impact (TI) are identified, a value of TCL 1 to TCL 3 is provided, depending on the required confidence level. Sometimes multiple use cases can result in numerous TCLs. In this case, the highest value of TCL is used. 

Software Tool Documentation

You must provide numerous pieces of information to ensure proper usage of the software tool.

1. Description of features
2. Description of the installation process
3. User manual
4. Operating environment
5. The anticipated behavior in abnormal conditions

Software Tool Qualification Report

The STQ Report: Software Tool Qualification Report holds the results and evidence that you fulfilled the tool qualification and requirements. Any erroneous outputs or malfunctions in the validation process should be analyzed and documented here.

Increased confidence in the use

A crucial functional safety aspect of tool qualification is the concept of increased confidence from use. If you can already demonstrate the qualification requirements for a given tool, further qualification is no longer required. This can drastically save on cost and time throughout the development process. But you must demonstrate qualification requirements for each safety-related item or element before being used to develop that item. To illustrate this, the tool must prove that:

• It has been utilized before for the same purpose with similar use-cases.
• The specification of the device is not altered.
• There has not been a breach of safety requirements allocated to the safety-related item developed before.

For instance, you used test tool A to validate car X’s Engine Control Unit (ECU software). If test tool A has not broken any safety requirements and remains unchanged, you can use it to validate car Y’s ECU, given that car Y’s ECU is being used similarly to car X’s ECU.

Evolution of ISO 26262

2018 saw ISO 26262 undergo a major update, adding two new standards: requirements for semiconductors and for trucks, motorcycles, and buses. It was already a different system from others through its Society of Automotive Engineers (SAE) which has long provided standards for rating automotive horsepower and currently defines best practices for cybersecurity in SAE J3061. The SAE is actively involved in defining vehicle autonomy levels and developing automotive testing standards. It also has AEC-Q100 (which was established by the Automotive Electronics Council) specializing in reliability, particularly stress testing for integrated circuits in automotive applications.

The benefit of utilizing ISO 26262 is OEMs which can vet your supply chain and make sure that E/E safety hazards don’t appear later in the production process, when issues are far costlier to fix. You may choose to apply coding standards, for instance AUTOSAR or MISRA, making it simpler to verify code against safety guidelines. You can also establish traceability in the interface to the tests, source code, and issues.