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.

SE: We’ve been talking about deliberate attacks, but the problems may not be caused by hacking. It could be the car itself malfunctioning. How do we address this?

Hupcey: It could be anything. Water can seep into a module. The sensor could be off.

Shatara: The defense industry was here before us, and we can leverage a lot from them. There are obviously a lot of secrets we can’t get out of them, but they’ve been there and they’ve done a lot of what we need.

Hupcey: A lot of this is done in mil/aero. The challenge is, because those are lower-volume products, everybody could share the costs. So you have parts that are five times the cost of what a commercial part would be. The difference here is that there is such price pressure. We’re going to get stuck with some of that cost.

Shatara: It’s like LIDAR. It doesn’t work in all weather, but it’s needed for autonomous vehicles. You can’t afford $70,000 LIDAR in a vehicle.

Boutillier: Yes it’s new for the auto industry, but this is something they’ve been dealing with in defense for a long time. They worked out a solution. This needs to go up the IP level, so my IP will only work ‘this way.’ You know that these guys cannot talk to these guys if they’re not stakeholders. That’s one way of solving the security issue, which is what networking and defense are doing. There is a middle layer.

Minwell: There are other levels where you can do things, too. At a very low level, wherever you’re storing your programming you can store that under diffusion layers, for example. That’s very difficult for people to understand or try to pull the data out of that.

SE: That’s diffusion layers in memory?

Minwell: It’s out of ROM. ROMs typically will have boot code. It’s very difficult to get in there. There are also some programmability options that we can support.

SE: Is the auto industry sticking with ECUs, or is it moving to SoCs?

Shatara: SoCs will be one issue, but it won’t be all SoCs. The automotive industry has to adapt to system engineering rules, and it hasn’t in the past. The front system engineering defines a big picture, but then you need to deal with the details. That could be a family of SoCs that is scalable. Interfaces are important, as well. Ethernet will have a place, but cost is an issue. You will probably see multiple buses in a car. Ethernet would be great, and you’ll see it on the high-end cars. But for the mass market, you’ll probably see different architectures. But it’s not just SoCs. It’s also the software. SoCs will come with 80% of the software implemented. Semiconductor companies have invested a lot in software and they are becoming software powerhouses. Those are key for the future.

Hupcey: We’ve all seen concepts of, in the future, ‘Here is your car with only two ECUs.’ There are two black boxes that are identical, and inside are SoCs with multiple processors and maybe 200 instances on each box that are all virtualized. The only thing you have in the rest of the car is wires going to each actuator, sensor and screen. That’s one extreme vision that will take a while to get to. In other industries, that’s all gathered up in one fat SoC. We’re used to dealing with that in verification.

Jain: There are many different names for that—domain controller, MCU—but this is a centralized architecture. It’s functionally safe and secure. We spoke about one safety processor and another processor that does the heavy lifting, with dumb sensors scattered around. At the other extreme is a distributed architecture with smart sensors, which is based on a bottom-up approach. At the end of the day, it’s probably going to be a hybrid system. We have to be able to grow one into the other. We have to be able to justify the cost. It has to meet the performance to do that. And as these applications get stricter, where we get to level 4 and level 5, that’s the kind of reliability we will have to meet. There are so many ways that’s being looked at. The cost in each one of these has to go down. The number of cores in each of these keeps increasing. But it’s not as if you add more cores, you get more performance. This has to be a well-justified decision.

Shatara: Complexity is the key. When it gets bigger and bigger, centralized will not do it. That’s key in the vehicle. What is limiting distributed right now is cost. But if you look at the technical challenges of these big SoCs, and you add in a lot of RF parts, there is a lot of noise. You have to go do a distributed system. When you go electric, it generates a whole new set of problems in terms of noise. Some parts are more sensitive than others. You have to isolate them so noise from one part will not affect another.

Hupcey: That means more shielding needs to be added, but that’s a lot of weight. If you’re trying to get a wire bundle into a certain space, that also takes up a lot of area. That’s another architectural challenge. We don’t necessarily see that in the semiconductor area, but it does have a domino effect. It interfaces with the SoC.

