By using ISO 26262 as agreed‑upon set of rules, engineers and sales can get along better, and customers get safer automobiles.

“Shoot the engineer and ship the product,” is a fun maxim that has stood the test of time. Engineers and developers like to get it right, step back, and take pride in the beauty of their work. CEOs, marketing, and sales want to get it shipped, on time and below budget.

That’s OK if it’s a small drone, but when it comes to automotive safety, who wins?

Counter‑intuitively, the labyrinthine ISO 26262 standard for functional safety may actually have provided a speedy solution to this seemingly eternal tug‑of‑war, but both sides must recognize the importance of the standard, and work together to minimize the cost of adhering to it.

ISO 26262 was defined in 2011 by the International Standards Organization as an international standard for functional safety of electrical and/or electronic systems in production automobiles. It is an adaptation of Functional Safety IEC 61508 and arrived just in time for the rapid adoption of electronics and software for automotive driving assistance systems (ADAS), as well as the increasing focus on autonomous vehicles (Figure 1).

 
Figure 1: ISO 26262 arrived just in time to define clear functional safety requirements for automobiles that are becoming increasingly reliant on electronic hardware and software. (Figure source: Clemson University Vehicular Electronics Laboratory)

It is a risk‑based safety standard, where the goal is to assess risks and define measures to mitigate their effects to avoid or control catastrophic failures. With so much complexity and 100s of millions of lines of code, there is a good chance something will go wrong. However, even if that failure happens in a critical subsystem, there is a good chance that by adhering to ISO 26262 requirements and guidelines, the driver and passengers in a vehicle will emerge unscathed.

Life‑cycle safety
ISO 26262 has a wide scope, from product conceptualization through to design, development, operation, service, and decommission at end of life. This is important, as a lapse at any point along that path could undermine what came before and what comes after.

Specific to automotive systems and with regard to passenger and driver safety, the standard has four Automotive Safety Integrity Levels (ASILs), A, B, C, and D. The ASIL is assessed right at the start of product development and asks the fundamental question of what will happen to the occupants of a vehicle – and other road users – if a failure occurs? For example, a failure of the anti‑lock brakes or engine’s electronic control unit (ECU) requires more attention than the failure of an in‑cabin USB charger.

The estimation is 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. The answer to this question determines the ASIL level, with D having the most safety critical processes and strictest testing regulations. For example, a failure of the anti‑lock brakes or engine’s electronic control unit (ECU) may be ASIL‑D, while an in‑cabin USB charger would be an “A” issue.

Lowering the cost of ISO 26262 compliance
Both hardware and software are addressed by ISO 26262 and need to be qualified through extensive testing. For hardware, many issues can be resolved or circumvented by using pre‑qualified modules where possible, but it must be accompanied by the documentation and a good supplier can help you get through the qualification process.

For software, the key word is standards: use MISRA coding guidelines. The group has even developed MISRA Autocode, which are guidelines for users of control‑system modeling packages, in much the same way as it developed MISRA‑C as a guideline to developing code directly.

There is another keyword, and while it applies to both hardware and software, it’s mostly an issue with software. That keyword is test. It bears repeating: Test, test, test. Thankfully, the standard does require test tool qualification and various tool chains are available from multiple vendors (Figure 2). Just make sure to verify the Tool Confidence Level (1 to 4) based on what comes out of the software tool qualification plan (STQP) that commences early in the design cycle.

Figure 2: Software is an increasingly important and complex element of system design and is addressed in Part 6 of ISO 26262 in a V‑shaped cycle. Ansys provides a useful Technical Paper for related safety model‑based approach applications. (Figure source: Ansys)

The testing phase is arduous, but the rewards far outweigh the costs of taking the time to do it right. A failure found in the field can be 10x more expensive than one found during the development stage. However, test and measurement companies and embedded tools providers provide many resources to model and execute a compliance program.

It seems like a lot of extra steps to have to go through so the immediate gains of ISO 26262 and its qualification processes may seem like extra work, time and expense. Be assured, however, that it’s worth it. An unmitigated catastrophic event in the field can haunt a brand for many years, particularly if it results in loss of life.

On this point, engineers, sales, and marketing can all agree. ISO 26262 therefore provides a set of common rules they can all adhere too with less subjectivity and more confidence in the final product’s quality. In cases where engineering is still pressured to ship, it often comes down to having the courage to say, “No,” for the sake of the customer, your company, and your development team.

A small note on safety versus security: A system can be secure without being safe, but a system isn’t safe unless it’s also secure.