| |
[User Guide]
Remote Unit Executive
is responsible
for executing NTMC SCADA functions. These include remote unit
database management, dispatching of control codes, polling of remote units,
proper evaluation of incoming data, system status displays, etc. RUEX also serves as an
operating system for higher level application modules, such as load management,
capacitor control, etc., as shown in the figure below. The following sections
summarize the program’s most important activities.
I/O Points
The program supports six
types of I/O points: status points, counters, analog points, latching control
points, timed control points, and momentary control points. Each can be
configured individually, and each must be associated with a remoter unit.
Remote Units
At the time of this writing RUEX can support remote units (RTUs, switches, PLCs,
meters, etc.) capable of communicating via industry standard protocols such as MODBUS
RTU or DNP 3.0, as well as a host of native protocols. In general, BTE can implement any protocol which has a
published specification, or any proprietary protocol whose vendor is willing to
share it on a case by case basis.
Domains
Domains are collections of
remote units. The latter can be grouped together based on their geographic
location, purpose, functionality, etc.
Data Evaluation
Incoming data must be
properly stored and made available for calculations. For example, to calculate a
transmission line power factor one must know power demand, and reactive power on
that line. RUEX provides a mathematical manipulation facility enabling system
administrators to enter mathematical equations which correctly map onto the
relevant I/O points in the database. This means that inputs and outputs of any
calculation can be I/O points anywhere in the database, and thus anywhere in the
system.
Event Logging
RUEX logs all events to
its log file which can be reviewed, analyzed, or printed at any time using MCEV,
the NTMC Event Viewer (See the MCEV brochure). Regular events such
as component startup and shutdown, system configuration changes, alarm
acknowledgements, and control point operations are logged, as well as alarms
such as non-reporting remote units, analog point value threshold crossings, etc.
Quiescent reports from remote units, and any external system reconfiguration
requests are also recorded. The working log file can be archived to a
predetermined target, such as a local area network drive at any time. If the log
file fills up and the operator is not interested in very old events, new log
entries automatically overwrite the oldest ones.
System Status Displays
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. An example of the first is displayed in the caption below,
showing a domain window
representing substations being polled by an NTMC at a rural public
power district.
One-line diagrams allow operators 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. A simple example is shown in the
figure below.
Data Displays
Remote unit domains can be displayed in windows showing two dimensional views, or as lists of remote units. Each remote unit gets its
own window such as the one below, where every I/O point associated with the unit
is displayed as shown. Analog points show trending diagrams in addition to
numeric values and value range indicators. More detailed data displays can be
obtained by viewing data recording files (see below).
Data Recording
Values of all or selected I/O points can be stored in individual
data recording files which get updated after every polling cycle. This is called
NTMC Resident Data Recording, or NTMCRDR. When using remote units
capable of data recording, RUEX is capable of downloading those data into data recording
files of the same format. This is called RURDR. Data originating from both types
of data recording can be viewed, analyzed, printed, and exported using MCDA, the NTMC
Data Analyzer.
Configuration Editing
RUEX configuration editing is done by using MCED, the NTMC
Configuration Editor. There are four levels of parameters. The highest are those
of RUEX itself. One level lower are domain parameters. These sets of parameters
are the same for each domain. One step lower are the remote unit parameters. In
this case parameter sets differ depending on the type of remote unit concerned.
The lowest level of configuration is found on I/O point level. Every such point
has a set of parameters relevant to its nature. For example, one of parameters
describing a timed control point is the point’s timeout period, while an
analog point has a parameter specifying a ‘high’ value threshold. In
addition to the above, MCED is responsible for displays and editing of all other
databases and configuration files, such as those governing communications
parameters, one line diagrams, client color tables, etc.
Remote Unit Programming
RUEX can be used to program remote units. Information uploaded to a
particular unit depends on the unit’s model, and on the overall RUEX
configuration. Data being uploaded can include routing information (see below),
control point operation sampling time (2-way load management capable RTUs), time
of day, RURDR parameters (see Data Recording section above), radio
transmitter timing parameters,
switch address programming, etc.
Routing
One of communications media
used by NTMC systems is radio. The latter is popular where other
types of media are not available, or are economically unfeasible. In such cases
NTMC systems can cover large geographic areas where some of the
remote units can not be reached directly by the master transmitter. NTMC,
in conjunction with RTUs capable of routing messages, fully supports routing whereby some
remote units can be used as communications repeaters. RUEX provides simple tools
for building routing databases, and programming of relevant RTUs with routing
information.
Timed Switch Support
Timed switches must be refreshed periodically to preserve their intended states.
Timeout periods vary from model to model. RUEX contains a timed switch manager
which sends refresh codes to timed switches as needed. Furthermore, depending on
other activities of the system, one must make certain that those refresh codes
really go out in time. The timed switch manager allows entry of a ‘padding’
period which gets subtracted from each switch’s timeout period thereby
ensuring that control codes go out on time even when execution of timed switch
manager is occasionally delayed by other RUEX activities.
Automatic Backup
RUEX backs up all
system files automatically every midnight onto an operator designated target.
The latter can be a disk in a Zip drive, or a directory on a local area network.
Multiple backup directories can be maintained. This allows recovery of the
system from an older backup in case the latest backup failed, or some of the
later backups are known to be bad.
RUEX Demo
shows RUEX polling remote
units. Click here to view it. The file is
large (500K), so it may take a while to load if using a dialup modem. Use the browser Back
button to come back to this page.
|
