|
Overview
Remote Unit Executive performs SCADA functions. It also serves as a
platform for higher level applications such as load management, capacitor
control, and automated
meter reading. While the latter deal strictly with application issues, such as
when to read a customer's meter, RUEX actually gets the job done by taking
care of issues such as database management, communications, protocols,
drivers, scheduling, and alike. RUEX is a powerful tool which can be set up in
many ways. It is up to the user to decide which of those ways are of interest
to him or her. Once configured RUEX runs unattended most of the time, except
for monitoring of events in the field, and occasional data archiving
chores. RUEX level configuration parameters affect all items managed by RUEX.
To do SCADA RUEX organizes its data as follows: RUEX maintains a list of one
or more domains. Each domain is a
collection of remote units
grouped into that domain for reasons selected by the user. This can be
functionality, geographic region, etc. Domain level parameters affect all remote
units within the domain, while remote unit level parameters affect all I/O
points within the remote unit.
Each remote unit is a collection of I/O
points. This organization reflects the fact that data inputs in the field
usually come via devices (remote units) capable of communication with the master
controller, such as NTMC. I/O point level parameters affect I/O points only.
To aid in data acquisition from remote units inaccessible because of distance
or obstructed line of sight, RUEX also maintains a list of routes.
Each route is a list of remote units which serve as message repeaters so
messages can be relayed to those inaccessible remote units.
Incoming data must be processed, and stored. While storage is a responsibility
of each individual I/O point manager, processing is handled by a list of evaluators
globally maintained by RUEX. Each I/O point which needs to process incoming data
before storing it is assigned an evaluator. Points which process data the same
way can be assigned one and the same evaluator. Modifying the latter affects all
points using that evaluator.
State of the system is presented in two ways: Listings and graphical
representation of remote units, and
one-line diagrams.
Database
Each of the above must be defined by the operator. This is a one time
process, most of which is done at the time of system installation. Subsequently
definitions usually get added or modified only when new devices are added to the
system, or when system changes are taken into account, such as changes in remote
unit model being used (new switch model, larger RTU, etc). Definition of each
item comes in two steps.
- First, a new database entry is made. This creates a record corresponding
to the item to be managed. For example, when one wants to communicate with an additional
remote unit, a new remote unit database entry is created. At that time, the
item is said to be off-line.
- Next, the new item has to be 'put on-line'. RUEX does not 'know' about the
new item until this step is performed. At that time RUEX verifies the type,
location, and integrity of the database entry. If all tests are passed RUEX
creates a manager of appropriate type. (For those familiar with modern
software engineering jargon, RUEX creates an object of appropriate class.)
From that time on RUEX 'knows' about that item and maintains it by calling
functions exposed by the manager. At that point the item said to be on-line.
Please click here to see how to
implement this.
Remote Unit Polling
Polling is periodic solicitation of data from remote units. Two polling
periods are available. The active polling period can be selected manually, or
automatically in which case one of the application modules decides which
polling period is in effect. All remote units can be on the same polling
schedule, or they can be on individual poling schedule.
Each polling cycle is followed by I/O point evaluation cycle, application
module notifications cycle, and computation of the next polling cycle time.
Please click here to see how to
implement this.
Quiescent Reports
Remote units can send unsolicited data to the master. Depending on the
programming of remote units this can be simple error condition reports (out of
power, battery low, analog point out of range), or regular periodic data
uploads to the master. In the case of the latter RUEX simply updates the
database as needed. In case of error reports RUEX also enters alarms into
appropriate event log entries.
Please click here to see how to
implement this.
Data Processing
Data may have to be processed after it comes to RUEX. Polled or
unsolicited, when data arrives it is first placed into the database.
Evaluation cycle first sorts all domains, remote units, and I/O points by
evaluation priorities specified by the operator. Evaluation manager then
proceeds down the sorted list of I/O points and evaluates them according to
each point's individual assigned evaluator. When no evaluator is assigned the
point's value is left unchanged.
After evaluation cycle RUEX notifies application modules of the presence of
new data. This triggers application module replication cycles (application
modules update their own databases with newly arrived data), and subsequent
application module activity cycles, whatever those may be. For example, LMEX
(the NTMC Load Management module) re-computes current demand values,
determines which loads (if any) need to be turned off or on, and instructs
RUEX to send out appropriate control codes.
Please click here to see how to
implement this.
Data Recording
Data gets recorded in several places. Databases keep only the most recent
data sufficient for displays of latest values and trends. Long term historical
data recording can be done in remote units themselves (RURDR),
and locally on the computer hard disk (NTMCRDR).
These 'current' data recording files need to be archived to a physically
different volume periodically, such as another hard drive, or a CD.
Please click here to see how to
implement this.
Data Analysis
Data recording files can be viewed, plotted, and analyzed by using MCDA.
Alternatively, data can be exported to spreadsheet programs for more end-user
custom analysis.
Please click here to see how to
implement this.
Routing
To aid in data acquisition from remote units inaccessible because of distance
or obstructed line of sight, RUEX also maintains a list of routes.
Each route is a list of remote units which serve as message repeaters so
messages can be relayed to those inaccessible remote units.
Routes can consists of as few one repeater, to as many as ten repeaters, and
can contain branches.
Please click here to see how to
implement this.
Remote Unit Programming
Remote units need to be programmed in order to work as desired. RUEX uploads
programming information to remote units when requested by the operator. The
information uploaded depends on remote unit in question, but the general nature
of these parameters is communication timing and delays, route tables, etc. In
case of routes, for example, each route
link needs to be programmed with appropriate route table entries
(essentially lists of addresses so the unit knows who to forward messages), and
each route user needs to be
programmed with return address it needs to use to respond to polls - the
unit can not respond directly to the master, otherwise there would be no
need to use a route to talk to that remote unit.
Please click here to see how to
implement this.
Control Code Dispatching
Control code dispatching means sending out messages to remote units
to operate their relays. Remote units can be single relay switches, or
multiple relay RTUs, control registers on PLCs, etc. Operation failures
must be detected, and provisions must be made for error reporting and
recovery. When remote units are 2-way, and are able to report failures, RUEX
needs to be able to retry operations if programmed that way. If repeat
operations clear the problem, RUEX control code dispatcher can move on to the
next task, otherwise proper events must be logged, and proper alarms raised to
attract operator's attention.
Please click here to see how to
implement this.
Timed Switch Management
Timed switches are switches which, when operated (usually to open state),
return to their original (usually closed) state after their respective
pre-programmed timeout periods. To keep such switches in open state one has to
refresh them periodically. Timed switch manager maintains a record of all
timed switches' timeout periods, when they were last turned off, and sends out
appropriately timed control codes to keep them off. Higher level application
modules, such as load management, therefore do not have to worry about this
function. Load management module simply declares a switch to be off and
assumes this will be so until it decides to turn it back on. How that switch
is kept off is not its concern.
Timed switch manager also performs other timer related switch functions.
One example are security timers. RUEX enforces security timer rules when
latched switches operating capacitor banks do not have built in security
timers. It is not advisable to put a capacitor bank back on-line right after
it was taken off-line. Doing so may damage the capacitor. Security timers
prevent CCEX, the RUEX capacitor control module from automatically placing
such capacitor banks on-line prematurely. When such banks are operated
manually RUEX issues a warning prompt which enables the operator to abort the
intended operation, or bypass the warning with another push button.
Please click here to see how to
implement this.
Clock Synchronization
RUEX sends a messages to all remote units which synchronizes their clocks
with that of the computer hosting NTMC. These messages is sent once per
day, using group addresses, via every configured communications channel to all
remote units which support this feature. Clock synchronization is important
when remote units are involved in RURDR
- downloaded data must have correct
time stamps.
Please click here to see how to
implement this.
Auto Backup
RUEX backs up all its files automatically, once a day, when this function
is enabled. This includes all executable files, databases, and co-resident
data recording files accumulating at that time. RUEX does not back up
archived data recording files stored elsewhere on the computer (for example,
on a ZIP disk), or the LAN. It is
the user's responsibility to back those files up after each archiving
operation.
Please click here to see how to
implement this.
Events
Event recording is an important function of all NTMC components. Each
component maintains an event log which can be viewed and analyzed with MCEV.
Many kinds of events are recorded, from activities such as switch operations
and data downloads, to system problems, such as non-reporting remote units, to
software errors. Each log entry includes additional information such as the
sub-system that generated the entry, and exact line in source code responsible
for the entry. This helps speed up system debugging, be it end-user system
problems, or software malfunctions.
Please click here to see how to
implement this.
Archiving
All data recording files and event logs fill up after a while, and must be
archived to a separate location, either on the same computer, or elsewhere on
the LAN. This is done manually by
the operator who executes archiving commands. Two kinds of information get
archived: data recorded from remote units, and event logs. RUEX does not
back up archived data recording files stored elsewhere on the computer (for
example, on a ZIP disk), or the LAN.
It is the user's responsibility to back those files up after each archiving
operation.
Please click here to see how to
implement this.
One-line Diagrams
One of important SCADA functions is presentation of the system in
graphical form. To accomplish this RUEX offers two ways: Listings and
graphical representation of remote
units, and one-line
diagrams. The latter allows the operator to
graphically draw the system being monitored, and map the components to the
database of I/O points. This makes it possible to model the monitored system
graphically, and view its state in real time.
One-line diagrams of the system are created by defining display panels.
One first defines one top level display panel which shows the entire monitored
system. The display is assembled from a library of available display
elements.
Small or simple systems can be shown in their entirety in one panel. Larger
systems must be displayed in pieces, or 'subsystems'. This is where layering
comes in. The top level display panel shows highest level subsystems. By
clicking on any of those subsystems one goes to a lower layer, and displays
that subsystem by opening another display panel. And so on, until one reaches
the bottom layers where all display elements represent the basic building
blocks, such as cables, relays, capacitor banks, etc. The number of layers
needed to describe the whole system depends on the size and complexity of the
system, and the size, and number of available display monitors.
Special display elements, called descriptors, can be associated with other
display elements to provide labeling and alpha-numeric displays. One can show
arbitrary strings, display element identifiers, I/O point identifiers, I/O
point values, their status, and alarms.
Panels can be displayed in monitor and design modes. Monitor mode is where
display panels are observed, monitored, used for control operations, etc.
Design mode is used for panel design and modifications. The latter includes
additions of new display elements, removal of obsolete elements, recording of
changes in monitored circuit topology, etc.
A special window, called Display Element
Library, is available in design
mode only. The library includes all display elements available to the
user for use in modeling his system, such as cables, relays, capacitor banks,
etc. Display elements are dragged from the library window onto the panel being
constructed. The panel must be in design mode.
Please click here to see how to
implement this.
| 