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 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:

Characteristics of the current version:

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:

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:

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


Note: The parameters of the backup server (Host and Port) are not used in this protocol.


Line protocol parameters

KeywordFull nameMeaningUnitDefault value
DBGI
Debug InputDebug information about the input data. Meaning of the bits:
  • 1. bit - debugging of ASN message parsing
  • 2. bit - debugging of the I/O tag names that received a new value
  • higher bits - not used
-0
DTQ
Debug Timeout QueueDebug information about messages in time queue.-False
DI
Device InstanceNon-zero value causes that KOM process answers to Who-Is request by I-Am message. It contains a defined Device Instance. Zero value causes that Who-Is request is ignored.-0
RB
Receive Buffer(for TCP/IP-UDP lines only) Size of the receive buffer which is configured for the UDP socket. A zero value means the buffer size remains unchanged. 8192 bytes is a normal size in Windows. If there are more stations or more intensive communication, the buffer should be enhanced.bytes0
RO
Receive OnlyIf the value is True, no messages are sent to any station on the line. This parameter may be used when listening to the LonTalk communication: Configure the address, which is the same as the address of an existing LonTalk device, on the line. Also, configure the station with the device address which communication you need to listen to. The communication between devices is recorded in the log file of the line. RO=True ensures that the KOM process does not influence the communication by its commands and responses.-False
SC
Send Count(for LonWorks lines only) The retry count of one packet - default value is 1. However, in some situations when using iLON(TM) 10 Ethernet Adapter, the first message did not pass and the communication started to work correctly when SC=2.
Note: Later we found out that this was caused because the Free topology bus had not been ended by a terminator. However, this parameter had been already implemented.
-1
SD
Send Delay(for LonWorks lines only) A complement to the Send Count parameter that defines a delay (in ms) after each sending of the packet.ms0
VI
Vendor IDParameter Vendor ID of I-Am message (see the parameter Device Instance).-1


Line protocol parameters specific for BACnet MS/TP

KeywordFull nameMeaningUnitDefault value
BR
MS/TP baud rateBaud rate of the line. This parameter helps to recalculate some timeouts that are defined in a bit time in the communication line protocol. The bit time is a multiple of the period which is required for transfer of 1 bit at the particular baud rate.bits/sec9600
MIF
MS/TP Nmax_info_framesMaximum of information frames that may be sent by the KOM process before it must send a token. The standard does not specify a particular value. It recommends that the value must be 1 if this value is not configurable in a device. The higher value is set, the less time remains for other Masters. But on the contrary, it reduces the number of frames without information.-5
MO
MS/TP Nmin_octetsA minimum number of data (bytes) received on the line to be received by the KOM process before it indicates the line as "active".-4
MY
MS/TP my addressAddress of the KOM process on the line RS-485. The valid value is from the interval 0 - 127. It must be different from the addresses of other devices on the line (their addresses are defined in the station configuration).-1
TFA
Tframe_abortA minimum time (the unit is the length of bit transmission, i.e. it depends on MS/TP baud rate), after the expiration of which, the whole frame is discarded if no character was received. According to standard, the value may be higher but it cannot exceed 100 ms in absolute time.bits60
TNT
Tno_tokenTime (in milliseconds). After it expires, without receiving any data, the token will be considered lost.ms500
TR
Treply_timeoutThe minimum time (specified in ms) that the KOM process must wait for the station to respond to the request.ms255
TS
Tslot

Time (specified in ms) during which the station can generate a token.

ms10
TU
Tusage_timeoutA minimum time (specified in ms) for which the KOM process must wait while a partner starts to use a token or responds to a Poll for master frame. The standard value is 20 ms. According to the standard, the value may be higher - a maximum of 100 ms.ms20

Communication station configuration


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





Example of station configuration on TCP/IP-UDP line:

Example of station configuration on LonWorks line:


Station protocol parameters

KeywordFull nameMeaningUnitDefault value
RSD
Receive-send DelayDelay between the receiving of the reply from the station and sending the next packet.ms0
SR
Segment-ResponseA byte that contains Max Segs and Max Resp parameter (see the specification of BACnet protocol). Only some values from the 0-127 are permitted, which are specified by the BACnet standard. The KOM process considers the value 128 as default:
  • LonWorks line: set the value to 0x70 (more than 64 segments are accepted, the maximum length of the message is 50 bytes)
  • TCP/IP-UDP line: set the value to 0x75 (more than 64 segments are accepted, the maximum length of the message is 1476 bytes)
  • Serial and SerialOverUDP Device Redundant line: set the value to 0x73 (more than 64 segments are accepted, the maximum length of the message is 480 bytes)
