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. To view part one, click here. Part two is here.

SE: How much of a consideration is power in automotive design?

Jain: Many of these vehicles are hybrids, which means they have a battery. With every increase of 10 watts of power consumption at the chip level, you’re getting to the point where you need active cooling. That puts drain on the entire system. So you want enough range, but you also want the best features. As a user, I’m not happy with a drop in range. We need to handle that power requirement, sufficient range, great performance—these are big requirements we have to satisfy.

Boutillier: If you look at each of these requirements, they are focused on one domain. So you may see resiliency in one domain. With IoT, there are batteries. But you typically don’t deal with all of these in the same chip or you could fry an egg with the chip. You want to put more gates for power saving, and you need resiliency because you are already using most of the space on an SoC. That’s a big challenge.

Hupcey: Low power is a big part of what verification brings to the table. You need to do estimates of an application during its lifetime. If an application starts up, you need to understand how much power that takes, and then when you shut down that application, how much power that consumes in its lifetime. And you have to take that all the way down to the functional side of an SoC. That can be turned on, and then turned off when it’s not being used. It can save power when it’s shut down. That’s a big part of verification. And then there’s the whole side of fault verification. There are a lot of pieces to that puzzle. First of all, there is no silver bullet. There are a lot of vendors who say they have a fault simulator. ‘Just run that and you’re done.’ That doesn’t work. It’s about the requirements traceability, starting at the front end, and having that electronically linked to your lines of code—both in RTL and then in the firmware—and then bringing that into one of the verification engines and the related stimulus. So two things that are on the vanguard of this in the EDA world are the Portable Stimulus and formal. With Portable Stimulus, the idea is they can capture the stimulus description in a language- and engine-independent manner. The solution today is that you basically draw a state-machine graph and the tool automatically netlists code for pure software verification, for hardware/software, or RTL. The tool takes care of the back end and you just capture the behavior of all of the possible states. Formal verification basically turns your circuit into a big mathematical equation that can be solved, so you can prove things exhaustively.

Minwell: There has been a lot of work on being able to improve on low voltage operation reliably, with reduction in power and leakage characteristics in the process technology. There also has been work done on memory bit cells and different types of memory that can deal with operating at high temperature and also at very low power. Once those architectures mature, they will have to be adopted into these systems to manage the power needs and requirements.

SE: Cars have been in widespread use for more than a century and while they’re better than in the past, they’re still not totally reliable. As we move to autonomous vehicles, can we achieve even better reliability—at least for the electronic portion?

Shatara: We will have problems. You can’t avoid that. There will be faults. The key is what you can tolerate, particularly for functional safety. But things will fail. You solve that with redundancy. In the case of failure, the issue is how you mitigate that.

Hupcey: Part of the solution also includes the near-illegal case. You set the Portable Stimulus, and then things that would likely be the likely failure cases. Those would also go into your description. How does the system react to that?

Shatara: The question is whether it is going to hurt anybody. There are levels of certification.

Hupcey: It’s moving the MTF (mean-time between failures), or whatever the correct terminology is, to a very small number.

SE: It’s more sigmas than in the past, right?

Hupcey: Yes, and in the security case, it’s like when you buy a safe. It takes X amount of time to break into a safe or with tools. If you buy the cheap safe, you can break into it with a hammer. If you buy the highly secure safe, that has a whole other standard. You increase the cost of attack. If you have all the time in the world, you can break into any system. The mission is to make it very difficult.

Shatara: How about updating and changing the keys every couple of years.

Hupcey: Yes. This is a whole industry that is about to be created—secure key management. That includes encryption key management and updating and maintenance and tracking, so when you drive back into the Ford dealership 10 years from now, they can authenticate it’s you and know what Trojans have been introduced. That’s a lot of data. It’s a whole other information technology problem.

SE: That’s a piece of reliability. But if you look at a phone, how many things die on a periodic basis?

Boutillier: If you have an SoC and part of the SoC is safe, but then there is another part that is not safe, you can build that into the IP to make sure the part that is not safe has no impact on the other part. Then you can go into safe mode and find the nearest place where you can stop safely. If you look at AES, you can reboot it and that’s fine. But it’s not fine with a car. You can’t just crash or continue straight. You need a safe mode inside of the SoC.

Jain: You have some amount of flexibility to do the ASIL decomposition and bringing systems together. So one system may be capable of ‘this’ and a second system may be capable of ‘this’, and together they give you ‘this’ kind of fault tolerance. Autonomous cars are a big social change. We’ve always considered cars as a big step in life and a form of freedom, and that’s changing. When people start seeing the capabilities and the positives, they will want more, but that’s why it’s important that we ensure we learn from any failures and that there are no hazards.

Shatara: That’s what ASIL is trying to do. But we’re all still learning about it.

Jain: Ford today is talking about becoming an automobile and a mobility company. That’s a big shift.

Shatara: In the 1960s General Motors published an article about self-driving cars.

SE: So how will this play out?

Minwell: Our view is that we will have to beef up our reliability and quality. We’re already following the standards, but we see them getting more stringent. Customers already are asking for qualification at higher temperature. That’s expensive, so we need to find new ways of managing those costs. And from an SoC perspective, we need to figure out standards and how we can help with security issue. From our side, it’s about implementation.

Boutillier: It’s really about putting more performance, more reliability and fewer cores into every implementation. Coming up with solutions that add resilience will be critical, and that’s what we’re working on right now.

Hupcey: EDA verification has been all about helping customers avoid the cost of failure. We have a lot that we can build on. There obviously are new challenges and requirements coming from this. We’re innovating in those areas and we’re prepared to take on those challenges, including helping customers have zero re-spins. We want to make sure customers in the automotive domain can exhaustively verify their components.

Shatara: The automotive industry is changing. There is market acceptance of autonomous vehicles, and the industry is adapting new standards and finding a way to do it cost effectively. This will take some time, in my opinion. There will be new regulations for autonomous vehicles. How we get there remains to be seen.

Jain: Our goal is functionally safe and secure, highly accurate, autonomous vehicles that are affordable for the masses. You hear this from the outside, but when you see this happening with every decision inside the company, it’s completely different. You want to do the best for the customers and your investors, and each of these components is essential.

Related Stories
What Can Go Wrong In Automotive (Part 2)
Understanding security risks, ECUs vs. SoCs; dealing with an explosion in data.
What Can Go Wrong In Automotive (Part 1)
Security, diagnostics, standards and the future of autonomous vehicles.
Auto Security And Technology Questions Persist
Fallout could be slower adoption of autonomous vehicles as ecosystem proceeds with caution.