Driver Manual
(Supplement to the FieldServer Instruction Manual)
FS-8700-73 BACnet MSTP - Serial

APPLICABILITY & EFFECTIVITY
Effective for all systems manufactured after May 2009

Driver Version: 1.17
Document Revision: 3

1. BACNET MSTP DESCRIPTION

The BACnet Master-Slave/Token-Passing (MSTP) driver implements a data link protocol that uses the services of the RS-485 physical layer. See the FieldServer BACnet PIC statement for the level of conformance that this driver implements.

All information in a BACnet system is represented in terms of objects. The Object_Identifier is a 32-bit code that identifies the type of Object (also identified by the Object_Type Property) and its "Instance" number, which together uniquely identify the Object within its BACnet device. Theoretically, a BACnet device could have over four million Objects of a particular type. The Object_Name is a text string, which has a unique capability. BACnet devices may broadcast queries for devices that contain Objects with a specific Object_Name. This can greatly simplify project setup.

BACnet requires one Device Object to be present in every BACnet device. The Device Object makes information about the device and its capabilities available to other devices on the networks. Before one BACnet device starts control-related communications with another, it needs to obtain some of the information presented by the other device's Device Object. Unlike other Objects, the Device Object's Instance number must be unique across the entire BACnet internetwork because it is used to uniquely identify the BACnet devices. It may be used to conveniently identify the BACnet device from other devices during installation.

Standard object types are used to hold real time data and other information. Each Object Type is referenced by a number, for example 0 represents an Analog Input.

Each Object consists of a number of prescribed properties, the main property being the Present_Value. Objects are monitored and controlled through their properties. The Analog Input Object is representative of the Objects involved directly with control elements and many of its Properties reflect this.

The information that follows describes how to expand upon the factory defaults provided in the configuration files included with the FieldServer.

Max Nodes Supported

2. DRIVER SCOPE OF SUPPLY

2.1  Supplied by FieldServer Technologies for this driver

2.2  Provided by the Supplier of 3 ^rd Party Equipment

2.2.1 Hardware

2.2.2 Optional Items

3. HARDWARE CONNECTIONS

The FieldServer is connected to the BACnet MSTP as shown in connection drawing.

Configure the BACnet MSTP according to manufacturer’s instructions

3.1 Hardware Connection Tips/Hints

Follow standard RS-485 2-wire guidelines for installation. See connection diagram below.

4. CONFIGURING THE FIELDSERVER AS A BACNET MSTP CLIENT

For a detailed discussion on FieldServer configuration, please refer to the FieldServer Configuration Manual. The information that follows describes how to expand upon the factory defaults provided in the configuration files included with the FieldServer (See “.csv” sample files provided with the FieldServer).

This section documents and describes the parameters necessary for configuring the FieldServer to communicate with a BACnet MSTP Server.

The configuration file tells the FieldServer about its interfaces, and the routing of data required. In order to enable the FieldServer for BACnet MSTP communications, the driver independent FieldServer buffers need to be declared in the “Data Arrays” section, the destination device addresses need to be declared in the “Client Side Nodes” section, and the data required from the servers needs to be mapped in the “Client Side Map Descriptors” section.

Details on how to do this can be found below.

4.1  Data Arrays/Descriptors

Note that in the tables, * indicates an optional parameter, with the bold legal value being the default.

Example

4.2 Specify the MAC_Address of the FieldServer

The MAC_Address is used on the Data_Link (or physical) layer as the source or destination address. See section 9.1.1.2 of the BACnet ANSI/ASHREA standard for more information.

Example

4.3  Client Side Connection Descriptions

Example

-------------------------------------------------

