The Wild West Of Automotive

Automotive is considered one of the great new markets for EDA and IP. Electronic complexity is increasing rapidly, product update cycles are decreasing, and new standards mean that many of the old ways of doing development are no longer possible. Such change creates opportunity, along with a certain degreed of confusion.

As the number of discrete systems increases, so do costs. Electronics content is projected to be 50% of the costs of the car before long. This is bringing about integration and centralization, which in turn is causing some architectural changes within the car. Some of the more advanced features in development require much greater communications, an increase in both the number and complexity of sensors that require fusion, and much larger processing capabilities than what is currently found in systems.

With the rapid increase in consumer-level content going into cars, and the amount of integration happening in areas that previously were discrete functions, this market looks a lot more like cutting-edge semiconductor development than some of the more traditional control functions within a car. And while a car may have a bigger battery than a mobile phone, power is very much on the front of people’s minds because power it translates into emissions.

Rethinking architectures
The first question one has to ask is why does the car need a new architecture? “When cars had 50 or more processors, or chips, people started to measure the amount of cabling in them,” says Drew Wingard, chief technology officer at Sonics. “This is in the order of a mile or more, and this is expensive. This initiated efforts to share a single wiring harness across many functions. So we start to see a network inside the car. CAN is an example that is widely deployed. Once you have the network you can start to think about the best place to do processing.”

There is also a complex connection between power and cabling as explained by Robert Schweiger, director technology solutions for automotive within Cadence. “If you can reduce power, you can reduce the diameter of the wire harness,” he says. “This is heavy and so there would be a weight reduction. If the car gets lighter, the fuel consumption goes down. This has a knock-on effect in that you may need a smaller battery. That in turn is heavy, so reducing its size further reduces weight. A smaller battery requires a smaller generator. There are spiral dependencies related to saving power.”

One way to reduce power is by integration. “A considerable amount of the power in a chip is consumed by the I/O,” says Aveek Sarkar, vice president of product engineering and support at Ansys-Apache. “If you have multiple chips, each has to have I/O circuitry. When they are combined, a lot of this is eliminated.”

Sarkar provides one example. “Consider power steering. There are several sensors, such as a torque sensor, steering sensor or speed sensor. These inputs go through some conditioning, some muxing, and this is fed to the controller that then decides what to do. With transmission control there are several layers of sensors. There are several layers of sophisticated microcontrollers that control the various functions.”

Will Tu, director of embedded segment marketing for automotive within ARM uses a diagram from Bosch to explain what is happening architecturally. “We are currently in the integration and centralization phase, especially for body control.” Tu provides examples of body control functions, such as door nodes, mirrors, climate control, and locking function. “Many of these are being centralized into zone control functions. They have one big controller that does the processing. You still have a door node and it still has a controller in it, but the amount of electronics needed for it is very predictable. You have de-contented it as much as possible and centralized it.”

The current decentralized architectures implements one function per module. “New architectures are integrating ECU functions and adding more sensors,” says Ron DiGiuseppe, senior strategic marketing manager for Synopsys. “ECU designers are responding by adopting sensor fusion to integrate the sensor data more efficiently. By combining functions into integrated domain controllers and increasing sensor data, the SoCs are becoming more complex and consuming more power. Examples include the multiple image sensors needed for backup cameras including the surround view sensor data. By pre-integrating sensor and actuator-specific IP blocks together, complexity is reduced which minimizes the impact on power.”

ARM’s Tu points out some other advantages related to this architectural change. “It provides more flexibility from a processing standpoint. You don’t waste as much and you don’t have to worry about software growth in every node. The smaller nodes become very simple to define. The more centralized boxes have more potential for growth in memory, processing requirements etc.”

From the diagram it’s apparent that another catalyst for change is also brewing. “Automotive systems include a broad range of applications ranging from traditional control such as powertrain, chassis and body to consumer applications like infotainment and the emerging advanced driver assistance systems (ADAS),” says Marc Serughetti, director for business development with the System-Level Solutions group of Synopsys. His colleague DiGiuseppe adds, “ADAS systems are more complex due to new vision-based safety applications such as speed sign detection, driver drowsiness and gaze detection. ADAS apps processors require higher performance processors running at greater than GHz+ operation”

“ADAS features such as lane departure are still one box, one function,” points out Tu. “This is because they are new and there is hesitancy to integrate something that is new. In the more mature areas they can save money, and this makes room for more costly new electronics.”

Serughetti also sees other tradeoffs being explored in these new areas. “Power/performance requirements are emerging in areas such as ADAS that requires a balance between safety, performance and power.” He notes that power/performance analysis for these increasingly complex multicore SoCs executing a large amount of software needs to start at the architecture design stage. “Traditional static power calculation can no longer reflect the proper multicore behavior.”

