Method and system of power and thermal management for a data processing system using object-oriented program design

What is claimed is:

1. A power management architecture in a data processing system, comprising:

a plurality of physical devices, each being either power consumers or power suppliers, wherein each physical device has at least two possible states and a current state which is one of the possible states, and further wherein each state has a corresponding power value, and further wherein the system state is the set of current states for the plurality of physical devices;

a plurality of software objects, each corresponding to a physical device, wherein an object contains information about the power requirements of each possible state for that physical device and the current state of that physical device, the allowed state transitions from each possible state to another, and the power requirements of all possible state transitions;

event means for generating signals indicative of an event;

a policy module containing rules that direct an action, the rules being a function of events and of object information; and

a controller, in communication with the physical devices, the objects, the event means and the policy module, for changing the state of any one of the plurality of physical devices in response to a signal indicating an event, the controller determining whether to change a physical device state based on the policy module rules, event signals, and object information, including the power requirements of possible state transitions.

2. A power management architecture in a data processing system according to claim 1, wherein the object information includes attributes of the physical devices that are utilized by the controller when determining whether to change a physical device state.

3. A power management architecture in a data processing system according to claim 1, further comprising a plurality of envelope objects for logically grouping a plurality of objects, the envelope object providing information indicating the objects it contains and what types of objects they are.

4. A power management architecture in a data processing system according to claim 3, further comprising an envelope policy module for managing objects contained in an envelope object containing rules that direct an action by the physical devices that correspond to objects contained in the envelope object, the rules being a function of an event and of object information from the logically grouped plurality of objects in the envelope object.

5. A power management architecture in a data processing system according to claim 3, wherein at least one envelope object logically groups power objects.

6. A power management architecture in a data processing system according to claim 1, wherein an object can generate a signal indicative of an event.

7. A power management architecture in a data processing system according to claim 1, wherein an object contains information about the time required to make the allowed state transitions.

8. A power management architecture in a data processing system according to claim 1, wherein an object contains information about the reliability of the corresponding physical device.

9. A power management architecture in a data processing system according to claim 1, wherein the event means comprises at least one event source object, the event source object communicating the occurrence of a physical event and being associated with a physical device.

10. A power management architecture in a data processing system according to claim 1, wherein the event means comprises the objects, and wherein one or more objects generate signals indicative of a change in the system state.

11. A power management architecture in a data processing system according to claim 1, wherein the physical devices include a disk drive, a CPU, a display, a keyboard, and a battery power supply.

12. A power management architecture in the data processing system according to claim 1, wherein an object contains information about the performance of the corresponding physical device.

13. A method for power management in a data processing system, comprising the steps of:

retrieving object information from a plurality of software objects, wherein an object, each corresponding to a physical device, contains information about the power requirements of each possible state for that physical device and the current state of that physical device, the allowed state transitions from each possible state to another, and the power requirements of all possible state transitions, and further wherein the system state is the set of current states for all physical devices;

retrieving power management rules from a policy module;

receiving a signal indicating an event or a change in the system state; and

changing the state of at least one physical device in response to the event or change in the system state, the type of state change performed being determined by applying the power management rules as a function of the event, the system state and object information, including the power requirements of possible state transitions.

14. A method for power management in a data processing system according to claim 13, wherein the object information includes attributes of the physical devices that are that are representative of the physical characteristics of the devices, the attributes being used in applying the rules.

15. A power management architecture in a data processing system, comprising:

a plurality of physical devices, each being either a thermal source or a thermal sink, wherein each physical device has at least one state, and further wherein each state has a corresponding thermal value, and further wherein the system state is the set of current states for the plurality of physical devices;

a plurality of software objects, each corresponding to a physical device, wherein an object contains information about the thermal requirements of each possible state for that physical device and the current state of that physical device, the allowed state transitions from each possible state to another, and the thermal requirements of all possible state transitions;

event means for generating signals indicative of an event;

a policy module containing rules that direct an action, the rules being a function of events and of object information; and

a controller, in communication with the physical devices, the objects, the event means and the policy module, for changing the state of any one of the plurality of physical devices in response to a signal indicating an event, the controller determining whether to change a physical device state based on the policy module rules, event signals and object information, including the power requirements of possible state transitions.

