Bristol BSAP/IBP Driver

Not counted towards your tag license limit.

The Bristol driver enables communications between VTScada and Bristol RTUs using the serial BSAP protocol and Ethernet-based IBP protocol.

This driver defines the connections to each individual RTU that VTScada will communicate with. There will be one Bristol Driver tag for each unique RTU that VTScada will communicate with or pass data through. When configuring Bristol Driver tags, the individual driver tags must correctly reference their associated Network Tag and the Driver tag of the RTU acting as its network master (in serial networks) to route messages correctly. To simplify the tag configuration, the Bristol Network and Bristol Drivers can be arranged into a tree structure that mimics the physical arrangement of the RTUs in their communication infrastructure. The following section contains a number of configuration examples showing physical arrangements of RTUs and their associated VTScada Port, Network, and Driver tags.

Related information:

Bristol Network Tags

Ethernet to Serial Converters - Troubleshooting.

Configuration Examples

The Bristol driver tags allow communication with several distinct RTU configurations as described in the fol-lowing sections.

BSAP Serial Networks

The Bristol Driver can communicate with multi-level serial networks as shown in the following figure using the BSAP protocol option. For this network setups, create a single Bristol Network tag and a single port tag to represent the entire network and one Bristol Driver tag for each RTU.

BSAP serial network

For the example shown, the following tag tree will automatically implement the correct network and driver message routing. Note that each level of RTUs is nested below the node in the tag tree that acts as a store and forward node in the physical configuration.

Tag tree for the serial example

IBP Ethernet Networks

The Bristol Driver can communicate with Ethernet LAN/WAN connected RTU networks as shown in the following figure using the IBP protocol option. For this network setup, create a port tag and a Bristol Network tag for each RTU, along with a Bristol Driver tag for each RTU.

Ethernet LAN/WAN using IBP

For the example shown, the following tag tree will automatically implement the correct network and driver message routing. Note the difference from the previous example – each RTU connected to the Ethernet LAN will require its own port tag, its own network tag, and its own driver tag. The reason each requires its own Network tag should become clear in the next example.

Tag tree for Ethernet LAN/WAN example

Mixed Networks

The Bristol Driver can communicate with RTUs connected to "mixed" Ethernet LAN/WAN and BSAP serial networks as shown in the following figure using the IBP protocol option. For this network setup, create a port tag and a Bristol Network tag for each Ethernet connected RTU, along with a Bristol Driver tag for each RTU regardless of how it’s connected.

Mixed IBP & BSAP

For the example shown, the following tag tree will automatically implement the correct network and driver message routing. Note the difference from the previous example – each Ethernet connected RTU still has its own Network tag but all RTU connected serially to that RTU use the same network tag.

Tag Tree for Mixed Example

Bristol Driver properties ID tab

The ID tab of every tag includes the same common elements: Name, Area, Description, and Help ID.

Name:

Uniquely identifies each tag in the application. If the tag is a child of another, the parent names will be displayed in a separate area before the name field.

You may right-click on the tag's name to add or remove a conditional start expression.

Area

The area field is used to group similar tags together. By defining an area, you make it possible to:

Filter for particular tag groups when searching in the tag browser
Link dial-out alarm rosters to Alarm tags having a particular area
Limit the number of tags loaded upon startup.
Filter the alarm display to show only certain areas.
Filter tag selection by area when building reports

When working with Parent-Child tag structures, the area property of all child tags will automatically match the configured area of a parent. Naturally, you can change any tag's area as required. In the case of a child tag, the field background will turn yellow to indicate that you have applied an override. (Orange in the case of user-defined types. Refer to Configuration Field Colors)

To use the area field effectively, you might consider setting the same Area for each I/O driver and its related I/O tags to group all the tags representing the equipment processes installed at each I/O device. You might also consider naming the Area property for the physical location of the tag (i.e. a station or name of a landmark near the location of the I/O device). For serial port or Roster tags, you might configure the Area property according to the purpose of each tag, such as System or Communications.

You may define as many areas as you wish and you may leave the area blank for some tags (note that for Modem tags that are to be used with the Alarm Notification System, it is actually required that the area field be left blank).

To define a new area, type the name in the field. It will immediately be added. To use an existing area, use the drop-down list feature. Re-typing an existing area name is not recommended since a typo or misspelling will result in a second area being created.

There is no tool to remove an area name from VTScada since such a tool is unnecessary. An area definition will exist as long as any tag uses it and will stop existing when no tag uses it (following the next re-start).

Description

Tag names tend to be brief. The description field provides a way to give each tag a human-friendly note describing its purpose. While not mandatory, the description is highly recommended.

Tag descriptions are displayed in the tag browser, in the list of tags to be selected for a report and also on-screen when the operator holds the pointer over the tag’s widget. For installations that use the Alarm Notification System, the description will be spoken when identifying the tag that caused the alarm.

The description field will store up to 65,500 characters, but this will exceed the practical limits of what can be displayed on-screen.

This note is relevant only to those with a multilingual user interface:
When editing any textual parameter (description, area, engineering units...) always work in the phrase editor. Any changes made directly to the textual parameter will result in a new phrase being created rather than the existing phrase being changed.
In a unilingual application this makes no difference, but in a multilingual application it is regarded as poor practice.

Help Search Key

Used only by those who have created their own CHM-format context sensitive help files to accompany their application. Refer to Custom Help Files

Bristol Driver properties Communication tab

Local Address

Local address of the RTU (1 - 127).

