BACnet communication protocol

• Supported device types and versions

• Communication line configuration

• Communication station configuration

• I/O tag configuration

• Scheduler in Siemens Desigo devices

• Scheduler in Delta Controls devices

• Information about events

• Information about alarms

• Comment on the address cache

• Comment on Delta Controls devices

• Comment on E-DDC3.1 devices

• Comment on Siemens Desigo devices

• Comment on Klimasoft MBG-MSTP devices

• Comment on iLON 10 Ethernet adapter

• Comment on Easylon USB Interface+

• Comment on BACnet MS/TP implementation

• Comment on BBMD (BACnet Broadcast Management Devices) support

• Tell commands

• Literature

• Changes and modifications

• Document revisions

Supported device types and versions

The BACnet communication protocol (Building Automation and Control Networks) implements ANSI/ASHRAE 135-2001 standard.
This implementation was tested with the following devices:

• Siemens

  • Desigo PXM20 (Control unit, LON interface, BACnet over LON)

  • Desigo PXC22 (Control station, LON interface, BACnet over LON)

  • Desigo PXC22-E.D (Control station, Ethernet interface, BACnet/IP)

  • Desigo PXG80-N (BACnet router, Ethernet interface, LON interface, BACnet/IP, BACnet over LON)

• Delta Controls

  • DSC-1212E (System controller, Ethernet interface, BACnet/IP)

  • DAC-633 (Application controller, MS/TP interface connected to DSC-1212E, which works as BACnet router)

  • DAC-633 (Application controller, MS/TP interface connected to the Moxa 5250 serial/ethernet converter and communicated directly as a BACnet MS/TP device in UDP mode)

  • DAC-1146 - (Application controller, MS/TP interface connected to DSC-1212E which works as BACnet router)

• Sauter

  • EYK220F001 (Automation station, Ethernet interface, BACnet/IP)

  • EYR203F001 (Universal controller connected to EYK220F001)

  • EYR207F001 (Universal controller connected to EYK220F001)

• York

  • BACnet MS/TP MicroGateway (Communication card for York coolers, RS485 interface, BACnet MS/TP)

• SE-Elektronic GmbH:

  • E-DDC3.1 (DDC automation station, Ethernet interface, BACnet/IP)

• Klimasoft

  • BACnet/Mbus converter MBG-MSTP: Converter from BACnet to Mbus protocol (RS485 interface, BACnet MS/TP)

Characteristics of the current version:

• Communication in Ethernet (BACnet/IP) and LONTalk networks.

• Limited support of MS/TP network (master-slave token-passing on RS-485): without automatic searching for Master stations.

• Support of BACnet router (the connection between BACnet/IP and LONTalk networks).

• Reading and writing of simple values (binary, integer, real, strings, date, time, etc..) and any ASN sequences.

• Support of the polling method of data reading (messages ReadProperty-Request and ReadPropertyMultiple-Request messages)

• Support of change method of data reading (an optional registration by SubscribeCOV-Request or SubscribeCOVProperty-Request and following processing of ConfirmedCOVNotification-Request and UnconfirmedCOVNotification-Request).

• Writing the values by WriteProperty-Request.

• Dynamic change of I/O tag address by TELL command SETPTADDR (to read the values of Schedule objects).

• Work with objects of Schedule type (schedules).

BACnet protocol considers all the participants of the communication as the network devices. Each network device contains at least one (mostly just one) object Device (its Object Identifier must be unique within the whole network). This object contains other objects of defined types (Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, Binary Value, Calendar, Command, Event, Group, File, etc.). The object detection - see a description of Who-Is and Who-Has Request types.
Each object has properties, which can be mandatory or optional. Moreover, each producer of BACnet devices can implement other properties when necessary.
The messages in the BACnet protocol are related to the manipulation of objects and their properties. They are defined with the help of ASN.1 (Abstract Syntax Notation version 1) and encoded by a simple version of BER (Basic Encoding Rules - encoding of ASN.1 messages).
The messages contain, besides fixed defined items, also items of 'Abstract Syntax & Notation' type. It means that any sequence (or "tree"), the meaning of which is defined by an implementer, can be in its place in the message. When using BER, it enables parsing of the message with the unknown items. BER defines two basic item types (tags): application and context.
The application tags are predefined:

• Null - empty value

• Boolean - yes/no

• Unsigned - positive integer

• Signed - integer

• Real - 4-byte real number

• Double- 8-byte real number

• Octet String - a sequence of character

• Character String - charset + text string

• Bit String - a sequence of bits

• Enumerated Value - enumerated value

• Date - date

• Time - time

• Object Identifier - identifier of the object (32-bit number, it consists of 10-bit number - Object Type and 22-bit number - Instance)

The context tags depend on the context (on the position in the message). Without knowing the context (a description of the message that is being parsed), it is possible to find out that the context tag No. 5 with the length of 4 bytes is on the particular position, but you need additional information whether the value is Unsigned, Signed, Real, Bitstring or a different type of value.
Besides the simple application and context tags, the properties may be also complex:

• Sequence - the sequence that consists of other properties (both simple and complex one), they are either required or optional

