Best practices

I'm not going to run any risk of embarrassing anyone (other than me) by naming names, but there was an exchange on the BACNET-L today that rather implies we need something of a "BACnet Best Practices" document. Okay, the BTL Working Group has and is trying to do that in its BTL Implementation Guidelines document. But there are clearly things we miss, or perhaps that new developers miss when faced with this sizable standard. (And I don't blame them: In my "grasshopper" days of ancient yore, as the newly just-designated "corporate expert -- now learn it," I was on the horn often enough with questions.)

Today's case provided an example.

Somebody had fielded BACnet devices that ran into difficulties with a management system, and sent a query to the list about what the issues might be.

One of those problems was with "potential objects" such as an I/O pin that could be either an input or output, depending upon configuration. An old-timer BACneteer would respond that the list of objects in the device should only reflect what is present, not what could be present. Clearly, somebody's client made that assumption (which is the probable assumption, reading the standard -- does the language need to be more explicit? See Clause 12.11.16 in BACnet-2008).

(On the converse, not all workstation devices anticipated that one might configure, say I/O point #3 in a controller to be an input by creating the object "Analog Input #3", yet somebody created such a controller.)

Another of those issues was what to do if a sensor failed. It might seem obvious that an appropriate response was to deny read access to the input object's value, since it was not going to be correct, but some management device apparently recorded this as meaning that the value would never be readable. Understandable, because it's generally understood (though not codified anywhere) that Error messages tend to be protocol-oriented and not runtime-oriented.

It was pointed out that there is an expected approach to runtime issues such sensor failure, in this case through the Reliability and Status_Flags property. If a client device is reading, say, an input value ("Outside Air Temperature") it should also read the Status_Flags property to check the FAULT flag. If FAULT is true, it can check the Reliability property to see the reason why: whether it is NO_SENSOR, OPEN_LOOP, COMMUNICATION_ERROR or some other problems, and perhaps report that to the system operator.

All of this is known "best practice," but perhaps we have not propagated that well enough yet.

OTOH, all this would be rapidly conveyed to any vendor who submits his device to either of the BACnet conformance testing labs, which is one reason I always recommend specifying devices that bear the BTL Mark.