1 P1 to P8 will require the optional RS-485 converter (Part # 4301-00)

2 Not all ports shown are necessarily supported by the hardware. Consult the appropriate Instruction manual for details of the ports available on specific hardware.

3 76800 baud is supported on the X30, X25 and ProtoCessor

4.4 Client Side Node Descriptors

Example

------------------------------------------------------

⁴ P1 to P8 will require the optional RS-485 converter (Part # 4301-00)

⁵ Not all ports shown are necessarily supported by the hardware. Consult the appropriate Instruction manual for details of the ports available on specific hardware.

4.5  Client Side Map Descriptors

4.5.1 FieldServer Related Map Descriptor Parameters

4.5.2 Driver Related Map Descriptor Parameters

4.5.3 Timing Parameters

4.5.4 Map Descriptor Example.

5. CONFIGURING THE FIELDSERVER AS A BACNET MSTP SERVER

For a detailed discussion on FieldServer configuration, please refer to the FieldServer Configuration Manual. The information that follows describes how to expand upon the factory defaults provided in the configuration files included with the FieldServer (See “.csv” sample files provided with the FieldServer).

This section documents and describes the parameters necessary for configuring the FieldServer to communicate with a BACnet MSTP Client.

The configuration file tells the FieldServer about its interfaces, and the routing of data required. In order to enable the FieldServer for BACnet MSTP communications, the driver independent FieldServer buffers need to be declared in the “Data Arrays” section, the FieldServer virtual node(s) needs to be declared in the “Server Side Nodes” section, and the data to be provided to the clients needs to be mapped in the “Server Side Map Descriptors” section. Details on how to do this can be found below.

Note that in the tables, * indicates an optional parameter, with the bold legal value being the default.

5.1  Driver Specific FieldServer Parameters

Example

5.2  Data Arrays/Descriptors

 Note that in the tables, * indicates an optional parameter, with the bold legal value being the default.

Example

5.3  Server Side Connection Descriptors

Example

6 P1 to P8 will require the optional RS-485 converter (Part # 4301-00)
7 Not all ports shown are necessarily supported by the hardware. Consult the appropriate Instruction manual for details of the ports available on specific hardware.
8 76800 baud is supported on the X30, X25 and ProtoCessor
9 ForServer configurations the Max_Master and Max_Info_Frames parameters (or properties) can be overridden from a BACnet Client by using the "Write Property" command. Note that when the FieldServer is restarted, the default values specified in the configuration file will be applied

5.4  Server Side Node Descriptors ¹⁰

Example

5.5  Server Side Map Descriptors

5.5.1 FieldServer Specific Map Descriptor Parameters

10 Only one Server Nodes may be defined for each connection. For information on support for multiple virtual server nodes on a single connection please contact the Sales Department."

11 Note that Port is not declared in the Server Side Nodes

5.5.2 Driver Specific Map Descriptor Parameters

¹² See the BACnet DFS to determine if a particular object supports this property

5.5.3 Map Descriptor Example.

Appendix A. USEFUL FEATURES

Appendix A.1. BACnet object names

When an external BACnet Client builds a list of Object Names, the BACnet Server Map Descriptor names determine the BACnet Object Name. If the Map Descriptor length is greater than 1, the Object Name will be suffixed with the index into the Map Descriptor. For example, if the Map Descriptor name is SMD_AI_01 and the length 3, then the Object Names will be SMD_AI_01[0], SMD_AI_01[1] and SMD_AI_01[2].

Appendix A.2. Network number

If multiple BACnet Nodes are specified on the Server side, the FieldServer automatically defaults to virtual operation. In effect, the FieldServer simulates a software router. BACnet identifies this FieldServer using a combination of it’s network number and IP/MAC address. The default Network number of a FieldServer is 5. If there is more than one FieldServer on a BACnet intranet with multiple nodes, the default network number of the additional FieldServers will need to be changed and a unique number allocated to each.

A unique network number will need to be assigned if both of the following conditions are true:

• The FieldServer has multiple BACnet Server nodes.
• There is more than one FieldServer on a network which includes multiple BACnet nodes.

To override the FieldServer’s default network number 5 include the following in the configuration file:

Example

Note: While it is theoretically possible to have up to 65535 virtual nodes, it is recommended that a maximum of 32 is configured. If an application requires the configuration of more than 32 virtual nodes please consult FST.

Appendix A.3. Accessing Data from BACnet Properties comprising Arrays of Values

Some BACnet Object properties (e.g. Priority_Array) are arrays of values (the Priority_Array property is an array of 16 values). In order to read a specific array entry, the Array_Index must be specified in the Map Descriptor. Array_Index is a Client Side Map Descriptor function

The following example shows a configuration that will read the Priority_Array value at Array_Index 7, belonging to Analog Output 1.

Details of the relevant BACnet properties and their associated arrays can be found in the BACnet Protocol Spec.

Appendix A.4. FieldServer implementation of BACnet priority Arrays

When BACnet Output objects are written to the Server side of the FieldServer, an associated write priority is given to each write value. When the FieldServer receives the write value, it stores it to the Map Descriptor Priority Array Table at the specified priority. The Priority Array Table is then scanned and the value with the highest priority is stored to the Data Array location specified by the Map Descriptor.

When a Write “Relinquished” command is received, the value is removed from the Priority Array Table and the next highest value from the Priority Array Table is stored to the Data Array.

If all values have been “Relinquished” from the Priority Array Table, then the Map Descriptors “Relinquish Default” value will be stored to the Data Array.

Appendix A.4.1.  Accessing Priority Array information

The Priority Array table and its “In_Use” (or Not Relinquished) state are stored internally to every Map Descriptor, and cannot be accessed directly. The information can be accessed indirectly by specifying the following Data Arrays which will maintain an exact copy of the Priority Array Table for the Map Descriptor.

Appendix A.5. BACnet State Text Preload

BACnet Multistate Objects have a State_Text property. This property is defined as an array of character strings representing descriptions of all possible states of the Present_Value. The number of descriptions matches the number of states defined in the Number_Of_States property. The Present_Value, interpreted as an integer, serves as an index into the array.

When Multistate Objects are configured on a BACnet server it is necessary to define the State_Text property. This section illustrates how to define the State_Text character strings and how to associate these definitions with Multistate Server Map Descriptors. 

The maximum permitted length of any State_Text string is 50 characters.

Appendix A.5.1. Method 1 – Using an Offset/User Table:

Appendix A.5.2.  Method 2 – Using a Single Data Array:

Appendix A.5.3. Using Intrinsic Reporting for a Multistate Value

To use Intrinsic Reporting for a Multistate value, it is necessary to classify each of the states as either Normal, Alarm or Trouble. This is done by adding another column to the Offset_Table, called Table_User_Value. Each state is then classified by inserting one of the following values in its row:

0 = normal

1 = alarm

2 = fault

Note: The state value (Table_Index_Value) is an enumerated value greater than zero. Zero is not a valid value, but since many client side configurations will wake up with values of zero, the BACnet server will treat a value of zero as a normal value (i.e. not as an alarm or fault value)

Appendix A.6. COV and Intrinsic Reporting

The COV (Change of Value) and Intrinsic Reporting services are two distinct ways in which point values can be reported to a client workstation as they change, i.e. in an event-driven opposed to a polling method. This can increase performance dramatically compared to polling method alone. It also reduces network traffic significantly.

For BACnet/MSTP, only MSTP Master Nodes support COV and Intrinsic Reporting

The services are suited to different purposes:

• COV is suited to value updates. On analog points the sensitivity can be set using the COV_Increment property. Only changes larger than the COV_Increment value will be reported.
• Intrinsic Reporting is used for alarming. It is implemented via Notification_Class objects, which can receive subscriptions from client workstations that add themselves to the RecipientList property of a Notification_Class object.Notifications are done using ConfirmedEventNotification or UnconfirmedEventNotification. Intrinsic Reporting also allows for alarms to be acknowledged (using the AcknowledgeAlarm service) and for all subscribed client workstations to be notified of alarm acknowledgements (using EventNotifications of type ACK_NOTIFICATION)..

Appendix A.6.1. Notes on COV configuration:

• COV functionality is not enabled by default for MSTP. The Node_Option parameter can be configured to enable or disable COV. An example configuration is presented in Appendix A.6.5. Systems using BACnet/IP or BACnet/Ethernet to BACnet/MSTP routers may not function reliably if COV functionality is enabled as the router will make the MSTP device appear as a BACnet/IP or BACnet/Ethernet device, which could lead the BACnet Workstation to expect unrealistic throughput performance when subscribing to multiple points. It is recommended only to enable COV functionality on MSTP systems if the Client device communicates directly via MSTP, or if the user knows that the throughput issue will not arise..
• COV functionality (SubscribeCOV service) only applies to the Present_Value and Status_Flags properties of BACnet Objects - the SubscribeCOVProperty service is not supported by the FieldServer.
• For analog Server Map Descriptors the user may optionally configure a COV_Increment value to adjust the reporting threshold. If it is not set the COV_Increment defaults to zero.
• COV Notifications are generated for all data objects for which a remote client has issued a SubscribeCOV-Request. The SubscribeCOV-Request regulates whether Notifications are Confirmed or Unconfirmed. The remote Client may also write the COV_Increment property in order to control the deadband for changes in analog values. The COV_Increment property can be initialized via the configuration file by setting the COV_Increment Map Descriptor Property. The value set by the configuration is an initial value that is loaded on startup. It would be replaced by any new value written by the Client
• COV is not available on the ProtoCessor

Appendix A.6.2. Notes on Intrinsic Reporting configuration:

• Intrinsic Reporting is managed by Notification Class objects. At least one Notification Class object must be configured for Intrinsic Reporting to work.
• Each Data_Object that is to be monitored by Intrinsic Reporting must be linked to a Notification Class object via the Notification_Class Map Descriptor Property. For analog points alarm limits must be set up, and for binary points, the Input_Alarm_State (specifying which binary value (0 or 1) to regard as the Alarm state) must be set up.
• The Notification_Class object contains properties that allow a client workstation to modify rules governing event reporting, such as event_type, days of week, start and end times etc.
• The RecipientLists are non-volatile, and subscriptions must be renewed on system restart.

Appendix A.6.3.  Map Descriptor Example - COV

Appendix A.6.4.  Map Descriptor Example – Intrinsic Reporting

Appendix A.6.5.  Map Descriptor Example - Enable or Disable COV

Appendix B. TROUBLESHOOTING

Appendix B.1. Debugging a BACnet connection

• If duplicate Object_Instances are configured in the FieldServer, the second call of the Instance will overwrite the first one. This may cause a BACnet Object to be “lost.”
• If the Node Name configured on the BACnet Server Side of the configuration is not being indicated as the Device Name on the BACnet SCADA system, then the FieldServer is not communicating with the SCADA system. If the Device Object's name is being indicated, but the Present_Value shows question marks, then it is likely that the Client side of the FieldServer is not communicating.
• Extra memory is required to store Map Descriptors that have the active/inactive text parameters specified. If the defaults are appropriate, do not specify these parameters. This will save memory and allow more Map Descriptors to be created
• When a BACnet_MSTP connection is configured as a server, it is better to use connection_type MSTP_Slave_Node. The only time when a server connection must be a Master_Node is when alarming has been established on the FieldServer.
• When a FieldServer/ProtoCessor is configured to support MSTP virtual server nodes the firmware achieves this by implementing a virtual router and thus a network number is required so that it can expose its nodes to external devices as belonging to a specific network. (The default is network 5 if not specified). This network number is defined on the bridge descriptor as Network_Number. It must be unique for a site. Refer also to Appendix A.2.

Appendix C. VENDOR INFORMATION

Appendix C.1. McQuay

McQuay Units are shipped with a default Device instance of the last 6 digits of the McQuay Serial number.

Appendix C.2. Trane

When new points are added to the FieldServer it is important to restart the Summit Workstation or BCU, otherwise these new points may not be seen by the FieldServer.

Disconnect the FieldServer from the BACnet network when transferring images to the BCU.

Appendix C.3. Liebert

Polling BACnet addresses that are not configured for Liebert systems may cause the connection to fail in older versions of Liebert. Please contact your Liebert supplier for more information.

Appendix C.4. Automated Logic Corporation.

When an ALC module is powered up, and it does not detect valid BACnet/MSTP traffic on its MSTP port, then the module goes into a terminal mode and MSTP communications will not be intitiated.

When connecting the FieldServer to an ALC BACnet/MSTP module, always start the FieldServer first. Wait until the RUN Led is flashing on the FieldServer before powering up the MSTP module.

Appendix C.5. Honeywell EBI

Honeywell EBI cannot process EventNotifications with ACK_Required set to 1. The ACK_Required property of Notification Class Map Descriptors configured for use with EBI must therefore be set to 0.

Appendix D. REFERENCE

Appendix D.1. Object_Type Legal Values – Abbreviation Descriptions

Appendix D.2. Property Legal Values

Appendix D.3. Units

Appendix D.4. BACnet Specific Statistics