Anatomy Of An Autonomous Vehicle Crash

The rollout of autonomous vehicles will have far-reaching impacts on technology, business and social interactions, but it also will set in motion a whole new side of technology development and new legal frameworks to prove what went wrong when these vehicles are involved in an accident.

This isn’t just something to plan for down the road. The California Department of Motor Vehicles this week eliminated the requirement that autonomous vehicles need to have a driver present, in case of emergency. There is still a long list of rules about testing, and these cars need to be able to respond to cyber attacks and carry a black box, similar to airplanes. Carmakers do have to be able to operate vehicles remotely in case of a problem. And they need to communicate with police if something goes wrong, which it will, because no technology is perfect.

But what comes next is where things get really interesting, because there is no precedent for autonomous electronics operating on this kind of scale. What this is expected to boil down to is a combination of adherence to the ISO 26262 standard, simulation, verification and physical testing, as well as time-stamping and a massive amount of data mining.

“Traceability is going to be huge with the amount of data that we can actually collect, store and process,” said Sundari Mitra, CEO of NetSpeed Systems. “And, it need not all be on a vehicle. There is a certain amount of data that must be computed on the vehicle to make the rapid decisions in the case of a potential accident and the ability to make evasive measures. Of course that needs to happen right then and there, but the data the car has been collecting even seconds and minutes before may not necessarily sit on the vehicle. The traceability piece is going to be a huge advantage of the autonomous vehicles because there is so much information gathering ability in the newer vehicles, which was completely missing in the past. Otherwise, we are relying on the memories of drivers who were emotionally charged at the time of an accident, which is absolutely the wrong time to be confident about remembering anything.”

Data will be stored such that it can be retrievable and then analyzed. From there it becomes a matter of whose fault it is, why the technology failed, where and when it was developed and by whom, and whether other vehicles may be affected. But it also will take time to evolve these rules for liability because the technology itself is new and evolving.

“Say you rear-end someone today,” said Mitra. “It doesn’t matter whether the other driver was sitting in the middle of the road for no reason. You are the one to blame because you hit them from behind. You saw that vehicle and should have stopped. They’re going to have to keep some of those rules. Otherwise the number of dimensions in the problem space are so many that we would not be able to get our arms around it.”

Just how far along carmakers are with autonomous driving isn’t entirely clear. The general consensus is that most of the industry is a long way from ADAS level 4 or 5. But companies are keeping their development efforts rather vague for competitive reasons. Ford said it will roll out self-driving cars next year, and GM announced plans to deploy driverless taxis in cities next year, as well. In a presentation at the SEMI Industry Strategy Symposium, Maarten Sierhaus, director of Nissan Research Center Silicon Valley, said that “Eyes on, hands free, will happen in 2020 in cities. Eyes off, robotaxis, will show up in 202x.”

But what exactly constitutes “eyes on” is open for interpretation, and it may depend to some extent on just how ready different countries or regions are to deal with this.

Fig. 1: 2018 KPMG Autonomous Vehicle Readiness Index.

Endless testing required
Getting to that point will require a combination of simulation and physical testing, most experts agree, and it won’t end with the rollouts of that technology. The key is to establish a set of best practices that everything possible has been done to ensure that autonomous vehicle technology is as safe and reliable as possible, and then take quick action when problems do surface.

“Physical testing is the proof of the pudding,” said Martijn Tideman, product director at TASS International, a Siemens Business. “People want to see it, touch it, feel it in the end. However, in physical testing you can only do so much. You can only do a handful of tests. A handful in the query means 10. A handful in automated driving means 1,000 or 10,000. But in the real world, there aren’t 10,000 possibilities. There are 10 billion possibilities. It’s too much to possibly test. Suppose you do test it, you get a hardware or software change on the vehicle, and you have to retest. It’s completely unfeasible to do every test on the real world.”

This creates a huge opportunity for simulation on a gigantic scale. “You need simulation to do this massive evaluation of consequences given a certain system design, given a certain set of scenarios, and what could happen,” said Tideman. “Simulation is safe, it’s relatively cheap, and importantly, it’s also reproducible. In the real world, if I drive a certain road today, and I drive the same road tomorrow, it’s different. There’s different traffic, different weather circumstances. The person in front of me brakes with a different deceleration, so the results that I saw yesterday are not being reproduced today. In simulation, every time I run a certain scenario, it gives me the same results.”

Fig. 2: What’s at fault and why?

The aerospace legacy
The best example for how this has been handled in the past comes from the aerospace industry, which created an entire infrastructure to improve commercial airline safety. Even though there are many more possible permutations of a crash in a car, and many more cars on the road than airplanes, there are still parallels to be drawn.

“If you have an autonomous car and it goes into a crash, what happens, and how do you go about it,” asked Marc Serughetti, director of business development for virtual prototyping at Synopsys. “In the aerospace industry, because it is so controlled and depending on the problem, they ground the plane until it is fixed if it’s absolutely critical. The question is how that translates to real autonomy where suddenly you don’t have the same level of regulation and there are many more vehicles. This comes back to how you’ve designed, tested, and tracked the development and if you are able to reproduce the problem you are seeing. Then, how do you get to a fix?”

