Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Power/Alternative Energy
?
?
Power/Alternative Energy??

Applications approach regulates telematics power systems

Posted: 16 Jul 2004 ?? ?Print Version ?Bookmark and Share

Keywords:telematics? power? automotive? acpi? battery?

Automakers and their suppliers are introducing a growing array of telematics and infotainment systems. High-end or low-end, these systems must meet stringent standards for reliability. Just as important, they must operate within ultralow-power budgets, where the combined draw of all devices cannot exceed several milliamps or, in some cases, microamps.

Telematics power management is highly complex and can vary greatly between vehicles. For instance, a 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 or weeks after the ignition has been turned off.

But existing power-management standards, often based on the advanced configuration peripheral interface (ACPI), typically place control of power management in the BIOS or the operating system, neither of which has sufficient knowledge of a vehicle's systems or operational scenarios to make optimal power-management decisions.

Developers need a more flexible approach, called application-driven power management, that not only addresses events unanticipated by existing standards, but offers finer control over the power consumption of individual peripherals.

To illustrate the power-management problems in telematics systems, consider that a telematics device connected to a vehicle control bus must respond to bus wakeup and initialization messages within a specified time. Failure to do so compromises the initialization of other components and forces removal of the device from the bus.

Therein lies the problem. If the device "cold boots" in response to such events, the multiple initialization steps may take too long. On the other hand, leaving the device in a conventional standby power state can eventually exceed the allotted budget.

This dilemma can be resolved if the device can recover from a defined low-power state to another, well-defined power state. The developer must be able to "dial in" the exact state that enables predictable recovery and low current draw.

ACPI inadequate

The widely-used ACPI can be divided into two parts: an implementation at the hardware and BIOS level and functionality incorporated into the OS itself. Simply, 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 relies on the BIOS, a rare component in telematics systems. Moreover, giving the OS responsibility for power management does not 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. An OS has too little knowledge of them to make appropriate power-management decisions.

In contrast, application-driven power management gives more control to the application developer. This approach can address events not anticipated by current standards, including events whose semantics are invisible to the OS.

At the heart of this approach is a central power manager, a process that implements a power policy defined by the system designer. This policy is aware of the power states supported by each power-managed entity and implements the rules that determine exactly when each entity will switch from one power state to another. The power manager is, in effect, a power broker that can use its intimate knowledge of all subsystems and applications to negotiate the most appropriate power-state changes for any given scenario. For instance, if an application no longer needs a peripheral, the power manager could check whether other applications need that peripheral before deciding to power it down.

Supporting custom-usage scenarios and hardware is central to application-driven power management. Thus, the implementation comprises several building blocks that together form an extensible framework. The first component, a server library, provides APIs to build a custom power manager and to define the power policy.

The second component, a set of client libraries, helps developers create drivers for power-managed peripherals. It also allows developers to implement power-monitoring applications that notify the power manager of critical events and power-sensitive applications that modify their behavior according to the system's power state. A power-sensitive application could, for instance, be notified whenever a particular device driver is about to power down. Conversely, it could send a message to the power manager, saying it no longer needs a peripheral. The power manager would then decide whether the peripheral should enter a lower state.

A third component, the power callout, defines the CPU's power-management capabilities, thereby allowing the power manager to take advantage of them. For instance, to change the CPU state from sleep to deep sleep, the power manager simply invokes the callout via a generic kernel call. To simplify customization, the callout exists as a separate module. The developer can thus adapt it for a specific device without having to make any kernel modifications.

Addressing challenges

To appreciate the value of application-driven power management, consider the matter of predictable response. An approach like ACPI can easily power down a peripheral after a period of inactivity, not realizing that an application needs the peripheral to meet an important and imminent, deadline.

With an application-driven approach, the developer can build checks into the power manager to ensure that this does not occur. For instance, the manager could query every power-sensitive application before deciding whether, or how much, the peripheral should be powered down.

A telematics device may also 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 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 application specific and must take into account the time during which any operational scenario may occur.

- Sheridan Ethier

Software Engineer, QNX Software Systems Ltd





Article Comments - Applications approach regulates tele...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top