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
Literature
Changes and modifications
Document revisions

Supported device types and versions

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

Characteristics of the current version:

BACnet protocol consider 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 in the whole network). This object contains other object 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 Request type Who-Is and Who-Has.
Each object has the properties, which can be required and optional. Moreover, each producer of BACnet devices can implement other properties when necessary.
The messages in BACnet protocol relates to the manipulation with objects and their properties. They are defined by the help of ASN.1 (Abstract Syntax Notation version 1) and encoded by simple version of BER (Basic Encoding Rules - encoding of ASN.1 messages).
The messages contain, besides fixed defined items, also the items 'Abstract Syntax & Notation'. It means that any sequence (or "tree"), which meaning is defined by an implementator, can be on the given 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 message that is being parsed), you can find out that on the particular position is the context tag No. 5 of the length 4 bytes, but you need an additional information whether the value is Unsigned, Signed, Real, Bitstring or other one.
Besides the simple application and context tags, the properties may be also complex:

Example - a dump from trace file of 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 ===


Explanation:
It is the Sequence of two tags: objectIdentifier is contextual tag with the number 0, of Object Identifier type. Its value is Object type=0 (analog input), Instance=10.
The tag listOfResults contains the contextual tag 1 which is Sequence of two tags. First one is propertyIdentifier. It is the contextual tag No. 2,  Enum type, value = 85 that correspond to "present-value". A second tag is contextual one, No.4. It the sequence that contains one Enumerated Value tag with the value=1 (application tag).
To parse this message, KOM process must know ASN.1 definition of message. Without it, the process can find out that the message contains the contextual 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 do not know that the name of this contextual tag is propertyIdentifier and the value 85 correspond to "present-value".

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

Communication line configuration


Line protocol parameters

KeywordFull nameMeaningUnitDefault value
DBGIDebug 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
  • next bits - not used
-0
DTQDebug Timeout QueueDebug information about messages in time queue.-False
DIDevice 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
RBReceive Buffer(only for TCP/IP-UDP line) Size of received buffer which is set on UDP socket. 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 enlarged.bytes0
ROReceive OnlyIf value is True, any messages are not sent to any station on the line. This parameter may be used when listening the communication LonTalk: Configure the address, which is the same as the address of 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 to the log file of line. RO=True ensures that KOM process does not influence the communication by its commands and responds.-False
SCSend Count(only for LonWorks line) 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 Free topology bus had not been ended by a terminator. However, this parameter had been already implemented.		-1
SDSend Delay(only for LonWorks line) A complement to SC parameter that defines a delay (v ms) after each sending of packet.ms0
VIVendor IDParameter Vendor ID of I-Am message (see the parameter Device Instance).-1


Line protocol parameters specific for BACnet MS/TP

KeywordFull nameMeaningUnitDefault value
BRMS/TP baud rateBaud rate of line. This parameter recalculates some timeouts that are defined in a bit time in the communication line protocol. Bit time is a multiple of period which is required when transferring 1 bit at the particular baud rate.bits/sec9600
MIFMS/TP Nmax_info_framesMaximum of information frames that may be sent by KOM process before it must send a token. The standard does not specify the 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
MOMS/TP Nmin_octetsMinimum number of data (bytes) received on the line to be received by KOM process before it indicates the line as "active".-4
MYMS/TP my addressAddress of 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
TFATframe_abortMinimum time (the unit is length of bit transmission, i.e. it depends on MS/TP baud rate), after it expires, the whole frame is discarded if it does not receive other token. According to standard, the value may be higher but it cannot exceed 100 ms in the absolute time.bits60
TNTTno_tokenTime (in milliseconds). After it expires, without receiving any data, the token disappears.ms500
TRTreply_timeoutMinimum reply time of station.ms255
TSTslotTime during which the station can generate a token.ms10
TUTusage_timeoutMinimum time for which KOM process must wait while a partner start to use a token or respond on Poll for master frame. A standard value is 20 ms. According to a standard, the value may be higher - maximum 100 ms.ms20

Communication station configuration

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





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

Example of station configuration on LonWorks line:


Station protocol parameters

