Why Safety-Critical Verification Is So Difficult

The inclusion of AI chips in automotive and increasingly in avionics has put a spotlight on advanced-node designs that can meet all of the ASIL-D requirements for temperature and stress. How should designers approach this task, particularly when these devices need to last longer than the applications? Semiconductor Engineering sat down to discuss these issues with Kurt Shuler, vice president of marketing at Arteris IP; Frank Schirrmeister, senior group director, solutions marketing at Cadence; Ted Miracco, CEO of Cylynt; Dean Drako, CEO of Drako Motors; Michael Haight, director of business management, Micros, Security & Software Business Unit at Maxim Integrated; Neil Hand, director of marketing for digital verification technologies at Mentor, a Siemens Business; Sergio Marchese, technical marketing manager at OneSpin Solutions; Marc Serughetti, senior director, verification group at Synopsys; and Hagai Arbel, CEO of Vtool. To read part one & three of this discussion, click here and here.

SE: What does “verification by the book” mean in this space?

Arbel: In this space specifically, you have to prove that somebody is checking your verification and your compliance. We had a review with a standard compliance auditor and he told us very boldly, “I don’t care if your product is doing what it should do. I care if your product could potentially kill people.” That is a big impact. To follow up on what Marc said about the mentality being completely different, we need to prove that our process is good enough; not just for the commercial success of the product, but for it to be certified, and even be used. In regard to what was said about not stopping innovation, I’ve already seen that decisions are being made in projects when it comes to selecting IPs, for example, based on whether they are certified or not. It’s becoming a main design consideration. Sometimes, companies prefer to take the more expensive, less efficient solution in other aspects, just for the sake of being able to cross the certification faster or more efficiently. That will have a tremendous effect for example, on the ability of smaller players to compete, because it’s not enough just to get to the market fast with a better IP, it also has to be automotive standard certified, and that is a completely different ballgame.

Haight: I assume this means that clear standards would govern how this should be done, and then all the OEMs would exactly follow the rules. Since cars are growing more complex so quickly, standards like ISO 26262 may need revising or replacing in near future.

SE: What everyone has touched on is the fact that this is both software and hardware, and it’s a holistic solution. Given that automotive architectures are still evolving, what could this look like from the software side?

Miracco: You’re looking at the automobile of the future when you’re staring at your laptop. It’s a laptop with wheels. It really is going in that direction. The electronic content in an automobile is just going up, year after year; and the software contribution to that electronic content is also going up, year after year so things like diagnostics for automobiles, these things used to be done where you’d pull into a repair shop and download data if it was available. You would patch software at a repair shop maybe once a year. Tesla’s changed everything with over-the-air updates and constantly enhancing the features and functionality of the automobile so it is becoming a rolling computer from my perspective. With the complexity of the software comes a huge vulnerability. It’s a vulnerability from a consumer perspective because again, malware can get into there. People are very concerned about privacy and the access that you can get to information over the air is a vulnerability from a safety perspective. There’s a lot to think about but I do think we know what the automobile of the future looks like, and it is sitting right in front of you.

Haight: I really expect each OEM will have their own architecture, with no industry implementation standard. There may be some cross fertilization with limited OEM partnerships, or in some cases Tier-1 solutions that have a common base with some customization for each of their individual OEM customers. But the verification is certainly critical for each of them. I do expect that enhanced standards will emerge for the safety performance, and then back to the prior question, the verification by the book would become more pertinent.

Hand: If you look at the laptop, the laptop is actually trivial compared to the automobile systems we’re looking at. The automobile systems we look are many ECUs connected by networks. It’s more like a data center, and you’re looking at what a data center have, and it’s not even that because each system is different. A data center has homogeneity to it whereas an automobile has many systems working independently, working with each other, and any one of them can be an entrance point into a vulnerability. If you look at the classic example, a few years ago when [white hat hackers] drove a vehicle off into a ditch, they went in through the over-the-air update to the ECU that was handling the entertainment system. They got access into the CAN bus, and from the CAN bus they took control of other ECUs. But this is not just automotive; automotive is the one that we see. Everyone here has a car, I’m sure. The same standards apply whether it be aerospace, whether it be automotive, whether it be factory automation, IoT, the same things apply. And this idea of safety criticality while it came to light through automotive, it’s not unique. It’s underselling it when you say you look at a laptop. A laptop is a system of systems, but compared to a car, compared to a factory, the complexity is fractional.

