U.S. patent application number 11/548201 was filed with the patent office on 2007-06-21 for power management device with communications capability and method of use.
This patent application is currently assigned to Server Technology, Inc.. Invention is credited to Brian P. Auclair, Mark J. Bigler, Andrew J. Cleveland, Carrel W. Ewing, James P. Maskaly, Dennis W. McGlumphy.
Application Number | 20070140238 11/548201 |
Document ID | / |
Family ID | 34923518 |
Filed Date | 2007-06-21 |
United States Patent
Application |
20070140238 |
Kind Code |
A1 |
Ewing; Carrel W. ; et
al. |
June 21, 2007 |
POWER MANAGEMENT DEVICE WITH COMMUNICATIONS CAPABILITY AND METHOD
OF USE
Abstract
A power management device can include a power management device
housing, a power input associated with the power management device
housing, and a plurality of power outputs associated with the power
management device housing. At least certain power outputs can be
connectable to one or more electrical loads external to the power
management device housing and to the power input. In some
embodiments, a communications bus can be associated with the power
management device housing and one or more power control sections
can also be associated with the power management device housing. In
some embodiments, one ore more power control sections can
communicate with the communications bus and with one or more
corresponding power outputs among the plurality of power outputs.
In some embodiments, a power information display can communicate
with the communications bus. If desired, a power information
determining section can be associated with the power management
device housing and in communication with the communications bus.
The power information determining section may communicate
power-related information to the power information display.
Inventors: |
Ewing; Carrel W.; (Reno,
NV) ; Auclair; Brian P.; (Reno, NV) ;
Cleveland; Andrew J.; (Reno, NV) ; Maskaly; James
P.; (Sparks, NV) ; McGlumphy; Dennis W.; (Sun
Valley, NV) ; Bigler; Mark J.; (Eugene, OR) |
Correspondence
Address: |
KLARQUIST SPARKMAN, LLP
121 SW SALMON STREET
SUITE 1600
PORTLAND
OR
97204
US
|
Assignee: |
Server Technology, Inc.
|
Family ID: |
34923518 |
Appl. No.: |
11/548201 |
Filed: |
October 10, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10313314 |
Dec 6, 2002 |
7171461 |
|
|
11548201 |
Oct 10, 2006 |
|
|
|
09930780 |
Aug 15, 2001 |
7043543 |
|
|
10313314 |
Dec 6, 2002 |
|
|
|
09732557 |
Dec 8, 2000 |
7099934 |
|
|
09930780 |
Aug 15, 2001 |
|
|
|
09375471 |
Aug 16, 1999 |
6711613 |
|
|
09732557 |
Dec 8, 2000 |
|
|
|
08685436 |
Jul 23, 1996 |
5949974 |
|
|
09375471 |
Aug 16, 1999 |
|
|
|
Current U.S.
Class: |
370/389 ;
370/252 |
Current CPC
Class: |
H02J 13/00016 20200101;
Y02B 90/20 20130101; G06F 2200/261 20130101; G06F 1/266 20130101;
Y04S 20/222 20130101; H01R 25/003 20130101; Y02D 10/00 20180101;
G06F 1/3246 20130101; Y02B 70/3225 20130101; G06F 13/4282 20130101;
H02J 13/0062 20130101; Y04S 20/14 20130101; G06F 13/364 20130101;
H02J 3/14 20130101; Y04S 20/00 20130101; G06F 1/3287 20130101; G06F
1/26 20130101; Y04S 40/124 20130101; H01H 47/00 20130101; H02J
13/0005 20200101; G06F 1/3209 20130101 |
Class at
Publication: |
370/389 ;
370/252 |
International
Class: |
H04L 12/56 20060101
H04L012/56; H04J 1/16 20060101 H04J001/16 |
Claims
1. A power management device comprising in combination: A a power
management device housing; B. a plurality of power inputs disposed
in the power management device housing; C. a first plurality of
power outputs disposed in the power management device housing, each
among the first plurality of power outputs being connectable to one
or more electrical loads external to the power management device
housing and connected to a first power input among the plurality of
power inputs; D. a second plurality of power outputs disposed in
the power management device housing, each among the second
plurality of power outputs being connectable to one or more
electrical loads external to the power management device housing
and connected to a second power input among the plurality of power
inputs; E. a communications bus associated with the power
management device housing; F. a plurality of power control sections
associated with the power management device housing, each among the
plurality of power control sections being in communication with the
communications bus and thereby in power controlling communication
with one or more corresponding power outputs among the first or
second plurality of power outputs; G. a communications system
associated with the power management device housing, being in
communication with said communications bus, and having a
communications processor system in communication with (i) said
communications bus; (ii) at least one among said plurality of power
control sections through the communications bus; and (iii) a
communications port connectable to an external communications link
external to the power management device housing; H. a power
information display associated with the power management device
housing in communication with the communications bus; and I. a
power information determining section associated with the power
management device housing in communication with the communications
bus, whereby the power information determining section may
communicate power-related information to the power information
display.
2. The power management device of claim 1 wherein said
communications processor system comprises an Internet Protocol
network communications processor in selectively removable
communication with the external communications link through the
communications port.
3. The power management device of claim 1 wherein each among the
plurality of power control sections includes a power-on status
determination circuit, whereby the power-on status determination
circuit may report power-on status of said corresponding power
output through said communications bus.
4. The power management device of claim 1 wherein each among the
plurality of power control sections includes a power control relay
in power-controlling communication with at least one corresponding
power output.
5. The power management device of claim 2 wherein each among the
plurality of power control sections includes a power control relay
in power controlling communication with at least one corresponding
power output.
6. The power management device of claim 3 wherein each among the
plurality of power control sections includes a power control relay
in power-controlling communication with at least one corresponding
power output.
7. The power management device of claim 1 wherein said
communications section includes a slave application in
communication with a slave communications port mounted in the power
management device housing, whereby the communications system may
serve as a slave to a master communications section in a separate
power management device,
8. A power management device of the type useable to remotely
control, or assess information relating to, power provided to
external electrical loads from a manager location distal from the
external electrical loads, the power management device comprising
in combination: A. a power management device housing; B. a power
input disposed in the power management device housing; C. a
plurality of power outputs disposed in the power management device
housing, each said power output being connectable to an electrical
load external to the power management device housing; D. at least
one intelligent power section disposed in the power management
device housing in power controlling communication with at least one
corresponding power output among said plurality of power outputs;
E. a network communications module (i) having memory and a
transfer-control-protocol/Internet Protocol network interface
application system residing in the memory and providing a web page
interface, and (ii) being associated with the power management
device housing in communication with the intelligent power sections
and in communication with at least a first external network
communications port; and F. a current display mounted in
association with the power management device housing in
current-determining communication with at least one among the
plurality of power outputs; whereby an external power manager and
the network communications module may exchange, through the first
external network communications port and an external network link,
information relating to the intelligent power sections in the power
management device housing.
9. The power management device of claim 8 wherein the network
communications module also includes a second communications port
communicatingly connectable to at least an additional power
management device.
10. The power management device of claim 9 wherein the first
communications port provides a first communications service format
and the second communications port provides a second communications
service format.
11. The power management device of claim 8 wherein the network
communications module alternately comprises a master application or
a slave application, whereby the master application may communicate
with a slave network communications module in an additional power
management device.
12. The power management device of claim 9 wherein the network
communications module alternately comprises a master application or
a slave application, whereby the master application may communicate
with a slave network communications module in an additional power
management device.
13. The power management device of claim 10 wherein the network
communications module is removably mounted in the power management
device housing and alternately comprises a master application or a
slave application, whereby the master application may communicate
with a slave network communications module in an additional power
management device.
14. The power management device of claim 8 wherein the current
display mounted in association with the power management device
housing is in current-determining communication with the plurality
of power outputs.
15. The power management device of claim 9 wherein the current
display mounted in association with the power management device
housing is in current-determining communication with the plurality
of power outputs.
16. The power management device of claim 11 wherein the current
display mounted in association with the power management device
housing is in current-determining communication with the plurality
of power outputs.
17. The power management device of claim 8 wherein the network
communications module alternately comprises a master application or
a plural slave application, whereby the master application may
communicate with a plurality of slave network communications
modules in an additional power management device.
18. The power management device of claim 9 wherein the network
communications module alternately comprises a master application or
a plural slave application, whereby the master application may
communicate with a plurality of slave network communications
modules in an additional power management device.
19. The power management device of claim 10 wherein the network
communications module is removably mounted in the power management
device housing and alternately comprises a master application or a
plural slave application, whereby the master application may
communicate with a plurality of slave network communications
modules in an additional power management device.
20. The power management device of claim 14 wherein the network
communications module may alternately comprise a master application
or a plural slave application, whereby the master application may
communicate with a plurality of slave network communications
modules in an additional power management device.
21. The power management device of claim 15 wherein the network
communications module is removably mounted in the power management
device housing and may alternately comprise a master application or
a plural slave application, whereby the master application may
communicate with a plurality of slave network communications
modules in an additional power management device.
Description
RELATED APPLICATIONS AND PATENTS
[0001] This application is a continuation of U.S. patent
application Ser. No. 10/313,314, filed Dec. 6, 2002, and titled
NETWORK REMOTE POWER MANAGEMENT OUTLET, which is a
continuation-in-part of U.S. patent application Ser. No.
09/930,780, filed Aug. 15, 2001, issued as U.S. Pat. No. 7,043,543
on May 9, 2006, and titled VERTICAL-MOUNT NETWORK REMOTE POWER
MANAGEMENT OUTLET STRIP, which is a continuation-in-part of U.S.
patent application Ser. No. 09/732,557, filed Dec. 8, 2000, issued
as U.S. Pat. No. 7,099,934 on Aug. 29, 2006, and titled
NETWORK-CONNECTED POWER MANAGER FOR REBOOTING REMOTE COMPUTER-BASED
APPLIANCES, which is a continuation-in-part of U.S. patent
application Ser. No. 09/375,471, filed Aug. 16, 1999, issued as
U.S. Pat. No. 6,711,613 on Mar. 23, 2004, and titled REMOTE POWER
CONTROL SYSTEM THAT VERIFIES WHICH DEVICES IS SHUT-DOWN BEFORE SUCH
ACTION IS COMMITTED TO, which is a continuation-in-part of U.S.
patent application Ser. No. 08/685, 436, filed on Jul. 23, 1996,
issued as U.S. Pat. No. 5,949,974 on Sep. 7, 1999, and titled
SYSTEM FOR READING THE STATUS AND CONTROLLING THE POWER SUPPLIES OF
APPLIANCES CONNECTED TO COMPUTER NETWORKS, all of which are hereby
incorporated herein by reference.
BACKGROUND
[0002] 1. Technical Field
[0003] The technical field relates generally to power management
systems and, more particularly, to electrical power distribution
devices and methods.
[0004] 2. Description of the Prior Art
[0005] Network server "farms" and other network router equipment
have settled on the use of equipment bays in 19'' standard RETMA
racks. Many of these server and router farms are located at
telephone company (TelCo) central equipment offices because they
need to tie into very high bandwidth telephone line trunks and
backbones. So each TelCo typically rents space on their premises to
the network providers, and such space is tight and very
expensive.
[0006] The typical network router, server, or other appliance comes
in a rack-mount chassis with a standard width and depth. Such
chassis are vertically sized in whole multiples of vertical units
(U). Each rented space in the TelCo premises has only so much
vertical space, and so the best solution is to make best use of the
vertical space by filling it with the network appliances and other
mission-critical equipment.
[0007] Two kinds of operating power are supplied to such network
appliances, alternating current (AC) from an uninterruptible power
supply (UPS) or direct from a utility, the second kind is direct
current (DC) from TelCo central office battery sets. Prior art
devices have been marketed that control such AC or DC power to
these network appliances. For example, Server Technology, Inc.
(Reno, Nev.) provides operating-power control equipment that is
specialized for use in such TelCo premises RETMA racks. Some of
these power-control devices can cycle the operating power on and
off to individual network appliances.
[0008] Such cycling of operating power will force a power-on reset
of the network appliance, and is sometimes needed when an appliance
hangs or bombs. Since the network appliance is usually located
remote from the network administration center, Server Technology
has been quite successful in marketing power managers that can
remotely report and control network-appliance operating power over
the Internet and other computer data networks.
[0009] Conventional power management equipment has either been
mounted in the tops or bottoms of the server farm RETMA racks, and
thus has consumed vertical mounting space needed by the network
appliances themselves. So what is needed now is an alternate way of
supplying AC or DC operating power to such network appliances
without having to consume much or any RETMA rack space.
SUMMARY
[0010] Briefly, a network remote power management outlet strip
embodiment of the present invention can comprise a long, thin
outlet strip body with several independently controllable power
outlet sockets distributed along its length. A power input cord can
be provided at one end, and this can supply AC-operating power to
relays associated with each of the power outlet sockets. The relays
can each be addressably controlled by a microprocessor connected to
an internal I2C-bus serial communications channel. The power-on
status of each relay output to the power outlet sockets can be
sensed and communicated back on the internal I2C-bus. A
device-networking communications processor with an embedded
operating system may translate messages, status, and controls
between external networks, the internal I2C-bus, and other
ports.
[0011] In alternative embodiments of the present invention, a power
manager architecture can provide for building-block construction of
vertical and horizontal arrangements of outlet sockets in equipment
racks. The electronics used in all such variants is essentially the
same in each instance. Each of a plurality of power input feeds can
have a monitor that can provide current measurements and reports on
the internal I2C-bus. Each of the power input feeds could be
independently loaded with a plurality of addressable-controllable
outlets. Each outlet can also be capable of measuring the
respective outlet socket load current and reporting those values on
the internal I2C-bus. Separate digital displays can be provided for
each monitored and measured load and infeed current. The internal
I2C-bus, logic power supply, network interfaces, power control
modules and relays, etc., could be distributed amongst several
enclosures that have simple plug connections between each, the
infeed power source, and the equipment loads in the rack.
[0012] An advantage of certain embodiments of the present invention
is that a network remote power management outlet strip is provided
that frees up vertical rackmount space for other equipment.
[0013] Another advantage of certain embodiments of the present
invention is that a network remote power management outlet strip is
provided for controlling the operating power supplied to network
appliances over computer networks, such as TCP/IP and SNMP.
[0014] A further advantage of certain embodiments of the present
invention is that a network remote power management outlet strip is
provided that allows a network console operator to control the
electrical power status of a router or other network device.
[0015] A still further advantage of certain embodiments of the
present invention is that a network remote power management outlet
strip is provided for reducing the need for enterprise network
operators to dispatch third party maintenance vendors to remote
equipment rooms and POP locations simply to power-cycle failed
network appliances.
[0016] There are other objects and advantages of various
embodiments of the present invention. They will no doubt become
obvious to those of ordinary skill in the art after having read the
following detailed description of the preferred embodiments which
are illustrated in the various drawing figures.
IN THE DRAWINGS
[0017] FIG. 1 is a functional block diagram of a network remote
power management outlet strip embodiment of the present
invention;
[0018] FIG. 2A is a front diagram of an implementation of the
network remote power management outlet strip of FIG. 1;
[0019] FIG. 2B is an assembly diagram of the network remote power
management outlet strip of FIG. 2A without the sheetmetal
enclosure, and shows the interwiring amongst the AC-receptacles,
the power input plug, and the various printed circuit board
modules;
[0020] FIG. 3 is a non-component side diagram of a printed circuit
board (PCB) implementation of an intelligent power module IPT-IPM,
similar to those of FIGS. 1, 2A, and 2B, and further illustrates an
insulating sheet that is fitted to the back;
[0021] FIG. 4 is a component-side diagram of a printed circuit
board (PCB) implementation of an intelligent power module IPT-IPM,
similar to those of FIGS. 1, 2A, 2B, and 3, and further illustrates
the bus connections of the power outlet receptacles it sockets
onto;
[0022] FIG. 5 is a functional block diagram of an IPT-NetworkPM
module embodiment of the present invention;
[0023] FIG. 6 is a schematic diagram of a circuit that could be
used in an implementation of the IPT-PS of FIGS. 1, 2A, and 2B;
[0024] FIG. 7 is a functional block diagram of a network remote
power management system embodiment of the present invention;
[0025] FIG. 8 is a functional block diagram of an expandable power
management system embodiment of the present invention;
[0026] FIG. 9 is a functional block diagram of a power distribution
unit embodiment of the present invention; and
[0027] FIG. 10 is a schematic diagram of one way to implement the
IPT-IPM's in any of FIGS. 1-9.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0028] FIG. 1 represents a network remote power management outlet
strip embodiment of the present invention, and is referred to
herein by the general reference numeral 100. The outlet strip 100
provides independently managed power to each of sixteen AC-output
receptacles 101-116. A power supply (IPT-PS) module 118 senses and
totalizes the combined current delivered to all the AC-output
receptacles 101-116 from its AC-power input.
[0029] Peripheral integrated circuits (IC's) that have to
communicate with each other and the outside world can use a simple
bi-directional 2-wire, serial data (SDA) and serial clock (SCL) bus
for inter-IC (I2C) control developed by Philips Semiconductor. The
I2C-bus has become a worldwide industry-standard proprietary
control bus.
[0030] The IPT-PS module 118 digitally encodes the total AC-current
information onto an internal I2C-bus 119. The IPT-PS module 118
supplies DC-operating power for the internal I2C-bus 119 which is
derived from the AC-power input. Each of four intelligent power
modules (IPT-IPM) 120-123 have four relays (K1-K4) that switch
AC-power from the IPT-PS module 118 to respective ones of the
sixteen AC-output receptacles 101-116. Such relays K1-K4 are
controlled by a single I2C transceiver daisy-chain connected to
others along the internal I2C-bus 119. Each such I2C transceiver is
independently addressable on the I2C-bus 119, and provides a
digitally encoded power-on status indication for all four relays
K1-K4.
[0031] An I2C-module (IPT-I2C) 124 receives digital messages on the
internal I2C-bus 119 and decodes and displays the totalized
combined current, e.g., in AC-amperes, on an LED-readout 126. A
user is thus able to see the effect on the total current caused by
plugging or unplugging a load from any or all of the AC-output
receptacles 101-116.
[0032] The Philips 87LPC762 microcontroller is used as an I2C
interface to a dual seven-segment display. Port-0 pins select the
illuminated segments of a seven-segment display. Pin P1.7 selects
which of the two seven-segment displays is being driven, and
alternates between the two seven-segment displays fast enough to
avoid flicker. The I2C slave address is configurable. Five commands
are supported: STAT (status) RBTN (Read button), RPRB (Read probe),
CRST (Clear reset), and WDSP (Write display). A checksum is used on
received/sent bytes for data integrity across the I2C-bus.
[0033] The IPT-I2C microcontroller starts up with the I2C interface
in idle slave mode. Main ( ) waits in a loop until the I2C
interface is flagged as non-idle. After an I2C start occurs, and
the rising edge of SCL sets DRDY (and thus ATN), an I2C interrupt
occurs. The I2C ISR disables the I2C interrupt and sets a global
I2C non-idle flag. The main loop then proceeds to read in the first
byte from the I2C-bus. When seven bits are received, the target I2C
is known and is compared to the IPT-I2C microcontroller's own
module address. If different, the I2C interface processing stops
and waits for another start to begin again. If the same, the last
bit of the first byte is read, which is the R/W bit. If a Read,
then the IPT-I2C microcontroller acknowledges the byte and
repeatedly sends a fixed number of response bytes: an address byte,
a type byte, one or more data bytes, and a checksum. If a Write,
then the IPT-I2C microcontroller acknowledges the byte, and then
will read up to four more bytes: a command byte one or more data
bytes, and a checksum. As received, the bytes are acknowledged and
compared to expected valid commands and data. As soon as a valid
command, any data parameters and a valid checksum are received and
acknowledged, the command is acted upon. Without a valid checksum,
the command is not acted upon. If an unexpected command or data is
received, or more bytes are received than expected, then a negative
acknowledge occurs after the next byte is received, and the I2C
interface is stopped, and another start is needed to begin again.
Throughout the I2C processing loop, a bus timeout (by Timer 1
interrupt) resets the I2C interface to idle and the I2C processing
loop to the appropriate states Timer U also guards the I2C
interface with a 5-millisecond inter-clock timeout and a 15 second
total I2C timeout. The total I2C timeout is reset when the IPT-I2C
microcontroller is addressed on the I2C with its primary address
(not the secondary address).
[0034] The I2C IPT-I2C microcontroller commands include the STAT
command which sets the IPT-I2C microcontroller to a read type to
STAT. This means that an I2C Read will send four bytes (address,
type data checksum) in which the data byte represents the status of
the IPT-I2C microcontroller.
[0035] The RBTN command sets the IPT-I2C microcontroller read type
to RBTN. This means that an I2C Read will send four bytes (address,
type, data, checksum) in which the data byte represents the status
of the button.
[0036] The RPRB command sets the IPT-I2C microcontroller read type
to RPRB. This means that an I2C Read will send five bytes (address,
type data, data, checksum) in which the data bytes represent the
type of 1-wire bus probe and the probe data.
[0037] The CRST command clears the Reset Flag (RSTF), Power On
Reset Flag (PORF), Brownout Reset Flag (BORF), and WatchDog Reset
Flag (WDRF) bits of the IPT-I2C microcontroller status byte.
[0038] The WDSP command sets the values for the dual seven-segment
display.
[0039] At power up, the dash-dash blinks until a valid WDSP command
is received. After that, if ten seconds pass without receiving a
valid WDSP command, the display reverts back to the blinking
dash-dash.
[0040] A read command is started by the master addressing the slave
with the R/W bit set. A read command to the slave IPT-I2C
microcontroller results in a fixed number of bytes repeatedly being
transmitted by the slave (address, type, data1 . . . dataN
checksum). The first byte is the address of the slave. The second
byte indicates the type of data in the following data byte(s). The
last byte is a checksum of all the previous bytes.
[0041] A write command is started by the master addressing the
slave with the R/W bit cleared. This is followed by the master
transmitting multiple bytes to the slave, followed by a stop or
restart.
[0042] The internal I2C-bus 119 is terminated at a network
personality module (IPT-NetworkPM) 128. Such provides an operating
system. HTTP-server and network interface between the internal
I2C-bus 119 an external I2C-bus 130, an Ethernet 10/100. BaseT 132,
a modem 134, and a local operator's console 136. The IPT-NetworkPM
128 preferably uses Internet protocols like TCP/IP and supports
simple network management protocol (SNMP). In one application, the
outlet strip 100 could be used in the remote power management
environment described by the present inventors in their U.S. Pat.
No. 5,949,974, issued Sep. 7, 1999. Such Patent is incorporated
herein by reference.
[0043] Network messages, e.g., using TCP/IP and SNMP, are
communicated over the Ethernet 10/100 BaseT interface 132. Such
messages are able (a) to independently control the power on-off to
each of AC-output receptacles 101-116, (b) to read the power-on
status of each, and (c) to report load current supplied by each
outlet, or simply the total combined current measured passing
through IPT-PS 118.
[0044] In one embodiment, the power applied to AC-output
receptacles 101-116 is not allowed by the individual IPT-IPM
modules 120-123 to be simultaneously applied. Instead, each is
allowed to turn on in succession so any instantaneous load in-rush
currents can not combine to exceed the peak capabilities of the
AC-power input source.
[0045] The total input current display 126 could be used to
advantage by a technician when installing or troubleshooting a
RETMA equipment rack by watching how much current change is
observed when each network appliance is plugged in and turned on.
Unusually high or low currents can indicate particular kinds of
faults to experienced technicians.
[0046] FIGS. 2A and 2B represent a network remote power management
outlet strip embodiment of the present invention, which is referred
to herein by the general reference numeral 200. These illustrate
one way the network remote power management outlet strip 100 of
FIG. 1 could be physically implemented and arranged. The outlet
strip 200 provides independently managed power to each of sixteen
AC-output receptacles 201-216. These have AC-neutral and AC-ground
bussed through two sets of eight, e.g., with 12-gauge wire. A power
supply (IPT-PS) module 218 is daisy-chained in an internal I2C-bus
219 to a series of four intelligent power modules (IPT-IPM)
220-223. The IPT-PS module 218 has, for example, a Philips
microcontroller type 87LPC762 that senses and totalizes the
combined current delivered on the AC-Line leads to all of four
intelligent power modules (IPT-IPM) 220-223.
[0047] The Philips 87LPC762/7 microcontroller is programmed as an
I2C 8-bit I/O Expander, with an 8-bit 4-channel A/D converter.
Eight pins are individually selectable as either an Input
(quasi-bidirectional) or Output (open drain). Four address lines
determine the I2C slave address. Eight commands are supported: STAT
(Status), RCFG (Read Config) RPRT (Read Port), RADC (Read ADC),
CRST (Clear Reset), WCFG (Write Config), WPRT (Write Port), and
ADCE (ADC Enable). A checksum is used on received/sent bytes for
data integrity across the I2C-bus. Without a valid checksum, a
command will not be acted upon.
[0048] The microcontroller starts up with the I2C interface in idle
slave mode. Main( ) waits in a loop until the I2C interface is
flagged as non-idle. After an I2C start occurs, and the rising edge
of SCL sets DRDY and thus ATN, an I2C interrupt occurs. The I2C ISR
disables the I2C interrupt and sets a global I2C non-idle flag. The
main loop then proceeds to read in the first byte from the I2C-bus.
When seven bits are received, the target I2C is known and is
compared to the I/O Expander's own module address. If different,
the I2C interface processing stops and waits for another start to
begin again. If the same the last bit of the first byte is read,
which is the R/W bit. If a Read, then the microcontroller
acknowledges the byte, and repeatedly sends a fixed number of
response bytes (an address byte, a type byte one or more data
bytes, and a checksum). If a Write, then the microcontroller
acknowledges the byte and then will read up to three more bytes (a
command byte, a data byte, and a checksum). As received, the bytes
are acknowledged and compared to expected valid commands and data.
As soon as a valid command, any data parameters and a valid
checksum are received and acknowledged, the command is acted upon.
If an unexpected command or data is received, or more bytes are
received than expected, then a negative acknowledge occurs after
the next byte is received, and the I2C interface is stopped and
another start is needed to begin again. Throughout the I2C
processing loop, a bus timeout by Timer 1 interrupt resets the I2C
interface to idle and the I2C processing loop to the appropriate
state. Timer 0 also guards the I2C interface with a 5-millisecond
inter-clock timeout and a 15-second total I2C timeout. The total
I2C timeout is reset when the I/O Expander is addressed on the I2C
with its primary address, not the secondary address.
[0049] The I2C microcontroller commands include the STAT command,
which sets the I/O Expander read type to STAT. An I2C Read will
send four bytes: address, type, data, checksum. The data byte
represents the status of the I/O Expander.
[0050] The RCFG command sets the I/O Expander read type to RCFG.
This means that an I2C Read will send four bytes: address, type,
data, checksum. The data byte represents the I/O configuration of
the eight I/O pins.
[0051] The RADC command sets the microcontroller read type to RADC.
This means that an I2C Read will send eight bytes (address, type,
ADCE status, ADCO data, ADCI data, ADC2 data, ADC3 data, checksum)
in which the data bytes represent the value of the four ADC
channels. For ADC channels that are disabled, a value of 0xFF is
returned. For enabled ADC channels, the value represents the
average of the last eight averages of 64 A/D conversions during the
last four AC cycles. All four channels are converted once during
each 1.042 ms, about 260 us apart. After four AC (60 Hz) cycles,
each channel has be converted 64 times. For each channel these 64
conversions are averaged and stored. The most-recent eight stored
averages are then again averaged, making the reported value the
truncated average over 64.times.8=512 AC cycles, which spans just
over a half second.
[0052] The CRST command clears the ReSeT Flag (RSTF) Power On Reset
Flag (PORF), BrownOut Reset Flag (BORF), and IiiatchDog Reset Flag
(WDRF) bits of the I/O Expander status byte.
[0053] The WCFG command sets the microcontroller I/O configuration
of the eight I/O pins. The WCFG command also sets the read type to
RCFG.
[0054] The WPRT command sets the state of the eight I/O pins that
are configured as outputs. The WPRT command also sets the read type
to RPRT.
[0055] The ADCE command enables or disables any or all four ADC
channels. The ADCE command also sets the read type to RADC.
[0056] A read command is started by the master addressing the slave
with the R/W bit set. A read command to the slave IPT-I2C
microcontroller results in a fixed number of bytes repeatedly being
transmitted by the slave (address, type, data1 . . . dataN
checksum). The first byte is the address of the slave. The second
byte indicates the type of data in the data bytes that follow. The
last byte is a checksum of all the previous data bytes.
[0057] A write command is started by the master addressing the
slave with the R/W bit cleared. This is followed by the master
transmitting multiple bytes to the slave, followed by a stop or
restart.
[0058] The IPT-PS module 218 digitally encodes the total AC-input
current information onto the internal I2C-bus 219. The IPT-PS
module 218 derives DC-operating power from the AC-power input for
modules on the internal I2C-bus 219. Each of the IPT-IPM modules
220-223 has four relays (K1-K4) that switch the AC-Line from the
IPT-PS module 218 to respective ones of the AC-Line connections on
each of the sixteen AC-output receptacles 201-216. Such relays
K1-K4 are controlled by a single I2C transceiver located on each
IPT-IPM 220-223. For example, such I2C transceiver could be
implemented with a Philips microcontroller type 87LPC762.
[0059] Each such I2C transceiver is independently addressable on
the I2C-bus 219, and provides a digitally encoded power-on status
indication for all four relays K1-K4. An I2C-module (IPT-I2C) 224
receives digital messages on the internal I2C-bus 219 and decodes
and displays the totalized combined current, e.g., in AC-amperes,
on an LED-readout 226. The internal I2C-bus 219 terminates at a
IPT-NetworkPM 228.
[0060] Preferably, IPT-NetworkPM 228 includes an operating system,
an HTML webpage, and a network interface. Such can connect a remote
user or command console with the internal I2C-bus 219, an external
I2C-bus that interconnects with other outlet strips through a RJ-11
socket 230, an Ethernet 10/100 BaseT RJ-45 type socket 232, etc.
The IPT-NetworkPM 228 preferably uses Internet protocols like
TCP/IP and supports simple network management protocol (SNMP).
[0061] The modular construction of outlet strip 200 allows a family
of personality modules to be substituted for IPT-NetworkPM 228.
Each such would be able to communicate with and control the
IPT-IPM's 220-223 via the internal I2C-bus 219.
[0062] The manufacturability and marketability of IPT-IPM 220-223
could be greatly enhanced by making the hardware and software
implementation of each the same as the others. When a system that
includes these is operating, it preferably sorts out for itself how
many IPM's are connected in a group and how to organize their
mutual handling of control and status data in and out.
[0063] FIG. 3 illustrates a printed circuit board (PCB)
implementation of an intelligent power module IPT-IPM 300, similar
to those of FIGS. 1, 2A, and 2B. On the component side of the PCB,
the IPT-IPM 300 has a two-position connector 302 for AC-Neutral,
and on the non-component side screw connector 304 for the AC-Line.
A PCB trace 306 distributes AC-Line power input to a series of four
power control relays, as shown in FIG. 4. An insulator sheet 310
screws down over the IPT-IPM 300 and protects it from short
circuits with loose wires and the sheetmetal outlet strip
housing.
[0064] For example, insulator sheet 310 can be made of MYLAR
plastic film and may not necessarily have a set of notches 312 and
314 that provide for connector tabs 302 and 304. Connector tabs 302
and 304 can alternatively be replaced with a two-position connector
with screw fasteners.
[0065] FIG. 4 illustrates the component side of a PCB
implementation of an IPT-IPM module 400, e.g., the opposite side
view of the IPT-IPM module 300 in FIG. 3. The IPT-IPM module 400
comprises a pair of I2C daisy chain bus connectors 402 and 404, a
PCB trace 406 distributes AC-Line power input from AC-Line screw
connector 304 connect at a via 408 to a series of four power
control relays 410-413. A microcontroller 414 processes the I2C
communications on the internal I2C-bus, e.g., I2C-bus 119 in FIG. 1
and 219 in FIGS. 2A and 2B.
[0066] FIG. 5 shows the basic construction of an IPT-NetworkPM
module 500, and is similar to the IPT-NetworkPM module 128 of FIG.
1 and 228 of FIGS. 2A and 2B. A NetSilicon (Waltham, Mass.) type
NET+50 32-bit Ethernet system-on-chip for device networking is
preferably used to implement a communications processor 502. A
flash memory 504 provides program storage and a RAM memory 506
provides buffer and scratchpad storage for the communications
processor operations. A local I2C-bus is implemented in part with a
pair of 2N7002 transistors, for example. It connects into the I2C
daisy chain with a J1-connector (CON4) 510. An external I2C-bus is
implemented in part with a pair of 2N7002 transistors, for example.
It connects into an external I2C system with an RJ12-type
J7-connector 510. Such external I2C system can expand to one
additional outlet strip that shares a single IPT-NetworkPM module
500 and a single network connection.
[0067] An Ethernet 10/100 BaseT interface with the media access
controller (MAC) internal to the communications processor 502 is
provided by a physical layer (PHY) device 516. An Intel type
LXT971A fast Ethernet PHY transceiver, for example, could be used
together with an RJ45 connector 518. A pair of RS-232 serial
interfaces are implemented in part with an SP3243E transceiver 520,
an RJ45H connector 522, another SP3243E transceiver 524, and an
IDC10 connector 526.
[0068] The flash memory 504 is preferably programmed with an
operating system and HTML-browser function that allow web-page type
access and control over the Ethernet channel. A complete OS kernel,
NET+Management simple network management protocol (SNMP) MIBII and
proxy agent, NET+Protocols including TCP/IP, NET+Web HTTP server,
and XML microparser, are commercially available from NetSilicon for
the NET+50 32-bit Ethernet system-on-chip.
[0069] FIG. 6 represents a circuit 600 that could be used in an
implementation of the IPT-PS 118 of FIG. 1 and IPT-PS 218 of FIGS.
2A and 2B. An AC-Line input 602 from the AC-power source is passed
through the primary winding of an isolation transformer 604. A set
of four AC-Line outputs 606 are then connected to the four
IPT-IPM's, e.g., 120-123 in FIG. 1 and 220-223 in FIGS. 2A and 2B.
The voltage drop across the primary winding of isolation
transformer 604 is relatively small and insignificant, even at full
load. So the line voltage seen at the AC-Line outputs 606 is
essentially the full input line voltage.
[0070] A voltage is induced into a lightly loaded secondary winding
that is proportional to the total current being drawn by all the
AC-loads, e.g., AC-receptacles 101-116 in FIG. 1 and 201-216 in
FIGS. 2A and 2B. An op-amp 608 is configured as a precision
rectifier with an output diode 610 and provides a DC-voltage
proportional to the total current being drawn by all the AC-loads
and passing through the primary of transformer 604. An op-amp 612
amplifies this DC-voltage for the correct scale range for an
analog-to-digital converter input (A0) of a microcontroller (uC)
616. A Philips Semiconductor type P87LPC767 microcontroller could
be used for uC 616. Such includes a built-in four-channel 8-bit
multiplexed A/D converter and an I2C communication port. When a
READ ADC command is received on the I2C communication port, the A0
input is read in and digitally converted into an 8-bit report value
which is sent, for example, to LED display 126 in FIG. 1.
[0071] A prototype of the devices described in connection with
FIGS. 1-6 was constructed. The prototype was a combination of new
hardware and software providing for a 4-outlet, 8-outlet, or
16-outlet vertical-strip power manager that could be accessed
out-of-band on a single RJ45 serial port, or in-band over a
10/100Base-T Ethernet connection by Telnet or an HTML browser. An
RJ12 port was connected to a second, nearly identical
vertical-strip power manager that was almost entirely a slave to
the first, e.g., it could only be controlled by/via the
first/master vertical power manager.
[0072] Vertical power manager hardware and software was used for
the IPT-PS power supply board, the IPT-IPM quad-outlet boards, and
IPT-I2C peripheral/display board. For the master vertical power
manager, new personality module hardware and software was
developed. This personality module, trademarked SENTRY3, was based
upon the NetSilicon NetARM+20M microprocessor, and provided all of
the control and user interface (UI). On the slave vertical power
manager, a preexisting IPT-Slave personality module was modified
slightly to bridge the external and internal I2C-buses. This
allowed the master to control the slave vertical power manager
exactly the same as the master vertical power manager, with no
software or microprocessor needed on the slave. New software could
be included to run in a microprocessor on the slave vertical power
manager personality module to act as a backup master for
load-display and power-up sequencing only.
[0073] A new SENTRY3 personality module was developed to support an
HTML interface for Ethernet, and a command-line interface for
Telnet and serial. Multiple users were supported, up to 128. One
administrative user (ADMN) existed by default, and will default to
having access to all ports. Outlet grouping was supported, with up
to 64 groups of outlets.
[0074] There were two I2C-buses that can support up to sixteen
quad-IPM (IPT-IPM) boards, across four power inputs, with at most
four quad-IPM's per input, and with each input having its own load
measurement and display. Each power input was required to have the
same number of quad-IPM's that it powered. There was one I2C
peripheral/display (IPT-I2C) board for each power input. Each bus
had only one smart power supply (IPT-PS) board at I2C address 0x5E.
Each bus had at least one I2C peripheral/display (IPT-I2C) board at
I2C address 0x50, and at least one quad-IPM (IPT-IPM) board at I2C
address 0x60 (or 0x40).
[0075] Determining what was present on an I2C-bus, and at what
address, was done by reading the 8-bit I/O port of the power
supply. The eight bits were configured as, TABLE-US-00001 Bit 0
=> Undefined Bit 1 => Display orientation (1 = Upside-Up, 0 =
Upside-Down) Bit 2 => Number of quad-IPM's per power input Bit 3
=> Number of quad-IPM's per power input Bit four => Overload
point (1 = 30.5A [244ADC], 0 = 16.5A [132ADC]) Bit 5 =>
Undefined Bit 6 => Number of power inputs Bit 7 => Number of
power inputs
Bits 2 & 3 together determine how many quad-IPM's there were
per power input. Bits 6 & 7 together determine how many power
input feeds there were.
[0076] The I2C address of the quad-IPM's were determined by the
version of LPC code on the IPT-PS board, as determined by a read of
the STATus byte of the of the IPT-PS. TABLE-US-00002 Version 3+
=> quad-IPM's start @ 0x60 and were 0x60, 0x62, 0x64, 0x66,
0x68, 0x6A, 0x6C, 0x6E, 0x70, 0x72, 0x74, 0x76, 0x78, 0x7A, 0x7C,
0x7E. Version 2- => quad-IPM's start @ 0x40 and were 0x40, 0x42,
0x44, 0x46, 0x48, 0x4A, 0x4C, 0x4E, 0x50, 0x52, 0x54, 0x56, 0x58,
0x5A, 0x5C, 0x5E.
[0077] Up to four IPT-I2C peripheral/display boards were supported
at I2C addresses: 0x50, 0x52, 0x54, and 0x56.
[0078] There was a direct mapping relationship between power
inputs, IPT-I2C peripheral/display boards I2C addresses, and the
IPT-IPM boards I2C addresses: TABLE-US-00003 Power IPT-I2C IPT-IPM
v3+ addresses Input address (subtract 0x20 for v2-) A 0x50 0x60,
0x62, 0x64, 0x66 B 0x52 0x68, 0x6A, 0x6C, 0x6E C 0x54 0x70, 0x72,
0x74, 0x76 D 0x56 0x78, 0x7A, 0x7C, 0x7E
[0079] Considering that each input power feed can support up to
four quad-IPM's (sixteen ports), and that each bus can have four
input feeds, and that there were two I2C-buses, an addressing
scheme for a port must include three fields (a) Bus ID, (b) Input
Feed ID, and (c) Relay ID
[0080] The Bus ID could be regarded as vertical-strip power
manager/enclosure ID, since one I2C-bus were for the internal/local
I2C vertical power manager components and the other I2C-bus were
for the external/remote vertical power manager. Other
implementations could use a CAN bus in place of the external
I2C-bus. Each enclosure had an address on the bus, e.g., an
Enclosure ID. Thus, the three address fields needed were (a)
Enclosure ID, (b) Input Feed ID, and (c) Relay ID.
[0081] The Enclosure ID was represented by a letter, starting with
"A", with a currently undefined maximum ultimately limited to "Z".
Only "A" and "B" existed for the prototype. The Input Feed ID was
represented by a letter, with a range of "A" to "D". The Relay ID
was represented by a decimal number, with a range of "1" to
"16".
[0082] An absolute identifier was needed for the user to enter
commands. A combination of Enclosure ID, Input Feed ID, and Relay
ID must be expressed in the absolute ID. This were done with a
period followed by two alphabet characters and then one or two
numeric characters, e.g.,
".{enclosure_id}[input_feed_id]{#}[#]".
[0083] The first alphabet character represented the Enclosure ID
("A" to "Z"). The second alphabet character represented the Input
Feed ID ("A" to "D"). The third and fourth number characters
represented the Relay ID ("1" to "16"), e.g., ".{AZ}[AD]{116}". The
input feed ID was optional. If not specified, "A" was assumed. With
an absolute ID scheme, a period, letter, and number must always be
entered, making it very similar to our current scheme, but allowing
for future multiple input feeds. For displaying IDs, the optional
input feed ID should only be shown when the port was in an
enclosure with 2 or more input feeds. A vertical power manager ID
could be specified with just a period and letter. An input feed ID
could be specified with a period and two letters.
[0084] Existing outlets were determined by reading the power supply
I/O port of the master and slave vertical power manager. One
administrative user exists by default, and has access to all
outlets and groups. This administrator (ADMN) could be removed, but
only if one or more other users with administrative privileges
exist. Additional users could be created or removed. Administrative
privileges could be given to or removed from added users.
[0085] The administrative privilege allows access to all
currently-detected outlets and groups without those outlets or
groups actually being in the user's outlet or group tables. Lists
of outlets or groups for administrative users should include all
currently-detected outlets and groups. This allowed administrative
privileges to be given or taken away without affecting the users
outlet and group tables.
[0086] Groups of outlets could be created or removed. Outlets could
be added or removed from groups. Outlets, or groups of outlets,
could be added or removed from users. An outlet may belong to
multiple groups. All user-defined outlet and groups names were
unique. This were enforced at the time names were defined by the
user. All user-defined names also cannot be the same as any
KEYWORDS. For example, they cannot be "GROUP", "OUTLET", or "ALL".
This were enforced at the time names were defined by the user.
Usernames were uppercased when stored and displayed, and were
compared case-insensitive. Passwords were stored and compared
case-sensitive. Separate tables existed for each user's outlet
access and group access.
[0087] When an ADMN user specifies "ALL" it means all currently
detected outlets. For non-ADMN users, the "ALL" parameter refers to
all of the outlets in the current user's outlet access table. There
was no "tall" to refer to all groups.
[0088] All commands that specify outlet IDs need to be
bounds-checked against the currently detected number of enclosures,
number of input feeds on the target enclosure, and the number of
relays on the target enclosure. Power actions could be applied to
only one target at a time. The target could be an outlet or a group
of outlet.
[0089] A wakeup state determined the default power-up state of each
outlet. Power-on sequencing occurred independently on each vertical
power manager and power feed, with each outlet being initialized to
its wakeup state two seconds after the previous outlet, e.g.,
starting with outlet-1. Outlet names could be up to 24-characters.
These were stored and displayed case-sensitive, but were compared
case-insensitive as command parameters. Group names could be up to
24-characters These were stored and displayed case-sensitive, but
were compared case-insensitive as command parameters A 24-character
vertical power manager/enclosure name could be user-defined. This
were stored and displayed case-sensitive, but was compared
case-insensitive as a command parameter A 32-character location
name could be user-defined. This were stored and displayed
case-sensitive. Usernames could be 1-16 characters, and were
case-insensitive. Passwords also could be 1-16 characters, and were
case-sensitive. Variable length command parameters were
length-checked for validity. An error was displayed if too short or
too long, as opposed to and automatic behavior, such as truncating
a string that was too long.
Prototype I2C Address Map
[0090] TABLE-US-00004 I2C Address I2C Address Device (binary) (hex)
I2C-01 0101-000x 0x50 I2C-02 0101-001x 0x52 I2C-03 0101-010x 0x54
I2C-04 0101-011x 0x56 IPT-PS 0101-111x 0x5E IPM-01 0110-000x 0x60
IPM-02 0110-001x 0x62 IPM-03 0110-010x 0x64 IPM-04 0110-011x 0x66
IPM-05 0110-100x 0x68 IPM-06 0110-101x 0x6A IPM-07 0110-110x 0x6C
IPM-08 0110-111x 0x6E IPM-09 0111-000x 0x70 IPM-10 0111-001x 0x72
IPM-11 0111-010x 0x74 IPM-12 0111-011x 0x76 IPM-13 0111-100x 0x78
IPM-14 0111-101x 0x7A IPM-15 0111-110x 0x7C IPM-16 0111-111x
0x7E
[0091] The prototype required several major software components to
be constructed for use with the NetSilicon NET+50 device. The
configuration and operational control blocks used in the prototype
were described in the following tables. All of the control blocks
were readable by all components in the system. The configuration
control blocks were written by the user interface tasks. When the
configuration control blocks were modified, the modifications were
mirrored in EEPROM where copies of these control blocks were
stored. The operational control blocks were also accessible to all
components for read access, but each operational control block has
an "owner" that performs all writes to the operational control
blocks. If a non "owner" wishes to change an operational control
block, a signal or message was used to let the "owner" know the
control block should be updated.
[0092] The major design tasks for the prototype included designing
and documenting the external I2C protocol that was used to
communicate to "chained" SENTRY boxes, and the new command line
interface commands to support features that were previously
available only via the SENTRY SHOW Screen interface. The HTML code
was developed for the prototype, as well as the "slave" SENTRY code
to run in a personality module of a "chained" SENTRY. Further
discrete design efforts were required to code the system
initialization, the local I2C task, the external I2C task, the
serial port control task, the telnet control task, the user
interface task, the power coordination task, the extern user
interface (button/LED) control task, and the WEB control task.
[0093] The major software components developed for the prototype
are listed in the following Tables. TABLE-US-00005 SenINIT - SENTRY
initialization procedure. This software was the first SENTRY
software that executes. It performs hardware, software (builds the
Configuration and Operational global control blocks), and OS
initialization. This code spawns the SENTRY operational tasks that
provide the system services.
[0094] TABLE-US-00006 TskSER - One instance of this task was
spawned for each active serial port. In the initial product there
was one instance of this task. This task spawns TskUSR when a logon
was detected. This task owns the serial port operational array
control block in global memory. This control block was updated to
reflect the status of the serial port. Once a TskUSR was spawned,
this task performs serial port monitoring functions and if modem
status signal indicate a lost connection, this task will signal
TskUSR (via an OS interface) of this event.
[0095] TABLE-US-00007 TskTELNET - One instance of this task was
spawned to listen for telnet connections. When a connection was
detected, this task spawns TskUSR for the connection.
[0096] TABLE-US-00008 TskFTP - One instance of this task was
spawned to listen for FTP connections. The function of this task
was to provide field software updates for the system. The mechanism
used was determined based on the developer kit capabilities.
[0097] TABLE-US-00009 TskWEB - This task was to provide WEB access
via the system provided WEB server. The mechanism and number of
instances of this task was determined based on the developer kit
capabilities.
[0098] TABLE-US-00010 TskI2C - There were two versions of this
task; the local version that controls internal I2C connections and
the global version that controls external I2C connections. For the
first implementation there were two instances of this task, one to
control the single I2C internal connection and one to control the
single I2C external connection. These tasks implement the protocol
for communicating control requests from the system to the I2C
connected devices. Control requests were received via system
signals or messages (depending on the OS capabilities) from the
power control coordinating task (TskPCntl) for power control
requests and from the external user interface task (TskEUI) for LED
control requests. This task communicates power control status
updates received from the IPM's to TskPCntl and external button
status updates to TskEUI using system signals or messages as
necessary.
[0099] TABLE-US-00011 TskPCntl - This was the power control
coordinating task. There was one instance of this task. This task
receives power control request from the user interface tasks
(TskUSR and TskWEB) via system provided signals or messages and
passes them to the correct I2C task (internal or external) using
signals or messages. This task receives status updates from the I2C
tasks via signals or messages. TskPCntl "owns" the IPMO and PCRO
arrays and it updates the status fields in entries in these arrays
as necessary.
[0100] TABLE-US-00012 TSkEUI - This was the external user interface
task that handles the push button functions and the LED display
functions for the system. This task communicates with the local
TskI2C via signals or messages to update the LED. TskI2C sends
signals or messages to this task when the state of the external
push button changes.
[0101] TABLE-US-00013 TskUSR - This command line user interface
task was spawned by TskSER and TskTELNET when a user connection was
detected. This task verifies the user login and then implements the
command line interface. This routine communicates power control
commands via signals or messages to TskPCntl. This routine "owns"
the active command line user array. Because there were multiple
instances of this task, locks were used to serialize access to the
active user array.
[0102] TABLE-US-00014 TskSYS - This was the general system task.
Specific functions for this task were defined as development
progressed.
[0103] The control blocks were globally addressable by all software
in the system. Such data structures exist in RAM and were mirrored
in EEPROM memory. They were constructed during system
initialization using the non volatile versions in EEPROM memory. If
the EEPROM memory was empty, the control blocks were built using
defaults and the EEPROM memory was initialized using defaults as
well. All software has read access to all of the data structures.
The data in these control blocks was configuration data and was
only changed as a result of configuration updates. The data was
mostly static and was written during initialization and when
configuration changes occur during an authorized user session. All
write access to this data consists of a two step process where the
Global RAM copy of the data was updated followed by an update of
the EEPROM copy of the data. There were seven global configuration
control blocks as illustrated below. The following Tables describe
each control block structure used in the prototype. TABLE-US-00015
SENTRY Configuration Table (SCT) - This control block contains
global configuration information. There was a single instance of
this control block.
[0104] TABLE-US-00016 Username/Password Array (UNP) - This was an
array of control blocks with each entry representing a user defined
to the system. System locks were used to serialize access to this
array when adding/deleting users. There was room for sixty- four
entries in this array.
[0105] TABLE-US-00017 Intelligent Power Module (IPM) Array - This
was an array of control blocks with each entry representing an IPM
defined to the system. There was room for 32 entries in this
array.
[0106] TABLE-US-00018 Power Control Relay (PCR) Array - This was an
array of control blocks with each entry representing an PCR defined
to the system. There was room for 128 entries in this array.
[0107] TABLE-US-00019 Group Power Control Relay (GRP) Array - This
was an array of control blocks with each entry representing an
Group of PCRs. There was room for 64 entries in this array.
[0108] TABLE-US-00020 Serial Port (SER) Array - This was an array
of control blocks with each entry representing a serial port that
can be used to access the system. There was room for two entries in
this array.
[0109] TABLE-US-00021 I2C Array - This was an array of control
blocks with each entry representing an I2C connection. There was
room for two entries in this array.
[0110] The Global RAM Operational Control Block Structures were
globally addressable by all software in the system. These data
structures exist only in RAM and are lost during a system restart.
They were constructed during system initialization using current
operational values. All software has read access to all of the data
structures. The data in these control blocks was operational data
and was changed to reflect the current operational status of
devices in the system. Each of these control blocks has an "owner"
task that performs updates by writing to the control block. There
were six global operational control blocks as illustrated below.
Complete descriptions of each control block structure follows.
TABLE-US-00022 Intelligent Power Module (IPMO) Array - This was an
array of control blocks with each entry representing an IPM defined
to the system. There was room for 32 entries in this array. The
entries in this array correspond directly to the IPM configuration
control block. These control blocks contain dynamic information
that changes regularly. The relay coordination task (TskPCntl)
"owns" this array.
[0111] TABLE-US-00023 Power Control Relay (PCRO) Array -- This was
an array of control blocks with each entry representing an PCR
defined to the system. There was room for 128 entries in this
array. The entries in this array correspond directly to the PCR
configuration control block. These control blocks contain dynamic
information that changes regularly. The relay coordination task
(TskPCntl) "owns" this array.
[0112] TABLE-US-00024 I2C (I2CO) Array -- This was an array of
control blocks with each entry representing an I2C connection.
There was room for 2 entries in this array. The entries in this
array correspond directly to the I2C configuration control block.
These control blocks contain dynamic information that changes
regularly. The I2C task (TskI2C) "owns" this array.
[0113] TABLE-US-00025 Serial Port (SERO) Array -- This was an array
of control blocks with each entry representing a serial port that
can be used by the system. There was room for two entries in this
array. The entries in this array correspond directly to the serial
port configuration control block. These control blocks contain
dynamic information that changes regularly. The serial port task
(TskSER) "owns" this array.
[0114] TABLE-US-00026 Active Command Line User (UCLI) Array -- This
was an array of control blocks with each entry representing a
current active command line user of the system. The SCT was room
for 5 entries in this array. These control blocks contain dynamic
information that changes regularly. The user interface task
(TskUSR) "owns" this array. There were multiple instances of TskUSR
so locks were used for this array.
[0115] TABLE-US-00027 Active HTTP Interface User (UHTP) Array --
This was an array of control blocks with each entry representing a
WEB user. There was room for 5 entries in this array. These control
blocks contain dynamic information that changes regularly. The WEB
task (TskWEB) "owns" this array.
[0116] In FIG. 7, a network remote power management system 700
includes a host system 702 connected over a network 704 to a remote
system 706. A power manager 708, e.g., like outlet strips 100 and
200 of FIGS. 1, 2A, and 2B, is used to monitor and control the
operating power supplied to a plurality of computer-based
appliances 714 associated with a network interface controller (NIC)
716.
[0117] Such computer-based appliances 714 are subject to software
freezing or crashing, and as such can become unresponsive and
effectively dead. It is also some mission-critical assignment that
suffers during such down time. It is therefore the role and purpose
of the network remote power management system 700 to monitor the
power and environmental operating conditions in which the
computer-based appliance 714 operates, and to afford management
personnel the ability to turn the computer-based appliance 714 on
and off from the host system 702. Such power cycling allows a
power-on rebooting of software in the computer-based appliance 714
to be forced without actually having to visit the site. The
operating conditions and environment are preferably reported to the
host 702 on request and when alarms occur.
[0118] The power manager 708 further includes a network interface
controller (NIC) 718, and this may be connected to a security
device 720. If the network 704 is the Internet, or otherwise
insecure, it is important to provide protection of a protocol stack
722 from accidental and/or malicious attacks that could disrupt the
operation or control of the computer-based appliance 714. At a
minimum, the security device 720 can be a user password mechanism.
Better than that, it could include a discrete network firewall and
data encryption.
[0119] The protocol stack 722 interfaces to a remote power manager
724, and it converts software commands communicated in the form of
TCP/IP datapackets 726 into signals the remote power manager can
use. For example, messages can be sent from the host 702 that will
cause the remote power manager 724 to operate the relay-switch 712.
In reverse, voltage, current, and temperature readings collected by
the sensor 710 are collected by the remote power manager 724 and
encoded by the protocol stack 722 into appropriate datapackets 726.
Locally, a keyboard 728 can be used to select a variety of readouts
on a display 730, and also to control the relay-switch 712.
[0120] The display 730 and keyboard 728 can be connected as a
terminal through a serial connection to the power manager 724. Such
serial connection can have a set of intervening modems that allow
the terminal to be remotely located. The display 730 and keyboard
728 can also be virtual, in the sense that they are both emulated
by a Telnet connection over the network 704.
[0121] The host 702 typically comprises a network interface
controller (NIC) 732 connected to a computer platform and its
operating system 734. Such operating system can include Microsoft
WINDOWS-NT, or any other similar commercial product. Such
preferably supports or includes a Telnet application 736, a network
browser 738, and/or an SNMP application 740 with an appropriate MIB
742. A terminal emulation program or user terminal 744 is provided
so a user can manage the system 700 from a single console.
[0122] If the computer-based appliance 714 is a conventional piece
of network equipment, e.g., as supplied by Cisco Systems (San Jose,
Calif.), there will usually be a great deal of pre-existing SNMP
management software already installed, e.g., in host 702 and
especially in the form of SNMP 740. In such case it is usually
preferable to communicate with the protocol stack 722 using SNMP
protocols and procedures. Alternatively, the Telnet application 736
can be used to control the remote site 706.
[0123] An ordinary browser application 738 can be implemented with
MSN Explorer, Microsoft Internet Explorer, or Netscape NAVIGATOR or
COMMUNICATOR. The protocol stack 722 preferably includes the
ability to send hypertext transfer protocol (HTTP) messages to the
host 702 in datapackets 726. In essence, the protocol stack 722
would include an embedded website that exists at the IP-address of
the remote site 706. An exemplary embodiment of a similar
technology is represented by the MASTERSWITCH-PLUS marketed by
American Power Conversion (West Kingston, R.I.).
[0124] Many commercial network devices provide a contact or
logic-level input port that can be usurped for the "tickle" signal.
Cisco Systems routers, for example, provide an input that can be
supported in software to issue the necessary message and identifier
to the system administrator. A device interrupt has been described
here because it demands immediate system attention, but a polled
input port could also be used.
[0125] Network information is generally exchanged with protocol
data unit (PDU) messages, which are objects that contain variables
and have both titles and values. SNMP uses five types of PDU's to
monitor a network. Two deal with reading terminal data, two deal
with setting terminal data, and one, the trap, is used for
monitoring network events such as terminal start-ups or shut-downs.
When a user wants to see if a terminal is attached to the network,
for example, SNMP is used to send out a read PDU to that terminal.
If the terminal is attached, a user receives back a PDU with a
value "lyes, the terminal is attached". If the terminal was shut
off, a user would receive a packet informing them of the shutdown
with a trap PDU.
[0126] In alternative embodiments of the present invention, it may
be advantageous to include the power manager and intelligent power
module functions internally as intrinsic components of an
uninterruptable power supply (UPS). In applications where it is too
late to incorporate such functionally, external plug-in assemblies
are preferred such that off-the-shelf UPS systems can be used.
[0127] Once a user has installed and configured the power manager
708, a serial communications connection is established. For
example, with a terminal or terminal emulation program. Commercial
embodiments of the present invention that have been constructed use
a variety of communications access methods.
[0128] For modem access, the communication software is launched
that supports ANSI or VT100 terminal emulation to dial the phone
number of the external modem attached to the power manager. When
the modems connect, a user should see a "CONNECT" message. A user
then presses the enter key to send a carriage return.
[0129] For direct RS-232C access, a user preferably starts any
serial communication software that supports ANSI or VT100 terminal
emulation. The program configures a serial port to one of the
supported data rates (38400, 79200, 9600, 4800, 7400, 7200, and 300
BPS), along with no parity, eight data bits, and one stop bit, and
must assert its Device Ready signal (DTR or DSR). A user then
presses the enter key to send a carriage return.
[0130] For Ethernet network connections, the user typically
connects to a power manager 708 through a modem or console serial
port, a TELNET program, or TCP/IP interface. The power manager 708
preferably automatically detects the data rate of the carriage
return and sends a username login prompt back to a user, starting a
session. After the carriage return, a user will receive a banner
that consists of the word "power manager" followed by the current
power manager version string and a blank line and then a
"Username:" prompt.
[0131] A user logged in with an administrative username can control
power and make configuration changes. A user logged in with a
general username can control power on/off cycling. Users logged in
administrative usernames can control power to all intelligent power
modules, a user logged in with a general username may be restricted
to controlling power to a specific intelligent power module or set
of intelligent power modules, as configured by the
administrator.
[0132] A parent case, U.S. patent application Ser. No. 09/732,557,
filed 72/08/2000, titled NETWORK-CONNECTED POWER MANAGER FOR
REBOOTING REMOTE COMPUTER-BASED APPLIANCES, includes many details
on the connection and command structure used for configuration
management of power manager embodiments of the present invention.
Such patent application is incorporated herein by reference and the
reader will find many useful implementation details there. Such
then need not be repeated here.
[0133] Referring again to FIG. 7, a user at the user terminal 744
is able to send a command to the power manager 724 to have the
power manager configuration file uploaded. The power manager 724
concentrates the configuration data it is currently operating with
into a file. The user at user terminal 744 is also able to send a
command to the power manager 724 to have it accept a power manager
configuration file download. The download file then follows. Once
downloaded, the power manager 724 begins operating with that
configuration if there were no transfer or format errors detected.
These commands to upload and download configuration files are
preferably implemented as an extension to an already existing
repertoire of commands, and behind some preexisting password
protection mechanism. HyperTerminal, and other terminal emulation
programs allow users to send and receive files.
[0134] In a minimal implementation, the power manager configuration
files are not directly editable because they are in a concentrated
format. It would, however be possible to implement specialized
disassemblers, editors, and assemblers to manipulate these files
off-line.
[0135] FIG. 8 is a diagram of an expandable power management system
800 that could be implemented in the style of the outlet strip 100
(FIG. 1). In one commercial embodiment of the present invention, a
first power controller board 802 is daisy-chain connected through a
serial cable 803 to a second power controller board 804. In turn,
the second power controller board 804 is connected through a serial
cable 805 to a third power controller board 806. All three power
controller boards can communicate with a user terminal 808
connected by a cable 809, but such communication must pass through
the top power controller board 802 first.
[0136] Alternatively, the user terminal could be replaced by an
IP-address interface that provided a web presence and interactive
webpages. If then connected to the Internet, ordinary browsers
could be used to upload and download user configurations.
[0137] Each power controller board is preferably identical in its
hardware and software construction, and yet the one placed at the
top of the serial daisy-chain is able to detect that situation and
take on a unique role as gateway. Each power controller board is
similar to power controller 208 (FIG. 2). Each power controller
board communicates with the others to coordinate actions. Each
power controller board independently stores user configuration data
for each of its power control ports. A typical implementation had
four relay-operated power control ports. Part of the user
configuration can include a user-assigned name for each control
port.
[0138] A resynchronization program is executed in each
microprocessor of each power controller board 802, 804, and 806,
that detects where in the order of the daisy-chain that the
particular power controller board is located. The appropriate main
program control loop is selected from a collection of firmware
programs that are copied to every power controller board. In such
way, power controller boards may be freely added, replaced, or
removed, and the resulting group will resynchronize itself with
whatever is present.
[0139] The top power controller board 802 uniquely handles
interactive user log-in, user-name tables, its private port names,
and transfer acknowledgements from the other power controller
boards. All the other power controller boards concern themselves
only with their private resources, e.g., port names.
[0140] During a user configuration file upload, power controller
board 802 begins a complete message for all the power controller
boards in the string with the user-table. Such is followed by the
first outlets configuration block from power controller board 802,
and the other outlet configuration blocks from power controller
boards 804 and 806. The power controller board 802 tells each when
to chime in. Each block carries a checksum so transmission errors
could be detected. Each block begins with a header that identifies
the source or destination, then the data, then the checksum.
[0141] During a user configuration file download, power controller
board 802 receives a command from a user that says a configuration
file is next. The user-name table and the serial-name table is
received by power controller board 802 along with its private
outlets configuration block and checksum. The next section is
steered to power controller board 804 and it receives its outlets
configuration block and checksum. If good, an acknowledgement is
sent to the top power controller board 802. The power controller
boards further down the string do the same until the whole download
has been received. If all power controller boards returned an
acknowledgement, the power controller board 802 acknowledges the
whole download. Operation then commences with the configuration.
Otherwise a fault is generated and the old configuration is
retained.
[0142] In general, embodiments of the present invention provide
power-on sequencing of its complement of power-outlet sockets so
that power loading is brought on gradually and not all at once. For
example, power comes up on the power outlet sockets 2-4 seconds
apart. An exaggerated power-up in-rush could otherwise trip alarms
and circuit breakers. Embodiments display or otherwise report the
total current being delivered to all loads, and some embodiments
monitor individual power outlet sockets. Further embodiments of the
present invention provide individual remote power control of
independent power outlet sockets, e.g., for network operations
center reboot of a crashed network server in the field.
[0143] The power-on sequencing of the power-outlet sockets
preferably allows users to design the embodiments to be loaded at
80% of full capacity, versus 60% of full capacity for prior art
units with no sequencing. In some situations, the number of power
drops required in a Data Center can thus be reduced with
substantial savings in monthly costs.
[0144] FIG. 9 represents a power distribution unit (PDU) embodiment
of the present invention, and is referred to herein by the general
reference numeral 900. The PDU 900 allows a personality module 902
to be installed for various kinds of control input/output
communication. For an Ethernet interface, a NetSilicon type NET+50
system-on-a-chip is preferred, otherwise a Philips Semiconductor
type P89C644 microcontroller could be used in personality module
902.
[0145] The PDU 900 further comprises an I2C peripheral board 904,
and a set of four IPM's 906, 908, 910, and 912. Such provide
sixteen power outlets altogether. A power supply 914 provides
+5-volt logic operating power, and a microcontroller with a serial
connection to an inter-IC control (I2C) bus 917. Such I2C-bus 917
preferably conforms to industry standards published by Philips
Semiconductor (The Netherlands). See,
www.semiconductor.philips.com. Philips Semiconductor type
microcontrollers are preferably used throughout PDU 900 because
I2C-bus interfaces are included.
[0146] A SENTRY-slave personality module 916 could be substituted
for personality module 902 and typically includes a Server
Technology, Inc. (Reno, Nev.) SENTRY-type interface and
functionality through a standard RJ12 jack. See, e.g., website at
www.servertech.com. A slave personality module 918 could be
substituted for personality module 902 and provides a daisy-chain
I2C interface and functionality through a standard RJ12 jack. A
terminal-server personality module 920 could be substituted for
personality module 902 and provides a display terminal interface,
e.g., via I2C through a standard RJ12 jack, or RS-232 serial on a
DIN connector. A network personality module 922 preferably provides
a hypertext transfer protocol (http) browser interface, e.g., via
100Base-T network interface and a CAT-5 connector. The on-board
microcontroller provides all these basic personalities through
changes in its programming, e.g., stored in EEPROM or Flash memory
devices. All of PDU 900 is preferably fully integrated, e.g.,
within power distribution outlet strip 100, in FIG. 1.
[0147] FIG. 10 illustrates an intelligent power module (IPT-IPM)
1000 and represents one way to implement IPT-IPM's 120-123 of FIG.
1; IPT-IPM's 220-223 of FIGS. 2A and 2B; IPT-IPM 300 of FIG. 3;
IPT-IPM 400 of FIG. 4; power controller boards 802, 804, and 806 of
FIG. 8; and, 4-port IPM's 906, 908, 910, and 912 of FIG. 9. The
IPT-IPM 1000 comprises an I2C microcontroller 1002 connected to
communicate on a daisy-chain I2C serial bus with in and out
connectors 1004 and 1006 An AC-Line input 1008, e.g., from IPT-PS
118 in FIG. 1, is independently switched under microcontroller
command to AC-Line output-1 1010, AC-Line output-2 1011, AC-Line
output-3 1012, and AC-Line output-4 1013. A set of four relays
(K1-K4) 1014-1017 provide normally open (NO) contacts 1018-1021.
DC-power to operate the relays is respectively provided by relay
power supplies 1022-1025. Optical-isolators 1026-1029 allow logic
level outputs from the microcontroller 1002 to operate the relays
in response to I2C commands received from the I2C-bus.
[0148] Similarly, optical-isolators 1030-1033 allow the presence of
AC-Line voltages at AC-Line output-1 1010, AC-Line output-2 1011,
AC-Line output-3 1012, and AC-Line output-4 1013, to be sensed by
logic level digital inputs to microcontroller 1002. These are read
as status and encoded onto the I2C-bus in response to read
commands. A local user is also provided with a LED indication
1034-1037 of the AC-Line outputs. A set of load sensors 1038-1041
sense any current flowing through the primaries of respective
isolation transformers 1042-1045. A logic level LS1-LS4 is
respectively provided to microcontroller 1002 to indicate if
current is flowing to the load.
[0149] In general, remote power management embodiments of the
present invention are configurable and scaleable. Such provides for
maximum fabricator flexibility in quickly configuring modular
components to meet specific customer requests without overly
burdening the manufacturing process. The following list of various
customer requirements can all be met with minimal hardware, and no
software changes: Vertical or Horizontal enclosure mounting;
Variable controllable outlet configurations (4, 8, 12 ,16
outlets/enclosure); Variable number of power input feed
configurations to support redundant power to critical network
equipment (up to 4 input feeds); Option of displaying one or more
input load currents on a dual 7-segment LED display(s); Ability to
reorient the enclosure without having to invert the 7-segment LED
display(s); Measuring per outlet load current for individual
appliance load reporting; and a Variety of user interfaces that can
be substituted at final product configuration time.
[0150] A modular component concept allows for communications and
automated detection of any included modular components over a
common communications channel. So a multi-drop, addressable, and
extensible bus architecture is used. The Inter-IC (I2C) bus
developed by Philips semiconductor is preferred. Each modular
component contains a microprocessor capable of interpreting and
responding to commands over I2C-bus. An application layer
enhancement on top of the standard I2C-protocol allows for data
integrity checking. A checksum is appended to all commands and
responses. Such checksum is validated before commands are acted
upon, and data responses are acknowledged. Each module on the I2C
power control bus has either a hard-coded or configurable address
to enable multiple components to communicate over the same two
wires that comprise the bus. Configuration jumpers on the power
supply module are used to select operational items, e.g., #Power
input feeds, #four port Intelligent Power Modules (IPM) attached to
each input feed, Input feed overload current threshold, and Display
inversion.
[0151] The main components used in most instances are the power
supply board (IPT-PS) that supplies DC voltage on the
interconnection bus, and monitors and reports input feed load and
enclosure configuration information; the intelligent power module
IPM (IPT-IPM) which controls the source of power to each outlet
based on I2C commands from the master controller personality module
(PM), and that reports whether the outlet is in the requested state
and the outlet load current back to the master controller; the
display board (IPT-I2C) used to display load current as supplied by
the master controller and to monitor user-requested resets, and
that can communicate with sensors attached to its Dallas
Semiconductor-type "1-wire" bus to the master controller; and, the
personality modules that act as an I2C-bus master, e.g., IPT-Serial
PM, IPT-Slave PM, and IPT-Network PM.
[0152] Such personality module can initialize, issue commands to,
and receive responses from the various components on the bus. It
also is responsible for executing user power control and
configuration requests, by issuing commands on the bus to the
various modules that perform these functions. These personality
modules support several user interfaces and can be swapped to
provide this functionality. The IPT-Serial PM is used for serial
only communications. The IPT-Slave PM is used to connect to an
earlier model controllers, and allows for a variety of user
interfaces, e.g., Telnet, Http, SNMP, serial, modem. The
IPT-Network PM has much of the same functionality as a previous
model controller, but has all that functionality contained on the
personality module itself and requires no external enclosure.
[0153] By combining and configuring these components, a variety of
power control products can be constructed in many different
enclosure forms, each with a variety of power input feed and outlet
arrangements.
[0154] Lower-cost power control products can be linked to a more
expensive master controller using an IPT-Network PM to configure a
large-scale power control network that needs only a single
IP-address and user interface. Such would require a high level,
high bandwidth, multi-drop communications protocol such as
industry-standard Controller Area Network (CAN). The CAN bus
supports 1-Mbit/sec data transfers over a distance of 40 meters.
This would enable serial sessions from a user to serial ports on
the device being controlled to be virtualized and thus avoid
needing costly analog switching circuitry and control logic.
[0155] Although the present invention has been described in terms
of the present embodiment, it is to be understood that the
disclosure is not to be interpreted as limiting. Various
alterations and modifications will no doubt become apparent to
those skilled in the art after having read the above disclosure.
Accordingly, it is intended that the appended claims be interpreted
as covering all alterations and modifications as fall within the
true spirit and scope of the invention.
* * * * *
References