User guide

US 8,549,067 B2
11
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”.
An absolute identi?er 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] {#} [#]”.
The ?rst 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., “.({A§ Z}[A§ D]{1§16}”. The input feed ID Was
optional. If not speci?ed, “A” Was assumed. With an absolute
ID scheme, a 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 speci?ed With just a period and
letter. An input feed ID could be speci?ed With a period and
tWo letters.
Existing outlets Were determined by reading the poWer
supply I/ O port of the master and slave vertical poWer man
ager. 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 admin
istrative privileges exist. Additional users could be created or
removed. Administrative privileges could be given to or
removed from added users.
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 adminis
trative privileges to be given or taken aWay Without affecting
the users outlet and group tables.
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-de?ned outlet and groups
names Were unique. This Were enforced at the time names
Were de?ned by the user. All user-de?ned 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 de?ned by the user. Usemames 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.
When an ADMN user speci?es “ALL” it means all cur
rently 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 “all” to refer to all groups.
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.
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-i. Outlet names
couldbe up to 24-characters. These Were stored and displayed
case-sensitive, but Were compared case-insensitive as com
20
25
30
35
40
45
50
60
12
mand 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-de?ned. This Were stored and displayed case-sensi
tive, but Was compared case-insensitive as a commandparam
eter. A 32-character location name could be user-de?ned.
This Were stored and displayed case-sensitive. Usernames
could be 1-16 characters, and Were case-insensitive, Pass
Words 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
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-Ol 0110-000x 0x60
IPM-02 0110-001x 0x62
IPM-03 0110-010x 0x64
IPM-04 0110-011x 0x66
IPM-OS 0110-100x 0x68
IPM-06 0110-101x 0x6A
IPM-07 0110-110x 0x6C
IPM-08 0110-111x 0x6E
IPM-09 0111-000x 0x70
IPM-lO 0111-001x 0x72
IPM-ll 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
The prototype required several major softWare compo
nents to be constructed for use With the NetSilicon NET+50
device. The con?guration 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 con?guration control blocks Were Written by the
user interface tasks. When the con?guration control blocks
Were modi?ed, the modi?cations Were mirrored in EEPROM
Where copies of these control blocks Were stored. The opera
tional 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.
The major design tasks for the prototype included design
ing 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 extem user interface (button/LED)
control task, and the WEB control task.