User guide

US 8,549,067 B2
13
The major software components developed for the proto
type are listed in the following Tables.
SenINIT —— SENTRY initialization procedure. This software was
the ?rst SENTRY software that executes. It performs hardware,
software (builds the Con?guration and Operational global
control blocks), and OS initialization. This code spawns the
SENTRY operational tasks that provide the system services.
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.
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.
TskFTP -- One instance of this task was spawned to listen for
FTP connections. The function of this task was to provide
?eld software updates for the system. The mechanism used was
determined based on the developer kit capabilities.
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.
TskI2C —— There were two versions of this task; the local
version that controls internal 12C connections and the global
version that controls external 12C connections. For the ?rst
implementation there were two instances of this task, one to
control the single 12C internal connection and one to control
the single 12C external connection. These tasks implement the
protocol for communicating control requests from the system to
the 12C 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.
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 12C task (internal or external) using
20
25
30
35
40
45
50
55
60
65
14
-continued
signals or messages. This task receives status updates from
the 12C tasks via signals or messages. TskPCntl “owns” the
IPMO and PCRO arrays and it updates the status ?elds in
entries in these arrays as necessary.
TskEUI —— This was the external user interface task that
handles the push button ?lHCtlOHS 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.
TskUSR —— This command line user interface task was spawned by
TskSER and TskTELNET when a user connection was detected. This
task veri?es 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.
TskSYS —— This was the general system task. Speci?c functions
for this task were de?ned as development progressed.
The control blocks were globally addressable by all soft
ware 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 con?guration data and was only changed
as a result of con?guration updates. The data was mostly
static and was written during initialization and when con?gu
ration 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 con?guration control blocks as illustrated below. The
following Tables describe each control block structure used in
the prototype.
SENTRY Con?guration Table (SCT) —— This control block
contains global con?guration information. There was a single
instance ofthis control block.
Username/Password Array (UNP) —— This was an array of control
blocks with each entry representing a user de?ned 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.