SoCs are replacing MCUs in electronic control units as complexity rises.
The fuel injection control unit has come a long way since 1983 when Ford Motor Co. first included a 16-bit Intel microcontroller-based fuel injection system in its 4-cylinder Escort. Today, some high end vehicles contain more than 100 microprocessors, which is mind boggling in comparison to that Escort that contained just one.
To be sure, the automotive industry is a unique animal. Compared to the consumer-oriented market, automotive has some very specific requirements that are tougher to follow. The car has to work under any circumstances, weather conditions, temperatures, rain, snow, you name it, which makes the requirement list a bit longer, noted Robert Schweiger, sales director for EMEA field marketing and automotive at Cadence.
“There are a lot of safety requirements, but in addition there are a lot of government regulations that are put on top of the automotive industry that ripple down even to companies like Cadence and its IP. They are keen to reduce emissions, which really starts with the power consumption, so there’s also a low power issue — not only for electric vehicles, but for gasoline-powered vehicles, because if the engine needs to produce your electricity in a car and you need to have the right diameter of the power supply cables, it all adds up to the overall weight of a car. There are other regulations in terms of safety in terms of advanced driver assistance systems,” he said.
What also makes the automotive market different than others is the additional verification task that is seen in other mission-critical businesses such as medical and mil/aero, observed Adam Sherer, product management group director for automotive safety in the Systems Verification Group (SVG) at Cadence. Of course, there are different degrees and different levels of development, and it all adds up to a fundamental realization that while the traditional functional verification has been done, there is a new task when it comes to safety verification. The automotive industry is now trying to understand exactly what needs to be done to provide increasing amounts of data to support the verification that’s been done. Specifically, this means requirements tracing from the OEM to Tier 1 to the semiconductor to the IP. “We’re going to have a larger burden of proof that not only traces the requirements — in the spirit of an ISO 9000, repeatable, traceable process — but there is a specific requirement to identify the quality, and this is coded in the automotive safety integrity level (ASIL).”
The good news is that improved safety and reliability have been the leading megatrends for the automotive industry over the past century, reminded Arvind Shanmugavel, director of application engineering at Ansys-Apache. “Automobiles have evolved to be safer and more reliable to own and operate with advances in the area of safety and reliability. Over the past decade, the automobile industry has undergone a transition to bring in two additional megatrends – efficiency (fuel and emissions) and connectivity (infotainment) to improve the driving experience.”
In addition, the advances in electronic component design, improvements in integrated circuit performance and integration have been instrumental in improving the overall safety, reliability, efficiency and connectivity of automobiles, he said. “Most contemporary automobiles will contain four main electronics subsystems that are responsible for its operation: 1) engine and power-train control unit; 2) safety control subsystem; 3) advanced driver assistance subsystem; and 4) infotainment subsystem. These four electronic subsystems either control the vital operation and safety of an automobile or influence the driver/user experience.”
Electronics that are part of an automobile inherently work in a ‘noisy’ environment, and this means that the electronic systems that support critical functions such as the engine control unit or the safety system should have a systematic design philosophy with noise immunity and reliability in mind, Shanmugavel continued. “Temperature variations in automotive environments range from -50C to 200C. Semiconductors and electronics need to be able to operate in these high temperature environments. Thermal stability, electromigration and thermal aware fatigue should be appropriately simulated on automotive electronic components. Semiconductor ICs specifically should be simulated at these temperatures for reliability and lifetime effects. ICs should also be able to reject noise that is coupled through different forms. High energy noise sources such as inductive discharge ignition system and power line emissions to low energy noise sources such as antennas radiation on the vehicle should be appropriately rejected. Separately, the ICs themselves should be designed in such a way to minimize the amount of noise that is emitted from its own operation. Electromagnetic immunity standards such as ISO1152 and ISO7673 are rigorously tested on all automotive components that sustain critical functions.”
When it comes to the design of those electronic control units (ECUs) that provide the control for each system in a vehicle, this continues to evolve over time.
“If you think about the basic systems of an automobile — braking, steering, engine, lighting, door locks, windows and so on — those go back a long way, and those systems have been electrified, ” said Jim Buczkowski, global director of electronic systems, research & innovation, at Ford. “Crank windows to electric windows to smart windows that bounce back up to prevent entrapment or one-touch-up windows. It’s a pretty trivial system for a lot of folks but really important. Before you even start adding on the fancy stuff, such as auto-park assist, forward collision warning, and so on, the early adoption of electronics to these systems was really siloed. You’d have body controls for lighting and lock controls, and a separate powertrain controller, a separate one for transmission, a separate one for anti-lock brakes. Now you are starting to see more of those systems come together.”
The first phase of that evolution involves sharing of information. “Automatic door locks when you reach a certain speed will lock automatically,” Buczkowski said. “This requires vehicle speed information. The powertrain control system needs that, too, to understand transmission shifting. Now you have these shared signals that have to be communicated across these different systems, so that’s where the emergence of networking between these electronic control modules came into the system. We’re probably about 20 years into different networking in the vehicle. We’ve leveraged CAN networks, and we’re now starting to see that evolve into higher speed networking that leverage technology that comes out of the IT and computer industry. Ethernet is an example. We’re looking at projects in the future that we use Ethernet as an additional communication network in addition to CAN for certain kinds of signals that we need to pump a lot of information across.”
All of this is an evolution from individual control systems. The systems gain the capability to share signals, and the semiconductors and electronics incorporate more features and functions into one control unit.
“You start to see more integration of features together into a single box,” he said. “The microcontrollers are much more powerful and capable and able to do many more things simultaneously, which helps us reduce cost and improve performance, as well. You’re going to continue to see that trend. We’ll add new features, such as backup cameras, things that may be standalone at first and eventually integrated into a single unit that can control multiple functions. There won’t necessarily be one single unit for the entire car, but where we might have 60, 70, 80 different ECUs today, there will be some significant reduction as we integrate those together by using a more powerful processor. Again, costs in the semiconductor industry has helped us drive the cost down, and integrating saves in terms of power supplies and other ancillary types of things.”
Cadence’s Schweiger noted that traditional ECUs were mainly based on MCUs. In contrast, new systems such as advanced driver assistance will require something different because these type of systems need a completely different performance level than the previous MCU-based unit. “And because they have a more powerful core in those ECUs, those are not based on MCUs anymore because they are running out of steam, especially for camera-based systems. Semiconductor companies are doing SoC design for these type of ECUs, and because they are doing SoC design, they have a lot of IP in their SoCs. They can only realize those SoCs by using advanced process technologies like 28nm CMOS.”
But that also changes the entire design process. “The design of an SoC-based ECU is very different from an MCU-based ECU because the MCUs are off-the-shelf, standard devices, so there are all kinds of tools available. For instance, if you want to do Hardware-In-The-Loop simulation of such an ECU, you will find tools that have already the MCU of Company XYZ in their library to simulate that MCU. But if you want to do an SoC, it’s not a standard device and therefore the tooling is very different because you do not start by selecting just any MCU. You have to start by selecting the right IP to first of all build the SoC. And for the OEM, their tool environment is not so exhaustive,” Schweiger added.
To Chris Turner, director of product marketing for the CPU Group at ARM, the ECU is like a ‘silver box’ hidden around the car, in the engine compartment, behind the dash, under a seat, in the trunk. Often there are 50 or more per vehicle, and each can have multiple PCBs inside and multiple semi devices – MCU, power, analog.
Numbers vary greatly, depending upon the make and the model. Charlie Janac, chairman and CEO of Arteris, puts the number of ECUs as high as 145, most of them being MCUs. “Each major subsystem has an SoC, with a lot of the functions done by the MCUs. What’s changing is that cars are being assembled out of larger subsystems that are being custom designed for a class of car, and the best way to keep those up to date is with SoCs. Tesla didn’t force everyone to go electric, but they are forcing a rethinking of the strategy for putting together a car. The electronic architecture of the car has to be redone so it can be updated. You need security chips everywhere and software has to be rethought.”
Design challenges of ECUs
Given the constraints, operating modes, government regulations, among other things, Turner stressed that one of the challenges of designing ECUs today is achieving functional safety goals on high performing processors within acceptable cost and power/thermal constraints. The second is managing software complexity given that modern cars are operated by up to 100 million lines of source code written by multiple companies and teams with requirements for high availability and safety critical systems.
Still, automotive is a very unique industry as the carmakers drive most of the industry, and the Tier 1 and Tier 2 suppliers do what they request. Interestingly, Andrew Patterson, director automotive business development at Mentor Graphics, pointed out that there are even different tools depending on whether you’re an OEM, or a Tier 1 supplier — and the use cases are thought about quite differently. “At the OEM level, if you are building a complete car, what types of tools do you need for the ECU design? When it comes to the architectural level, there are actually in a vehicle many different types of networks. Almost every car has a CAN (controller area network) that’s been around since the 1980s, and it’s been very proven and safe. It’s recently been extended to CAN FD (Flexible Data-Rate) to allow bigger data messages to be sent around. As the ECUs have gotten more complex, people need to send more complicated and more detailed messages, and the old CAN data size was not enough.”
Of course, there is a big trend toward Ethernet in vehicles, which can carry even more data due to the higher speed. 100Mbps Ethernet is being used in cars today to increase the bandwidth of what can be sent round.
Patterson said carmakers first need to consider the network type, then they work out messaging schemes: what data needs to be passed from ECU1 to ECU2. With the number of ECUs in the car, that gets very complex.
As such, modeling at that architecture level is a really important first step, Patterson explained. “In the very early stages people don’t even use the physical connections. They use something called a virtual function bus, so it’s just passing messages from one to another, modeling the logic states of the vehicle. For example, if you’re not in the park position, you can’t take the key out of the ignition. All the little things that happen in your vehicle are all defined in this sort of interconnect logic between the ECUs. So when you think about your car and all the things that happen, perhaps when you leave the lights on, when you’ve shut the door and turned the engine off, you get a little warning beeper — those are all interacting ECUs that define a logic state.”
He said carmakers want to worry at that level about how everything interacts, as well as modeling all the messages that go backward and forward. Modeling is also done on a virtual platform on a PC before connecting to real hardware.
One of the big changes in ECU design in the last few years is AUTOSAR, which defines a standard methodology for carmakers so they can define how ECUs are created from a software point of view, how they communicate with each other, and the data types/data messages that are used, Patterson noted. AUTOSAR also allows more interchange between carmakers and their suppliers by providing a way to take an individual ECU and extract its template — the connection points, the data it needs to handle, the messages — and that can be sent electronically to a Tier 1 supplier as a digital specification.
But even more significant changes are coming in the automotive industry, particularly as it relates to ECUs. There is now the need to update ECUs during the lifetime of the vehicle, he said. “In the old days, they would be sealed for life. With the need for carmakers to innovate, perhaps at the pace of consumer electronics, certainly at a faster pace than they are now, they’ve seen that they can change or improve functionality of ECUs by updating the software on them, and that’s one of the biggest changes we’re seeing going forward. With the infotainment system or instrument cluster display, it’s quite nice if that can be updated during the life of the car, perhaps as new standards arrive or new applications are included. Map updates would be a good example. Carmakers are having to leave open a way to re-flash or reload data onto the ECUs, and that can be done manually or over-the-air.”