-128
TSU
Time-Synchronization UTCThe parameter is important only if the synchronization is enabled on the "Time parameters" tab in the configuration of the station.
If the parameter is True (default), the time synchronization is performed by the UTCTimeSynchronization-Request message (the synchronization in UTC time). If the parameter is False, the time synchronization is performed by the TimeSynchronization-Request message (the synchronization in the local time).
Notes:
  • We recommend you to use the synchronization in UTC if it is supported by the device - you can avoid the problems with "jumping" time during the transition from/to DST time.
  • The requests for the time synchronization are unacknowledged messages, i.e. the device will not send the answer whether it supports the time synchronization or not.
  • The time synchronization has been tested on Siemens PXC36-E.D (HW=V3.02). This device supports the synchronization in both UTC and local time. You can find out the current time and date as local-date(56) property and local-time(57) property of the object of Device(8) type.
    From this object, you can find out also utc-offset(119) property which defines the offset of local time from the UTC (in minutes, i.e. -60 is Central European Time) as well as daylight-savings-status(24) property, which defines whether the device works in the summer-time (when testing in September 2012, the value on the device was True).
    After the time synchronization, the values of local-date(56) and local-time(57) have been changed.
-True

I/O tag configuration


Type of I/O tags: Ai,Ci,Di,TiA,TiR,TxtI,Ao,Co,Dout,ToA,ToR,TxtO.

I/O tag corresponds to object property.



Browsing of address space

When clicking the "Browse" button in the Address tab of the I/O tag, the BACnet Item Browser dialog box opens. In this dialog box, the user may browse the address space of a device and insert its items to the address dialog of the I/O tag.

The items can be filtered based on four basic criteria:

Note: In case of Type, Object name, and Object description it is not necessary to enter the full text in the filter field. The notation "*FILTERED EXPRESSION*" is supported. The symbol * represents any text before and after the expression.

Note: Using Ctrl+C it is possible to copy the content of the BACnet Item Browser into the Windows clipboard. All rows will be copied unless a specific row is selected.

Note: In versions from 20th December 2018 and newer, the recycling of browser dialog has been implemented. If the dialog is closed by the Cancel button or after selecting an object, it is actually only hidden and it is available for browsing by another I/O tag within the same station so that the tree structure, containing the browsed objects, is preserved. Clicking on the close icon at the top right corner will cause the dialog to be really closed.

Browsing of address space

Writing of any ASN sequence
Any ASN sequence can be written via I/O tag of text output type (TxtO) which has the Application tag property undefined. The rules are the following:

Note 1: If a result of the reading of I/O tag from communication is an ASN sequence and the I/O tag is of Txt type, this ASN sequence is written into it (according to the above-mentioned rules) using the following rules:

Note 2: The empty sequence may be written by a string " ", the string of length 0 (i.e. "") is ignored.

Examples of I/O tag configuration (Siemens Desigo PXC64-U device):
Analog input:

Binary input:

Binary value:

Note: If the Application tag is not configured properly (for the binary value it is Enum), the Desigo station returns an error 'invalid-data-type' when attempting to write:

  error-class ENUM 2 property
  error-code ENUM 9 invalid-data-type	

The Siemens Desigo PXC64-U device requires the following settings of Application tag:

Comment on input-output I/O tag: you can configure the I/O tag which is both input and output:
I/O tag of Ao type - Analog output:

When writing the value, the WriteProperty-Request message is used. As Subscribe/read is checked, the value is read after it's written. If I/O tag would be configured with Request type WriteProperty, its behavior would differ only by an absence of periodic value reading (the period is configured on the station, in Time parameters tab).

Comment on Siemens Desigo devices: I/O tags has a text name in the Desigo control system. The instance of the I/O tag may be found out from the DOTS00.DAT file in the application configuration - it is located 24 bytes before the beginning of the name.

Scheduler in Siemens Desigo devices