SE: We used to think in terms of horsepower. Now we’re looking at the speed at which data moves around the car. How do we ensure there are no bottlenecks?

Shatara: It’s still under investigation.

Jain: Yes. Today all of these connected cars are driving around and we all want to do data logging. It all adds up quickly, particularly when you’re doing 360-degree LIDAR, 360-degree cameras. And then you want everything about mapping. An automotive entity has never seen that kind of data before. We’ve dealt with big data in the past, but this is much, much more.

Shatara: That brings up the question of distributed versus centralized again. If you do the processing locally, you need a smaller pipe or less bandwidth. That is one solution.

SE: What happens on the IP side?

Minwell: From a cost perspective and a data perspective, 2.5D solutions might work as this progresses. Now that we’re getting fan-out wafer-level packaging, by 2019 or 2020 that should be less cost-prohibitive. If we’re looking at neural networking/deep learning activities happening in the car, it seems that it will have to move in that direction. You’ll have to manage all of that data and all of the processing of that data. And then with that, if you have IP that is already proven and you can do 2.5D, you can put pre-proven IP chiplets into a package. So things that you have already proven you are not proving again.

Boutillier: We are already seeing new approaches and proofs of concept. In a smartphone we have the same capabilities. The main issue is that those are being done without coherency or security sometimes. Adding coherency is a big deal. Some features need to be implemented, which add to the cost. And you need proof that you did it correctly. Carmakers already know how to do infotainment and they can do 4K. Now they have to make sure they are safe. If you have eight processors or eight cores, we already know how to do that. But it is something that is adding to the cost right now.

SE: As cars become more electronic, they have to start dealing with signal integrity. But signal integrity now has another side, which is security. How much of a problem is this?

Shatara: The more ECUs or SoCs, the more entry points for the hacker. Any wireless network in the vehicle can be tapped. You have important code sitting in ROM/RAM. That has to be authenticated. So the SoCs have to come with security built into each one of them. But everyone does AESD (Advanced Encryption Standard Development). If you give a hacker enough time, they will find the key and open the dome. You need to make it harder for the hacker to enter that dome. You need a small door, and you need to make it harder to find. And then once you get in, you will need advanced encryption. While 256 bits may be enough today, in 10 years it might not be sufficient, so you might have to go to 512 bits. You need to build headroom into existing hardware so you only need to update it with software.

SE: But is any of this really enough?

Shatara: One of the challenges with autonomous vehicles is that they have to be aware of its environment. They have to be smart enough to be aware of anything going on outside and try to avoid any problems. But there also will be a mix. In the Midwest, they might not drive autonomous vehicles. But in New York and San Francisco, we will have autonomous vehicles because people don’t want cars. Still, if you have an accident, who’s responsible it involves an autonomous vehicle?

Jain: I want to go back to the distributed components and how each one has to have its own safety and security capabilities. That’s definitely an advantage, because you have less data being transferred. But there’s a con to that, as well. If a sensor fails, whatever you were relying on that sensor for doesn’t exist anymore. In a centralized architecture, if you have information from multiple sensors, if one fails then you can handle a good chunk of that task.

Shatara: But you still can have redundancy in a distributed architecture.

Jain: Yes, and that’s why we need to figure out the balance for a hybrid system to ensure safety—and to have the most efficient transfer of data with the most efficient amount of data so that you can make the best decision as fast as possible. We’re also talking here about vehicles that may require the standard 10-year, 150,000-mile warranty, and there are vehicles that within one year may go 100,000 to 300,000 miles. We will have to satisfy those with hardware and software.

Related Stories
What Can Go Wrong In Automotive (Part 1)
Security, diagnostics, standards and the future of autonomous vehicles.
Prioritizing Vehicle Data Traffic
Challenges grow for classifying and tagging huge volumes of data from connected cars.
Sensors Enable ADAS
Advanced driver assistance requires a careful and complex balance of hardware, software and security.