16. A power management architecture in a data processing system according to claim 15, wherein the object information includes attributes of the physical devices that are utilized by the controller when determining whether to change a physical device state.

17. A power management architecture in a data processing system according to claim 15, further comprising a plurality of envelope objects for logically grouping a plurality of objects, the envelope object providing information indicating the objects it contains and what types of objects they are.

18. A power management architecture in a data processing system according to claim 17, further comprising an envelope policy module for managing objects contained in an envelope object containing rules that direct an action by the physical devices that correspond to objects contained in the envelope object, the rules being a function of an event and of object information from the logically grouped plurality of objects in the envelope object.

19. A power management architecture in a data processing system according to claim 17, wherein at least one envelope object logically groups thermal objects.

20. A power management architecture in a data processing system according to claim 15, wherein an object can generate an event source.

21. A power management architecture in a data processing system according to claim 16, wherein an object contains information about the time required to make the allowed state transitions.

22. A power management architecture in a data processing system according to claim 15, wherein an object contains information about the reliability of the corresponding physical device.

23. A power management architecture in a data processing system according to claim 15, wherein the event means are at least one event source object, the event source object communicating the occurrence of a physical event and being associated with a physical device.

24. A power management architecture in a data processing system according to claim 15, wherein the event means comprises the objects, and wherein one or more objects generate signals indicative of a change in the system state.

25. A power management architecture in a data processing system according to claim 15, wherein the physical devices include a disk drive, a CPU, a display, a keyboard, and a battery power supply.

26. A power management architecture in a data processing system according to claim 15, wherein an object contains information about the performance of the corresponding physical device.

27. A power management architecture in a data processing system, comprising:

a plurality of physical devices, wherein each physical device has at least one state, and further wherein each state has a corresponding thermal value and a corresponding power value, and further wherein the system state is the set of current states for the plurality of physical devices;

a plurality of thermal software objects, each corresponding to a physical device, wherein a thermal object contains information about the thermal requirements of each possible state for that physical device and the current state of that physical device, the allowed state transitions from each possible state to another, and the thermal requirements of all possible state transitions;

a plurality of power software objects, each corresponding to a physical device, wherein a power object contains information about the power requirements of each possible state for that physical device and the current state of that physical device, the allowed state transitions from each possible state to another, and the power requirements of all possible state transitions;

event means for generating signals indicative of an event;

a policy module containing rules that direct an action, the rules being a function of events, of thermal object information and of power object information; and

a controller, in communication with the physical devices, the thermal objects, the power objects, the event means and the policy module, for changing the state of any one of the plurality of physical devices in response to a signal indicating an event, the controller determining whether to change a physical device state based on the policy module rules, event signals and object information, including the power requirements of possible state transitions.

28. A power management architecture in a data processing system according to claim 27, wherein the object information includes attributes of the physical devices that are utilized by the controller when determining whether to change a physical device state.

29. A power management architecture in a data processing system according to claim 27, further comprising a plurality of envelope objects for logically grouping a plurality of physical objects, the envelope object providing information indicating the physical objects it contains and what types of physical objects they are.

30. A power management architecture in a data processing system according to claim 29, further comprising an envelope policy module for managing objects contained in an envelope object containing rules that direct an action by the physical devices that correspond to objects contained in the envelope object, the rules being a function of an event and of object information from the logically grouped plurality of objects in the envelope object.

31. A power management architecture in a data processing system according to claim 29, wherein at least one envelope object logically groups physical objects, wherein physical devices include thermal objects and power objects.

32. A power management architecture in a data processing system according to claim 27, wherein at least one thermal object and at least one power object can generate a signal indicative of an event.

33. A power management architecture in a data processing system according to claim 27, wherein the physical devices include a disk drive, a CPU, a display, a keyboard, and a battery power supply.

34. A power management architecture in a data processing system according to claim 29, wherein each thermal object and each power object contains information about the time required to make the allowed state transitions.

35. A power management architecture in a data processing system according to claim 27, wherein at least one power object and at least one thermal object contains information about the reliability of the corresponding physical device.

36. A power management architecture in a data processing system according to claim 27, wherein the event means comprises the thermal objects and the power objects, and further wherein one or more thermal objects generate signals indicative of a change in the system state, and wherein one or more power objects generate signals indicative of a change in the system state.