D2000 supports the reading and writing of schedulers. A scheduler contains BACnet attributes weekly-schedule(123) and exception-schedule(38).
Weekly-schedule is an array of 7 items (one item for each day of the week). Each item represents a sequence of time-value pairs that define the value changes of the scheduler in a given time. When reading and writing, you can configure also an Array index and access individual items of a weekly-schedule(123) array. The array index is 1-7 for individual days (1=Monday), the index 0 contains a size of the array (value 7 for the weekly-schedule(123) attribute, value 0 up to N for the exception-schedule(38) attribute).
Exception-schedule is intended for the holidays that require a different mode as is configured for common days. Exception-schedule is the sequence of 0 up to N items. An item always contains a date (or range of dates), several time-value pairs (as in a weekly-schedule), and a priority (1= top, 16= the lowest). The priority defines which of the items will be used if they overlap.

Reading of scheduler (the weekly-schedule attribute)

The times and values separated by a semicolon are read into the text value (see Note).
When writing the value to a scheduler you should realize that the value can be sent with various application tags (Unsigned, Signed), however, the device expects a particular tag (the easiest way to find it, is by reading of the value while line logging is active). The application tag of value is defined by the Application tag item in the configuration. The valid value of Application tag can be Boolean, Unsigned, Signed, Real, and Double. If any other type is set, the Unsigned value is automatically sent. A value type can be changed dynamically - if the first character of a text value is B, U, S, R or D, it stands for (B)oolean, (U)nsigned, (S)igned, (R)eal or (D)ouble.


Writing to the scheduler (the weekly-schedule attribute)

Note: Another possibility to write weekly-schedule, besides the ReadWriteScheduler request, is writing of an ASN sequence, e.g. the sequence "{ T0:0:0 u1; T2:30:40.5 u2; T5:0:0 u1 }" corresponds to the value "0:0:0; 1; 2:30:40.5; 2; 5:00:00;1". The I/O tag configuration differs only in Request type=ReadProperty. You can also write the time schedule for the whole week, if Array index is not set and the value contains 7 sequences for individual days, e.g. "{ T0:10:0 u3 T1:3:0 u1; } {T2:0:0.0 u2 T5:30:10.0; u3; } { T6:0:0.0 u2 T7:0:0.0 u3} { T20:0:0.33; u1} { T21:0:0.0; u1} { T22:0:0.0; u2} { T0:0:0.0; u3; T1:2:0.0; u1; T2:0:0.0; u2; T5:30:10.0; u3}".


Writing to the scheduler (the exception-schedule attribute)

The writing to the exception-schedule is supported via the writing of an ASN sequence.
Example: I/O tag configuration:

I/O tag type: text output (TxtO)

Request type: WriteProperty

Subscribe/read: Y

Object type: schedule(17)

Instance: 6

Property type: exception-schedule

Application tag: not defined (write the whole ASN sequence)

Using the string "0{ 0D2.10.2005 } 2{ T1:0:0; u1; T12:0:0; u3 } 3u10" you can write the time schedule for the day October 2, 2005. The scheduler has the value 1 since 1:0:0, the value 3 since 12:00:00. The priority of the exception-schedule is 10. When reading a value after writing (Subscribe/Read was configured) with the activated debug on the line, you can see the following log:

 === ASN Body beg ===
 objectIdentifier (tag 0) OBJID 17 schedule,6
 propertyIdentifier (tag 1) ENUM 38 exception-schedule
 propertyValue (tag 3) SEQUENCE 3 {
  readResult (tag 0) SEQUENCE 0 {
   date (tag 0) DATE 2.10.2005 NoDay
  }
  listOfTimeValues (tag 2) SEQUENCE 2 {
   time TIME 1:0:0.0
   value UNSIGNED 1
   time TIME 12:0:0.0
   value UNSIGNED 3
  }
  eventPriority (tag 3) UNSIGNED 10
 }
 === ASN Body end ===

To set the exception-schedule for the range of dates, write the value "0{ 1{ D5.10.2005; D8.10.2005}} 2{ T1:0:0; u1; T7:0:0; u3; } 3u15". This value for the range of dates 5.10.2005-8.10.2005 sets the scheduler from 1:00:00 to the value 1 and from 7:00:00 to the value 3. The priority of the exception-schedule is 15. When reading a value after writing (Subscribe/Read was configured) with the activated debug on the line, you can see the following log:

 
 === ASN Body beg ===
 objectIdentifier (tag 0) OBJID 17 schedule,6
 propertyIdentifier (tag 1) ENUM 38 exception-schedule
 propertyValue (tag 3) SEQUENCE 3 {
  readResult (tag 0) SEQUENCE 0 {
   dateRange (tag 1) SEQUENCE 1 {
    startDate DATE 5.10.2005 NoDay
    endDate DATE 8.10.2005 NoDay
   }
  }
  listOfTimeValues (tag 2) SEQUENCE 2 {
   time TIME 1:0:0.0
   value UNSIGNED 1
   time TIME 7:0:0.0
   value UNSIGNED 3
  }
  eventPriority (tag 3) UNSIGNED 15
 }
 === ASN Body end ===

