BACnet Driver

Not counted towards your tag license limit.

The BACnet driver follows the American Society of Heating, Refrigerating and Air Conditioning Engineers (ASHRAE) standard protocol document ANSI/ASHRAE Standard 135-2012 (Supersedes ANSI/ASHRAE Standard 135-2010) entitled, "BACnet - A Data Communication Protocol for Building Automation and Control Networks".

The driver was written using this standard as a protocol reference and supports protocol version 1.14. The protocol follows the seven-layer, Open Systems Interconnection (OSI) Basic Reference Model, in which each layer communicates with the immediately adjacent layer or layers.

The seven-layer OSI model:

Application Layer

Presentation Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer

Not all of these layers are required for the BACnet protocol implementation, therefore the layer diagram can be condensed as follows:

BACnet Layers
BACnet Application Layer
BACnet Network Layer
ISO 8802-2 (IEEE 802.2) Type 1		MS/TP	PTP	LonTalk	BVLL	BZLL
ISO 8802-3 (IEEE 802.3)	ARCNET	EIA-485	EIA-232	LonTalk	UDP/IP	ZigBee

Equivalent OSI Layers
Application Layer
Network Layer
Data Link Layer
Physical Layer

Supported Data Links

The VTScada BACnet communications driver supports two of the most common and useful data link and physical layers (highlighted with red in the preceding table), which are:

BACnet Virtual Link Layer over User Datagram Protocol/Internet Protocol (more commonly known as BVLL over UDP/IP or BACnet/IP).
Master / Slave Token Passing over EIA-485 (more commonly known as MS/TP over RS-485 serial).

Support for MS/TP data link is achieved through foreign network routing.

BACnet/IP

Requires the use of an UDP/IP port.

BACnet/IP is the recommended data link and protocol for most situations. Using this option of the driver, turnaround times (time from control action to control feedback) are typically less than a second. The device address is an IP address, which allows a multitude of possible stations. Additionally, the Ethernet network used for the BACnet/IP communications can be a dedicated network or it can use your existing Ethernet in order to reduce cost and complexity.

MS/TP

The driver supports the MS/TP Data Link over serial RS-485. This would be present in older installations or installations that do not require fast update times. Under this protocol, a "token" is passed around the serial RS-485 network and only the station or device holding the token is allowed to initiate communications. Due to the nature of the token-passing protocol, it can take several seconds for a control action to be seen back at the control point.

MS/TP is designed to support serial RS-485 speeds of up to 115200 baud, and up to 255 stations or devices in the same network. Addresses 0 to 127 are valid for both master and slave nodes. Addresses 128 to 254 are valid only for slave nodes. The possible baud rates, both required and optional, and the maximum communication distances are shown in the following table:

Baud Rate	Requirement	Recommended Maximum Distance
9600	Required	1200 meters (4000 feet)
19200	Optional	1200 meters (4000 feet)
38400	Required	1200 meters (4000 feet)
57600	Optional	1200 meters (4000 feet)
76800	Optional	1200 meters (4000 feet)
115200	Optional	1000 meters (3280 feet)

The current design model of PC software and hardware prevents a reliable implementation of direct connections to MS/TP networks. This is because the timing requirements can easily exceed the microsecond range, which may be too fast for the task-switching mechanism of modern operating systems. Moreover, systems with many drivers running in parallel can fail to achieve the minimum timing requirements for any baud rate. Using a remote port server through an IP link considerably worsens the situation, as it adds a lag between the generation of the network layer messages and the actual transmission to the media, as well as may fragment packets in a way that exceeds the framing demands of the protocol. Therefore, MS/TP communications are only available through foreign network routing.

Foreign Network Routing

BACnet supports a routing system alternative to the one used by higher-layer protocols (such as UDP/IP). It is based on the use of specially designed devices called BACnet routers. They are intended to interconnect two or more BACnet networks to form a BACnet internetwork. Different networks can use different data links and technologies, as long they are supported by both the BACnet standard and the router network being used.

