OnNow and the Evolution of the PC Platform
For OnNow-related specifications and a status report, see the OnNow home page.
This paper introduces the background issues that demand a comprehensive, system-wide approach to system and device power control, referred to as the OnNow Design Initiative. This new approach presents requirements for the operating system, device drivers, hardware, and applications that must be incorporated to deliver transparent power management and improved system integration for PCs designed to work with the Microsoft Windows family of operating systems.
On This Page
Introduction
For the PC to become a more integral part of daily life in the office and the home, the PC must be instantly available to answer the phone, display new email, or browse the Internet. As with appliances, the PC must always be on and ready for use but appear to be off when not in use. The PC hardware and software must be capable of responding immediately to the On button, network or communication events, and other actions. Finally, the PC must be capable of returning to its "off but ready" state automatically and must be able to survive the abuse served up in daily life.
The goal of the OnNow initiative is to advance the PC platform to a high level of usability and robustness that will allow the PC to deliver these new capabilities. For the OnNow initiative, the term "PC Platform" involves not only the PC hardware but also the software running on the PC. The key to creating the OnNow PC is integration. It is essential that the hardware, the operating system, and the applications work together to ensure the PC operates as the user would expect.
The OnNow PC platform will be expected to function in these ways:
| • | The PC is ready for use immediately when the user presses the On button. |
| • | The PC is perceived to be off when not in use but is still capable of responding to wake-up events. Wake-up events might be triggered by a device receiving input such as a phone ringing, or by software that has requested the PC to wake up at some predetermined time. |
| • | Software adjusts its behavior when the PC's power state changes. The operating system and applications work together intelligently to operate the PC to deliver effective power management in accordance with the user's current needs and expectations. For example, applications will not inadvertently keep the PC busy when it is not necessary, and instead will proactively participate in shutting down the PC to conserve energy and reduce noise. |
| • | All devices participate in the device power management scheme, whether originally installed in the PC or added later by the user. Any new device can have its power state changed as system use dictates. |
Current Platform Shortcomings
The current PC platform cannot meet the demands of the OnNow PC for several reasons. Current PCs must boot when you turn them on, a lengthy and annoying process. Once on, the PC must be left fully on in order to respond to asynchronous or timed events. For a plethora of reasons, end users prefer to leave their PCs turned off: PCs are too noisy for home use; PCs are expensive to run; novice users tend to be afraid of breaking their computers; and, lastly, most people will not leave an appliance turned on simply because we are trained not to waste energy. To facilitate the new services that can be provided if the PC is left on, the industry must address all of the following problems.
No cooperation among system components. Hardware, system BIOS, operating system, and applications do not cooperate, resulting in the various system components fighting for control of the hardware. This causes erratic behavior: disks spin up when they are not supposed to; screens come on unexpectedly.
Add-on components do not participate in power management. When a person buys a computer, the hardware in the system operates in an integrated power management scheme, but any peripherals added by the user or reseller do not. Traditional power management is no longer sufficient, because it does not deal outside the domain of the system board. To meet the OnNow goals, the entire system must function as an integrated power-managed environment, which requires a generalized solution in the operating system.
Current power management schemes fail for purposes of the OnNow goals. The power management schemes currently in use focus only on the system board and use only device access information to make decisions about when to power down a device. This approach causes two major problems:
| • | The system cannot be extended and still be fully power managed. The PCMCIA subsystem is a good example of this. The BIOS might know what port the PCMCIA controller is using but cannot determine whether the device currently inserted in the socket is actually busy or not. To fully power-manage PCMCIA, the device driver running the device must be able to indicate when it is really time to power down its device. |
| • | There are lost opportunities for extra power management. For example, the operating system knows that the disk I/O is really a paging maintenance operation and should not be considered when trying to determine whether a device is busy. Current power management schemes cannot determine this "user priority" or intent of a particular I/O access. By moving the policy into the operating system, individual devices will be powered down more quickly. |
Installing new devices is still not as easy as it must be. Plug and Play provides an architecture that allows the user to install hardware more easily; however, the task is still not an easy operation for the end use. To install a new device under Windows 95, the user must turn off the computer and open the box. The OnNow PC must be easily extensible by the end user, and any device the user adds must become available without requiring a reboot or restart.
In general, applications assume that the computer is fully on at all times. Applications that assume this can inadvertently keep the system from entering a lower power state. Also, applications that assume the PC is always on can crash when the PC wakes up after time has passed or devices have been removed.
OnNow Architecture
To overcome the past shortcomings in the PC platform, the industry has been working to improve the integration of PC hardware and software for simpler operation and greater reliability. To meet the goals for OnNow, the specific improvements required are to eliminate the startup and shutdown delays, enable automated tasks to run while the PC is "off," and improve overall PC power efficiency.
To achieve the OnNow goals, specific changes must be incorporated at various levels of the system architecture so the operating system assumes responsibility for power management, applications can be involved, and consistent, effective power management can be applied to all devices in the system. These required changes are the following:
| • | Enhance the core operating system functionality for power management. In the OnNow architecture, the operating system assumes the central role of coordinating power management activities at all levels and takes responsibility for defining the power-state transitions for the system. This is achieved in Windows 2000 and Windows XP. |
| • | Create a unified device driver model for power management and Plug and Play. The Windows Driver Model supports per-device power management, in addition to supporting Plug and Play. |
| • | Implement a new system interface for power management and Plug and Play. A system design is required that implements operating system-directed power management policy and enables per-device power management of devices on the system board. With an ACPI-enabled hardware, firmware, and operating system, the runtime functionality of the system interface can support additional complexity, provide future extensibility, and improve integration. |
| • | Define bus and device power management standards for hardware. In the same way that Plug and Play standardized configuration mechanisms throughout the PC, OnNow provides comprehensive standards for power management interfaces and state definitions. |
| • | Define an application architecture that integrates applications into power management. By building on the existing Plug and Play mechanisms for applications, improvements in Windows 2000/Windows XP have been made in the flow of control and information through the application interface so the user's environment is more smoothly integrated with the underlying PC capabilities. |
Enhancing Core Operating System Functionality
To achieve OnNow, all elements of the system must operate as an integrated whole according to defined roles and responsibilities and standard interfaces. It is the operating system's responsibility to coordinate activities throughout the system and manage the necessary interfaces. The required enhancements in the operating system are described in this section. These enhancements have been implemented in Windows 2000/Windows XP
Define and Manage the PC's Global Power Policy
The global power policy refers to the system's power state transitions made in response to usage input from the user, applications, and device drivers.
To the user, the PC is either on or it is off, and no other conditions are visible. However, for system designers, there is an overall operational state of the PC that must transition through a number of different power states according to a policy defined in the operating system. This policy must be based on a standard set of detailed system power states defined by system designers and implemented by the operating system. For OnNow, these system power states are defined in the following table.
| Power state | Description |
Working | On. System is fully usable; power conservation is occurring on a per-device basis. |
Sleeping | Appears Off. Power consumption is reduced. The system returns to the Working state in an amount of time inversely proportional to the power consumption. |
Soft Off | Appears off. Very low power consumption. The system returns to the Working state after a full reboot. |
In practice, there are multiple discrete power consumption/response time modes within the Sleeping state, so a wide variety of systems and market needs can be supported. The implementation and selection of these modes vary, depending on the target market or usage. For example, an appropriate power policy for a system designed for home use might include placing the PC in a "light" Sleeping mode when the user pushes the Off button, because the user wants the PC to return to the Working state quickly the next time it is needed. A system designed for use in the corporate environment might be placed in a much "deeper" Sleeping mode or even Soft Off mode in response to the Off button, because response time is considered secondary to reducing power consumption.
The global power policy might also be affected by the required response times for devices and applications that are set to wake up the system. Global policy also defines factors such as when automatic power state transitions should occur based on system idleness. Implementation of a global policy relies on the other parts of the architecture such as the application architecture, which is discussed later in this paper.
Integrate Power Awareness into the Operating System
Power awareness must be integrate into the operating system so that system functions take place only while a device or the system itself is in an appropriate power state, and unnecessary power state transitions are avoided. In general, the usage of a system will tend in one of two directions: toward conservation or toward performance. The term "conservation" here applies both to cases where certain system functions are secondary to power conservation (for example, when a notebook is running on battery power) and to cases where system functions are secondary to demands in the user's environment (for example, when audible noise is undesirable).
The OnNow architecture provides a simple user interface through which the user can express preferences, and the operating system must adjust its behavior based on the appropriate usage. This requirement extends to all software running on the system including applications, as discussed later in this paper.
Improve System Robustness
The OnNow PC must be able to run for long periods of time without complete re-initialization (rebooting) of the software. Operating system components must take the lead in ensuring that rebooting the system is not required for any design reason and in minimizing the likelihood of user rebooting because of software faults.
Windows Driver Model for Power Management and Plug and Play
In the same way that Microsoft Windows provides a common API for Windows-based applications, the Windows Driver Model (WDM) is designed to provide a common set of I/O services and binary-compatible device drivers for Windows 2000/Windows XP and Windows 98/Windows Me operating systems. The details of the WDM are covered in separate papers. However, notice that WDM is designed to include Plug and Play and power management capabilities from the beginning.
The layered structure of the WDM allows driver functionality to be partitioned, with class functionality, bus functionality, and device-specific functionality all having separate layers in a driver "stack." Device I/O is handled through an I/O Request Packet (IRP) passed down the stack. Although driver layering can be even more complex than this, the separation of class, bus, and device functionality has particular implications for OnNow.
In the same way that Plug and Play isolates generic device drivers from bus-specific configuration details, the power management capabilities defined in the WDM enables Class drivers to focus on class-specific power policy without any concern for power control details.
Bus drivers, on the other hand, can generically handle power signaling for devices on their bus, regardless of device class. Device minidrivers are responsible for saving and restoring device-specific context (settings) and can also perform any implementation-specific or proprietary power signaling required for their device. This enables the use of common code and reduces the number of drivers that must be written, while making the system easily extensible. It also allows the introduction of a bus driver that provides specific control functionality associated with devices on the system board. (For more information, see the following section, "Creating a New System Interface.")
OnNow Driver Architecture
The WDM defines a control IRP used to implement Plug and Play and power management down the driver stack. For power management, the control IRP is generated by the I/O system in response to either a driver's request to perform a power management function -- based on its power policy, or in response to a power management function requested by the user or an application, or based on the operating system's global power policy.
The control IRP provides an interface for drivers to perform the following power management functions:
| • | Get the power-related capabilities of a device |
| • | Query, set, or get the power state of a device |
| • | Enable a device to wake up the system |
| • | Get battery status |
See also:
| • | OnNow Power Management and WDM, which describes the requirements and implications for WDM device drivers in an OnNow power-managed system, with preliminary descriptions of the driver interfaces. |
| • | Device Power Management for VxDs, which reviews OnNow-related messages and services for Windows 98 VxD device drivers. |
Creating a New System Interface
An extremely high level of integration and functionality is implied by the OnNow requirements. This calls for an interface between the operating system and system board hardware that allows each device driver to individually power-manage its device without handling the variety of possible power interconnections and control mechanisms that characterize system board design. In addition, this interface must allow the system board itself to be moved smoothly through global power state transitions as dictated by PC usage, including managing the power consumption of the processor itself. In creating such a system interface, the design must attend to integration, robustness, and extensibility requirements.
The solution implemented by the industry is defined in the ACPI specification.
Creating the Software Interface
The software interface allows a WDM bus driver to be layered into the stack of drivers associated with each device for which power or configuration control is provided through the system interface. This driver supports system board devices with the same device power-control functions described in the "Windows Driver Model for Power Management and Plug and Play" section earlier in this paper.
However, the software interface also supports the implementation of the system's global power state policy by handling the actual control associated with global power state transitions. Specifically, the software interface supports controlling the following:
| • | Processor power conservation control |
| • | Power and Clock plane control |
| • | Timer control |
| • | Thermal control |
| • | Battery support |
| • | System control events generated on the system board (pressing the power button, closing the lid, docking, and so on) |
| • | Resuming the system on any wakeup event |
| • | System indicators control |
| • | Plug and Play functions such as Get/Set resources and Lock/Eject device |
These interfaces are part of the Windows Hardware Abstraction Layer (HAL) that provides Plug and Play and power management capabilities and serves as the system interface for the WDM. Details about these interfaces and their implementation are in the Microsoft WDM and HAL Development Kits.
Creating Hardware Interface
The Advanced Configuration and Power Interface (ACPI) defines a standard way for the system board to describe its device configuration and power control hardware interface to the operating system. The ACPI specification defined a standard register interface for common functions such as system control events, processor power and clock control, thermal management, and resume handling. This interface then provides a flexible way to describe the interconnection and control commands for additional devices and functions such as Plug and Play configuration, Battery/AC power source management, and controls for power planes, clock planes, and individual devices.
The system board designer is responsible for implementing the required register interface and for providing information about the devices, resources, and control mechanisms for that particular system board design. The information is contained in Description Tables, which are flexibly linked together in a "table of tables" structure. Description Tables can easily be extended and can describe most useful designs.
The ACPI starts with the Root System Description Table, which provides a standard way for listing all System Description Tables for this PC. Although there can be any number of tables for any number of uses, the relevant one for OnNow is the one identified by the signature "SPCT," which defines the location of the common register blocks and the location of the Definition Files that describe the rest of the system board devices, interconnections, and commands. For more flexibility in the implementation of system board commands, the Definition Files can refer to Control Methods, which use a pseudocode language to describe the sequence of operations that implement a specific command on the particular arrangement of control registers implemented on that system board. This allows BIOS-like control functionality while remaining independent of the operating system and processor architecture.
The system BIOS plays an important role in the Advanced Configuration and Power Interface. In addition to providing the tables and files described above, the system BIOS works cooperatively with the operating system by performing the necessary initialization processing and handoff during boot and when resuming the Working state. Also, because the interface is designed to be compatible with APM and Plug and Play BIOS implementations, the system BIOS must implement the prescribed procedure for transitioning between BIOS control and operating system control.
Advanced Configuration and Power Interface Description Tables
For each device, the description data lists the following:
| • | Power management capabilities and requirements |
| • | Methods for setting and getting the power state |
| • | Hardware resource settings (all the necessary Plug and Play information) |
| • | Methods for setting hardware resources |
For more information, see the Advanced Configuration and Power Interface Specification and related implementation information available on the ACPI home page 
.
Defining Device and Bus Power Management Standards
Within the OnNow architecture, each class driver is the owner of power policy for its device (or devices). The class driver is responsible for making decisions about power state transitions for its device and for the basic power-related operations on its device. To manage this responsibility, the driver must know the power states of its device, the specific functionality and capabilities of the device when it is in each state, and the methods required to cause the device to enter a specific state or enable a particular feature.
As mentioned in the discussion of the WDM earlier in this paper, this functionality can be allocated to separate class, bus, and device drivers with strong associated benefits. For this reason, OnNow standardizes power-related functionality at both the class-independent and class-specific hardware levels. At the class-independent level, there must be a standard baseline definition for device power states so that all components can consistently communicate about and manipulate these states. For OnNow, the four standard device power states are named D0, D1, D2, and D3. These states are defined as shown in the following table.
| Power state | Power consumption | Responsiveness to return to D0 |
D0 | Highest | -- |
D1 | < D0 | Faster than D2 |
D2 | < D1 | Faster than D3 |
D3 | None* | Slowest |
1 Essentially 0, although may have some negligible consumption
This level of definition allows each bus hardware specification to standardize implementations of these states in a way that can be implemented within the given bus standard and that can apply universally to any device connected to the bus, regardless of device class. All other definition -- such as whether device context is saved in the D1 or D2 state, the actual responsiveness to return to D0, and so on -- is class-specific and must be defined in the Device Class Power Management Specification (described later in this paper). After the state definitions are standardized, each bus standard must also define standard power operations that can be performed on a device.
To support the OnNow architecture, the required power-related operations are the same as the functions that device drivers are responsible for performing: Get Capabilities, Set Power State, Get Power Status, and Wakeup. Some buses already specify some of these operations and others do not. In general, the level of standardization required will vary from bus to bus. For the future, the PCI, PC Card, USB, and 1394 buses will be prevalent in PC systems, so these standards are being extended to include these definitions where needed.
The level of standardization described here allows buses to provide standard power management signaling and allows power control code to be centralized in bus minidrivers. However, these power state definitions are not detailed enough to meet the requirements for a class driver to implement a consistent power policy for devices in its class. To do this, each class must have its own standard, agreed-upon set of interpretations or implementations of each power state. For example, the exact implementation of a state that meets the definition of D1 will be different for a sound device than for a storage device.
These differences will be important to the class driver in defining power policy and in deciding what level of class functionality can be achieved in a given power state. For this reason, Device Class Power Management specifications are being developed to standardize the following class-specific power-related issues:
| • | Device-class power characteristics. Each class of device should have a standard definition for each bus power state in terms of latencies and power consumption. |
| • | Minimum device-class power capabilities. Each class of device should define a standard set of power capabilities appropriate to the class. |
| • | Device-class functional characteristics. Each class of device should have a standard definition of the available subset of device capabilities and features in each power state. |
| • | Device-class wakeup characteristics. Each class of device should have a standard definition of its wakeup events, if any. |
For more information on these standard definitions and requirements, please see the paper entitled "OnNow Device Power Management" and see also the relevant bus or class power management specification, available on the OnNow home page.
Defining an Application Architecture for Power Management
In this new architecture, applications play a key role in delivering OnNow capabilities to users. Currently, applications are oblivious to the power state of the system or devices, because power management is inconsistently implemented on only a small subset of PCs (notebooks). We have all seen the effects of this, for example, when the mail program starts compacting its mail file while the notebook is on battery power with no AC available. In other cases, applications crash after a resume because they did not adequately prepare for the suspend event.
With the broad introduction of OnNow capabilities on desktops and notebooks, this sort of behavior will become unacceptable to users. Within a comprehensive OnNow architecture, Applications can both enhance the user experience and help save power. By not performing background operations (such as compressing mail files or background pagination) while the computer is on batteries and by checking the power state of disks before trying to access them, power conservation will be increased. When applications gracefully handle power state transitions and inform the system of current processing states, the user will perceive a more elegant, integrated system.
Although the operating system will perform most of the work for OnNow, applications must be designed for power management and Plug and Play to make the entire process appear seamless to the user. Some of the support that applications need already exists today in Plug and Play system messages. However, additional APIs must be added to the application interface to enhance this support. The required changes fall into two categories:
| • | Mechanisms that allow an application to inform the operating system about its processing state in regards to power policy. Such mechanisms allow an application to report, for example, that it is processing a long calculation or showing a movie, so the PC should not transition to the Sleeping state (or, conversely, that it is OK to interrupt the current calculation for power conservation). These mechanisms also allow the application to specify devices that it needs to use (such as the display in the case of the movie) or does not need to use (as in the case of the calculation). |
| • | Mechanisms that give applications more knowledge of and control over device power state. Such mechanisms allow applications to modify their behavior based on the power state of specific devices they might want to use and to specify devices that the applications need in order to awaken the PC at some future time or on some event. |
For more information, see OnNow: Power Management Architecture for Applications, which provides information for applications developers and OEMs who want to build applications that take advantage of OnNow power management capabilities in future versions of Windows and Windows NT.
Conclusion
Achieving the capabilities of OnNow operation offers benefits in the home environment as well as in traditional PC markets. But OnNow requires a comprehensive, system-wide approach that affects all aspects of the PC. New requirements for the operating system, applications, device drivers, and hardware must be incorporated into the system to deliver transparent power management and improved integration.
The advances made with Plug and Play provide a foundation for the necessary incremental improvements. By building on the Plug and Play infrastructure and focusing on the new usage paradigms, the PC architecture will evolve to deliver the benefits of OnNow functionality to traditional users and to meet the usability expectations of new ones.