Several items of above mentioned types can be written to the exception-schedule using a string which contains joined sequences, e.g. "0{ 0D2.10.2005 } 2{ T1:0:0; u1; T12:0:0; u3 } 3u10 0{ 0D3.10.2005 } 2{ T0:0:0; u2; T5:0:0; u3; T14:0:0; u1 } 3u11 0{ 1{ D5.10.2005; D8.10.2005}} 2{ T1:0:0; u1; T7:0:0; u3; } 3u15 "

Scheduler in Delta Controls devices


We also tested the reading and writing to the scheduler in the Delta Controls DAC-1146 device. Only the BACnet attribute weekly-schedule(123) was tested. The weekly-schedule is an array with 7 items (one item for each day in the week). Each item is the sequence of time-value pairs that define the value changes of the scheduler at a specific time. In contrast to Siemens Desigo devices, the schedulers are implemented with Boolean values True/False that are externally presented as Enum values 0/1. This is the example of scheduler Delta Controls:
"{ T0:10:0 E0 T1:3:0 E1; } {T2:0:0.0 E1 T5:30:10.0; E0; } { T6:0:0.0 E0 T7:0:0.0 E1} { T20:0:0.33; E0} { T21:0:0.0; E1} { T22:0:0.0; E0} 0{ T0:0:0.0; E0; T1:2:0.0; E1; }"
The writing as well as subsequent reading of E2 value can be performed, however, we don't know the DAC-1146's interpretation of E2 :-) .

Information about events


The GetEventInformation-Request is intended to ask the list of objects that are in theOffnormal or Fault states or whose change to Offnormal, Fault, or Normal has not been acknowledged.
Example of I/O tag configuration:

A reply to GetEventInformation-Request is the GetEventInformation-Ack message, which contains the list of objects and the list of properties for each object:

At the end of the list, there is the moreEvents attribute that is non zero if the list of events is incomplete (e.g. the exceeding of the maximum length of the message, etc.). In this case, you must reconfigure the I/O tag and set Object type and Instance to the last object in the list. It causes the generation of a new GetEventInformation-Ack message.

Example of GetEventInformation-Ack response:

 === ASN Body beg ===
 listOfEventSummaries (tag 0) SEQUENCE 0 {
  objectIdentifier (tag 0) OBJID 0 analog-input,1
  event-state (tag 1) ENUM 3 high-limit
  acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
  eventTimeStamps (tag 3) SEQUENCE 3 {
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:28:49.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:25:59.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:25:56.0
   }
  }
  notifyType (tag 4) ENUM 0 alarm
  eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
  eventPriorities (tag 6) SEQUENCE 6 {
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 7
  }
  objectIdentifier (tag 0) OBJID 214,1
  event-state (tag 1) ENUM 2 offnormal
  acknowledgedTransitions (tag 2) BITSTRING 0,1,0 to-offnormal(0),to-fault(1),to-normal(2)
  eventTimeStamps (tag 3) SEQUENCE 3 {
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 18.11.2005 Fri
    time TIME 12:52:11.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 18.11.2005 Fri
    time TIME 11:16:23.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 12:23:58.0
   }
  }
  notifyType (tag 4) ENUM 0 alarm
  eventEnable (tag 5) BITSTRING 0,0,0 to-offnormal(0),to-fault(1),to-normal(2)
  eventPriorities (tag 6) SEQUENCE 6 {
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 7
  }
 }
 moreEvents (tag 1) BOOLEAN FALSE
 === ASN Body end ===    

Information about alarms


You can acknowledge the events and alarms, whose list has been received by the GetEventInformation request. According to the BACnet protocol, the format of this request is (the record in ASN.1 syntax):

  *********************** Confirmed Alarm and Event Services ******************
  AcknowledgeAlarm-Request ::= SEQUENCE {
    acknowledgingProcessIdentifier [0] Unsigned32,
    eventObjectIdentifier [1] BACnetObjectIdentifier,
    eventStateAcknowledged [2] BACnetEventState,
    timeStamp [3] BACnetTimeStamp,
    acknowledgmentSource [4] CharacterString,
    timeOfAcknowledgment [5] BACnetTimeStamp
  }