Each domain has its own specific concerns, and that is very much the case with automotive. “Performance isn’t based as much on throughput as it is on latency,” says , chief technology officer at Carbon Design Systems. “Design techniques that sacrifice latency to achieve throughput don’t have much application here. Taking a system configuration that works well in a mobile application and putting it into an automotive control space will cause lots of wasted power and cycles.”

Different parts of the car appear attractive to different vendors. There is one module that is becoming very sexy to ARM and that is the gateway module. “This is a box that contains the CAN protocols, Ethernet, LIN,” explains Tu. “It connects the whole vehicle together. The gateway is like the heartbeat and liver functions of the human body. The heart spreads all the data throughout the car and the liver is the filter function that provides some of the security features. It provides the firewall between the infotainment systems. It also enables the upgradeable car.”

Constraints
The car is a hostile environment for electronics. There are extreme temperature ranges and lots of electro-magnetic noise. At the same time, we have expectations for a car that do not exist in, for example, the desktop or smart phone worlds. “Boot time of infotainment (and other functions within the car) is required to be fast,” says Schweiger. “Part of this is because the display is also used for the parking assistant. You want this active quickly.”

But consider what happens when you park a car in the sun. “You get in, turn on the engine and select reverse,” says Sarkar. “You expect the radar in the back to be operating, but because of the high temperature the chips slowed down and the radar is not ready. The latency increased because of temperature. But you expect the radar to work and possibly don’t even check by looking over your shoulder. This could result in an accident. People working on these systems have to worry about these scenarios.”

Having the equivalent of the blue screen of death also would be considered detrimental, although several of the people interviewed for this article did describe situations where they had to pull over and reboot part of the car’s electronics.

Some of the biggest differences are related to the required longevity of the systems. Phones get thrown away after a few years, whereas cars stay on the road for 15 or more years. “There are long-term reliability requirements,” says Sarkar. “Often these cannot be proven in the latest technologies,” meaning that the newer technologies often do not find their way into cars.

There are other differences in the makeup of the controllers. “Automotive uses embedded (NVM),” says Tu. “This is done for power and security. It is harder to read embedded flash compared to off chip. Integration of DRAM is not friendly in automotive.”

But perhaps the biggest difference is safety, and this trumps the power concerns. “They don’t want to move the brain that decides when to deploy the airbag or deal with anti-lock braking,” says Wingard. “You don’t want to move that very far from the sensors. The extra cost outweighs the safety aspects of making each a fairly closed system.”

Networking
With more data moving around the car, the existing networks are under pressure. Schweiger is anticipating the biggest change in 25 years, calling for “the introduction of the automotive Ethernet network. This will completely change the architecture. Subsystems will all be communicating with each other. They are all becoming inter-dependent.”

Many of the new sensors create huge amounts of data. Consider some for the functions necessary for ADAS. Radar has been on the car for some time, and now they are introducing cameras. “Radar tells you where an object is, how far away it is, how fast it is moving,” says Schweiger. “The camera will tell you what it is. CAN, FlexRay and all of these other networks do not have the necessary bandwidth. With the introduction of Ethernet, you are able to have video streams, but there is an even higher performance network in the final standardization phase – Gigabit Ethernet. This will mean that you don’t have to do compression of data streams and compression may remove some important information that could be important for decision making.”

Can we expect to see Ethernet everywhere in the car? “The investments in CAN and FlexRay are not going away,” warns Wingard. “Those fabrics have real-time capabilities that are not easy to duplicate with Ethernet and that is critically important for functionality and safety of some of the systems. Thinking that Gigabit Ethernet will replace this is silly. With Ethernet, the single packet level is assumed to be unreliable. That does not mean that Gigabit Ethernet will not exist in a car, especially in systems that are not safety-critical such as infotainment. It is cheap and will reduce the wiring in the car by replacing a bunch of stuff with a couple of twisted pair.”

Updating the firmware
There is another change coming to cars that has a scary side to it. “The ADAS systems are very algorithm-based,” says Tu. “The sensors do not change but the algorithm will constantly be improving. They need to be able to perform over-the-air upgrades on these capabilities.”

Tu explains how something as mundane as air bag deployment could be optimized. “Today, they don’t consider the seat position and use that as data into the airbag algorithm. If you have an interior camera and notice that someone is leaning forward, or that a very small person is there, or there is a car seat installed, then you could deploy just one part of the dual-stage airbag to offer partial protection but not fire both stages. This is dependent on the data from several sources. There is a whole bunch of passenger contextual awareness that could be added.”

