Wednesday, December 30, 2009

Basic BACnet: objects and properties

Hard to believe it's been over 13 years since my article "The Language of BACnet" was published (available on the BACnet.org website), but here we're revisiting that material again, though a bit more briefly and in this blog post I will only cover BACnet Objects and Properties, leaving Services for a subsequent posting.


In this posting we will focus on how data is presented over the networks to other devices by the application program. In some protocols data may be fetched simply by a number (e.g. "Give me data item #37"), but one has to know beforehand what one is asking for: what its datatype is (is it an integer, a floating-point number, or a string of text?), and what it represents (is it a status indicator, a message, a measure value?). Such protocols are easily implemented on controllers with very little memory, but configuring systems using them takes a bit of work.


BACnet, on the other hand, uses a self-descriptive system called "objects and properties." Very roughly, an "object" represents some aspect of the device. For example, an "Analog Input" object could represent a temperature or air velocity sensor. A "Binary Output" object might control a relay. A "Multi-state Output" might be a fan speed control -- off, low and high. A "Calendar object"... well, we'll look at the various kinds of BACnet objects later.



A general rule is that an object presents some element of a building automation system, including I/O, schedules, issuing alarms, trendlogging data values, downloading and executing user-created programs and so on. Often the object is "centered" on a data value as in the example here, where a thermometer input is represented by an Analog Input object and that data value is presented in a "property" of the object called "Present_Value" (in the drawing just "Value"). Of course, that number is useless by itself because we don't know the units -- it could be degrees Fahrenheit, Celsius, Kelvin or Rankine. (Does anyone use Rankine?) So we need another property called, of course, Units. Part of the object's self-description is to advertise its object type in yet another property (shown here as "Type" but actually called Object_Type").


Every object in a device is uniquely identified by its type and "instance number" (Binary Value 0, Binary Value 1, ..., Binary Value 9999). But it can also be uniquely labeled through either the Object_Name property or the Description property, both of which hold text strings though the former property is required and the latter is optional (a decision to be made by the implementer of the device).



Required versus Optional: BACnet establishes a minimum set of properties for each object type, but defines additional properties that can be included if certain additional capabilities are supported. For example, if one wants to issue alarms for a temperature being out of range one can add a set of properties that include the range limits, as shown here.


The following table (from "The Language of BACnet" article) shows the full set of defined properties for the Analog Input object, (at least as it was in 1996; properties have been added since then):




A property of an object is accessed, for reading or writing, by sending a message that says, for example: "Tell me the value in object Analog Input 1's Present_Value property." If that object is the on in the table, the answer would say: "the value in object Analog Input 1's Present_Value property is 68.0".

Thursday, December 17, 2009

Basic BACnet: packet delivery

I've had quite a difficult time getting back to the blog, what with a big internal project, Smart Grid work, and other after-hours activities chiseling away at my time this week. In part too it's because I underestimated the work ahead, so I will break some of the "Basic BACnet" sections into smaller pieces.


We'll start with the BACnet protocol stack, which is fairly complex inside but at a non-technical level can be described fairly simply.


BACnet Stack
A BACnet device can be defined as having two elements. The uppermost is the "application", which is the functionality of the device whether it's a simple thermometer (represented by the gray part in the figure), a complex controller, a workstation, or whatever else. The lower portion is the protocol stack, whose function is to take information issued by an application in one device and deliver it to an application in some other device.


An analogy can be made with the a process of a medieval lord (let's call him Sir Aldfrid) sending an important message to another lord (Sir Bertwald), elsewhere in the realm.



Sir Aldfrid calls for his scribe, dictates a letter to be sent to Sir Bertwald. The scribe converts it to Latin, the language understood by all scribes everywhere, and writes it down on paper.



The scribe the hands the letter to a secretary who makes a copy of the letter (just in case), puts it in an envelope, makes a note about when and where the letter was sent, and hands the envelope to the cartographer.



The cartographer then decides from his maps which direction (or roads) should be used, selects a courier to carry the message, and hands him the envelope and a map. (Couriers are not very bright.)



When the courier arrives at the destination castle, he hands the envelope to the cartographer there, who hands it to the secretary.



The secretary gives a note to the cartographer to give to the courier to carry back to the original castle so they know the letter is delivered and the copy can be destroyed. (If the return note is not received within a specified number of days, a copy of the original letter will be re-sent.) The secretary opens the envelope and hands the letter to the scribe, who will read it to Sir Bertwald, translating from Latin to the local language.


In American postal parlance, this letter was sent "registered, return receipt requested," and each actor in this scenario represents a layer of the BACnet protocol stack. The lord represents the communicating application, the scribe converts the message to or from BACnet, the secretary tries to make sure the message is delivered or informs the sender of a message that it has been received, the cartographer directs the message across the proper routes, and the courier carries the actual packet over the roads (networks).


And that's it!


Well, almost. There are variations of this situation, to wit:


1. Sir Bertwald is to return a letter with the courier. In this case Sir Bertwald's secretary doesn't make a copy of the return letter, he just places it in the envelope and hands it to the cartographer.


2. Sir Aldfrid doesn't need a reply. In this case Sir Aldfrid's secretary doesn't make a copy, he just places the letter in the envelope and hands it to the cartographer.


3. The letter is to be sent to all lords (broadcast), with no reply expected. This is very similar to #2 except the message is carried or copied to everyone.

The example presented here consists of one single network. If there are multiple networks (i.e. the courier has to pass through several realms, going on horseback, by boat, or on foot depending upon the realm) the picture is quite a bit more complicated but the process is pretty much invisible except to BACnet implementers or when some realm (BACnet router) isn't following the rules.

Monday, December 14, 2009

Basic BACnet

During the BACnet International plugfest, Sarah said that the blog was beginning to provide her a bit of a look into the BACnet world, though she still didn't know much about BACnet itself. Ever since then I have been considering drawing on my non-technical (or maybe semi-technical) hour-long "Basic BACnet" presentation for an introductory series on this blog, probably in three parts: "Scheduling, Trending and Alarming," "Objects, Properties and Services," and "Packet Delivery."


So when this comes up soon, Sarah, it's for you.

Tuesday, December 8, 2009

Slave proxy

Yesterday there was a short exchange on the BACNET-L e-mail list about the slave discovery mechanisms (Clause 12.11.41, Auto_Slave_Discover) used for proxying I-Ams for MS/TP slave devices. If implemented incautiously, such a mechanism could use 100% of MS/TP bandwidth for a minute while it polled for unknown new slaves. The recommendation that a mechanism for turning on the search capability when the LAN is (re-)configured seems a reasonable one, and perhaps someone (Thomas? Leeds?) should submit a proposal for this.


For my part I remain an abolitionist, and wish we could get rid of the slaves. As I noted here months ago, it takes little additional code and memory to implement a master. JMHO

Monday, December 7, 2009

Broadcast management and IPv6

The issue of broadcasts in BACnet has come up again -- and it looks like I have some reading to do.


In normal situations broadcasts are not an issue in BACnet and this has lead to different approaches to broadcasts. For example, early BACnet adopter Company A by default sends all alarms in Confirmed-Request messages (return acknowledgements are expected and the message is re-sent if the acks aren't received in time). But another early adopter, Company B, broadcasts an alarm, expecting that it will reach every device that is supposed to receive it. The former approach intends to guarantee delivery but may result in a number of messages being sent for one alarm; the latter assumes delivery but requires only one message.


This difference is no doubt in part based on certain assumptions about the BACnet netorks, but experience gained over time says it doesn't really matter for a properly functioning system. Both approaches work.


Of course, this requires attention to the proper use of broadcast messages. The classic example of misuse is to periodically send an unrestricted Who-Is broadcast, which results in every single device broadcasting an I-Am response. On the lab workbench this works just fine; in really large systems this doesn't. (Which is a reason why the BACnet Testing Labs working group permits the unrestricted Who-Is broadcast in only one situation -- devices that violate this rule will not be awarded the BTL Mark. [Insert my usual plug for specifying devices that have the Mark.])


It also requires attention to handling the situation where a device or a network of devices goes offline and the peer devices start trying to locate the absent device(s). Again, the rules are fairly well known so that very large networks can be constructed.


Still, experiences with improper implementations or acquired experience with ever-larger systems has led a number of BACneteers to wish for mechanisms to reduce broadcasts. One such published not long ago (Addendum 135-2008q-2) allows I-Am responses to be sent directly to the Who-Is requester instead of requiring that they be broadcast.


Where this has come up now is in, of all places, the Internet Protocol working group, where the topic of supporting IPv6 has come to the fore. IPv6 is already important in some places around the globe, where the available IPv4 addresses have already been exhausted. It appears IPv6 has a means for eliminating broadcasts, with concepts that possibly be brought into BACnet in a more general means.


It's not clear to me right now how all this will play together, and as one member of the group notes, the "dynamic binding" aspect of BACnet (such as obtaining a device's network address using only its device instance -- sort of a "Car 54, where are you?" mechanism) relies on broadcasts. I can imagine ways in which this could be made to work without global broadcasts, but I don't know exactly what's been done in IPv6.


Some general approach questions have been put to the group. Looks like I'll have some light reading to do during the holidays.

Thursday, December 3, 2009

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.

No news is not, well...

...good news (for me). Last Friday, the day after U.S. Thanksgiving, I woke up ill (not H1N1) and have not fully recovered yet. Went into the office yesterday only because of an important meeting (hear that, Babak?) -- I hate calling into face-to-face meetings because the dynamics are so different than teleconferences and weigh against the caller; better just to go.


But the major amount of my time today will be spent in teleconferences (BACnet Testing and Smart Grid activities); I can do that from home. And at least have made it thus far without coughing the whole time.


Next teleconf is coming up. More soon.