For a more detailed description of the parameters, see the literature.
The acknowledgment is executed by the writing of the above-mentioned sequence to the text of the output I/O tag according to the rules of writing of any ASN sequence.

Example: The following list of alarms and events was read using the GetEventInformation request:

   ===  ASN Body beg ===
   listOfEventSummaries (tag 0) SEQUENCE 0 {
    objectIdentifier (tag 0) OBJID 0 analog-input,1
    event-state (tag 1) ENUM 4 low-limit
    acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:4:37.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
    objectIdentifier (tag 0) OBJID 0 analog-input,2
    event-state (tag 1) ENUM 3 high-limit
    acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:41:59.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:20.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:21.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
    objectIdentifier (tag 0) OBJID 214,1
    event-state (tag 1) ENUM 2 offnormal
    acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:20.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:21.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 0,0,0 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
   }
   moreEvents (tag 1) BOOLEAN FALSE   === ASN Body end === 

The first object is the list
objectIdentifier (tag 0) OBJID 0 analog-input,1
which has the low-limit status 
event-state (tag 1) ENUM 4 low-limit
and has unacknowledged transition to the offnormal status (i.e. according to D2000 terminology it is an active low-limit alarm which requires the acknowledgement):
acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
This transition occurred in time
dateTime (tag 2) SEQUENCE 2 {
date DATE 25.11.2005 Friri
time TIME 11:54:23.0
}

The alarm is acknowledged by writing a text value
0u1; 1o0:1 ; 2E2; 3{ 2{ D25.11.2005 T11:54:23} } 4C'D2000' 5{ 2{ D25.11.2005 T11:55:23 }}
and the individual items are as follows (see the definition of AcknowledgeAlarm-Request above):

After acknowledging of alarm and a repeated reading of the list of alarms and events by the GetEventInformation request , you will see the alarm has been acknowledged, as 
acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
will change to:
acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)

If the object had been in a normal state, it would not have been listed in the list of alarms at all. In this example it is in low-limit state, i.e. it is an active acknowledged alarm.

To read the list of alarms, to show them in a browser, and to acknowledge the alarm, you must write the ESL scripts which will parse the text value of GetEventInformation request and compose a text value for AcknowledgeAlarm.

Note: in the specific case, when acknowledging the alarm, the DESIGO PXC 100E.D device required the day of the week to be specified within the date (eg D8.6.2020.1 for Monday). A default value of 255 (unspecified) of a day of the week, which is sent when the day is not specified, did not suit the device when acknowledging the alarm.

Comment on address caching


If the station has at least one I/O tag with Address Type = Name, the numerical address is detected by Who-Has-Request from ObjectName when initializing these I/O tags. After getting the address, the data (the quadruplet ObjectName; Object Type; Instance; DeviceInstance) is saved to the cache file and is available for the next start of the KOM process.
There is one cache file for every station. It is located in an application directory, in a subdirectory Cache. Its name is Cache_station_name.txt, e.g. Cache_B.StationX1.txt.
When saving a BACnet station, the data is reloaded from this file. If the file was not found, the Who-Has messages are generated for all I/O tags that contain Address Type = Name in this station.
This behavior may be used after changing the configuration of the device which communicates with the KOM process (if the addresses of objects were changed when changing the configuration). Just delete the cache file in this station and save the station - within several seconds, the cache file will be created again and it will be filled with the acquired data.

Note: the interaction of cache and I/O tags with Request type = WhoHas.

Comment on Delta Controls devices


The test configuration included a DSC-1212E device connected to the local Ethernet network and a DAC-633 device connected to DSC-1212E over MS/TP interface (RS-485). D2000 KOM communicated directly with DSC-1212E, and with a DAC-633 over DSC-1212E (which performed the function of a BACnet router).
We used the ORCAview 3.30 Build 1481 software from which we obtained the following configuration information:

DSC-1212E
After logging on to the ORCAview and finding a DSC-1212E device, the object BACnet Settings 3200 (3200 is a software address of the particular device) can be found in the right pane of the Navigator window. Clicking on BACnet Settings 3200 opened a dialog window that contained several tabs. The first tab (Setup) contained also the UDP/IP port type. After clicking it, its parameters are displayed at the bottom of the window, among others Network (during the testing, we saw a specific number 40032), IP Address, and UDP Port.
When communicating with DSC-1212E, in the D2000 configuration of the station the Source network could be either set to the value of Network or left empty. The IP Address and UDP Port parameters must be used to configure the Address and Port parameters in the station configuration in D2000. A station type was BACnet/IP.