Serughetti: There’s one important difference with automotive: If you look at mobile phones, you don’t have a safety critical system or laptop, but you have a consumer, somebody like you and I, and the people on this roundtable. If you look at avionics, if you look at industrial processes, you have very safety-critical systems, but you leave them in the hands of professionals. In automotive, this is the convergence of the consumer user with the safety critical. On top of this, you bring what Ted was talking about. All these over-the-air updates, and suddenly the dynamic is changing drastically in what you need to do in terms of technology you bring, in terms of what you do for verification, how you do it because the dynamics of the market at the end are changing. That’s what specific. That’s what automotive suddenly brings into the picture although we are trying to take away from the consumer the use of the car with things like autonomous driving , we’re not there yet. That’s an important factor; that’s what’s happening in automotive, the convergence of a lot of things happening where the safety critical aspect is becoming so important because of who the user is and what the system does.

Marchese: Another crucial difference of automotive is that it’s a cyber physical system. It has stronger security and safety requirements of course. But unlike for example, a mil/aero application, it has the power of a high-volume application. You get, for example, Tesla verticalizing and building their own chip and software stack and investing hundreds of millions of dollars literally on building a chip because if they produce a million cars, of course they can spread the cost of that. You have an industry that potentially could move forward very quickly in terms of having all sorts of crazy applications. But I think ultimately, maybe it’s a bit sad to say, safety and security are going to put the brakes on all these potential advancements.

Schirrmeister: Picking up on the discussion about whether we are looking at a computer on cars, if I look at the most recent presentations, the computer on wheels is a good start trying to look at it but what I find even more interesting and striking is what they refer to in automotive as the zonal architecture. This is more like Neil said about the data center on wheels because it’s specifically the sorting of things by workloads. It’s the Hennessy-Patterson dynamic with domain specific architectures so you actually don’t have one CPU doing it all. You actually have these zones which you connect where you have domain specific compute, and domain specific security and safety requirements, with the added complexity on top of it, which is the systems of systems discussion that you now don’t want to be hacked. You want to have separation. Now, putting it back to hardware and software, it’s containerization of different software so there’s a lot of software co-design going on. Then on top of it, you have the system of systems, where there are domain specific zones, and then you need to secure the interaction between them. In a hack like Neil referred to, it takes the rest of the world data center type compute with all the intricacies like workload optimization, moving it on wheels and having not only security but safety requirements.

SE: Does a ‘zonal’ architecture cover things like over-the-air updates, and is that enough to keep it secure and safe?

Haight: For sure this would help to partition off systems and assist in troubleshooting and fixing zones. This is not enough by itself but certainly a smart approach. All these zones are connected and so one failing zone may lead to others going into the weeds that are otherwise working okay. Troubleshooting is easier because reviews of inputs and outputs of each zone can be analyzed.

Hand: I think it’s the wrong question. The biggest challenge we have is that every one of us as engineers has been taught how to design something that does what we want. And how do we think of scenarios where it behaves correctly when people do things we don’t want? We are very good at that. Whether it be hardware, whether it be software, we have methodologies for that. The whole safety criticality whether it be through functional safety which largely relies on underlying failures, whether it be security, it all relies on a different level of mentality the idea of how to exploit something because it will behave in a way that I want when it doesn’t want, or it fails incorrectly. It’s an interesting challenge whether you’re in hardware, whether you’re in software, whether you’re hardware and software together. In the hardware and the hardware/software community, which is I think where most of us are from, there are some lessons we can learn from the hacking community in the pure software world. People have found exploits and ways to do things that are mind blowing. When you add in the complexity of modern safety critical systems, whether it be automotive, industrial, mil/aerospace, it’s a different mindset, and we can enable them with tools and we have to enable them with tools. It’s a mentality. It’s switching what you think. It’s going from the white hat hacker to a black hat hacker. It’s how do you go from, using it for good versus how to exploit it for evil.

Related
Variables Complicate Safety-Critical Device Verification
Part 1: What’s the best way to approach designs like AI chips for automotive that can stand the test of time?
Pivoting Toward Safety-Critical Verification In Cars
Experts at the Table Part 3: Changing the automotive mindset; verification after manufacturing; security updates.
Sensing Automotive IC Failures
Improving reliability and yield will require new ways to identify defects in chips.
Using Static Analysis For Functional Safety
Why this technology is suddenly so important.
Ensuring Functional Safety In Design
How to reduce logic BiST area while improving test time in automotive chips.