What Can Go Wrong In Automotive

Semiconductor Engineering sat down to discuss automotive engineering with Jinesh Jain, supervisor for advanced architectures in Ford’s Research and Innovation Center in Palo Alto; Raed Shatara, market development for automotive infotainment at STMicroelectronics; Joe Hupcey, verification product technologist at Mentor Graphics; Alexis Boutillier, senior corporate application engineer at Arteris; and Lisa Minwell, eSilicon’s senior director of IP marketing. What follows are excerpts of that conversation.

SE: What changes are you seeing in the automotive market and where are the problems?

Hupcey: If you look at autonomous vehicles, the automotive industry is seeing similar requirements as we’ve seen in aviation and other related industries. Things have to be fault tolerant now. If you look at DO 254 and ISO 26262, there is a lot of overlap. ISO is devoted to the nuances of the automotive industry. We’re familiar with this in verification. We’re used to tracking requirements back to specification to see if you’ve fulfilled the verification plan in a systematic way. That kind of self-documenting process with the tools and good results is coming to the foreground here. What’s different here is the emphasis on safety-critical verification, whether it’s in pure software, firmware, bare-metal software, all the way to RTL. There are some new requirements, as well.

Boutillier: From an IP point of view that’s an interesting story. We’ve been in the automotive market for a long time, but until recently there were not any specific requirements. Some things could be done in software to meet the requirements for ISO 26262. This is no longer the case. The SoC is becoming more and more complex, and there is more functionality being added into them. To fulfill requirements just with software is not possible. So we have a lot of requirements and the documentation to fulfill ISO 26262 requirements. We are in SEooC—safety element out of context–which means we have to validate our IP on the assumption that someone will use it for a safety-critical SoC. What we’re also seeing since last year is coherency, and with a CPU managing coherency. This is a new level of complexity.

Jain: Everything is changing, from the capabilities that each sensor provides for each function all the way up to the ecosystem business models. Only then can we get to the point of reaping the most out of these systems. Part of this is verification and validation to handle ISO 26262. We need to make sure these systems are the best that are out there. At the end of the day we want a functionally safe and secure system that is affordable by the masses. That has been the theme all along, and it has come top-down, bottom-up, and all the way through. When you look at each of these components, the key elements are affordability, functional stability, and this has to be a very reliable system—accurate in everything it does. So what does it take to meet all of these? There are opportunities in each of these areas.

Shatara: Autonomous vehicles is the buzzword now from every corner. But just dealing with the OEMs and seeing the changes in the vehicle, the first issue is active safety. We talk about vision systems and radar. What’s clear is that no company can do it all. We teamed up with AUTOVOX, and for V2X we teamed up with Mobileye for vision systems. Those bring in huge security and functional safety issues. For safety there also will be adaptable lighting and braking. The other thing changing is hybrid and electric vehicles. What makes it greener is the power in the vehicle. From a silicon standpoint, you have to use different silicon. Traditional mosFETs don’t handle a lot of temperature. If you look at silicon carbide, that handles 100 to 200° C. You can buy this like a normal transistor. You can shrink your hardware in the car now and get extended range. That’s also happening.

Hupcey: So you can run hot safely.

Shatara: Exactly. That’s one of the things for electric and hybrid-electric vehicles. Another thing that is changing is infotainment system connectivity. That has to do with integrating new things. A cell phone doesn’t know where the content comes from. Whether it’s traditional satellite communication or HD, it all has to work together. Another big issue is functional safety and security. All of this has to be ASIL-B compliant by customer requirements. If you have a million functional devices in a vehicle, something is going to go wrong. Where the standard comes in is whether this hazard is going to be fatal. What do you do after that?

Minwell: In the past when you built IP for automotive, everyone did their own and it was a specialized process. About five to six years ago, a customer came up to me and ask, ‘Why can’t the IP providers come up with standard IP that is qualified and ready to go?’ That was somewhere around the 40nm node. That’s where we are today. The goal as much as possible is to use the same IP that you would use for commercial purposes in automotive and have the IP providers support the additional specs that go along with it. We also do chips for automotive. We understand the qualification procedures and how to test IP that we develop. There is a significant challenge from an IP perspective to understand the IP and provide the documentation for your reliability and quality needs. What you’re seeing is all the IP providers are really having to step up their game to be able to do that. There also are not companies that have been testing their IP in systems. They have an additional challenge.

