Database
NTMC databases are managed centrally, by a single core component. The user
interface of that component is MCED, the NTMC database editor. Please see the
MCED User Guide for details on how to operate that component.
MCED is integrated through all NTMC components. In RUEX it gets invoked
whenever any of the configuration commands are
executed. The latter edit both, on-line,
and off-line database entries. When
on-line items are edited, appropriate managers also get notified of the
database changes. NTMC does not have to be restarted after such changes.
A small number of rarely used databases must be edited outside of RUEX, by
starting the MCED editor manually. The table below lists those databases, and
their purpose. In most cases below all NTMC components must be restarted for
changes to take effect.
| DATABASE |
DESCRIPTION |
| ColorsABCD |
NTMC component color schemes. ABCD stands for
MCEX, RUEX, LMEX, etc. |
| Holidays |
Holiday table. Automatic LMEX (Load Management)
functions are inactive on days of the year specified in this table. |
| NTMC |
Parameters common to all NTMC components.
Various file paths, computer host identifiers, etc. To be edited by
qualified personnel only. |
| Sound |
Sound effects that go with the various events,
such as startup, shutdown, important events, alarms, etc. They can be
enabled or disabled here. |
| StatusNames |
List of staus labels meant to identify the
various binary conditions in the system, such as ON, OFF, OPEN, CLOSED,
etc. The list built here appears in pull-down MCED menus when one edits
control point state ids for example. No need to restart NTMC. |
| UnitsOfMeasure |
Table of units of measure labels used
throughout the system in displays and reports, such as kWh, Amps, Volts,
etc. No need to restart NTMC. |
Any other databases that can be seen by starting MCED are are either not
meant to be edited off-line while NTMC is running, or are meant to be edited
by qualified BTE personnel only.
Remote Unit Polling
RUEX can be programmed to poll remote units automatically on a predefined
polling schedule. Remote units can also be polled manually. In either case,
I/O points, remote units, domains, and RUEX have to be set up appropriately.
I/O Point Setup
When a remote unit is polled, its manager first checks which I/O points
within the unit are to be involved. The manager then assembles an appropriate
message which is then sent out to the remote unit. The latter responds with
sought for data. For an I/O point to be involved in polling, first and
foremost, the point must be enabled.
In addition, the polling parameter
on that point must be enabled. It is essential, that the point
address is defined correctly.
Remote Unit Setup
Regardless of remote unit model, for the unit to be pollable by RUEX, I/O
points must be defined and configured properly (see above), and the unit's remote
client id assignment must be made. In addition, the unit's address must
also be defined. The latter comes in different forms depending on the unit
model. For RTUs, it is the RTU
address, for a PLC it is the PLC
Address, etc. If messages to the unit must be relayed, routing
must be set up, and appropriate route
must be assigned, after which the remote unit must be programmed.
When remote units are configured as described above they can be polled
manually. For the units to be polled on a scheduled basis, automatically by
RUEX, additional parameters must be defined. Remote unit manager
must be enabled, and so must be polling.
If one is dealing with a 'slow' input, bad calculation results may be
generated because of poor pulse counter numbers, for example. Minimum
polling period may have to be specified for the remote unit hosting that
input. The parameter specifies minimum interval, in seconds,
between automatic polls of that unit.
Domain Setup
In addition to the above, the following have to be properly defined for
automatic scheduled polling to be functional. Domain manager
must be enabled, and polling
must be enabled.
Failed Poll Repeating
parameter may have to be set to a positive value if communications are
intermittent, and polls fail occasionally. This minimizes data loss from
failed polls. This parameter should not be set too high, for the system will
waist too much time trying to retrieve data from a remote unit which is out of
order. Such remote units should be disabled
until their hardware counterparts are repaired or replaced.
RUEX Setup
In addition to the above, the following have to be properly defined for
automatic scheduled polling to be functional. RUEX manager
must be enabled, and polling must
be enabled.
In addition, system polling
periods and polling offset
from midnight must be defined. If RUEX alone is to control which polling
period is in effect, system polling period control authority
must be set to RUEX. In this case this
RUEX parameter determines polling period selection. Otherwise, the authority
parameter must be set to LMEX, in which case load management module is
to control polling period selection.
LMEX Data Input Domain
must be set to domain which contains remote units gathering data for the load
management module. This makes LMEX aware of executed polling cycles, and makes
it initiate its own processing cycles after each poll is completed.
CCEX Data Input Domain
must be set to domain which contains remote units gathering data for the
capacitor control module. This makes CCEX aware of executed polling cycles,
and makes it initiate its own processing cycles after each poll is completed.
Quiescent Reports
There are no parameters to set in RUEX with respect to quiescent reports.
IOEX server must be set up on the channel used for remote unit communications
- see the IOEX User Guide. In addition, remote units must be programmed
appropriately when deciding which quiescent reports they will generate.
When reports are data updates, RUEX updates database in the usual manner.
When a remote unit reports a problem, RUEX generates an alarm event entry,
recording as much information as possible.
Data Processing
One must decide for each I/O
point in the system whether:
- There is a real data point out in the field, and data has to be fetched
from it, or
- The point is a fictitious one, serving as a target of some computation.
For example, electric energy consumption is often measured by counting
pulses generated by a metering device. In RUEX, one can set up a pulse counter
which receives data from the counterpart in the field (type 1 above), and an
analog point, which is used to store kW numbers computed from the counter
(type 2 above). The analog point is fictitious in the sense that there is no
real world counterpart in the field.
For type 1 points polling
must be Enabled, and Evaluator
Name parameter must be set to NONE.
For type 2 points polling
must be Disabled, and Evaluator
Name parameter must specify a valid Evaluator identifier. That evaluator
is used to evaluate the point's value.
When order in which I/O point values are evaluated is important, each
point's Evaluation Priority
parameter must be properly defined. The lower the value, the higher the
point's evaluation priority within the remote unit.
When order in which remote units are processed during evaluation cycles is
important, each unit's Evaluation
Priority parameter must be properly defined. The lower the value, the
higher the unit's evaluation priority within the domain.
When order in which domains are processed during evaluation cycles is
important, each domain's Evaluation
Priority parameter must be properly defined. The lower the value, the
higher the domain's overall evaluation priority.
Data Recording
Two kinds of data recording are supported: RURDR
and NTMCRDR. The difference is
mainly in how the data ends up in RUEX.
In case of RURDR, as the name
suggests, data recording is performed by remote units. That data is
periodically downloaded to RUEX in bulk quantities. For example, a remote unit
may be set up to record electric current every 15 minutes. The numbers are stored
in the unit's memory, and are downloaded once a day.
One can enable data recording on an individual
I/O point, or on all remote
unit channels. Data can be downloaded
manually, or on a scheduled basis by MREX. Downloaded data is stored in
raw form, or properly
rescaled, in NTMC data recording files.
In case of NTMCRDR, data
recording is performed by NTMC. Any data that comes in, be it as a result of a
poll, or quiescently, is stored in raw form, or properly
rescaled, in NTMC data recording files.
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 see MCDA
User Guide for details on MCDA usage.
Additionally, data can be analyzed by running reports in RUEX. Report
results end up in simple ASCII files which can be opened with any program of
choice (such as notepad, WordPad, Microsoft Word), printed out, etc. The files
end up in the directory
specified by the operator.
On RUEX level, the following reports are available: RUR
Parameter Downloads, Recent
Control Point AOT, Archived
Control Point AOT, Recent
Control Point States, and Archived
Control Point States.
On domain level, the following reports are available: Recent
Control Point AOT, Archived
Control Point AOT, Recent
Control Point States, and Archived
Control Point States.
On individual I/O point level, one can spawn MCDA and analyze I/O point
data individually.
Routes
For routing to work properly the following steps need to be taken.
First the system has to be analyzed to determine which, if any, remote
units are inaccessible to the master, and which remote units will serve as
communications repeaters.
Second, of all routes have to be defined in the RUEX route database. For
each route this is done by first defining
it, then populating it with route
links.
Next, all routes must be programmed
- this programs all route links so they know how to relay messages in the
future.
The last step is programming
of all route users - i.e.
programming of all directly inaccessible remote units to use above routes.
This step has to be done for each domain containing route users.
Remote Unit Programming
Remote unit programming
needs to be done whenever:
- A new remote unit database entry is made,
- A new remote unit is placed in the field, or when units swap
places,
- Changes are made to routes in any way - remote unit programming
must be done after routes have been re-programmed (see above),
- Remote unit addresses are changed,
- Remote unit communications parameters are changed.
|
Control Code Dispatching
RUEX can be programmed to operate remote switches in groups, as dictated by
application modules. Remote unit relays can also be operated manually. In either case,
control points, remote units, domains, and RUEX have to be set up appropriately.
Control Point Setup
When a remote unit relay is controlled its manager first assembles an appropriate
message which is then sent out to the remote unit. The latter operates the
target relay and, when able to respond, responds with a confirmation or
failure message. For a control point manager to be involved in any kind of
control code dispatching, the point
address must defined correctly. Fir the point to be operated
automatically, the point must be enabled,
and in automatic mode.
Remote Unit Setup
Regardless of remote unit model, for RUEX to be able to operate their
relays, I/O
points must be defined and configured properly (see above), and the unit's remote
client id assignment must be made. In addition, the unit's address must
also be defined. The latter comes in different forms depending on the unit
model. For RTUs it is the RTU
address, for a PLC it is the PLC
Address, etc. If messages to the unit must be relayed, routing
must be set up, and appropriate route
must be assigned, after which the remote unit must be programmed.
When remote units are configured as described above their relays can be
operated
manually. For automatic code dispatching remote unit manager
must also be enabled.
Domain Setup
In addition to the above, the domain manager
must be enabled, for automatic code dispatching to work properly.
When working with intermittent communications, or unreliable hardware
control codes may have to be repeated
once or twice to maximize success.
RUEX Setup
In addition to the above, the RUEX manager
must be enabled, for automatic code dispatching to work properly.
Timed Switch Management
For timed switch management to work, first and foremost, control code
dispatching must work - see above section.
To enable timed switch management, timed
switch manager must be Enabled. Also, the manager execution
period and update
period cushion must be defined properly. The latter can be set to 0 if
RUEX is not busy, otherwise it must be estimated by observing system
operations. When RUEX is busy and timed switch manager is delayed at times,
the size of those delays must be taken into account by setting the update
period cushion appropriately.
Timed control point time-out
periods must be properly defined so time switch manager knows how often to
send refresh codes to remote units hosting corresponding timed relays.
Another function of timed switch manager is to keep track of safety
timers. When the latter are used, timed switch manager checks on all
control points, and clears safety timers once they time out.
Clock Synchronization
For the function to work RUEX midnight
clock synchronization must be Enabled. In addition, at least one
remote units per communications channel utilized must have the manager
Enabled, and external
client id defined, as well as group
address usage Enabled, and proper group
address defined.
Auto Backup
For the function to work RUEX auto
backup must be Enabled. In addition, the backup
target directory must be defined, preferably residing on another computer,
or at least on a detachable drive. The number
of subdirectories (one gets created every day when files are backed up)
must also be defined. It is advisable to keep this number larger when
performing extensive system configuration changes. At other times it can be
kept at a minimum (2).
Events
Event logging is almost completely automated and needs almost no
adjustment. One of the few exceptions is control
point operation logging. Only audio portion of alarms
can be Disabled, but alarm events always get logged into event log
files. All events can be viewed and analyzed using MCEV.
Archiving
One has to periodically archive data and event logs. Both operations are
manually initiated by the operator.
Data archiving is initiated by executing the RUEX Archive
Data Recording Files command. The accumulating data files get appended to
the corresponding archives located in the RURDR
archive directory and the NTMCRDR
archive directory.
Event log archiving is initiated by executing the RUEX Archive
Event Log File command. The accumulating event log file gets copied to the
NTMC event log archive directory, common to all NTMC
components, and reset to empty.
Data recording files and event log file can be periodically
archived automatically if so desired. Care must be taken that archive
directory is always available and in the same place, otherwise archives are
scattered in different locations, and historical searches become inconvenient.
One-line Diagrams
In what follows it is assumed that a database of domains,
remote units, and I/O
points already exists.
To create a new display panel, proceed as follows:
- Execute the RUEX Panel à
New command.
- Place the new panel on-line.
- Display the new panel
in design mode.
- Execute the RUEX Panel à
Show Display Element Library command.
- Drag the desired display
elements from the library
into the panel window.
- Configure the display
elements as desired.
- Size display elements by dragging their edges until desired dimensions
and aspect ratios are achieved.
- Move display elements into their position by dragging them into proper
locations. Move the mouse, and / or press the keyboard arrow keys while
the left mouse button is depressed. The arrow keys are useful when
fine-positioning the objects in the panel window.
To map a display element onto another
panel:
- Display the panel which
contains display element of interest.
- Make certain that the target panel onto which display element is to be
mapped exists, and is on-line. If not, create that panel, and place it
on-line as described above.
- Right-click onto the display element.
- Select Configure, then Mapping.
- Set the 'Mapping Mode' parameter to Display Panel.
- Set the 'Child Panel Id' parameter to identify the target panel.
- Press Save + Exit.
To map a display element
onto an I/O
Point:
- Display the panel which
contains display element of interest.
- Make certain that the target I/O point onto which display element is to
be mapped exists, and is on-line. If not, create
that I/O point, and place it on-line.
- Right-click onto the display element.
- Select Configure, then Mapping.
- Set the 'Mapping Mode' parameter to I/O Point.
- Set the 'Domain Id' parameter to identify the target domain.
- Set the 'Remote Unit Id' parameter to identify the target remote
unit.
- Set the 'I/O Point Id' parameter to identify the target I/O
point.
- Press Save + Exit.
To crate a descriptor
which displays display
element properties:
- Display the panel of
interest in design mode.
- Click on Show Display Element Library in the RUEX Panel
menu.
- Drag the display element marked ABC into the panel window, and
place it next to (or onto) the display element to be labeled.
- Size and configure the
descriptor as desired. Change the
'Display Element Id' to some appropriate name. For example, if the display
element to be labeled is called 'Relay 3', call the descriptor 'Relay 3 Labels'.
- Associate the descriptor with the display element to be labeled as
described in the next section.
To associate a display element
with a descriptor:
- Display the panel which
contains display element of interest.
- Make certain that the target descriptor with which display element is to
be associated exists, and is on-line. If not, create the descriptor as
described in the previous section.
- Right-click onto the display element.
- Select Configure, then Mapping.
- Set the 'Descriptor Id' parameter to identify the target descriptor
(created in the previous section).
- Press Save + Exit.
| 