Key wordFull nameMeaningUnitDefault value
RSDReceive-send DelayDelay between the receiving of the reply from station and sending next packet.ms0
SRSegment-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 BACnet standard. KOM process considers the value 128 as default:
  • LonWorks line: set the value to 0x70 (more than 64 segments are accepted, maximum length of message is 50 bytes)
  • TCP/IP-UDP line: set the value to 0x75 (more than 64 segments are accepted, maximum length of message is 1476 bytes)
  • Serial and SerialOverUDP Device Redundant line: set the value to 0x73 (more than 64 segments are accepted, maximum length of message is 480 bytes)
-128
TSUTime-Synchronization UTCThe parameter is important only if the synchronization is enabled on the tab "Time parameters" in the configuration of station.
If the parameter is True (default), the time synchronization is executed by the message UTCTimeSynchronization-Request (the synchronization in UTC). If the parameter is False, the time synchronization is executed by the message TimeSynchronization-Request (the synchronization in the local time).
Notes:
  • We recommend you to use the synchronization in UTC, if it is supported in the device - you can avoid the problems when advancing the time.
  • The requirements for the time synchronization are the unacknowledged messages, i.e. the device will not send the answer neither if it supports the time synchronization nor if it does not support.
  • 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 "property local-date(56)" and "local-time(57)" of the object of Device(8) type.
    From this object, you can find out also "property utc-offset(119)" which defines the offset of local time from UTC (in minutes, i.e. -60 is Central European Time) as well as "property daylight-savings-status(24)", 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 "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 on "Browse" button in Address tab of I/O tag, Bacnet Item Browser dialog box opens. In this dialog box user may browse the address space of a device and insert its items to the address dialog of I/O tag.

The items can be filtered through the four basic criteria:

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

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

Browsing of address space

Record of any ASN sequence
Any ASN sequence can be written with the help of I/O tag - text output (TxtO) without setting of application tag. The rules are the following:

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

Note 2: The empty sequence may be recorded by the 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 set properly (for binary value it is Enum), Desigo station returns an error 'invalid-data-type' when trying to record it:

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

Siemens Desigo PXC64-U device requires to set the following parameters for Application tag:

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

When writing the value, the message WriteProperty-Request is used. As Subscribe/read is ticked, the written value is reread. If I/O tag would be configured with Request type WriteProperty, its behavior would differ only in an absence of periodic value reading (when starting KOM process and during its running, the period is set on the station, tab Time parameters).

Comment on Siemens Desigo devices: I/O tags has a text name in the Desigo control system. The instance of I/O tag may be detected from the file DOTS00.DAT in the application  configuration - it is placed 24 bytes before 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 the field of 7 items (one item for each day in week). Each item represents a sequence of time-value pairs that defines the value changes of scheduler in given time. When reading and writing you can configure also Array index which enables to access to the items in an array weekly-schedule(123). The array index is 1-7 for single days (1=Monday), the index 0 contains a size of array (value 7 for the attribute weekly-schedule(123)), value 0 up to N for exception-schedule(38).
Exception-schedule is intended for the holidays that require different regime as is configured for common days. Exception-schedule is the sequence of 0 up to N items. One item always contains date (or range of dates), several time-value pairs (as regards weekly-schedule) and priority (1= top, 16= the lowest). The priority defines which of the items will be used if they overlap.

Reading of scheduler (the attribute weekly-schedule)

Note 2



Recording of scheduler (the attribute weekly-schedule)

Note: Another possibility, besides the special request ReadWriteScheduler, to write weekly-schedule is recording of 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 frame for whole week, if Array index is not set and the value contains 7 sequences for the 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} 0{ T0:0:0.0; u3; T1:2:0.0; u1; T2:0:0.0; u2; T5:30:10.0; u3}".


Recording of scheduler (the attribute exception-schedule)

The recording of the exception-schedule is supported over the recording of ASN sequence.
Example: I/O tag configuration:

With the help of this string "0{ 0D2.10.2005 } 2{ T1:0:0; u1; T12:0:0; u3 } 3u10" you can write the time frame for the day October 2, 2005. The scheduler has the value 1 from 1:0:0, the value 3 from 12:00:00. The priority exception-schedule is 10. When rereading of value (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 exception-schedule is 15. When rereading of value (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 by the string which contains jointed 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 Delta Controls DAC-1146 device. Only BACnet attribute weekly-schedule(123) was tested. The weekly-schedule is an array with 7 items (one item for each day in week). Each item is the sequence of time-value pairs that define the value changes of scheduler in given time. In contrast of 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 has done and then reading of value E2, however the interpretation by DAC-1146 is unclear.

Information about events

The request GetEventInformation-Request is intended to call for the list of objects that are in the state Offnormal or Fault or whose change to Offnormal, Fault or Normal has not been acknowledged from the device.
Example of I/O tag configuration:

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

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

Example of response GetEventInformation-Ack:

 === 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 loaded by the request GetEventInformation. According to 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
  }

The more detailed description of the parameters is stated in a literature.
The acknowledgement is executed by the writing of above mentioned sequence to the text of output I/O tag according to the record of any ASN sequence.

Example: The loading of list of alarms and events with the help of GetEventInformation:

   ===  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 object is the first in list
objectIdentifier (tag 0) OBJID 0 analog-input,1
which is in the status low-limit
event-state (tag 1) ENUM 4 low-limit
and contains unacknowledged transition to the offnormal status (i.e. according to D2000 terminology it is an active alarm low-limit 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 with the record of 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):

After acknowledging of alarm and loading the list of alarms and events by the request GetEventInformation, you will see the alarm has been acknowledged.
This record:
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 normal state, it would not have been listed in the list of alarms. In this example it is in low-limit state, i.e. it is an active acknowledged alarm.

To load the list of alarms, their record to a browser and acknowledgment of alarm, you must write the service scripts which parse the text value of the request GetEventInformation and compound it for AcknowledgeAlarm.

Comment on address cache

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 (ObjectName; Object Type; Instance; DeviceInstance) are saved to cache file and are available for next starting of KOM process.
For each station there exists one cache file. It is placed in an application directory, subdirectory Cache. Its name is Cache_station_name.txt, e.g. Cache_B.StationX1.txt.
When saving BACnet station, the data are reloaded from file. If the file was not found, the Who-Has messages are generated to 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 KOM process (if the addresses of objects was changed when changing the configuration). Just delete the cache file in this station and save it - the cache file occurs again and is 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 DSC-1212E device connected to the local network Ethernet and DAC-633 device connected to DSC-1212E over MS/TP interface (RS-485). D2000 KOM communicated directly with DSC-1212E and DAC-633 over DSC-1212E (it performed the function of BACnet router).
We used the software ORCAview 3.30 Build 1481 from which we detected the following configuration information:



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

I/O tags:


Comment on E-DDC3.1 devices

The communication was revived according to the following configuration:


We tested ReadProperty, SubscribeCOV, WriteProperty (in the objects of Binary Output, Binary Value, Analog Value type).
The defined I/O tags (the test configuration contained only these types):


The device (2.01.05) with the original firmware did not work with Who-Is. 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 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 converter MBG-MSTP, which communicated with a heat meter Siemens UH50-A21R-SK06-G. Only analogue inputs was detected. The converter MBG-MSTP supported only ReadProperty.
The communication was revived according to the following configuration:

Comment on iLON 10 Ethernet adapter

When using 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 the longer packets. It can be seen in the web interface iLON 10 - tab Status and the parameter Missed Messages 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 when schedule of scheduler contained more than 4 pairs time-value. When there were 4 pairs, the length of LON message was 63 bytes. After adding next pair via PXM20, the loading of schedule failed.

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

Comment on BACnet MS/TP implementation

The implementation of BACnet MS/TP is not complete yet. It was tested only on basic configuration (KOM against BACnet MS/TP MicroGateway produced by York company). The communication works with both 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 MS/TP Master type (i.e. it sends the frame Poll for master to detect the existence of other Master stations). KOM relies on a partner station and does not contain the method of sending of this frame. Also it does not solve a failure of the station to which it sends a token.
The actual implementation is applicable only for communication with one Master station. It can be applicable for communication with one or more Slave stations (not tested). Also the time ratio could cause some problems in loaded systems, i.e. KOM could answer to the frames Poll for master or Token later than in required time, which may cause the collisions on the line. The time ratios may become worse when you activate the logs on the line.

Literature

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

ASN.1 Complete by Prof. John Larmouth

Changes and modifications

-

Document revisions

Communication protocols