37. A power management architecture in a data processing system according to claim 27, wherein the event means are at least one event source object, the event source object communicating the occurrence of a physical event and being associated with a physical device.

38. A power management architecture in the data processing system according to claim 27, wherein an object contains information about the performance of the corresponding physical device.

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates in general to power management of a data processing system, and in particular to a method and system for object oriented power management of a data processing system.

2. Description of the Related Art

Managing and conserving the usage of electrical power in computing equipment such as portable laptops and tablets is a primary engineering design concern. Of particular concern in mobile computing equipment, which typically operate with a battery as its primary source of power, is the conservation of electrical power in order to maximize operating time by efficiently managing and using the battery power. For example, one technique of power management powers down components of the computer system remaining idle for a specified period of time.

In many portable units, a self supporting power source, such as a battery, functions as the main power source when the unit is decoupled from its main external power source, such as 110 volts AC. In some instances, the battery functions as an auxiliary power source to maintain certain critical circuits active when the unit experiences a sudden loss of power. This keeps the unit's memory alive to retain any information stored in the memory which would be lost otherwise. Advanced management schemes monitor various functions and remove power from those elements when they are not needed to extend the time period that the device could operate from its internal power source. Further, a time out scheme puts the unit in a stand-by mode after a certain time period in order to preserve power. For example, it is common for modern laptop computers to remove power from their display screen when the computer remains idle for a specified period of time.

Laptops are designed to operate for a certain number of hours from its internal power source. In order to extend the self-sustaining time period of these laptops while keeping the battery size and weight to a minimum, a sophisticated power management scheme is required to provide power only to those circuits and devices which require such power and to remove power or make a given circuit enter into a low power consumption mode when that circuit is not needed. The management scheme must also continually monitor the various circuits and devices in order that power can be reapplied immediately to activate such circuits and devices when needed.

More significantly, large modern mainframe computers have complex configurations which require large amounts of power. Management and budgeting of the available power to these large systems presents similar problems as those presented in addressing laptop power management. For example, the computer system may have a limited supply of power to operate the system which has a potential consumption that far exceeds this power supply. A power management system is required to budget the power throughout the system.

The current generation of power management techniques have a number of problems. The first problem with modern power management systems in mainframe computers and laptops alike is that the power management architecture is system specific. It would be desirable to provide a power management architecture which can be utilized with any computer system. Further, it would be desirable to provide a power management architecture which can operate on any computer system but which can be customized to any desired configuration by designing the rules to which the architecture responds so that they meet the desired power criteria optimized for the computer system.

Thus, it would be desirable to provide the power management architecture which has broad application to different types of systems. The operating system or kernel to which an architecture is designed may eventually run on a variety of computer systems. This requires that the power management architecture be general and enduring in systems ranging from a hand-held relatively fixed function system to a high powered system that has thousands of processors. Each type of system imposes its own key requirements that must be satisfied by the power management architecture. The following list of system types describes each type of system and what its key requirements might be.

1. MPP Systems

These systems are "Massively Parallel Processor" systems that may contain hundreds or thousands of processing elements. The goal of these types of systems is to provide "raw" performance. That performance is usually oriented towards processing power but usually has fairly high bandwidth I/O for feeding the processor performance. Anything that would tend to inhibit or limit the performance of the system is to be avoided. A power management architecture must be capable of not interfering with the system's performance.

2. Server Systems

These systems are used for delivering some service to a number of other client systems. Typically they are used as a file service providing (relatively) large numbers of files to multiple clients. However this type of system can be used to provide any type of service that is to be shared (i.e. printers). The main requirement that these systems have is that the data is reliable and the service is available a high percentage of the time. A power management architecture can augment the needs of a server system by notifying the system of impending power outages and possibly switching to backup power sources to "ride out" the power outage.

3. Desktop Systems

These systems are used primarily by end users and are the systems that end users typically interact with. While there are many attributes about this type of system that concern end users, the one that is probably the most important for end user satisfaction is response time. That is, when a user initiates some action on the system, the time in which it takes for the user to "see" some response in large part determines the user's satisfaction with the system and greatly influences the user's perception of the speed or performance of the system. A power management architecture must not cause large (perceptible) increases in the response time of this type of system.

4. Laptop Systems

