Toward the ISO26262 update: Still fighting an old war?

Next year should see the publication of the second edition of ISO 26262, the functional safety standard for electrical and electronic automotive systems. The new edition will take greater account of the development of the silicon that resides within those systems. It will also broaden the range of vehicles covered to include trucks, public transportation and motorcycles.

In the run-up to its publication, Tech Design Forum will look at what revisions to the standard will mean for automotive IC design. But this series begins by looking at two areas that do not fall within the scope of its second edition, though they are among the hotter topics in automotive design: autonomous vehicles and security.

“There is more in there on hardware design, and that’s good because the current edition is very hand-wavy on that. But in many other ways, it’s still fighting the last war,” says Robert Bates, Chief Safety Officer for Mentor Embedded, which provides a full AUTOSAR stack among other automotive offerings.

Bates argues first that when it comes to autonomous vehicles, the second edition of ISO 26262 still will not address these concerns. The ISO committee is going to take at least another year before they will release a new standard and recommendation on autonomous vehicles. When they do, it will only provide recommendations on reaching as far as ‘Level 2’ functionality, and not the type of ‘Level 3’ and ‘Level 4’ requirements that will truly pave the way for self-driving or self-correcting vehicles (see Figure 1 for a description of the five autonomous driving levels).

Figure 1. The SAE J3016 levels toward autonomous driving (click to enlarge – SAE/Wikipedia)

“If you look at what we’re trying to achieve at Level 2, you can basically define the functional safety requirements for a lane keeping assist system,” he explains. “That means, in terms of how we see 26262 and how it’s worded, you can go through the process: ‘I had a requirement. I designed the requirement. I implemented the requirement.’

“Or, put another way, you can look at that system and basically say, ‘Here is the hardware, here is the software and here is the software that actually fulfills the function.’ And, for ISO 26262, you’re good.”

This kind of pragmatic compliance flow comes up short, however, when the system’s AI and machine learning content begins to increase.

“But then you get to Level 3 or 4,” says Bates. “Now everything is mostly being done through machine learning. All of a sudden, I’m wondering, ‘Where is my implementation? I have a bunch of logic that can do pretty much anything and it has to be trained. But how do I know that I’ve trained it correctly? And how do I demonstrate compliance on that?’

“As things stand, the standard still won’t offer anything there in the next edition, though there are a lot of people working to address all of this. But we’re still fighting that last war.”

ISO 26262 and security

Security is similarly absent from the next version ISO 26262, which again may strike some as strange.

“If I’m the CEO of a major Detroit automotive company and I’m looking five or so years out, what’s my biggest nightmare?” wonders Bates. “Very likely, it’s waking up to an email that says, ‘Pay me $2B or tomorrow morning at 10, all your cars will turn left.’”

SAE International has developed a cybersecurity guidebook, J3061, but, in Bates’ view, this is “more a collection of good ideas.”

“What it doesn’t do is provide a structure. OK, when it was released two years ago or so, there wasn’t one basic position on security,” says Bates. “But if we are going to talk about security in a formalized manner in automotive, as we can in other industries, then we are going to need something like that.”

Bates’ view is that ISO 26262 has provided that kind of necessary common ground in other areas of automotive safety-critical design. “I can be very critical of 26262, and you do want to draw attention to its limitations. However, it has also had and will continue to have a lot of value.

“For example, it now means that when a guy from, say, Delphi talks to one from Continental, they are using the same language to achieve the same goals – even though they may go about that differently.”

Creating the same kind of environment for security would make sense.

So, who would have thought it, but a standard does not go quite as far as the technology. The ISO system itself is part of the issue here – typically standards come up for review every five years. Consider what has happened to the ADAS market in that short time and how quickly demonstrators that reach toward Level 5 autonomy have emerged.

And it has long been the case that analyzing the strength of any standard has often had to begin, as here, by looking at what it does not yet address.