Application-Driven Power Management Keys In-Car Telematics

In a bid to enhance the safety, convenience, and market appeal of their vehicles, automakers and Tier One auto suppliers are introducing a growing array of telematics and infotainment systems. High-end or low-end, these systems must meet stringent standards for reliability. But, just as important, they must operate within ultra-low power budgets, where the combined draw of all devices cannot exceed several milliamps or, in some cases, microamps.

Power management for telematics is, in fact, highly complex, and must often address conflicting demands for performance, product features, and power conservation. For instance, a telematics device may need to deliver predictable response times while in low-power states, fine-tune power consumption in response to vehicle-specific events, or maintain operational readiness for days, even weeks, after the ignition has been turned off.

Unfortunately, existing standards, such as the Advanced Configuration and Power Interface (ACPI), typically place control of power management in the operating system (OS), which has insufficient knowledge of a vehicle's systems and operational scenarios to make appropriate power management decisions. Developers need a more flexible approach that not only addresses events and scenarios unanticipated by existing standards, but offers finer control over the power consumption of individual peripherals.

Predictable response times
To understand, let's begin with the issue of predictable response. An in-vehicle device may need to respond to external events in a timely manner, either to enable a feature of value or to ensure that the device, or the larger system to which it belongs, operates correctly. For instance, a telematics unit connected to a vehicle control bus must respond to bus wakeup and initialization messages within a specified time frame. Failure to do so can compromise the initialization of other components and result in forced removal of the device from the bus.

Therein lies a problem. If the device "cold boots" in response to such events, the multiple initialization steps involved may exceed the system's time constraints. On the other hand, leaving the device in a conventional standby power state can eventually exceed the allotted (and very small) power budget. This dilemma—too many initialization steps or too much power consumption—can be resolved, however, if the device can recover from a precisely defined low-power state to another, well-defined power state. The developer must, in effect, be able to "dial in" the exact state that enables both predictable recovery and low current draw.

Extended operational lifetime
A telematics device may have to respond to external events for hours, days, or weeks after the ignition key has been pulled out. But, as with predictable response, this extended readiness can rarely be achieved by placing the system's peripherals into normal standby power states. The combined draw will, over time, greatly exceed the battery's reserve capacity.

Instead, the device must gradually step down its power consumption, shedding operational capabilities and powering down peripherals as it goes. This gradual reduction is very application specific, and must take into account the duration of time during which any operational scenario may occur.

Consider, for instance, a cell phone-equipped telematics system that can unlock the vehicle doors in response to a phone call from a customer service center—a valuable feature for anyone who has ever locked their keys in the car. Since a cell phone can draw significant power, the telematics device could maintain a standby mode with near-instantaneous response for a matter of hours or days, but no longer. After that, it would wake up long enough to power down the cell phone and then periodically check for an appropriate condition.

Existing approaches and their drawbacks
Unfortunately, the requirements we've examined are inadequately addressed by the current standards for power management. Consider the widely used ACPI. This specification can be divided into two parts: an implementation at the hardware and BIOS level, and functionality incorporated into the OS itself. In a nutshell, tables in the BIOS define the power modes for individual peripherals, and the OS uses these definitions to decide when to switch devices from one power state to another.

The approach has two immediate drawbacks. First, it relies on the BIOS, a component rarely used in embedded systems. Second, the very notion of giving the OS responsibility for power management was conceived for general-purpose computers—systems that are typically "on." It doesn't apply to telematics devices, which also require intelligent power conservation when the ignition is off. Such devices require a power policy that responds to battery level, passage of time, and other application-specific scenarios. As noted before, an OS, by nature, has far too little knowledge of such scenarios to make appropriate power management decisions.