We can but hope that car updates are better that those in the phone and that security is improved before this becomes a reality.

Power reduction
The need for low power in cars is different from the mobile world. “With mobile, the phone is active for a few minutes and then inactive for a longer period,” says Anand Iyer, director of product marketing for Calypto. “In a car, the on timeframe is minutes to hours. This affects the power budgets. Dynamic power becomes more important. Form factors are also not as constrained.”

“Dynamic power is key,” agrees Sarkar. “While leakage is important, dynamic is not just a consumption problem, but also a reliability problem because more switching creates more EMI. They also want to reduce current flow in the chip because that adds to electromigration (EM) and other problems.”

Sarkar explains that with smaller geometries and smaller wires, there is a higher propensity for failure if the current densities are higher. With more adverse conditions than experienced by mobile, things have to be controlled more. “Newer nodes tend to have higher switching currents – the di/dt. The libraries are faster, the device operates at a higher speed. Higher di/dt creates more EMI. Slower speeds reduce these effects. Higher frequency also generates more heat, and that coupled with higher ambient temperatures worsens EM and other reliability concerns.”

At the end of the day, there are other reasons why power has to be minimized. “The problem with power is coming from the fuel savings and the emissions dictated by the government,” says Schweiger. “In order to reduce emissions, you need to reduce fuel consumption, and to reduce this you have to save power. Power consumption by the electronics is indirectly contributing to emissions.”

Standards
You can’t talk about cars for long before the conversation turns to standards. “ISO 26262 was ratified a couple of years ago and that defines a set of integrity levels,” explains Wingard. “At different levels you need to be able to describe different levels of resilience and fault isolation. The question boils down to the most likely places that faults will show up and the best ways of containing them.”

When talking about ISO 26262, it seems to create more differences than alignment. “ISO 26262 affects the software mainly,” says Sarkar. “A software bug is likely to be more detrimental than a hardware bug. So how do we help them design the software to meet these requirements? From a chip point of view is additional logic required? Possibly, but from a power consumption point of view it may not be as critical.”

When it comes to hardware, ISO 26262 appears to concentrate more on reliability-induced failures. If flash becomes corrupt or a wire burns out, you need to have a way to check for this type of error. The ways to do this are still evolving. Wingards says you could “build redundant copies that are laid out separately so that it doesn’t have the likelihood of the same error showing up in two places at the same time – and then use simple circuits to compare.”

This is a strategy also being adopted by ARM. “Running two processors together in lock-step allows us to very easily meet the requirements for the safety critical functions,” says Tu. “There is a cost ramification in that you have two CPUs, but this is well understood. Self-test has to be done at the chip level and often software is used to do this.”

But this is not the case for all systems within the car. “For safety-critical systems it is accepted that you have redundancy,” says Schweiger. “Lock-step is the usual way where they are both being checked against each other. Up until now, they have used functional verification and also verified their safety mechanism. Today they have more automation on the fault simulation side for safety verification. The OEMs require that all components are 26262 compliant. You have to test and verify how your system would react to all kinds of potential faults on the software or hardware side.”

This is the subject of much discussion. “We need to look at possible failure modes and work out which ones are likely to be worth building hardware to detect or protect against,” says Wingard. “Some can be handled in software if they occur. It is a system problem, not just a software problem.”

Wingard also points out that data and control paths are very different. He believes that people find duplicating the hardware attractive because they don’t have to figure out how to do error checking on the control logic. “This is hard. You have to figure out a way to model that function and produce an alternative view of what the output should be. Error checking or correcting around numerical values in the datapath is fairly straightforward.”

It also has implications on EDA tools. “ISO 26262 imposes restrictions about how optimization can be done,” explains Calypto’s Iyer. “Redundancies may have been added to provide fault tolerance. In one design, we located redundant reset flops and would normally have eliminated them from the design, or identified them to the designer. In this case, a European standard prohibited the removal of this redundancy due to safety measures imposed by that standard.”

There are several standards in Europe that are country-specific. These are often applied in addition to ISO 26262. Many of them add guidelines similar to ISO 9000. For example, Italy’s AVSQ concentrates on checking the manufacturing process’s stability, and developing products from design through the completion stage, while Germany’s VDA 6.1 requires things that exceed ISO 9001, takes elements from other standards and attempts to integrate them into a cohesive quality system specific to the German automobile industry.

Conclusions
While the infotainment system gets most of the attention when talking about electronics and cars, the rest of the system is undergoing a large amount of change and is becoming increasingly sophisticated. It took many years of evolution before the mobile phone turned into a smart phone, and with automotive electronics we have hardly started to leave the gate. No wonder everybody wants to try and carve out a piece of the action for themselves.