SE: SoC implementations are just rolling out now for automotive. What can go wrong?

Boutillier: Security is a big issue. There are things that can go wrong that are unintentional, but when you talk about security, you’re looking at misuse of IP in a way that it was not designed for. You have varied connections with varied interactions that are not part of the SoC or the IP, so you want to put in place elements that define what are the use cases and make sure that it can only be used this way. And you want to confirm that, without anyone knowing how you did that, because that is part of the security. You also need a way to determine what went wrong if it is not intentional and correct that and give that information back as quickly as possible.

Hupcey: The OEMs and component providers never expected that someone would try to hack a car. Auto electronics were built in isolation, assuming that everything would work and play well together. Now you have potential for outside action. You have a completely open, undefended network. So take, for example, the CAN bus. It has 24 bits. That’s just enough to flip controls, which is what was designed to do. It’s clearly inadequate to have an electronic signature in it. That’s going to have to change. That’s where verification can come into play. Do all of the components on that network inside of the automobile handle security protocols effectively? You’re designing a car so it doesn’t trust itself. If the tire pressure sensor begins sending packets that have not been properly signed, then the system assumes that area of the car has been compromised and reports the fault or the ‘check security’ light goes on. Verification can play a lot of roles to help people design for that. There are a lot of people invested in the CAN bus, and now there are whole other layers that need to be added on top of that. Security is a key part of that.

Jain: Diagnostics is going to be an important part. They will have to do something they have never done before. Now you have to start looking at this from a system perspective. Will you even be able to detect that? If something goes wrong, it needs to take a corrective action now and then make sure that works. In the lab, there are a number of questions we try to answer. What is the minimum number of sensors we need for autonomous vehicles? What is the software that is going to use all of this information, so that you have a complete robust 360-degree understanding of the environment? And then you need to look at the silicon on which this will reside and how each of these affect each other. So now, when you talk about sensors, there is redundancy and robustness that needs to come from multiple sensors and the way you fuse them. How are you going to achieve 100% or 99.9999% coverage? In many cases, a single sensor will not allow you to get there, so you will need multiple sensors. And then with each of these systems, how do you put these together in a way that is affordable, optimal, and how will the silicon handle that? Is it lockstep cores? Is it CPUs? These all have to be thought of from a power standpoint. And if we use GPUs, how do we get that into a car? It has to meet ASIL-B today, but it will have to meet ASIL-D. How do you define those requirements?

Shatara: To get to the different ASILs is going to take a while. We have to ensure everything is secure, so you have to look at the gateway into the car. There are all the ECUs, as well. Some of them will have a separate security element. How do you ensure the data integrity of all of them? If you look at what can go wrong, the government mandate is that every car has to have a GPS, and the cars have to talk to each other. What if a hacker comes in and takes over a car that is misbehaving in a network right now and tampers with the GPS coordinates? That’s a disaster.

Hupcey: That’s where it has to go. Every node in a network, whether it’s a sensor or an actuator, has to have its own key management solution. That’s a big departure from the past. You can’t trust anything that’s connected to the network at any level.

Shatara: But the OEM has to take the responsibility that any wireless data coming in the car, that box has to guarantee the authenticity of the data.

Hupcey: I agree. All of the updates over the air have to be signed.

Shatara: So what if it’s been tampered with and this is not the code that’s supposed to run? What do you do with that module?

Hupcey: If anything is compromised, the vehicle is deemed unsafe and you’re done. It’s off. Safety and security are used in the same breath. You fail the vehicle safely and pull it over to the side of the road.

Related Stories
What Can Go Wrong In Automotive (Part 2)
Understanding the security risks, where to hide the keys, and why the defense industry can provide some help.
Auto Security And Technology Questions Persist
Fallout could be slower adoption of autonomous vehicles as ecosystem proceeds with caution.
The Higher Cost Of Automotive
Suppliers looking to enter this market pay a premium in design time, certification and verification requirements.
Lawyers, Insurance And Self-Driving Cars
Semiconductor companies have to contend with more than technology when it comes to the automotive market.