Note: On the Advanced tab, in the BACnet Properties area, the parameter Local Netwok Number was set to 10032 (it was the same as the Network port of the Ethernet type on the Setup tab). This port is used for BACnet over Ethernet communication (without the use of IP protocol), which is not supported by D2000 yet.



DAC-633
After logging on to the ORCAview and finding a DAC-633 device, the object BACnet Settings 3202 (3202 is a software address of the particular device) can be found in the right pane of the Navigator window. Clicking on BACnet Settings 3202 opened a dialog window which contained several tabs. The tab (Setup) contained also the MS/TP port with the Status attribute and its value Active, and the attribute Status Reference with a value BACnet Settings 3202 (NET1). After clicking it, its parameters displayed at the bottom of the window, among others Network and MAC Address.
When communicating with DAC-633, the following station parameters had to be configured in D2000:

As D2000 communicates with DAC-633 via DSC-1212E, the parameters Address, Port, and Source network, which correspond to DSC-1212E, and Destination network and Destination address, which correspond to MS/TP network between DSC-1212E and DAC-633, must be set in the station configuration.

Both devices support both polling and change method of reading of data (both ReadProperty and SubscribeCOV).
The Object type and Instance parameters in the configuration of the I/O tag were detected in ORCAview from the Object and Description attributes (e.g. object 3200.AI12 is Analog Input, Instance 12; the object 3202.PG3 is Program, Instance 3). The Address type parameter is Object type+Instance and Request type is SubscribeCOV, unless declared otherwise:

Communicated I/O tag types:


Comment on E-DDC3.1 devices


The communication worked with the following settings:


We tested ReadProperty, SubscribeCOV, WriteProperty (with the objects of Binary Output, Binary Value, Analog Value type).
Communicated I/O tag types (the test configuration contained only these types):


The device with the original firmware (2.01.05) did not properly handle Who-Is request. We had to upgrade this firmware to the version 2.01.16. Then everything, including WriteProperty, worked properly.

Comment on Siemens Desigo devices


Based on the document "DESIGO INSIGHT: Installation, setup and communication - Engineering guide", the recommended address settings for LonWorks communication are:

Comment on Klimasoft MBG-MSTP devices


The test configuration contained Moxa NPort 5150 (a converter from UDP to RS485) connected to the MBG-MSTP converter, which communicated with a heat meter Siemens UH50-A21R-SK06-G. The analog inputs were read, the MBG-MSTP converter supported ReadProperty only.
The communication worked with the following settings:

Comment on iLON 10 Ethernet adapter


When using the iLON 10 Ethernet adapter for communication you should realize that the communication processor of this device (Neuron 3120) has relatively short default buffers (network buffer is 66 bytes). Therefore it does not receive longer packets. It can be seen in the web interface of iLON 10 - on the Status tab, the Missed Messages number increases when trying to read the value (e.g. always after saving the I/O tag if its parameter Subscribe/read is marked). This problem occurred during testing when a time plan of a scheduler contained more than 4 time-value pairs. When there were 4 pairs, the length of the LON message was 63 bytes. After adding another pair via PXM20, the reading of the scheduler failed.

Warning! The NodeUtil utility enables to increase the size of the received packet by increasing both the network and application buffers. However, if you set improper values, you can damage the iLON 10 device (Neuron 3120 stopped communication with the user processor).
If you decide to reconfigure the size of buffers, just change it from 66 bytes to 88 (and reduce the number of buffers) because the KOM process informs, in its packets, that it is able to receive 50-byte ASDU (+ 3 bytes BACnet header and 16 bytes LON header).
The buffers of the PCLTA-10 ISA adapter (built on the Neuron 3150 communication chip) had long enough buffers (255 bytes).
After we bought a new iLON 10, the configuration was successful with these parameters:

    DEVICE:0> (B)uffer configuration
    Node buffer configuration
    Type			Count	Size	Bytes
    Receive transaction	11	13	143
    Transmit transaction	2	28	56
    App buffer in		2	82	164
    App buffer out		2	82	164
    Net buffer in		5	82	410
    Net buffer out		2	82	164
    App buff out priority	1	82	82
    Net buff out priority	1	82	82
    ==> Total bytes = 1265
    