These types of systems are similar to desktop systems in that they are used by end users. However, unlike desktop systems (which remain largely in one location) these systems are mobil. That is they are moved around alot. As part of the mobility of these systems, there is a portable power supply (usually in the form of a battery). As in desktop systems, laptop systems have response time as an important criteria. However, because of their mobility, there is the requirement that the portable power supply provide power for as long a period of time as possible. This is sometimes at odds with the desire for fast response time, but some response time is usually traded off to obtain longer battery life. These types of systems are where the majority of the focus of power management has been placed in the past. This will continue to be true until either power consumption of the system itself can be greatly reduced so as to increase battery life, or battery technology becomes sufficiently advanced to where power consumption is no longer a concern, or more likely some combination of refinement where power consumption is somewhat reduced and battery technology is refined to yield the desired "long" battery life.

5. Embedded Systems

These types of systems fall into two sub-categories. "Single board computers" that are usually used in some type of process control such as plant floor controllers, and "controllers" that are used as part of a sub-system in another type of system such as a disk controller in a server system. The main focus of these types of system is usually real-time. That is, the software has certain expectations of the system performance characteristics that it relies on to achieve correct operation (i.e. program correctness is judged not only on algorithmic correctness but also contains a time component). A power management architecture must allow for real-time applications to operate in a manner so as to allow them to meet their timing criteria.

6. PDA Systems

These systems are "Personal Digital Assistants" or hand-held systems. They are much smaller than laptop systems and are usually not as flexible as their more general counter-part systems. There are two main requirements that PDA systems exhibit. The first is extremely long battery life. If a laptop system's battery life is measured in hours or a few days, a PDA system's battery life is measured in at least months. Performance of the system is usually traded off to achieve a long battery life. The other requirement is what is called "instant on." That is the "boot" sequence for a PDA is measured in fractions of a second.

In addition to laptops and PDA's, power management is becoming important in all these types of systems. In all systems, there needs to be a power supply. In stationary systems it is the power supply that converts the wall supply (120 V, 60 HZ in the U.S.) to the various DC voltages needed internally in the system. The more current required for a given voltage, the larger the power supply. Larger power supplies generally cost more than smaller power supplies. To keep the cost of the system down, a manufacturer will use the smallest power supply that is believed to get the job done. However, the end user may wish to configure a system that can consume more power than the supply can provide. Historically, the user would usually resort to a purchasing a system with a larger power supply at greater cost. It would be desirable to have a system that budgets power in the system to solve this problem.

Another problem may arise in a system using a wall supply. A power supply that is capable of producing more power internal to the system, by necessity must require more input power. In certain situations, it is not possible to get more input power. Take for example an installation that has 100 systems that each consume 500 watts. This results in an overall power consumption of 50 KW. If the building that these systems is located in is capable of supporting a 60 KW load, everything is fine. But if those systems were to be replaced with systems that consume 750 watts each, there would be a problem because the total power consumption would be 75 KW which is 15 KW over what the building can support. This is why one sees more and more of the low power consuming "green machines" appearing. Therefore, power management is important to all types of systems and not just laptops and PDAs.

The power management architecture must not rely on any implementation specifics in order to define the architecture. For example, some processor architectures have specific additions to deal with power management (such as special execution modes for power management code). The power management architectural definition must not presume particular processor architectural features. This would severely limit the applicability of the architecture to other processor architectures.

Machines like the IBM Thinkpad series laptops are based on the Intel Advanced Power Management Architecture and its precursors. These techniques are limited to specialized Intel architecture processors in the SL series and do not work for software systems that are based on open systems technology.

Advanced Power Management uses a specialized processor mode called System Management Mode to execute code that handles power events. Unfortunately, the use of such a mode violates the architectural principles of open systems. Open systems assume that they have complete control over processor operation. They execute solely in the ordinary privileged mode of the machine, generally with the address translator active. In the presence of real time work, all the scheduling and all the algorithms used to manage the processor resources are invalidated if the hardware enters System Management Mode.

Moreover, on multiprocessor systems, if one processor enters System Management Mode, the other processors in the multiprocessor complex may conclude that it has failed and attempt to eliminate it from the system. Should the process ever resume normal execution, the system becomes inoperable. In addition, if a processor enters system management mode while processing in a multiprocessor complex, deadlock may occur during certain particular types of critical sections of the process. For instance, if the operating system kernel is doing a Translation Lookaside Buffer shootdown, processors go through a sequence of spin and acknowledge cycles. Should a processor that is spinning enter system management mode, all of the processors in the system can wind up spinning.

