Driving down power

Software content in vehicles is rocketing — in 2011 the business research firm Frost & Sullivan estimated that cars will require 200 to 300 million lines of software code in the near future. On a higher end vehicle there can now be 100 Electronics Control Units (ECUs), to provide all the vehicle electronic functionality (from electric sunroof to automatic headlight levelling to rain sensor to engine management).

Figure 1: The number of ECUs is increasing in all car segments (Source: Strategy Analytics)

But increasing the number of ECUs in the car also increases electrical power consumption of the vehicle, and this energy is certainly not free. In fact, it can be directly linked to fuel consumption:

• 100W electrical power = 0.1litre/100km
• If the vehicle weight is also considered:
• 50kg weight = 0.1litre/100km

Figure 2: UK fuel prices (Source: The UK Department of Energy & Climate Change)

Both these factors demonstrate why minimising electrical energy consumption and the weight of ECUs and the vehicle electrical infrastructure are essential in the drive to improve fuel consumption. Considering other factors, such as legislation and the desire to increase the range of electrical vehicles, power consumption is clearly a critical aspect of modern automotive design. Looking at the long term trend of fuel prices highlights the scale of the challenge.

The ECUs in the vehicle are distributed around the vehicle, grouped together in domains, connected by one or more of the system busses, such as CAN, LIN, and FlexRay. In the future, vehicle network architectures will consist of highly-integrated domain-controllers, which will be interconnected via higher-speed bus systems, like Ethernet. Figure 3 illustrates an example of a future vehicle network partitioned into separate application domains with associated domain controllers. These controllers will require significant amounts of processing power coupled with real-time performance and communications peripherals.

Figure 3: Vehicle networks arranged by application domains

There are three basics methods for power reduction in the vehicle: reducing the number of ECUs in the vehicle; lowering the power drawn by the MCU, and; managing power in the car at a network level.

Minimising ECUs

The key to reducing the number of ECUs in the vehicle is to break the 1:1 correspondence of a vehicle feature to an ECU, with the central ECUs hosting multiple applications. This also helps make vehicle options cost effective and manageable in a complex manufacturing environment, by enabling vehicle features by software on a common hardware platform.

Supporting multiple applications within a single architecture lends itself to multi-core design and associated feature set, for example the MPC5748G MCU from Freescale. A high degree of separation and isolation between different cores and their associated resources permits isolation at the application level. This means that it is possible to dedicate some resources of the MCU, for example a core, subset of the periphery and memory, to one application while retaining another core with its own subset of the periphery and memory for a completely separate application.

Figure 4: Application isolation & protection mechanisms implemented on the MPC5748G MCU

Another side benefit of this application isolation is the protection it offers the software integrator to collate software from many third-party developers, knowing that they will run independently and autonomously. The diagram of the MPC5748G architecture in Figure 4 shows some of the features that enable such a high degree of application isolation.

To demonstrate these features and the capabilities of the MPC5748G MCU in a practical real-world application, Figure 5 shows a proposed use case. In this example, the device controls two independent domains:

Figure 5: Multi-domain operation with the MPC5748G MCU

An AutoSAR domain

• Handles classic AutoSAR automotive body & gateway functionality.
• Has dedicated CPU and associated memory and peripheral resources.
• Runs almost independently of IP router domain, but is capable of safely and securely exchanging data through shared memory and interrupt messaging schemes.

An IP router domain

• Connects to the internet and is intended for supporting applications such as distributing in-field flash downloads within the vehicle network.
• Uses a dedicated core, dedicated system RAM, and a portion of the flash array and runs its own operating system with its own OS timers, watchdog, and system resources.

Multi-core multi-application MCUs need to be developed in advanced technologies to meet the performance demands. However these new technologies introduce many challenges for the system designer including coping with increased power consumption. While each technology step helps devices execute faster to increase performance, and hence meet customer expectations, it also requires an innovative way of thinking to solve the power crisis. Figure 6 shows the increasing demand for power.

Figure 6: Power trends through 2020 (Source: International Technology Roadmap for Semiconductors (http://www.itrs.net/))

MCU power reduction

Previous generations of MCU contained only two basic states: either ON or OFF. Advanced MCU technologies force several operating modes to cope with concerns for power consumption, such as: RUN (traditional full-execution mode, usually the highest consumption mode); HALT (all MCU elements powered, main elements clock gated); STOP (all MCU elements powered, only a subset operational), and; STANDBY (only a small subsystem powered, main areas of device power gated).

In the last generation of Freescale MCUs for the body electronics market, STANDBY mode was introduced. This dictated a different mind-set to address the entire power reduction eco-system, requiring applications developers to create special RAM-based routines to obtain the lowest power consumption.

But the industry has risen to the low power challenge, proving that hardware architecture designers and software developers can work closely together to yield the optimum results. At Freescale, our contribution to this effort has evolved through work with leading industry partners and customers — the introduction of a more advanced power management concept. The main innovation has been in two areas; the introduction of a Low Power Unit (LPU), and the integration of an analog comparator with a periodic timer.

Figure 7: Low-power modes in the MPC5748G MCU

The LPU has emerged as a real product differentiator where full RUN performance is not always required. It is an aggressive mode of device operation, allowing large sections to be completely powered off while supporting the full execution capabilities of a processor core.

The Low Power Unit initially introduced in the MPC5748G MCU family of products allows the application developer to choose between traditional and several new operating modes.

The combination of an analog comparator with a periodic timer can be useful in multiple automotive body electronics application profiles which only require the periodic sampling of input pins. With a traditional approach, this can only be realised by moving to the device’s full RUN mode, however by intelligently interconnecting several analog comparators with an on-chip timer, all of this functionality can be realised within the STANDBY mode. This type of revolutionary approach allows aggressive low power consumption to be achieved.

Figure 8: Periodic sampling of analog inputs using an analog comparator

A typical application requires the periodic sampling of a number of analog inputs. As shown in Figure 8, the introduction of the analog comparator and its unique capability to operate from independent analog references provides a straightforward implementation solution.

Network level power reduction

Traditionally, an entire car network would be powered and operational whenever the ignition key is turned, but there are many examples where this is not required. For instance, when driving, some functions, such as seat movement, reversing sensors, etc, can be restricted.

Three techniques are proposed to limit the power at a network level:

Partial network: Allows the complete shutdown of an ECU that is independent of the other ECUs on the network. The lower level of Figure 9 shows this methodology. The transceiver on the ECU will wake up on a specific bus command.

Figure 9: Power consumption-reducing solutions through partial, pretended, and locally-optimised networks

Pretended network: In a pretended networking approach, elements of the network determine that the level of activity has significantly decreased. Once this decision has been made, the ECU places itself in a lower power state, including the MCU in standby mode, but the intelligent transceiver ‘pretends’ that it still has a network presence. As soon as the ECU is addressed, the MCU is brought back to full operational state quickly.

ECU degradation: In this mode the ultimate flexibility of the MCU is exercised — matching performance with demand, so cores and peripherals can be unpowered, and overall consumption reduced using techniques like voltage/frequency scaling.

With the ever-increasing levels of comfort, safety, efficiency and consumer features in vehicles, carmakers and their electronics suppliers must cope with the conflicting demands of electronics complexity versus power, weight and ultimately fuel consumption.

To manage the increase in power, and contribution to fuel economy, three strategies are followed: reducing the number of ECUs in the car by hosting multiple applications on new multi-core MCUs with higher levels of integration, performance and connectivity, while offering application protection; reducing the power consumption of the MCU by innovative low-power modes of functionality and signal monitoring capability while main MCU is powered down, and; enabling network level power reduction methods via selective powering of ECU and MCU features.