Comment on BACnet MS/TP implementation


The implementation of BACnet MS/TP is not complete yet. It was tested only in an elementary configuration (the D2000 KOM against a BACnet MS/TP MicroGateway produced by the York company). The communication works with both the Serial line (RS485/RS232 converter was used) and SerialOverUDP Device Redundant line (Moxa NPort series 5xxx was used).
MicroGateway (York company) implements the communication of an MS/TP Master type (i.e. it sends the Poll for master frame to detect the existence of other Master stations). The D2000 KOM relies on a partner station and does not implement a method of sending this frame type. Also, it does not handle a failure of the station to which it sends a token.
The present implementation is applicable only for communication with one Master station. It can be used for communication with one or more Slave stations (not tested). Also, the time ratio could cause some problems in heavily loaded systems, i.e. KOM could answer the Poll for master or Token frames later than required, which might cause collisions on the line. The time ratios may become even worse when you activate the logs on the line.

Comment on BBMD (BACnet Broadcast Management Devices) support

The following feature concerning the conversion of text names to numeric addresses of measured points (Siemens Desigo devices) on the TCP/IP-UDP line has been added to the BACnet protocol (and is available in versions published after 17.01.2012): if the KOM process sends a Who-Has request and the I-Have response comes from another IP address, the KOM process searches for the station that sent the Who-Has request with the text name specified in the response (within the line). If such a station is found, the answer is matched to its challenge.
This feature is useful when communicating with multiple Siemens routers (behind which are, for example, BACnet/LON devices), one of which is configured as a BBMD (Bacnet Broadcast Management Device) and the other is not.
Model situation:
The KOM process communicates with two Desigo PXG80-N BACnet routers (Rtr1 and Rtr2). Behind each router is a LON network, for simplicity with a single Desigo PXM20 station (Des1 or Des2). Router Rtr2 is configured to forward BACnet broadcasts from the LON network to Rtr1.

Let's have one TCP/IP-UDP communication line and on it two BACnet/IP stations representing Des1 and Des2

The KOM process sends a Who-Has request to the Des2 device to convert the text name configured in the M.Des2_test address. The IP address of Rtr2 (10.0.0.2) is used for sending.
Rtr2 forwards the request to the LON network to Des2 (according to the parameters Destination network = 12 and Destination address = 2.2 specified in the configuration of B.Des2 station ). An I-Have broadcast response arrives from the BACnet/LON device Des2. As the BACnet router Rtr2 is without BBMD support, it forwards the response (assuming it is configured to do so) to the BACnet router Rtr1, which has BBMD support enabled.
Rtr1 forwards the I-Have message as a UDP packet to the KOM process because the Register-Foreign-Device parameter of B.Des1 station is configured and thus the KOM process has registered as a broadcast message recipient at Rtr1. This way, the I-Have message gets to the KOM process with a different IP address than the original request. The functionality described above matches such a response with a request from the B.Des2 station based on the match of the text name of the object in the sent request.

At the same time, one configuration limitation results from the described procedure - all the described activities take place in the context of one line, so it is necessary that all stations that are within the scope of one BBMD device are located on one line.

Tell commands


CommandSyntaxDescription
STWATCHSTWATCH StationNameTell command sends commands ReadProperty, ReadPropertyMultiple and Subscribe to the station based on the configuration of individual I/O tags.

Literature


ANSI/ASHRAE Standard 135-2001: BACnet - A Data Communication Protocol for Building Automation and Control Networks

ASN.1 Complete by Prof. John Larmouth


You can read blogs about BACnet protocol:


Changes and modifications


-

Document revisions


Ver. 1.0 - August 30, 2005 - first version

Ver. 1.1 - October 20, 2005 - support of schedulers, reading, and writing of ASN sequences

Ver. 1.2 - November 22, 2005 - support of dynamic detection of I/O tag address from the object name, address cache in a file

Ver. 1.3 - June 14, 2006 - support of BACnet router (tested with PXG80-N)

Ver. 1.4 - April 02, 2008 - partial support of BACnet MS/TP protocol (tested on BACnet MS/TP MICROGATEWAY on the cooler produced by York company)

Ver. 1.5 - June 25, 2010 - testing the cooperation with E-DDC3.1 from SE-Elektronic GmbH

Communication protocols