ISO 26262’s Importance Widens Beyond Automotive

The ISO 26262 standard, which has become a mainstay since the trend toward vehicle electrification really took root a decade ago, is starting to gain traction in markets outside of automotive chip and system design.

At the center of this expansion is a focus on safety under a variety of conditions — extreme temperatures, unexpected vibration, or a collision that is unavoidable. This includes everything from drones to aerospace and robotics, where increasing levels of autonomy can easily transform a moving object into a safety hazard. ISO 26262 acts as something of a blueprint for best practices, including assessing what can go wrong and how to either fix it, or at least ensure that an autonomous machine fails gracefully, without injuring anyone or causing unexpected damage.

As the automotive industry gradually moves toward full autonomy, silicon plays an increasingly vital role, factoring into everything from infotainment, braking, and guidance. But the standard has become so entrenched that some OEMs outside of the automotive ecosystem are opting to follow it, with at least one autonomous drone manufacturer choosing to make its products ISO 26262-certified.

“At the highest level, there are two major parts to the standard,” said David Fritz, vice president of hybrid-physical and virtual systems at Siemens Digital Industries Software. “The first part is making sure everything that generates an output that ends up in the final product is certified, meaning there are certain qualifications that tool or that IP block needs to pass to be included. The second part is, once you use those tools and IP components and you put them together, there are certain types of functional safety-related tests that need to be done.”

Due to the robustness of ISO 26262’s requirements, its influence is growing in industries outside of automotive. George Wall, director of product marketing at Cadence, noted that other standards such as DO-254, which covers the design, verification, and validation of airborne electronic hardware, was directly influenced by IEC 61508, the predecessor of ISO 26262. “As a result, there is a lot of similarity between ISO 26262 and other existing standards. If there’s a new industry coming about — such as drones, or if boats become more autonomous, which is something that’s never really been a concern previously — then 26262 standards certainly could apply across other markets, as well.”

The difference lies in the level of certification, which can be slightly more comprehensive than what’s required in 26262. In essence, striving for ISO 26262 compliance can be a strong start for industries outside automotive, with other functional safety compliance then tacked on top to meet application-specific certifications.

“Everything in the automotive version of ISO 26262 does apply to other domains, as well, but you end up with the same level of competence,” said Siemens’ Fritz. “It’s not exhaustive and it’s not perfect. Unfortunately, that would just be way too difficult to do. On the other hand, ISO 26262 spun out of U.S. Department of Defense work, and that has been adopted by aerospace for some time. For example, we are currently working with an aerospace company that is creating a new device, and they are saying that all the tools and all the IP in that device need to be ISO 26262-compliant, which gets you about 80% of the way to DO 254 compliant. Then there’s another layer of certification for DO 254 on top of that. ISO 26262 is a bit more expansive and gives a bit more confidence behind the lower-level components than DO 254 does.”

Implementation challenges
ISO 26262 is meant to ensure the functional safety of each component and the system as a whole, regardless of the application domain. But implementing it adds a number of challenges. There are stringent documentation requirements, and the level of robustness required to qualify as ISO 26262-certified can affect the architecture of the chip, and the number and breadth of simulations. That, in turn, can increase the time and resources needed to reach final sign-off.

Much of the knowledge about how to implement this standard stems from the automotive market, which includes a variety of components, not all of which require the same level of robustness. For example, there is a big difference between a malfunctioning taillight and an airbag that doesn’t deploy or a steering system failure.

“When you look at a lot of the applications where our products go, such as steering systems, braking systems, the powertrain, whether it’s internal combustion engine or electric vehicle, those are already mission-critical systems,” said Bill Stewart, vice president of Automotive Americas marketing at Infineon. “Even with a lot of the ADAS systems, you’re taking sensor data, you’re converting that into what direction the vehicle is going to travel. You’re converting that into braking or throttle messages, and for much of that you must have very high quality devices. You must have a good understanding of whatever your potential failure modes are out there, because they’re going to occur, whether it’s in our chip, in the software, or an external event to the module. There are going to be things that impact functional safety. How do you prevent those failures? You measure and detect those failures so you can take the appropriate action.”

ISO 26262 ensures that level of quality, but it also allows for the difference in mission criticality by defining four different automotive safety integrity levels (ASILs).

“Before you decide whether or not you will implement ISO 26262, you really have to look at the target ASILs,” said Ron DiGiuseppe, automotive IP segment manager at Synopsys. “Those are application-based, and they have a range of safety integrity levels from ASIL A to ASIL D, along with a category called QM, which means it’s not safety critical so there’s no booster required. Once you look at the various risk levels, which means the potential of a failure and the impact of that failure, you need to implement a functional safety plan.”