Finally, Advanced Power Management depends upon the existence and use of a Basic Input/Output System (BIOS). Open systems do not use BIOS since they are portable, may offer real time support, execute on multiprocessor hardware and provide directly all of the functions of the BIOS layer. As can be seen by the problems detailed above, Advanced Power Management cannot be used on open systems.

When the notion of "real time" is introduced, traditional power management designs tend to break down, in that they would tend to solve the problem by either disallowing "real time" applications from running, or turning off power management. This results in a very sub-optimal solution. If one considers that multimedia is a real time application and that they are becoming more prevalent in the marketplace, then real time is very much a consideration that must be dealt with by a power management architecture. The reason that "real time" is hard when considered with power management, is that "real time" requires predictable availability of service (i.e. known subsystem response times). Traditional power management on the other hand is under no obligation to provide consistent subsystem response time, its goal is to reduce power at the expense of performance and subsystem response time and that those two parameters are likely to vary depending upon "perceived" system activity.

In addition to the non-portability of modern power management systems and the inability to budget the total power consumed in the system, current power management systems take no account of the power costs associated with making a transition from one power state to another, nor are they capable of budgeting power. The prior art is only capable of minimizing the power consumption of the computer system components. No value is placed on the power requirements of a given state, and state transitions are assumed to be of zero cost and instantaneous. For example, in an effort to minimize power consumption, the power management will assume that the disk drive consumes more power while in operation and much less when spun down. Thus, if the disk drive is not used for a time, the power management will shut the disk down. The problem with this simplistic approach to power management is that it does not take into consideration the power consumed while spinning the disk down or the power consumed while spinning the disk back up to be used again. Thus, if the disk drive consumes a different amount of power and takes some time to spin down and a different amount of power and time to spin up, the power management architecture should take these costs into account when determining the desirability of shutting down the disk drive to conserve power.

A related problem is that of thermal management. It would be desirable for the power management system to take into account the thermal affects on power consumption and supply, component reliability and overall system performance when making decisions about the proper distribution and power throughout the computer system.

Therefore, it would be desirable to provide a power management architecture for a data processing system which is not hardware specific. This would remove the need to redesign the power management architecture for each computer application. By making the power management more portable across platforms, its structure would be simplified, allowing more complex control functions to be easily incorporated into the power management. It would further be desirable for such a system to budget the available power throughout the system. Still further, the power management architecture must not rely on any implementation specifics in order to define the architecture. The power management system would also take into account the power cost of state transitions. Last, the power management system should take into account the thermal effects on power consumption and supply.

SUMMARY OF THE INVENTION

According to the present invention, a power management architecture in a data processing system comprising physical devices has at least one state, each state having a corresponding power value, and where a system state is defined as the set of all current states of the physical devices. Power objects and thermal objects, each corresponding to a physical device, contain information about the power requirements and thermal characteristics of each possible state for that physical device. The power and thermal objects also describe the allowed state transitions from each possible state to another state and the power requirements and thermal characteristics of all possible state transitions. Also communicated is the current state of each physical device. Event means generate signals indicating the occurrence of an event in the system. A policy module contains rules, implementing the power management, that direct an action, the rules being a function of events and of power object information. A controller, in communication with the physical devices, the thermal and power objects, the event means, and the policy module, changes the state of any one of the physical devices in response to an event. The controller determines whether to change a physical device state based on the policy module rules.

The above as well as additional objects, features, and advantages of the present invention will become apparent in the following detailed written description.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

FIG. 1 depicts a diagram of the computer system components managed by the power management architecture of the present invention;

FIG. 2 depicts a diagram of the computer system power objects corresponding to the computer systems components managed by the power management architecture of the present invention;

FIG. 3 graphically depicts the contents of a power envelope object;

FIG. 4 is a graphical diagram of the objects associated with a physical device according to the present invention;

FIG. 5 graphically depicts the contents of an event source object according to the present invention;

FIG. 6 is a graphical diagram of the physical device according to the present invention;