In that context, the first thing that comes into the picture is what was done during the development of that autonomous vehicle. “Here, ISO 26262 plays an important role in terms of how you go about development, tracking the requirements and tests associated with those things. This is a big part of the standard itself and the standard helps drive some of the behavior, the culture for functional safety such that you first try to avoid the problem coming in,” he said.

But what happens after vehicles are deployed and a problem is found? How is the problem identified; how is a solution found; how is the traceability understood into what happened during the development so it doesn’t reproduce itself?

“This also is about how to apply ISO 26262, and the tools you apply along the way to ensure the quality,” Serughetti noted. “Once it gets to deployment, how fast can you reproduce the problem? Here a question may be how deep the problem goes. It could be a mechanical problem. That’s just an OEM issue. But it could be a software problem, so it starts to go down the supply chain. Or it could go all the way down to a problem in the chip itself, and now you go all the way to the semiconductor. There is a big verification and test aspect that needs to be taken into account that needs to change in automotive, and we see this transition happening right now.”

The avionics industry has developed configuration management systems because everything is configured with different versions.

“So you have verification systems archived for PCIe boards, operating systems and tool versions,” said Louie de Luna, Aldec’s director of marketing. “The most successful aerospace companies archive this so that, in case of a problem, they can re-run tests. But this is an expensive best practice. It’s like insurance. If a plane crashes, how do you find out what went wrong, particularly if it’s 10 years old and that technology isn’t being used anymore? This isn’t just about having the right tools, though. It’s based on an engineering culture. If there is a process in place and no one follows it, that doesn’t work.”

At least part of this is based on traceability. “What you’re looking at is the relationship between functions and elements,” de Luna said. “You’re trying to identify which functions fail, which VHDL blocks are involved. Maybe it was never covered in previous tests. There might not even be a test for that.”

In other cases, technology exists that has never been applied to the automotive world, such as time-stamping—the same technology that tells when a video was recorded or a wireless conversation was initiated and ended.

“You can leverage a lot of existing technologies to enable these capabilities,” said Venu Balasubramonian, marketing director for the Connectivity, Storage and Infrastructure business unit at Marvell. “Instrumentation will be very important here. This will basically take black boxes in cars to a whole new level. Now you can add probes and instruments to figure out when something happened.”

A challenge for OEMs
How all the pieces go together for traceability isn’t entirely in focus, though. Automotive OEMs are still trying to figure out what it means, how they are supposed to deploy this technology, and what it involves, observed , president and CEO of OneSpin Solutions. “I have attended a few meetings at big car companies where people are discussing the methodologies of designing autonomous vehicles. Many of these companies are still in experimental stages and trying different things, so they are just beginning to understand the implications that it will have.”

One non-negotiable item is that safety has to be designed in, and according to the ISO 26262 standard, the way to approach functional safety from the chip level is a pretty well-known and well-established procedure, he said. “But when it comes to higher-level functions, like autonomous functions and machine learning-based decision making, engineers still have to learn how to translate those concepts and learn how to actually implement functional safety in these areas. This is something where people still are on a learning curve and experimenting with different approaches.”

Traceability is not just about semiconductors. It stretches back to design tools used to create those semiconductors. For this reason, there is a huge effort underway by tool providers to make sure their design and verification tool flows are certified by internationally-recognized testing body TÜV SÜD.

Joerg Grosse, product manager for functional safety at OneSpin, explained that while OneSpin’s customers may be the semiconductor companies, which are considered Tier 2 suppliers in the automotive ecosystem, they are getting a lot of requirements from the OEMs and Tier 1 suppliers to provide evidence that they did a good job during development of the ICs.

The ISO 26262 standard is also specific about this and includes the requirement to qualify the design and verification flow, he said. “It’s mostly about the flow rather than the individual tools. You always have to consider the tool inside the flow. What does it read? What does it write? Is the tool specifically certified? And is it certified for a given use case or within bounds similar to having a safety manual for your refrigerator or any other appliance?”

There’s an outgrowth of the ISO 26262 standard called “Safety Of The Intended Function,” and there has been some discussion around the two about what the industry should adopt as a voluntary way and a voluntary system of dealing with traceability, said Kurt Shuler, vice president of marketing at ArterisIP. “I don’t think we’re anywhere near where things will have to be. There are international standards for planes. There aren’t similar standards yet for cars. But for these electronic systems there are a few different things happening. One is that before there is a problem they are wanting logic within a system to say, ‘Hey, I’m seeing something abnormal within the system, so let me phone home.’ Everything will be connected just like airplanes are today. If you see a lot of cars with the same issue, you put out a maintenance bulletin about how you handle it.”

