Quality, security and the future of automobile electronics: A candid conversation with Jim Buczkowski, advanced engineering director for the auto giant.
Jim Buczkowski, director of electrical and electronics systems research and advanced engineering at Ford Motor Co., sat down with Semiconductor Engineering to talk about quality, security, architectures, packaging and automotive’s unique constraints. What follows are excerpts of that conversation.
SE: As more electronic content is included in automobiles, what kinds of issues are you dealing with now that you didn’t deal with in the past?
Buczkowski: Until we started using integrated circuits that are part of standards, such as USB and WiFi and Bluetooth, the direction was pretty strong in the car. More recently, as some of the IC designs want to transcend from the consumer business, which doesn’t have as stringent requirements as the auto business, there have been questions as to quality. It’s still a minority situation. If someone wants to use a unique chip that’s been designed in the consumer market, we carefully look at whether our usage of it would be low risk. It can’t be in a power train environment, for example. It has to be for an environment the customer can live in, so it’s not under-hood. Semiconductor companies are very familiar with the packaging-related requirements and thermal cycling. Our standards for quality exceed the typical requirements for consumer and approach those of the military. We have all the quality requirements of the military but the cost requirements of consumer markets.
SE: As we build in more connectivity, concerns over security are on the rise. How are you dealing with that?
Buczkowski: We definitely took a cue from technology and architectural approaches that exist within the IT world in terms of firewalling and partitioning. We looked at some of the pieces that relate to infotainment for the consumer side of the network, versus the vehicle control systems such as powertrain and brakes, and we built a firewall between the two so that we pass messages back and forth in a very controlled manner. If there is intrusion on the consumer side, the ability to access the vehicle side is very limited. For anyone, whether they’re talking about enterprise or embedded, if they think they have the complete answer to security it’s not a very realistic view. You have to continue to improve systems over time. The job is never done. It is a priority for us. We’re very much on top of understanding the challenges of connecting vehicles, partitioning critical system from non-critical systems or informational systems. That’s part of the solution. A lot of this technology comes out of the IT industry in terms of signing packets of information that come from off-board for updating software and things like that. It’s not just simply loading a piece of software.
SE: Given the breaches that have happened in large IT departments, is that enough?
Buczkowski: The root causes of those vary pretty dramatically. There are some technologies where over time they have found some breaches, which is why over time you do have to stay on your game. You have to constantly look for new types of attacks and attack surfaces. But when properly implemented, a lot of the systems from the IT world work pretty well. A lot of the challenges IT departments face is when there is a human involved, too. We have to make sure we protect our passwords and things like that. Those are pretty critical. We have to do those same things at the embedded level. We are working with NIST (National Institute of Standards and Technology) and the Department of Transportation in sharing information and best practices. We need constantly updated information on threats and various technologies.
SE: One obvious way to minimize a threat is to do updates only at authorized dealerships. Is that realistic?
Buczkowski: Updates can be for security, as well. We’re going to have to have a way to get them an update rather than finding a convenient time to get to a dealer. Updating systems is important. Of course, we have to design that and we’re still in the process of looking into how to design security in so it really is secure. We also are prioritizing systems we think will need the updates the quickest, preserving the safety systems to roll out later. But over-the-air software updates will be important for consumers, as opposed to sending customers back to dealers for every security patch that’s required.
SE: As you start adding in extra security and redundancy into these systems, you start using more power. Will there ever be the equivalent of dark silicon equivalent in a car, or some other power-saving techniques we find in consumer devices?
Buczkowski: There is a model you’ll see, at least indirectly in the way silicon in mobile devices is used, where you can shut down various unneeded systems and only have those listening at the lowest power level. Having vehicles connected all the time means there is going to be something in use. We have to make sure only those systems that are actually necessary are using power. And looking at power consumption over time, there are long periods of time when power will not be used and you shut all the systems down. You use the next time the person gets into the vehicle to wake it up. We will want to be able to connect to the vehicle for updates. But all of the connections will be controlled by the customer for security and privacy reasons. Customers are going to have a choice, so they can opt in or opt out. But when it comes to power consumption, we will design these systems so we are only using the power necessary to provide the basic level of communication. Just as chips in consumer devices can listen and power down the high-power-consuming portions of the silicon, we will power down the high-power-consuming portions of the electrical architecture in the vehicle. It’s creating a power-networking vehicle within the vehicle.
SE: These almost sound like data centers on wheels.
Buczkowski: There is a tremendous amount of data just to operate the vehicle—the signals between modules, communicating with the power train, communicating with the steering system—so as the vehicle is operating there is a lot of data being transferred around. Even within the modules for brakes or steering there is a lot of data that potentially is pretty valuable, whether it’s for performance of the systems or diagnostic for condition-based maintenance. To be able to create experiences for customers where we can anticipate and prevent any down time if we see unusual wear on a component, so we can alert them of a possible breakdown, is really important. Creating architectures that can export that information, whether it’s local processing or being able to export it to a place for external processing, is in the future as well.
SE: How much data are we talking about?
Buczkowski: We looked at things like brakes and did studies showing a lot of the value is for information over time. That’s a huge amount of data. What’s necessary to keep on board, what should be kept on board for analytics within the vehicle, as well as what data should we ship off-board? We haven’t determined whether we will ship images off-board, but if we do compression obviously will be important. A lot of the data doesn’t have to be visual, though. There’s a lot of data we collect from sensors that are measuring variable data such as speeds and pings from radar.
SE: So you’ve got all the issues of a consumer device, the challenges of connecting it into a cloud, and power management concerns?
Buczkowski: It’s similar or different, depending on how you look at it. We have looped control systems that don’t even involve the driver. They may pick up data to optimize performance. If you know from navigation information that a hill is coming, you can anticipate shifts. That can create a smoother drive without direct involvement of the driver, but it does depend on connectivity. There are good spots, but you can’t always rely on connectivity, so you also have to deal with the fact that a signal could go away and the system still has to work.
SE: Let’s dig down much deeper. What kind of chip process nodes are you working with?
Buczkowski: When I first started 35 years ago, silicon feature sizes were in the microns. Even at that time, we were pushing the reliability of 1 micron and 0.5 micron yield and performance. Today, the semiconductor industry has come a long way. They can design silicon in the nanometer range that yields a lot better and is more reliable. We’re still behind the leading edge, but it’s not like it used to be. At 1 micron and 0.5 micron, there was a lot of redesign. A chip would come in from the consumer side, which was pretty limited, and it would be redesigned for automotive. Today that’s not happening as much. Whether it’s for a consumer application or an industrial or automotive application, there’s far less redesign. And most of it is modeled ahead of time so they know they’re designing for a process that has to support minus 40C to 125C. We still don’t end up on the bleeding edge, more because of cost than anything else. But if the devices being designed are at 22nm and the silicon industry can pay off the multi-billion fabs used to manufacture them, we will come in as the cost per wafer goes down.
SE: Some of the established nodes, such as 65nm and 45nm, are rather leaky in terms of current. That leakage is more under control at advanced nodes with FD-SOI and finFETs. How does that affect your choices?
Buczkowski: The difference now, compared to the past, is that chipmakers are more aware of the challenges that automotive is dealing with. We don’t have to go in and spend a lot of time understanding the process efficiencies when you get to 28, 22 and 20nm. They understand what the challenges will be in five years for automotive. They’ve had enough experience in working with us and understand that for this part to eventually work in automotive, this is what will have to mature in the process and here are the design changes that will need to be made. As an automotive company we’re not getting involved in the design details of semiconductors anywhere near as much as we did before because in those days they didn’t understand automotive and didn’t have the design tools to design for automotive grade.
SE: But you are getting into much more of the SoC spec than in the past when a single MCU or processor was used, right?
Buczkowski: Definitely. Architectures are less unique, though. When I started in powertrain controls with 16- and 32-bit controls, we did custom architectures with Intel Corp. and Motorola chips. Today, semiconductor manufacturers are using ARM cores. They are designing modules and piecing those together for us today. There’s a lot more reusability than in the past, a lot less full-custom and even semi-custom, and the Intel’s and Freescale‘s of the world understand that, from an SoC perspective, this is what the automotive guys are looking for. That goes for memories too, and whether they’re going to integrate full memories on board. Each of the main semiconductor suppliers has automotive teams that keep their fingers on the pulse of what the automotive guys need.
SE: How much power can you save from an electronics side? Where are the big savings?
Buczkowski: We worry a lot less about power savings from electronics in regard to fuel economy and more about sizing the power and the power supply system. Those are heavily influenced by the actuators. Electric power steering is a big consumer of energy. It has some big motors in it. Some of the actuators are more efficient than in the past, but they’re still pretty big energy consumers. We don’t worry about the SoCs as consumers of energy, but we do worry about consumption when we’re not generating any power from the internal combustion engine. In electric vehicles, you have to worry about the battery all the time. It’s a question of how much drain you’re putting on the battery. The actuators are the big consumers on a 12-volt system, which is why there is talk about a 48-volt system or a split power supplies where the electronics can remain on even a lower voltage than 12 volts and the actuators can be on higher voltage systems to reduce the current.
SE: Ambient temperature can have a huge effect on an SoC’s efficiency. Is it the same for all the other components in a car?
Buczkowski: It depends on the actuator or sensor. Many can work over the entire temperature range. That’s not true of mobile devices. Typically, a mobile device is in your pocket. Even the battery in an electric vehicle generates self-heat that has to be dissipated. That does affect reliability. That’s why we have a spec for under hood of 125C. But with those kinds of temperature ranges, it’s more of a packaging issue. Semiconductor technology has come a long way with Moore’s Law, but so has packaging and package materials and wire bonding within the package. It’s amazing to see how much progress has been made, and more will be made in the future to withstand thermal shock. It’s all about materials science.
SE: What’s the vision for what a car looks like in five years? Is it a programmable device or is it off-the-shelf?
Buczkowski: At a more strategic level, the software is creating a lot more of the DNA in the differentiation of our vehicles. The software is going to ride on capable platforms. It will provide the vehicle’s DNA, as it does today, but it also will allow the vehicle to be upgraded over time. That means the hardware has to be extensible. At the first sign of a software upgrade the hardware can’t be obsolete. We do have our challenges in designing platforms that have extended capabilities so we can fully utilize software we build on top of it. But software will create the character of the vehicle. It will enable the vehicle to be upgraded and evolve over time.
SE: One of the concepts that is resurfacing on the chip side is resiliency. Is that in Ford’s future?
Buczkowski: Absolutely, both at the hardware and the software level. We have conversations with the aerospace industry, which is thinking about resiliency, and I’ve heard those discussions at the hardware level as well as the software level in terms of soft failures. We have a lot of work going on with ISO 26262 and ASIL design to ensure the hardware and the software working together form a reliable system that has a level of fault tolerance to it. There’s still a lot of work to do in that area.