FIG. 7 graphically depicts the contents of an event source object according to the present invention;

FIG. 8 is a graphical diagram of the physical device according to the present invention;

FIG. 9 graphically depicts the contents of an event source object according to the present invention;

FIG. 10 displays a table of the logical steps performed by a controller when implementing an example of policy module rules;

FIG. 11 depicts a subsystem relationship model of an alternative preferred embodiment of the preferred invention;

FIG. 12A and 12B depict the Power Management Framework including its objects and the relationships between objects;

FIG. 13 diagrams the Power Management States Subsystem including its objects and the relationships between objects; and

FIG. 14 diagrams the Power Management Event Subsystem including its objects and their relationships.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

The present invention of a power management architecture is described in its preferred embodiment as utilized in a laptop computer. However, it is understood that the present invention should not be limited to its application in laptop computers. The present invention is capable of operating in, and intended to be equally applicable to, any computer system. The present invention is a power management architecture which can be incorporated into any computer system because the mechanism of the architecture and the policy rules which direct that mechanism are independent, thus allowing the portability of the mechanism, the policy, or both.

Referring now to the figures, and in particular to FIG. 1, there is depicted a diagram of the computer system components managed by a preferred embodiment of the power management architecture of the present invention. In this simplistic example, there are nine physical devices within a laptop computer managed by power management. FIG. 1 shows nine physical devices controlled by the power management architecture: CPU 31, memory 32, display 33, backlight 34 (wherein the back light provides back lighting to the display), disk drive 35, keyboard 36, fan 37, battery 38, and AC adapter 39. These components comprise elements which are power managed in a laptop computer. For each physical device there is an associated "device object" as seen in FIG. 2.

FIG. 2 shows nine physical device objects: CPU object 40, memory object 45, display object 50, back light object 55, disk drive object 60, keyboard object 65, fan object 70, AC adapter object 90 and battery object 80. An object as used in this specification refers to a software module, containing data sets and possibly procedures, as that term is widely understood by computer programmers and software system engineers. Objects possess logical states and attributes, relations to other objects, and dynamic capabilities that may alter these across time. Each object is a potentially active, autonomously sequential agent, performing at most one activity at a time. Objects communicate by generating events. The nature of event generation varies, and may include point-to-point messages and non-specific requests. Events may trigger transitions or new events. Moreover, although the preferred embodiment uses object-oriented programming to enable the present invention, any method of programming or system design could be used to practice the power management architecture of the present invention in other embodiments.

The device objects are contained within power envelope 100. Power envelope 100 provides a means for logically grouping managed objects of a particular class. Envelopes are a convenient way to represent the topology of the system by dividing it into envelopes, and by defining the relationships between those envelopes. For example, power objects contained in an envelope either supply power to objects in that envelope or consume power from a supplier object. In this way, the power distribution topology of the system is defined by the nesting of power objects in the power envelope. Power envelope 100 is itself a "Managed Object." A Managed Object is an object controlled by the power management architecture through controller 110. The controller 110 is a processor or other logical engine for performing a procedure.

Policy module 120 is an object containing the rules by which the power management architecture distributes and controls power supply and consumption in the computer system, and maintains and controls thermal transfer in the computer system. Policy module 120 is directly fed into controller 110. Controller 110 carries out the desired power management by determining the configuration and current state of envelope 100 and calculating the actions dictated by the rules of policy module 120. The controller 110 then changes the state of the physical devices contained in the computer to implement the power management.

FIGS. 3-9 graphically depict the structure of software objects in the present invention. A solid-lined box represents a logical object as they are conceptualized in object-oriented programming. The dashed-lined boxes represent a fully specified instance of a real object. In other words, a dashed-lined box the actual software module or object that is implemented to practice the present invention. Each logical object contains fields presenting multiple attributes of that object. The logical objects are just a useful tool for grouping these attributes based on the type of physical device object but do not represent software implemented independent objects. The reference number used in referring to a logical object will be the number shown in the "id" field of the object. Objects without "id" fields have external reference numbers.

Referring now to FIG. 3, there is shown a graphical depiction of the contents of an "envelope object." "Power envelope object" 100 embodies the objects used to control electrical power. A "thermal envelope object" would embody the objects used to control thermal transfer. Managed Object 1 is identified to the power