Writing of  the value

The value is written using the WriteProperty-Request message. This message contains items specifying the object and attribute, optionally the index (if the attribute is an array). This is followed by the value written (again "anything") and optionally the priority.

There exists a WritePropertyMultiple-Request message that allows you to write several attributes of the same object at once, but the D2000 KOM process does not implement it.

If we write primitive (basic) data types, in the configuration of the output measured point it is necessary to specify the application tag and optionally the priority (priority 0 means that priority is not sent in the request). How to find the application tag? The easiest way is to configure the input measurement point first, turn on communication monitoring, and look at the logs, which application tag was received.

This is how we write the primitive data type. But is it possible for the D2000 KOM process to be able to write "anything"? The answer is - yes. Using a text output measurement point and the same syntax for writing structures as mentioned above.

So, for example, writing the string " { 1{ u23 s34 } 2E56 3r7.89 }" means sending a BACnet structure

SEQUENCE {
    [1] SEQUENCE {
         Unsigned 23
         Signed 34
    }
    [2] Enumerated 56
    [3] Real 7.89
}

In this way, it is possible to solve the writing of the time schedule after its editing by the user in the D2000 scheme.

Time synchronization

TimeSynchronization and UTCTimeSynchronization messages are used for time synchronization. Both have a single BACnetDateTime parameter, which is a sequence of date and time. The D2000 KOM process can use one of these messages (depending on the setting of the Time-sync is UTC protocol parameter on the station) to periodically synchronize the time of the BACnet device.

Events and alarms

Using the GetEventInformation-Request, it is possible to request from the device a list of objects that are in alarm states (the Event_State attribute is not in the Normal state) or whose transition to the Offnormal, Fault, or Normal alarm state has not been acknowledged (the Acknowledged_Transitions attribute has at least one bit set). It is, therefore, the equivalent of the process alarms in the D2000.

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

·         objectIdentifier: object identifier

·         eventState: object state (0=normal, 1=fault, 2=offnormal, 3=high-limit, 4=low-limit, 5=life-safety-alarm)

·         acknowledgedTransitions: 3 bits indicating whether the last transitions to offnormal/fault/normal states were acknowledged

·         eventTimeStamps: timestamps of the last transitions to the offnormal/fault/normal states

·         notifyType: indicates whether it is an alarm (0) or event (1) notification

·         eventEnable: 3 bits indicating whether to-offnormal, to-fault, to-normal events are reported

·         eventPriorities: 3 unsigned values indicating event priorities

At the end of the list, there is the moreEvents attribute, which has the value True if the list of events is not complete (exceeding the length of the maximum message, etc.). Then it is necessary to reconfigure the measured point and set the Object type and Instance to the last object in the list, which will generate a new GetEventInformation-Ack message (containing the lastReceivedObjectIdentifier), which will be the next part of the event list. Reconfiguration can also be done dynamically from a script using the SETPTADDR command to dynamically set the address of the measured point. In this way, it is possible to read a list of objects with alarms "page by page"  in the script and then display them to the user.

Alarms can then be acknowledged using the AcknowledgeAlarm-Request message. Since this is a multi-item message, the text output measurement point is used again for writing. A specific example of alarm acknowledgment is given in the D2000 help.

Siemens specifics

All manufacturers whose devices we have encountered (Delta Controls, Klimasoft, Sauter, York, SE-Electronic) respect the BACnet convention - an object is identified by the type and instance. This identification is found in all messages that handle or reference objects, in the form of the BACnetObjectIdentifier data type. The only exception is Siemens (sometimes I get the impression that their motto is "Think complicated"). Siemens Desigo management devices implemented by BACnet use object names to identify them. When editing a project and recompiling it and uploading it to a Desigo device, object instances may change, but object names remain. How to solve such a complication?

To support Desigo devices, the ability to address by name has been added to the measured point configuration. The BACnet protocol supports the Who-Has message to determine if a device contains an object with the required name or identifier.

For all measured points addressed by name, the D2000 KOM process sends a Who-Has request at the beginning of the communication and receives an I-Have response containing the object identifier.

Subsequently, it works with the measured point in the usual way. Because the BACnet device can have hundreds of objects and reading can take a long time on slow lines (LonWorks, MS/TP), the D2000 KOM process stores the responses in a cache file, so it no longer has to send requests the next time it is started. After uploading a new project to the Desigo device, it is necessary to manually clear the cache. Then, it is not necessary to restart the D2000 KOM process, but simply to save the appropriate communication station. The D2000 KOM process detects the clearing of the cache and performs the process of converting object names to identifiers again.

Browsing

The Browse button is visible in the previous measurement point configuration figures (e.g. Figure 21). What is it for?

The BACnet protocol supports reading a list of objects from the device, so it is possible to select an object (object type and instance, or object name) by selecting from the read list - provided that the D2000 KOM process is running and the communication with the device is functional. To read the list, it is necessary to know the device identifier, so browsing consists of two phases:

Phase 1 - determination of the device identifier. The D2000 KOM sends a Who-Is request and receives an I-Am response containing an instance of the Device object.

Phase 2 - sequential reading of the object-list (76) attribute of the object of Device type. This attribute is an array of object identifiers (object type + instance). Firstly, the size of the array is determined, then the array is read sequentially by ReadProperty requests. For each object identifier received, its object-name(77) and description(28) attributes are read. These are continuously sent to the D2000 CNF process so that the user can follow the gradual filling of the list of objects. Subsequently, it can filter and sort values in it, or insert its content into the clipboard and further process it (e.g. in Excel).

Because the reading of a list of objects is time-consuming (speed is usually only a few lines per second, even slower on slow media), the D2000 KOM process remembers the list of found objects and makes the results available immediately on the next request. The user can force the list to be reloaded by pressing the Refresh button in the browser window.

Conclusion

The BACnet protocol specification has more than 570 pages. This article did not focus at all on some of the options that BACnet offers (dynamic creation and deletion of objects, working with files, optional message segmentation, etc.), but aimed at reading and writing of values, and working with alarms, which are the basic required functionality for the superior SCADA / MES system.

Ing. Peter Humaj, www.ipesoft.com