Full documentation
While ISO 26262 levels can be widely applied across many components found in different markets and fulfilling a wide variety of functions, some areas remain vague. As a result, it’s not always clear how the standard is applied, what or how to test a component or system to ensure compliance, or how to ensure the standard is met. “In the end, you provide all of your documentation and all of your test results to show some regulatory body that, ‘Yes, we did do thorough testing,'” said Siemens’ Fritz. “Is it exhaustive testing? No. Do we know where the holes are? No. But we did what testing we could in the areas that were specified by this book.”

One of the most important aspects of 26262 is the documentation requirements. “The documentation is vital, because while the standard can be exhaustive, it can also be a bit exhausting,” Fritz said. “It covers such a wide variety of applications that there are no real coverage metrics, or anything like that, because of the complications behind the number of permutations that exist. And they’re different for every product that you produce, whether it’s a steering controller, a brake controller, or whatever.”

The documentation is particularly important due to the lack of defined tests to determine whether a system meets ISO 26262 requirements, but also because the standard covers both systemic faults and random errors, which can be a headache for designers.

“In terms of the systematic faults, there are a lot of procedures that have to be followed for documenting requirements and showing evidence that you have indeed followed specific processes to make sure your design meets those requirements, and that you’ve created a robust verification environment,” said Cadence’s Wall. “For example, you have to provide evidence that demonstrates you have followed those processes in the design. That takes care of the systematic side. On the random error side, there are a lot of different common techniques. What the standard itself specifies are safety integrity levels, which is one of the pieces borrowed from the old IEC 61508 standard. It says there are certain fault numerical coverage metrics that must be met to achieve that particular safety metric level, ranging from ASIL A up to ASIL D, with ASIL D being most strict.”

Architectural impacts
ISO 26262 requirements have a big impact on the chip architecture. Depending on the ASIL level, that can mean building in more redundancies than normally would be needed to ensure a random fault doesn’t cause an accident.

“The implementation of functional safety does impact the functionality and architecture of your design, and what is generally implemented is a safety processor, which can be considered a safety manager for an SoC,” Synopsys’ DiGiuseppe said. “Every SoC has its own applications processors, host processors, AI processors, VSB processors, and interfaces. The chip has an application and software stack, but generally there is an additional embedded processor that manages the safety since one of the requirements of ISO 26262 is a different interpretation of how to handle possible failures in some industries. You implement your automotive design to be as robust as possible, to operate for 15 or 20 years. That’s absolutely required. But functional safety requires you to have a different point of view, which is that you may design your chip to be very robust, but you have to have a use-case exercise of what happens to your product if there is a fault or a failure that affects the safety. You must design into your product how it will respond to that, and when you’re architecting your chip, you must have that in mind.”

This could include redundancy to deal with everything from higher than expected ambient temperatures to alpha particles, which can cause bit flips in memory.

“There are a number of common techniques around these types of redundancy, including periodic monitoring of the execution flow, and then, digging that down to the next level, a common failure mode,” said Cadence’s Wall. “Memories are particularly sensitive to alpha particles, and that would be a random failure. Nobody can predict when an alpha particle is going to hit, and one of the common techniques for addressing memory failures is using error correction codes, or ECC, which is basically a form of information redundancy where a little bit of extra information is added to each memory word to say, ‘Is this memory bit still valid?’”

Other situations may include the addition of sensors to detect errors along a signal path, or additional parity that can act as a fail-safe.

“You add functionality for safety processors, but you also have to add safety mechanisms, which is functionality that you add, such as cyclic redundancy checks that could raise a flag if there is a signaling issue. If there is a failure of your control logic, you might want to add a safety mechanism like parity, or you can have parity on the data path or ECC on your memories,” DiGiuseppe explained. “This is functionality that is added to the automotive chips that you really don’t need on consumer device chips, or even data center chips. You don’t need parity on your control logic for different applications. But for automotive, you must add this additional safety functionality throughout the whole chip, including the IP in there.”

Conclusion
The creation of ISO 26262 more than a decade ago has had an enormous effect on the design of automotive chips, and it will only continue to grow in importance with the shift toward software-defined vehicles and self-driving controls. The standard also is being adopted for some uses outside the automotive domain, such as in autonomous drones, robotics, and aerospace, due to the stringent and comprehensive functional safety requirements.

Key aspects of 26262 that designers must keep in mind include documentation, which is particularly important given the lack of standardized functional safety tests for chips used these systems. Design engineers also should be aware of how efforts to meet ISO 26262 certification can affect chip architectures, due to the redundancies that may be necessary to prevent catastrophes due to random faults and other errors.