To enable routing, an option other than "Local Network" must be selected on the Network Type drop list, on the Device tab. This will define the type of the network where the destination device is located, hence the way the MAC address of said device will be encoded in the message. VTScada communicates with the router through the parameters defined on the UDP/IP port attached to the driver. Therefore, both the router and the destination device must be compatible with one of the two data links that VTScada supports (BACnet/IP and MS/TP).

A typical network structure:

All numbers shown here are examples and may not work with your configuration. Refer to your device documentation rather than copying these.

While many other combinations are possible, this shows the typical scenario for a VTScada application. More information may be obtained at http://www.bacnet.org.

Because PC software and hardware evolved in a way that favors the concentration of all communications in a single IP-based link, using a BACnet router to manage low-level serial communications with compatible devices provides a much simpler and more reliable configuration. From VTScada’s perspective, all devices will be seen as BACnet/IP devices, even though MS/TP devices will share a single UDP/IP port and address, and still rely on a typically slower media.

To use the configuration shown on the diagram, four BACnet drivers are required, configured as follows:

Numbers shown in the following tables are examples.
Refer to the hardware documentation for your device rather than copying these values.

	BACnet/IP Device	MS/TP Device 1	MS/TP Device 2	MS/TP Device 3
Port	UDP Port 1	UDP Port 2	UDP Port 2	UDP Port 2
Device IP/Node	(Set by Port)	2	3	4
Network Type	Local	Foreign - MS/TP	Foreign - MS/TP	Foreign - MS/TP
Device Network #	-	2000	2000	2000
Local Network #	-	1000	1000	1000
Hop Count	-	1-255	1-255	1-255
Router IP	-	(Set by Port)	(Set by Port)	(Set by Port)

The two ports would be set with the following:

	UDP Port 1	UDP Port 2
UDP/IP Name/Address	10.1.1.3	10.1.1.2
Remote Port #	47808 (device-specific)	47808 (device-specific)
Local Port #	47808	47809

The local port numbers above are only an example. The standard BACnet port is 47808, but devices are required to support other ports as well. The intent of having a different local port for each connection is to prevent messages that should be routed to a specific driver from being read (and discarded) by another driver. The UDP port tag also offers the option: "Only accept datagrams from the configured remote port". By selecting this option, ports need only one out of the three parameters set differently in order to route messages properly. The MS/TP network node used by the router (1) is of no concern to this example, assuming that it doesn’t conflict with any other device located in the same network.

The BACnet router being used to connect to the foreign network does not need to be directly connected to the destination network or support the destination protocol, as long as it has a path to another router that provides a connection. Each router in the link will receive the message and attempt to discover the best path to the requested network. This will continue until either the device is reached, or the Hop Count reaches 0. Likewise, the response message (either successful or failed) will make its way back to the VTScada Station. Therefore, it’s important that the Timeout Limit be configured properly to allow enough time for the entire procedure.

Limitations

The driver currently supports basic I/O reading and writing of primitive types, including arrays of primitive items. More functionality is intended to be added throughout the next releases. Here is a list of current limitations and possible future enhancements:

Message segmentation and message security are not supported within the BACnet context. There is a "Segmented Messages Accepted" option on the configuration folder, but it is hard-coded to be permanently disabled, serving only as a reminder.
All standard BACnet objects and their properties defined in version 1.14 are supported, although not all of them will return values that can be used by VTScada’s standard I/O tags. Some complex types, including Sequence (and therefore, sub-properties), Choice and BACnet List are not supported in this version. Arrays of primitive items can be both read and written in an item-by-item basis. Vendor-specific objects and properties are supported only if their encoding is not context-tagged
While some properties may be writable per the BACnet Standard, or even some intended to be read-only could be written to on specific devices, the driver only supports writing to primitive types. As this is not enforced at the driver level, they might be configured to write, but the actual communications may fail depending on the device implementation.
The BACnet standard offers a few approaches to automatic network / device / object discovery, but this is currently not supported. Some properties or objects shown on the Address Assist dialog may not be present in the device being accessed.
The driver does not reply to queries regarding its capabilities as it does not expose the standard "Device" object.
Due to the limited object and property support, schedules and calendars may not be fully supported.
Services other than ReadProperty, ReadPropertyMultiple and WriteProperty are not supported.

