1.4.3 OpenBSI Time Synchronization ................................................................................. 13
2 Index ....................................................................................................................................... 14
Remote Automation Solutions
Website: www.EmersonProcess.com/Remote
Reference Guide
D5092
11-Dec-2007 - Page 3
NW3000 Administrator Guide
1 Network 3000 Administrator Guide
This documentation is primarily for System Administrators. It explains the configuration options that
can be used to modify and fine tune the default behaviour of OpenEnterprise with regard to Bristol
Babcock RTUs and their native driver software suite, OpenBSI.
Set up details for the OpenEnterprise NW3000 Database Builder, NW3000 Poll List Builder and the
NW3000 Driver (RDI300) are covered under the following headings:-
1. Database Build
2. Data Collection
3. NW3000 Driver
4. Time Zone Issues
Although targeted at System Administrators of OpenEnterprise SCADA systems, this documentation
does not attempt to fully explain the functionality and use of Network3000 or ControlWave RTUs
within OpenEnterprise.
1.1 Database Build
OpenEnterprise builds NW3000 and ControlWave signals and poll lists into the OpenEnterprise
database automatically using the NW3000 Database Builder (DBB) and Poll List (or Template)
Builder (TPB). This section deals with the set-up of the DBB and TPB generally and with regard to
remote alarms.
1.1.1 Configuring Post DBB and TPB Scripts
Both DataBase Builder (DBB) and Poll List Builder (TPB) can be optionally configured to run
customised scripts following a database or template build.
The intention is that these scripts are custom SQL statements to be run following a build. However,
anything can be run, not just SQL scripts.
The scripts to run are configured in the INI files DBB.INI and TPB.INI respectively. These files are
optional and should reside in the default Windows™ directory.
The following is an example DBB.INI file. The [postbuild] section specifies the default script details.
The [postbuild:<dataservice>] specifies the optional dataservice specific script details that override
those specified in the [postbuild] section. The 'visible' value makes the script run with desktop
interaction and should be considered as just a debug option when checking if the script has been
configured properly. Only the 'target' value is required.
In this example where DataBase Builder is connected to database "rtrdb1", DataBase Builder runs the
SQL Client which automatically loads the SQL file POSTDBB2.SQL, with output being captured in the
file DBB_SQL.TXT.
The TPB.INI file has an identical format to the DBB.INI file.
NW3000 Administrator Guide
1.1.2 Alarms
Device Failure alarm conditions enable the OpenEnterprise Database to flag an alarm should there be
any communication failure with the device.
Device status alarm conditions are automatically created when the DBB process creates a new
device. Entries are inserted into the nw3000DeviceStatusAlarmCondition table. The following
attributes are set as follows:
• Priority = 252 (where Priority is the alarm condition's priority).
• Condition = 9 (where 9 is a 'Change of State' condition type).
• Devicename = nw3000device.devicename (which is the RTU's devicename).
Device failure alarms use the alarm summary as follows, where <> denotes the value will be
substituted and | denotes a set of possible values.
Attribute
Name <devicename>
Description COMMUNICATIONS FAILURE <devicename>
Devicename <devicename>
Alarmtext <devicename> FAILED | OKAY
Value FAILED | OKAY
Eventtype COMMUNICATIONS STATUS
The automatic creation of device status alarm conditions will be inhibited if the poly.cfg resource
oe_nw3000_supress_status_alarms is set to TRUE. The default value of the resource is FALSE.
1.1.2.1 ACCOL Version Mismatch Alarm Conditions
When the DataBase Builder and TempPlate Builder processes are invoked they use the information
from the ACCOL load file found in the ACCOL directory on the OpenEnterprise Server.
If subsequently a new ACCOL file is downloaded to the RTU(s), then the OE Database will detect an
ACCOL version mismatch.
Values
Device status alarms include the annunciation of an Accol version mismatch for Network 3000
devices. When a version mismatch exists, template collection may fail and RBE collection will be less
efficient.
Remote Automation Solutions
Website: www.EmersonProcess.com/Remote
Reference Guide
D5092
11-Dec-2007 - Page 5
A correctly configured server should have both DBB and TPB running in monitor mode. If a version
mismatch occurs due to a download from the server, then DBB and TPB will automatically resolve the
mismatch.
Even so, version mismatches may still persist if ACCOL files have been downloaded locally at the
RTU. When this occurs the DBB will resolve the database MSD store from the RTU and then the TPB
will automatically rebuild the database template store.
However, because the OE Server does not have access to the new ACCOL load file, changes made
to the ACCOL signal configuration will not be changed in the OE Database. This will cause a
persistent version mismatch.
Therefore, when a device is inserted into the database (i.e. through the DBB process) optional
ACCOL version mismatch alarm conditions will be generated in the
nw3000DeviceStatusAlarmCondition table.
The automatic creation of ACCOL version mismatch alarm conditions will be inhibited if the poly.cfg
resource oe_nw3000_supress_version_alarms is set to TRUE. The default value of the resource is
FALSE.
1.1.2.2 Using the #PWRUP Remote Alarm
NW3000 Administrator Guide
The system can be configured to monitor for #PWRUP.000. remote alarms being generated by
NW3000 devices. The receipt of a #PWRUP alarm can optionally be used to generate one or more of
the following actions.
• Request to collect all templates for the NW3000 device.
• Request initial values for all RBE signals for the NW3000 device.
NOTE: This functionality only applies to a NW3000 device that generates a #PWRUP alarm while
OpenEnterprise believes that the NW3000 device is alive. Receiving a #PWRUP alarm from a
currently 'dead' NW3000 device does not result in any special #PWRUP logic being executed.
1.1.2.2.1 #PWRUP and Template Collection
The receipt of the #PWRUP alarm results in RDI 3000 requesting a template collection for all
templates configured for the appropriate RTU. This option is strongly advisable if the user is using
one-shot templates or slow collecting templates.
The EnablePWRUPTpls value is found on the OpenEnterprise\Tasks\RDI3000 key, and the option
is enabled by default. To disable the functionality, use the Settings Editor to set the value data to 0
(zero).
1.1.2.2.2 #PWRUP and RBE Initialization
The receipt of the #PWRUP results in the NW3000 RDI sending an initial values request for all RBE
values to the appropriate NW3000 device. This should not be necessary, as in most scenarios the
NW3000 device should generate a 'going active' message.
The EnablePWRUPRbe value is found on the OpenEnterprise\Tasks\RDI3000 key, and the option
is enabled by default. To disable the functionality, use the Settings Editor to set the value data to 0
(zero).
Remote Automation Solutions
Website: www.EmersonProcess.com/Remote
Loading...
+ 10 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.