What that means is that even down to the chip level, there will have to be logic inside that’s smart enough to figure out when something is “abnormal.”

“Things degrade over time at the level we deal with,” Shuler said. “One of the things that we’re dealing with right now in the ISO 26262 working group is how semiconductors wear over time, especially in the latest process nodes and especially in a chip that let’s say is an imaging processor. Those transistors are on 99% of the time because the system is on 99% of the time, but there may be something that isn’t. Well, the timing characteristics of those transistors, even though they are on the same chip, are going to change differently over time. How do you deal with that?”

Forensics are also required for autonomous vehicles, he continued. “This is after the vehicle has crashed. People already do that. There is already flash memory in vehicles so that when the airbags deploy, there is a system in there that covers everything – what the GPS was saying, where the knobs and dials are. But it’s going to have to be smarter, because instead of measuring whether the human being pressing the accelerator or the brake when it happened, or were they fiddling with the radio, were they putting on make up or brushing their teeth or reading the paper? The issue isn’t just knowing that–it’s what was actually going on in this highly complex system that has multiple brains and a nervous system spread out throughout the whole car with hundreds of sensors. It’s just as complicated as in an airplane.”

Changing automotive design
As with most issues in electronics, this requires much more up-front planning.

“In automotive, there are multiple Shift Lefts happening,” said Synopsys’ Serughetti. “You obviously have a Shift Left at the semiconductor level when it comes to the hardware verification, the functional verification, the functional safety verification, which is something that’s additional to the traditional verification.”

Software development also must be started earlier in the design cycle, which involves the Tier 1 and OEM. “Here also, software development has multiple technologies,” Serughetti said. “You may have static analysis, the whole process of managing the supply chain for software, and the concept of verifying shifting to a virtual environment to test the software. This is all what I would call pre-system. Then post-system, the concept of continuous integration and test is needed.”

Throughout the supply chain suppliers are recognizing this, which means they are looking for how they can improve test and verification. “Right now there are two ways to look at it,” he said. “You can start doing things earlier so you can do more and better testing pre-development. And once the system is in operation it is important to have a continuous verification and test that enables you to do this all the way down through the system, software, and hardware, as well. Everything needs to become traceable.”

Challenges ahead
All of this provides huge challenges, but it also big opportunities.

“Advanced driver assistance systems are the main driver right now for the [semiconductor industry] because they require a lot more computation than has been in the car, and that requires bigger chips,” said OneSpin’s Brinkmann. “Bigger chips, newer technologies, smaller scale, higher integration, larger area and lower power all mean they are more susceptible to faults induced by physical effects in the field. This is why the whole aspect of functional safety with fault injection analysis and fault propagation analysis has become such a big deal. Before, it was not so likely that something like that would happen on a small device, even though there were many of them in the cars already. Now it is a bigger challenge because these chips are just massive. It doesn’t even mean you have to have an autonomous car to have the problem. It’s enough to have some of these advanced assistance systems that are now going into production and into the field. They are not autonomous in that sense, but we still have have a lot of pressure from this angle and functional safety.”

Some of this can be handled in advance. Some if it has to be analyzed in retrospect, and that analysis needs to extend well beyond just the parts in a car.

“Lessons learned is the key subject for engineering teams, and such investigations require access to system monitoring and logging devices on the vehicle, but also all the parts, modules and functions and traceability management to get us to the source of the problem,” said Zibi Zalewski, general manager for Aldec’s Hardware Division. “Any vehicle project is advanced engineering and a logistics effort. Knowing the reason of the crash is just part of the solution. It is very important to trace all the parts sources and relations between the hardware and software elements of the vehicle. It becomes even more important for autonomous vehicles which are packed with most advanced technologies, software and hardware elements co-working with each other and not easy to debug.”

This includes project traceability management on all stages, from specification and design through prototype and actual production.

“Of course the main goal for engineering teams is to save us from the crash in the first place, which brings us to the verification and testing of such a complicated, multi-discipline project,” Zalewski said. “The modern vehicle is no longer mechanical art. It has become a ‘smart vehicle’ with powerful processors running complicated algorithms and IPs, using multiple sensors and cameras. The entire verification methodology with such elements as requirements management and traceability, software and hardware prototyping or testing coverage, is one of the most important and time-consuming elements of the whole project called the autonomous vehicle.”

And as self-driving cars begin rolling out throughout the world, we’re about to find out just how complex and time-consuming this ultimately will become.

Related Stories
Reshaping Automotive Design
Conflicting goals, evolving standards and the need for new methods and tools make this an interesting market for chipmakers.
Giant Auto Industry Disruption Ahead
Autonomous vehicles will cause fundamental shifts across a number of established industry segments tied to automotive, opening up big opportunities for chips and tools.
How To Make Autonomous Vehicles Reliable
Making sure ADAS designs function correctly over time will be an enormous challenge.
The Road To Autonomy
Automotive manufacturers and chip companies reveal what they’re up to in realizing self-driving cars.