BACnet 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 orange to indicate that you have applied an override.

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

Server List

Select (or create) a named server list. (Driver Server Lists) Servers for the list must be defined using the Application Configuration dialog, as described in Servers for Specific Services. Smaller sites that do not have multiple servers, or that use only the default server list, need not configure this field.

BACnet Driver properties Device tab

Device IP Address/Node

The IP address or node of the BACnet device with which to communicate. When using a local network, this field is editable by the user only in MS/TP mode, accepting values between 0 and 254. In BACnet/IP mode, it is populated automatically by the UDP port tag. When foreign networks are enabled, the contents are related to the foreign network selected, being editable in both BACnet/IP and MS/TP modes. If no port is specified in BACnet/IP mode, the default port (47808) is used.

Protocol Version and Release

Displays the ASHRAE standard protocol version that the driver follows, which is version 1.14. This value is not user-configurable.

Network Type (Routing)

This group of fields is only editable when a foreign network is selected in the drop list. The network type selected here affects only the network where the destination device is located. The options are the same as the Data Link drop list in the communications tab (BACnet/IP and MS/TP). Review the information related to Foreign Networks for more details.

Destination Network Number

The network number where the device is located. Accepts network numbers between 0 and 65535.

Local Network Number

The network number where the VTScada Station is located. Accepts network numbers between 0 and 65535.

Max Message Retransmissions (Hop Count)

The maximum times a message is retransmitted by routers when attempting to reach a foreign network. This number is decremented every time a router receives a message and attempts to forward it to the next destination in the BACnet internetwork. It is intended to prevent messages from using network resources indefinitely when the ultimate destination is unreachable. Accepts values between 1 and 255.

Router IP Address/Node

The IP address or node of the BACnet router located in the same network as the VTScada Station that is responsible to forward the messages to the next device in the route. Like the Device IP Address/Node, this field is editable by the user only in MS/TP mode, accepting values between 0 and 254. It is populated automatically by the UDP port tag in BACnet/IP mode.

Network Priority

The message priority for the device with which to communicate. (Not to be confused with property write priorities.) May be set to any of:

0 – Normal Message
1 – Urgent Message
2 – Critical Equipment Message
3 – Life Safety Message

Segmented Messages Accepted

Segmented messages are not supported by this version.

Read Property Multiple Supported

Some devices don’t support the reading of more than one property in a single message. When deselected, the driver will request values from the device through only the BACnet ReadProperty service.

BACnet Driver properties Communications tab

The Communications tab holds the configuration properties required for this device to communicate with your hardware.

There is one difference in the communications tab, depending on whether you are using BACnet/IP or MS/TP: For MS/TP the source and destination nodes are both editable and they are a device network node number between 0 and 255.

Port

The port parameter points to either a UDP/IP port tag (in the case of BACnet/IP) or a serial port tag (in the case of MS/TP).

In BACnet/IP mode, the device address and port number are defined by the port itself. Note that the default UDP port used for BACnet/IP is 47808, but all BACnet devices must support, at a minimum, values in the ranges 47808 - 47823 and 49152 - 65535.

The serial (RS-232) port tag is used to interface the BACnet driver to the RS-485 network used for MS/TP communications via a user supplied RS-232 to RS-485 converter. This tag defines the serial port communication parameters such as port number, baud rate, the number of data bits and stop bits, parity and so on. In this mode, you must specify both the VTScada Station and the device node numbers.

Even though it is possible to use any port tag in both modes, there is no guarantee that the communications will work with all devices. VTScada does not prevent the use of a serial port server through either a TCP or UDP link, but those devices may not satisfy the timing requirements for MS/TP communications.

Timeout Limit

Time (in seconds) that the driver will wait for a response to a message before trying again (if there are retries left).

Retries

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

Use only if the driver is connected to a Serial port. When using TCP/IP, do not set to any value other than 0.

Hold

Check this to have I/O tags attached to the driver hold their last value in the event of a communication failure. If not checked, 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.

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.