Conflating ISO 26262 and DO-254

If you’re in the ASIC business, by now you should have a rough understanding of ISO 26262, the safety standard for automotive electronics. You may be less familiar with DO-254 which has somewhat similar intent for airborne electronics. Unless, that is, you design with FPGAs in which case your familiarity may be the other way around since there aren’t enough new aircraft produced each year to justify custom ASICs. So, ISO 26262 – ground-based vehicles, DO-254 – air-based vehicles, right?

Those lines are starting to blur. FPGAs are increasingly popular in ADAS and self/assisted- driving applications, particularly for their flexibility in supporting logic updates. Similar functionality is also useful in airborne applications. Planes are already well ahead of cars in self-piloting and continue to advance. Meantime ASIC products for those advanced cars (think deep-learning platforms and more sensor fusion) could also be used in planes.

The technology and business potential are appealing. But if you’re aiming at both markets, you now have to comply with both standards. How much fun is that going to be? Two sets of documentation, two organizations, two engineering flows, even two products? Actually, it isn’t that bad. Aldec recently hosted a webinar on what it takes to get to dual compliance and showed there is a significant degree of overlap and that while there is some overhead, it can be managed with careful planning.

Aldec invited Tom Ferrell to present on this topic. Tom is principal in his own organization and has a 25-year background in dealing with standards of this type, which naturally have proliferated as indicated in the useful chart above. Tom broadly contrasted ISO 26262 and DO-254 in this way. The automotive standard is industry-driven, compliance depends on 3[SUP]rd[/SUP]-party accreditation through the supply chain, allows for different level of compliance depending on context and compliance is voluntary, at least in principle. The aeronautic standard on the other hand is highly regulated, compliance depends on government or surrogate approval, must be uniform for a class of equipment and is effectively mandatory. He also noted that the standards are in some ways moving closer (albeit slowly) particularly in DO-254 through “guidance” extensions.

There are differences in terminology which can be confusing, particularly with respect to safety levels. There are also differences in scope (ISO 26262 is primarily about safety whereas DO-254 covers a broader range of requirements), how reliability is treated (the ISO standard is more explicit here), handling validation out of context (again ISO is better here) and personnel requirements (ISO requires identified staff with training/certification).

He added that that the ISO standard better defines the supplier interaction and that thanks to its relatively recent development and learning from prior standards it takes a more holistic view of the system and software. It also allows for data-driven decision-making. In contrast, the DO standard is arguably less prescriptive and integrates requirements for process assurance (unlike ISO).

Tom’s net from this is first that there are no blocking points or direct contradictions between the standards and that the tailoring (alternate means of compliance) option in the ISO standard provides a path to having it both ways. That said, you can’t fudge the documentation. You still have to generate two sets, but you can simplify the task (internally) by generating a compliance matrix where you match “items” (a loaded word, with different meaning in the ISO and DO standards) to check and document your compliance.

He also stressed that dual compliance is not something you can bolt on at the end of the product cycle. Planning for both has to start up-front, looking at architectural mitigation plans and safety analyses in both contexts. On the plus side, the required safety manager for ISO can also serve as the focal point for certification for the DO standard.

Tom made the point that this is hard work, requiring a deep understanding of both standards. Of course he’s plugging his services but I’m guessing people with his level of expertise are not thick on the ground. You can watch his presentation HERE. I should add a plug for Aldec also. This is an important topic and the webinar barely mentions Aldec tools (which are widely used in FPGA design, particularly in support of needs like this). Kudos to Aldec for promoting this general interest topic. This is true high-value content marketing!