Global Address

Global address of the RTU. This value calculated automatically by the driver based on the associated Network tag’s NRT and the position of the RTU in the network tree.

Data Read Time Limit

The time limit in seconds to get a response from an RTU. This value will get progressively longer as the network nesting level of the RTU increases and must take into account the baud rates, the polling rates, the number of RTUs on the intervening networks, etc. Refer to Bristol documentation for information on expected delay times to get responses to messages on multilevel networks.

Retries

The number of times to retry a message before declaring an error.

Use only if the driver is connected to a device that uses a serial port or a UDP/IP port that is configured to be polled. When connected directly to a device using TCP/IP, this value should normally be set to 0 since TCP/IP is a guaranteed message delivery protocol.
For unreliable communications, such as radio, set to 3 or 4.

Hold

Select this to have I/O tags attached to the driver hold their last value in the event of a communication failure. If not selected, tags will have their value set to invalid on a communication failure.

Store Last Output Values

When selected, the driver will maintain a record of the last value written to each output address. This may be useful in at least two situations:

For hardware that does not maintain its state during a power loss and must be restored to that state when re-started.
When failed hardware is replaced by a new device and you would like to start that device with the values last written to the old one.

If the last output values are stored, they may be re-written by either of two methods:

Automatically, when communication is restored to the device.
Manually by way of a button press. See, Rewrite Outputs Widget for details.

Changing this value from selected to deselected will cause all stored values to be erased immediately.

If this driver is being used in conjunction with a Driver Multiplexer, then configure the Driver Multiplexer to store the last values, not the drivers connected to the Multiplexer. In this case, only the Multiplexer should be configured to re-write automatically.

Auto Read All RTU Signal Data

All communication between VTScada and Bristol RTUs is performed using the MSD numbers of the signals in the RTUs database. On initial startup, VTScada must communicate with the RTU to determine the MSD numbers for each signal to be read or written but by default only requests the MSD numbers for the specific signals that its interested in (i.e. the signals in the Input and Output tags). By selecting this option, the driver will automatically read all MSDs and signal names from the RTU whenever there is a request to read the needed MSD information. The data is then available for easy selection of the proper signals using the address picker tool on input and output tags for the driver. Note that this information is only read on an as needed basis – after it is read, it is stored to disk by VTScada and is still available on a system restart.

Long Names

Select when using ControlWave devices with firmware version 2.2 and higher to allow for longer tag names.

Enable Auto Rewrite

If selected, the Store Last Output Values option will also be activated. This option causes the driver to rewrite the last value written to each output, in the event that communications are lost and then restored.

Use this option only if you are certain that you want the last values to be rewritten automatically after an interruption in driver communications.

Delete Audit Log On Read

Select this flag to automatically delete the audit log entries from the RTU as they are read by the driver. By default, the log entries are not deleted and the driver keeps track of the last information read. The driver only reads the values that have been added to the audit log since the last read.

Bristol Driver properties Network tab

Bristol Network Tag

This is the Bristol Network tag that RTU is defined to be a part of. It can be defined explicitly as any Bristol Network tag configured in your tag configuration. If not defined explicitly, the driver will look up through the tag tree and use the first Bristol Network tag it finds as its network.

Master RTU Bristol Driver Tag

This is the Bristol Driver tag for the RTU that acts as the network master for this RTU. This tag is used by driver to determine its position in the network tree hierarchy and from that to calculate its global address.

The Master RTU can be defined explicitly as any Bristol Driver tag configured in your tag configuration. If not defined explicitly, the driver will look up through the tag tree and use the first Bristol Driver tag it finds as its Master RTU.

When configuring level 1 RTUs connected directly to the VTScada server with no intermediate RTUs, this tag must not be defined.

Enable Time Synch

Select this option to enable sending periodic time synchronization messages to the RTU. Note that this only applies to Level 1 RTUs – after the time is sent to these devices it is automatically propagated to all network levels beneath the RTU it is sent to.

Time Synch Frequency

The rate (in seconds) to send the time synchronization to the RTU. This value is only used if "Enable Time Synch" is selected and if the RTU is a level 1 device.

Bristol Driver properties Alarms Tab

Alarms and Events generated by the RTU can be processed and added to the VTScada alarm system using the settings on this dialog tab. All alarms & events received from the RTU and stored in the VTScada alarm manager are registered to the driver. In cases where the events have not cleared properly, the "Purge" control can be used to delete any and all alarms in the alarm manager associated with this RTU.

Handle Device Alarms

Select this option to enable the processing of alarms and sending of acknowledgments by the driver. For Ethernet-connected RTUs, the driver will send an alarm NAK message in response to any received alarms if this option is not enabled or an alarm ACK message if it is enabled.

If a Bristol device produces alarms, this option should be selected. Failure to process the alarms can interrupt normal communication with the device and prevent VTScada from reading current values and sending control outputs.

Record Device Alarms in VTScada

If alarm handling is enabled in the driver, this option allows you to then report received alarms and events from the RTU using the VTScada alarm manager.

Priority for "Events"

Sets the VTScada alarm manager priority for "Events" messages received from the RTU.

Priority for "OP Guide"

Sets the VTScada alarm manager priority for "OP Guide" messages received from the RTU.

Priority for "Non Critical"

Sets the VTScada alarm manager priority for "Non Critical" messages received from the RTU.

Priority for "Critical"

Sets the VTScada alarm manager priority for "Critical" messages received from the RTU.