BACnet - a brief introduction to the basics part 4

Writing values, priorities

In the previous section, we integrated an object of type Analog Input, ie an analog value. It is a good idea to start with a known quantity, such as the room temperature, because the real number is clearly visible at first glance, sometimes changes and can be easily checked, unlike, for example, binary values. In the vast majority of cases, we will only need a few basic types of objects:

  • Analog Input, Analog Value, Analog Output,
  • Multistate Input, Multistate Value, Multistate Output,
  • Binary Input, Binary Value, Binary Output,
  • Schedule - a separate chapter will be devoted to this.

For Schedule objects, ... Value and ... Output objects, it is also possible to write to the Present Value property. It makes sense, the Analog Value can store the required temperature, for example, and the Binary Output is, for example, a relay output that can be remotely controlled.

This brings us to the issue of writing.

For other, simpler communication protocols, it is simply the case that if a variable is writable, the value changes when a write request is made. Write protection can be provided, for example, by some login using a username and password: once the client is logged in, it can set a variable. If there are several entries in a row (even from different clients), the value entered last applies. We are used to it and it is logical and understandable.

BACnet has these mechanisms addressed differently, through priorities. There are a total of 16 priorities and they are, as usual, standardized. (At least some.) The smaller the number, the higher the priority:

Priority Description
1 (the highest) Manual Life Safety
2 Automatic Life Safety
4 Critical Equipment Control Manual
5 Critical Equipment Control Automatic
6 Minimum On/Off
7 Manual Operator Switch
8 Manual Operator Unit
14 Specific Command Control
15 Program Control
16 (the lowest) System Control

Blank priority names are freely usable, the device manufacturer can name them according to their needs. We can already see from the names that if the variable is controlled by a program with priority 15, ie quite low, and the operator would switch it over the control panel (ie priority 8), this control by the counter will take precedence. A step higher authority is, for example, the switch on the switchboard connected to the PLC input, which would have priority 7 - manual override by the operator "from the place". However, even more important is, for example, the overheating of the exchanger reported by the emergency thermostat, which would probably have priority 5, ie a critical override of the technology automatically.

Each writable object has two mandatory properties: Priority_Array (priority field) and Relinquish_Default (default value when released). This can be seen, for example, in the Analog Output object:

Fig. Properties for priorities for an object of type Analog Output. Source: ISO 16484-5, (C) ISO 2016

Fig. Properties for priorities for an object of type Analog Output. Source: ISO 16484-5, (C) ISO 2016

The priority field has 16 positions for storing values of the same type as the Present_Value object (for Analog_Output it is type Real). This is because if a priority is included in the enrollment request, the new value is written to the appropriate position for that priority. (Writing can be done without specifying a priority, then it is automatically considered the lowest priority request.)

Fig. Examples of entries with and without priorityFig. Examples of entries with and without priority

Figure a) shows the priority field of the object to which the value 23 with priority 8 has been written, Manual Operator Unit. This corresponds, for example, to a situation where the valve is set to 23 % from the control panel. The output, Present_Value, of this object is set to 23 because there is no entry on any of the higher priorities (1 to 7).

In the next step, a process, such as a control loop, writes a value of 19 to this object. This write is without a priority setting, so it is considered the lowest priority action (16). The value 19 is written to the appropriate item of the priority field, but this does not affect Present_Value, ie the output of this object - the value 23 % is stronger on priority 8. This situation is shown in Fig. b).

Now there will be an automatic write, let´s say from the procedure for emergency shutdown of the exchanger. With priority 5 (ie Critical Equipment Control, as we see in the table above), the value 0 is written. Because this is the record with the highest priority so far, the Present_Value of the object is set to 0 and the valve closes. (Fig. c).

What happens when the emergency situation disappears? The emergency procedure transfers control to normal regulation with lower priorities by releasing the priority: it writes a special "empty" value to the appropriate priority (here 5), symbolized by a dash in the figure. This gives up its reassignment and "it doesn't care what comes out." The situation in Fig. b) occurs again and the highest non-empty value from the top is at the output of the object, ie a manual intervention of 23 %. If the operator canceled the manual override from the counter, the output would be the value from the control loop that wrote with the lowest priority, ie 19 %.

If all 16 priorities have an "empty" value, the object output value will be Relinquish_Default.

In this way, BACnet elegantly aligns with the various priorities of write requests without the need for complex process logic in the program. For us, however, this means that if we are not entirely sure with what priority we can write, let's choose write without priority (in Merbon IDE "Not specified"). Otherwise, we could significantly interfere with the function of the device. It is not possible to send the priority release from the PLC or visualization, resp. there is no way for the PLC to "self" determine when the priority should be released. It is an automatic write with predefined properties, only the written value changes.

It is similar with the BACnet client Promotic, which has the option of selecting the priority for writing directly in the definition dialog of the variable:

Fig. Variable definition in Promotic visualizationFig. Variable definition in Promotic visualization

For visualization, we can set the priority ourselves, for the required values (temperatures, pressures, humidity, etc.) the notation without priority would probably be used. If the priorities are equal, the last value entered from any device applies.

PLCs with the Domat runtime use priority 16, the lowest, in the BACnet client function for writing to other devices. This is because it is an automated rewrite, and a higher priority such as 8 could conflict with a manual rewrite from the service terminal or from Scada.

Interesting fact: the settings from the local Siemens PXM20-E counter on the switchboard use priority 8 - manual override from the control panel. The data point is then displayed in the manual state (assembly key symbol). When released from the manual state, the counter writes NULL with priority 8, thus releasing the manual state.

In the last picture we see for illustration part of the answer to the question Read Property Multiple. An object (of the Multistate Value type, which is not visible in the viewport) has a current value (Present Value) of 1, because its only occupied priority is 16, just with a value of 1. Other, higher priorities are released, each has NULL value in the report.
 Fig. Priorities in the Wireshark listing

 Fig. Priorities in the Wireshark listing