• Sequence of - the sequence of N-tuple of properties

• Choice - one of N possibilities

Example - a dump from trace file of a KOM process with the debug enabled:

=== ASN Body beg === objectIdentifier (tag 0) OBJID 0 analog-input,10 listOfResults (tag 1) SEQUENCE { propertyIdentifier (tag 2) ENUM 85 present-value propertyValue (tag 4) SEQUENCE { ENUM 1 } } === ASN Body end ===

Interpretation:
It is the Sequence of two tags: objectIdentifier is a context tag with the number 0, of Object Identifier type. Its value is Object type=0 (analog input), Instance=10.
The tag listOfResults is a context tag with number 1 and it is a Sequence of two tags. The first one is propertyIdentifier. It is a context tag No. 2,  Enum type, value = 85 that corresponds to "present-value". A second tag is a context one, No.4. It is a sequence that contains one Enumerated Value tag with the value=1 (application tag).
To parse this message, the D2000 KOM process must know ASN.1 definition of a message. Without it, the process can find out that the message contains the context tag 2 (value=1 byte) but cannot know that it is Enumerated Value. It is not able to interpret this byte (it could be Enumerated Value, Unsigned or Signed number) and does not know that the name of this context tag is propertyIdentifier and the value 85 corresponds to "present-value".

The properties of objects are mapped to I/O tags in the D2000 configuration. Due to the existence of context tags, you may specify an Application tag in the I/O tag. It determines the interpretation of the context tag. The parameter Complex address defines "a path" in the parse "tree" to get the values from the sequence that is defined by the implementer.

Communication line configuration

• Communication line category: TCP/IP-UDP, LonWorks, Serial, SerialOverUDP Device Redundant.

• TCP/IP-UDP parameters:

  • Host: IP address or of the network interface that is used for communication by the D2000 KOM process. A symbolic name that can be translated to an IP address can be entered too.
    Note: a symbolic name ALL or * can be entered - in which case all available interfaces are used.

  • Port: UDP port number that is used for communication by the D2000 KOM process (according to standard 0xBAC0, i.e. 47808).

Line protocol parameters

Line protocol parameters specific for BACnet MS/TP

Communication station configuration

The communication station corresponds to a device on the BACnet network with which the KOM process communicates.

•  

  • Station type: BACnet/IP station must be configured on TCP/IP-UDP line. LonWorks station must be configured on the LonWorks line. MS/TP station must be configured on SerialOverUDP Device Redundant or Serial line.

  • Address:

    • BACnet/IP station: IP address of station (in the form A.B.C.D, e.g. 172.16.0.99)

    • LonWorks station: address of LON subnet and LON node (in the form subnet.node, a subnet is an 8-bit number and a node is a 7-bit number)

    • MS/TP station: number of the node on the line (0-254, address 255 is a broadcast)

  • Port: (only for BACnet/IP): UDP port number on station (according to standard 0xBAC0, i.e. 47808)

  • Domain: (only for LonWorks): 0 or 1, it is related to the line configuration. On the LonWorks line, a membership to one or two domains can be configured. On the BACnet station, the selection of domain means that the device belongs to this domain (it influences 'domain' bit in LON address).

  • Source network: source network number (i.e. a network with KOM process). This parameter may not be set for the LonWorks line. For TCP/IP-UDP line, it is a 16-bit number (or it is not set, see Note 2).

  • Destination netwoEditrk: a 16-bit number of a destination network (i.e. a network including the device which communicates with the KOM process).
    Set this for the LonWorks line if the KOM process communicates with the device that is located behind a BACnet router. In that case, the Address of the station is the address of the BACnet router and the Destination address is the address of the destination device.
    For TCP/IP-UDP line, the Destination network is used in a similar way if there is communication between different BACnet networks.
    
    Note 1: This configuration was tested as follows:

    • Line: TCP/IP-UDP

    • Station type: BACnet/IP

    • Address: 172.16.99.1 (address of a BACnet router PXG80-N)

    • Destination network: 1

    • Destination address: 1.1 (address of PXC22 on a LON network behind a BACnet router)

    The KOM process communicated with the PXC22 device which was connected to a LON network via PXG80-N BACnet router. The KOM process communicated with a BACnet router over Ethernet, so the line is TCP/IP-UDP. The communication between the BACnet router and the PXC22 station was performed over a LON network.
    
    

    Note 2: We tested a similar configuration. We used Delta Controls DSM-RTR (connected over Ethernet network) and a Klimasoft MBG device (a gateway to M-Bus) connected to Delta Controls via an MS/TP interface. The communication started only if the Destination network (value 50020) and Destination address (value 96) were configured and the Source network was not specified. However, in another configuration, the communication worked also with the Source network parameter specified. We recommend you try various settings of network parameters for the devices.

•  

  • Destination address: It is the address of the destination device if KOM communicates with it over the BACnet router. When setting this parameter, you can (but you do not have to, see note about E-DDC3.1) set also the parameter Destination network. The Destination address parameter should be in the subnet.node format (if the destination device is on a LON network) or in the A.B.C.D format (if the destination device is on a BACnet/IP network).
    
    Note 1: On a BACnet/IP station you can configure the Destination address in the subnet.node format (e.g. 1.31). This configuration corresponds to the BACnet router, which communicates with the KOM process over BACnet/IP and is connected to the destination device via a LONTalk network.
    
    Note 2: On BACnet/IP station you can configure the Destination address as a number from the interval 1-255. This configuration corresponds to the BACnet router, which communicates with the KOM process over BACnet/IP and is connected to the destination device by MS/TP bus (DAC-633).
    
    Note 3: On BACnet/IP station you can configure the Destination address as a bigger number (e.g. 2001), which works for E-DDC3.1.

• Resubscribe interval: Time in seconds. After it elapses, a station again gets a request to send changes of I/O tags. This parameter relates to the I/O tags with the Request type that is equal to SubscribeCOV or SubscribeCOVProperty.

• Max APDU: Maximum size of the message (APDU = Application Protocol Data Unit) that is sent by the KOM process. The default value is:

  • 1467 octets for TCP/IP-UDP line

  • 487 octets for SerialOverUDP Device Redundant or Serial lines (BACnet MS/TP)

  • 55 octets for LonWorks line
    
    The limitation depends on the size of packets that may be transmitted over Ethernet and LonWorks. For LonWorks, the maximum value is 206. The value 55 is due to the limitation of the iLON 10 Ethernet adapter.

  
  The changing of the default value is important for testing and complying with the stations which are able to process only smaller messages. Currently, the reduction of Max APDU influences only the size and amount of ReadPropertyMultiple-Request messages. These messages are intended for a periodic reading of the I/O tag value (see I/O tag configuration).
  
  Note: The setting of Max APDU does not affect the size of max-APDU-length-accepted in APDU BACnet-Confirmed-Request-PDU, by means of which the KOM process informs a partner how big messages it is capable to process. This parameter is configured by the station protocol parameter Segment-Response.
  
  

• Priority: A priority of a message in the BACnet protocol. There are 4 priorities: Normal (default), Urgent, CriticalEquipment, and LifeSafety.

• Rpt_timer & reply: (only for LonWorks) The parameters Repeat timer (default value = 1) and Retry (default value =1 ) of LonTalk protocol.

• Tx_timer: (only for LonWorks) Parameter Tx_timer in LonTalk protocol. Default value = 3.

• Timeout and retry: A timeout in milliseconds to confirm the message. The default value according to the BACnet protocol is 3000 ms. After the timeout elapses, the message is sent retry-times. If any confirmation is not received, an error count will increase for the station.
  
  Note: When testing the Siemens PXC64-U device (the communication over LonTalk), we had to set Retry=8, Timeout=300 (more retries with shorter timeout). Due to that, we had to increase the values COM_ERR=10, HARD_ERR=20 so that the station did not switch to an error state when retrying to send the message.

• COM_ERR: The value of the error counter for the station when the station switches to COM_ERR status. The situation when the station does not reply to a read/write request is considered as an error. A negative confirmation of a command (refusal of writing) is not an error. The default value is 5. See the parameters Timeout and retry.

• HARD_ERR: The value of the error counter for the station when the station switches to HARD_ERR status. The default value is 10. See the parameters Timeout and retry.

• Register-Foreign-Device, R-F-D Time to live: In this example, let's have a station located on a LONTalk network behind a BACnet router that communicates with the KOM process over Ethernet (e.g. Desigo PXG80-N). The BACnet router sends the broadcasts from LONTalk to Ethernet as UDP broadcasts. If the distribution of UDP broadcasts is disabled or the KOM process is placed in a different segment of the network than the BACnet router (so it does not receive any UDP broadcasts), you should check the option Register-Foreign-Device on the station. This will cause the KOM process to send the Register-Foreign-Device message to a BVLC router (BACnet Virtual Link Control) after the start. The message requests registration to the FDT table (Foreign Device Table) in the router. The router sends the broadcasts in the form of UDP unicast (whose distribution is not limited to one segment) to the devices that are registered in the FDT table. The TTL (time to live) - time in seconds (1-65535) is the parameter of the Register-Foreign-Device message . It defines the expiration of registration that stops the sending of UDP unicasts. That is why the KOM process must ask the BACnet router to re-register it before TTL expires. If there are more stations behind a BACnet router, just check Register-Foreign-Device on one of them.
  
  Note 1: If the router does not support BBMD functionality (BACnet/IP Broadcast Management Device), it replies to the Register-Foreign-Device message with an error code and it does not send LonTalk broadcasts to the KOM process in the form of UDP unicasts. In that case, you must use other solutions (the communication over iLon Ethernet Adapter, the placing of the KOM process on the same segment in the network on which the BACnet router is, etc.).
  Note 2: Router Desigo PXG80-N supports this functionality (tested). The control station Desigo PXC22-E.D does not support it probably (not tested yet).
  Note 3: In the case of Desigo devices, if the D2000 KOM process is on a different network segment than the Desigo device, this parameter must be checked at the station. Otherwise, Who-Is and Who-Has requests won't work (and thus addressing by object's name), as responses to these requests are sent as UDP broadcasts which will not go through a router.