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 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.

Sunday, November 29, 2009

Conserve energy -- consume more energy?

Following (somewhat) the twists and turns of the so-called "Climategate" fiasco this holiday weekend (being home ill, I had time), which has embroiled climate research facilities in the UK and New Zealand, I'd been trying to decide what this means for our business. After all, one important aspect of building automation systems is to reduce energy usage.

After having concluded it won't affect our business much, I was surprised to read this report on Slashdot. The concluding sentence of the item: "Perhaps the most provocative implication of Garrett's theory is that conserving energy doesn't reduce energy use, but spurs economic growth and more energy use." Hm.

Wednesday, November 25, 2009

Smart Grid Interoperability Panel - Governing Board

The runoff election in Category 18 is done and the SGIP Board is announced (which might not mean a lot to most folks, but there was considerable electioneering involved since this group is going to be shaping the future of power distribution in the U.S.):

Category 1 - Appliance and consumer electronics providers: Brian Markwalter,
Consumer Electronics Association

Category 2 - Commercial and Industrial equipment manufacturers and automation vendors: Tariq Samad, Honeywell

Category 3 - Consumers – Residential, Commercial, and Industrial: Todd Rytting,
Panasonic Electric Works Laboratory of America

Category 4 - Electric transportation industry Stakeholders: * open *

Category 5 - Electric utility companies – Investor Owned Utilities (IOU) and Publicly Owned Utilities: George Bjelovuk, American Electric Power

Category 6 - Electric utility companies—Municipal (MUNI): * open *

Category 7 - Electric utility companies—Rural Electric Association (REA): Bob Saint,
National Rural Electric Cooperative Association (NRECA)

Category 8 - Electricity and financial market traders (includes aggregators): * open *

Category 9 - Independent power producers: Kenneth Van Meter, Lockheed Martin’s Energy Solutions

Category 10 - Information and communication technologies (ICT) Infrastructure and Service Providers: Matthew Theall, Intel Corporation

Category 11 - Information technology (IT) application developers and integrators: Vint Cerf, Google Inc.

Category 12 - Power equipment manufacturers and vendors: Le Tang, ABB Inc.

Category 13 - Professional societies, users groups, trade associations and industry consortia: Wayne Longcore, Consumers Energy

Category 14 - R&D organizations and academia: Mladen Kezunovic, Texas A&M University

Category 15 - Relevant Federal Government Agencies: Perry Pederson, Nuclear Regulatory Commission (NRC)

Category 16 - Renewable Power Producers: John Nunneley, SunSpec Alliance

Category 17 - Retail Service Providers: Brent Hodges, Reliant Energy

Category 18 - Standards and specification development organizations (SDOs): John Caskey, National Electrical Manufacturers Assoc. (NEMA)

Category 19 - State and local regulators: Paul Centolella, Public Utility Commission of Ohio

Category 20 - Testing and Certification Vendors: Rik Drummond, Drummond Group Inc.

Category 21 - Transmission operators and Independent System Operators: Jamshid Afnan,
ISO New England Inc.

Category 22 - Venture Capital: * open *

Category 23 - At Large:

   Paul De Martini, Southern California Edison

   John McDonald, GE Energy

   Mark McGranaghan, Electric Power Research Institute

Tuesday, November 24, 2009

A week of quiet

Things are pretty quiet, no doubt because folks are away for the (U.S.) Thanksgiving holiday later this week. Even my e-mail is relatively quiet, with only one of the various newsletters I receive having come in this week; even the mailing lists, including BACNET-L, are silent.

I'm taking advantage of this to catch up --finished all my expense reports from late September on (9 reports total!)-- because things are going to get very busy on the Smart Grid front next week.

Sunday, November 22, 2009

Grid Interop 2009 wrap-up

Grid Interop 2009 has to go into the record books as the most intensive conference in which I have ever participated, hence the silence since Tuesday. Full of presentations of work done so far, directions forward, and just general discussions of the 15 PAPs (Project Action Plans) that have already been underway but which are now under the aegis of the Smart Grid Interoperability Panel (SGIP), formed to implement the Smart Grid per the American Energy Independence and Security Act of 2007. Yours truly will participate in the Architecture and Standards arena.

During the conference we heard from the candidates for the SGIP Governing Board, 3 "at-large" positions plus one each for the 22 stakeholders -- interest categories such as "appliance and consumer electronics providers" (category 1), "commercial and industrial equipment and automation vendors" (category 2), and "standard and specification development organizations (SDOs)" (category 18. As I was in attendance as ASHRAE's representative and voting member, I cast my vote in category 18 -- but Cat 18 had a tie and so there is a runoff vote underway until Monday.

Congratulations to Dr. Tariq Samad for his election to the Cat 2 slot on the Governing Board.

Tuesday, November 17, 2009

1st BACnet Middle East Journal published

As the second day of Grid Interop 2009 was getting underway, an e-mail came in announcing the publication of the first issue of the BACnet Middle East Journal. Congratulations to Mr. Sabry An-Naggar, who has been a driving force for BACnet in the Middle East.

Take a look.

Monday, November 16, 2009

Smart Grid Interoperability Panel formed of 3:30 PM MST. It took a LOT of last-minute work, because the bylaws presented on Thursday had a number of flaws, especially regarding the voting for Governing Board members. I was ready to address them during the Q&A session before the vote, but it appeared they had been raised Thursday and Friday, and a new corrected version was posted Saturday. Downloading a copy during the session (after my first question was asked and answered) I saw they had been resolved.

The count was something like 231 organizations represented in today's meeting! It's going to take a lot of work to coordinatge all this, even though we're all working in narrow fields of our own interests (commercial building automation systems have no direct concern regard electrical transmission lines, for example).

The real fun begins tomorrow.

11/17 Update: Over 440 attendees.

Sunday, November 15, 2009

Grid-Interop 2009

Got home late Friday night from the BACnet committee meetings in warm Atlanta, was off to the airport Sunday morning to fly to Denver for Grid-Interop 2009 and the kickoff of the (NIST) Smart Grid Interoperability Panel. Quite a bit chillier here; it's definitely not shirt-sleeve weather.

Looks like an interesting week ahead. One fellow apparently related to the Dept. of Energy was seated nearby on the plane, and the other passenger on the shuttle from the airport was also from Redmond -- a Microsoftie. A subsequent elevator chat with someone else hints that the commercial building controls sector might be under-represented here. I will do what I can.

Friday, November 13, 2009

This one's for Japan

Several years ago the BACnet committee received a request for a new capability from the Institute of Electrical Installation Engineers of Japan (IEIEJ), via the ISO/TC205/WG3 committee. As presented by Mr. Toyoda and Mr. Honda ("a driving force for BACnet" is how they introduced themselves in ISO/TC205/WG3 a long time ago), the overall capability was labeled ExternalModeNotification and was comprised a number of elements, many of which have already been added to the standard (the TrendLogMultiple object is one such case).

The last major piece was discussed by the final session of the Objects & Services Working Group this morning, taking up most of the allocated time. But it was worth it to get it much nearer to publication and the OS-WG voted it up for disposition.

Hopefully it won't be long before we can report to the IEIEJ that this request has been filled.

Thursday, November 12, 2009

"MS/TP wiring" addendum to go to publication

While reviewing the status of addenda in publication this autumn, it was announced that Addendum 135-2008y, "Specify Deployment Options for MS/TP," passed public review with only one comment and that one was editorial. Under ASHRAE rules this means that this addendum will go straight to publication.

This addendum is important in its comprehensive approach to wiring MS/TP networks, covering two-wire, two-wire plus ground or shield, and two-wire plus ground and shield wiring. I know some manufacturers of VFDs, which generate a lot of electrical noise, will be pleased with this outcome. Anyone who deploys MS/TP LANs should read this addendum.

When ASHRAE published this addendum (in a few weeks), it will appear here. A draft version was posted on the BACnet website.


The building in which we are meeting has a number of research labs, some with well-known sponsors. Given the concerns over cellphone use, the name of this lab is a little disoncerting.

Up today: the plenary session of ASHRAE/SSPC 135 (aka the BACnet committee), in which we review and approve, reject or send back materials from the various working groups that have been meeting this week.

Wednesday, November 11, 2009

Slow going

The committee process is often very slow, and today is an example. The Objects & Services Working Group (OS-WG), under Bernhard Isler's leadership, has been working hard to streamline and accelerate its processing of public review comments for addenda in its purview. This is necessary due to the number of addenda that have been in public review and the number of comments that were submitted.

One helpful measure is to hand members the task of reviewing comments ahead of time and to draft responses for the group to review. Yet for all this, it looks like it will take most of the day to get through due to the debates triggered by the comments. (We will still have Friday for change proposals.)

The addenda before the OS-WG are:

   Addendum 135-2008p: Global Group object (per request from Japan)

   Addendum 135-2008u: error codes

   Addendum 135-2008w: new primitive value objects

   Addendum 135-2008x: mostly clarifications

   Addendum 135-2008z: miscellaneous changes

Tuesday, November 10, 2009

IT-WG kickoff

The IT Working Group (as Jim Butler admits, it's "IT" only because we couldn't think of something better, and more dealing with IT folks is in our future) had its kickoff meeting this afternoon. While the other BACnet working groups tend to be pretty much focused on needs here & now, the IT-WG will be taking a longer-term view.

(Hmmm... I don't suppose "B2F-WG", or "BAC[net] to the Future" would be acceptable to the committee that long ago rejected "BACtalk" as being too cheeky, leaving that as a brand name to be picked up by a certain vendor.)

In any event, we had an interesting 2-hour brainstorming session, complete with voting to rank the various projected future issues, very similar to what we we did almost two weeks ago in NIST's "Measurement Science for Net-Zero-Energy Buildings" workshop. Jim will produce a working document from the compiled results and circulate for the next meeting at Winter ASHRAE. It will be an interesting read, I am sure.

Willkommen, Hans!

Looking at the growing list of Followers I was surprised to see that an old friend, Dr. Hans Kranz, had joined. Known in Russia (at least) as "The Godfather of BACnet," Hans was for years a colleague on and German member of ISO/TC205/WG3 ("Building Control System Design"), and instrumental in making BACnet an ISO standard.

As noted here, Hans is the published author of: BACnet Gebäude-Automation 1.4.

His website, under construction, is here.

Update 11/20: Well, well. Hans' work is recognized elsewhere!

Smart Grid WG and Electric Meter

The day's meetings in this conference room (Lighting has the other all day) kicked off with a two-hour meeting of the Smart Grid Working Group. David Holmberg led off with a review of where Smart Grid activities are today, then the working group reviewed Jim Butler's proposal "AC Electric Meter Device Interfaces" (JB-028-4). The direction for this proposal has not been established, whether it will result in a BACnet object or some generalized interface, though Jim is open for input on this.

He raised a question about the datatype to represent energy values; it was believed that Unsigned32 might be disfavored. But a poll of the working group failed to lead to a definitive direction -- most present ultimately voted "not qualified to respond."

It seems we have to look elsewhere for some answers.

Monday, November 9, 2009

MS/TP Working Group discussions

The MS/TP working group considered several issues, including:

1. Auto-addressing MS/TP devices. Craig Gemmill noted that this had been discussed last year, that there is a wish for this kind of capability, but that expectations varied. It was also noted that various protocols have solved this in various ways, and some of the methods were discussed. There are people not active with the BACnet committee working on this, and there may be a proposal for review during the Orlando meeting in January.

2. A proposal from Jim Butler, JB-030, "Minor Corrections to the MS/TP Master USE_TOKEN State Description," with changes to Clause that he believed were editorial in nature. The group agreed and voted the proposal up for review by the entire committee.

BACnet meetings begin

The week-long meeting of the BACnet Committee and its working groups is now underway, per the schedule posted above. The TI-WG has already revised a couple of addenda (revised and new tests) to the BACnet testing standard and sent them up for the entire committee to review and approve for public review this coming spring.

A hearty welcome to Chirag Nanavati from Softdel in Pune, India, who operates the BACnet Testing Lab. I, at least, look forward to hearing more about their testing operations and improvements they see that can be made to the BTL processes.

Update: The key to the working groups in the chart is as follows:

AP - Application Profiles (VFD, VAV, etc.)

IP - Internet Protocol (BACnet over the Internet)

MSTP - BACnet's Master-Slave Token Passing LAN and serial communications

LA - Lighting Applications

NS - Network Security (encryption and authentication)

OS - Objects & Services ("under the hood" stuff in BACnet)

SG - Smart Grid (formerly energy Utilities Integration)

TI - Testing & Interoperation (testing BACnet devices for conformance and interoperability)

WN - Wireless Networking

XML - Extended Markup Language applications in BACnet

Sunday, November 8, 2009

Burying the Alarm Forwarder

A pair of proposals from earlier discussions came up in the afternoon. Cliff Copass' "Alarm Forwarder Object" proposal (CHC-005) holds a lot of promise for supporting small embedded devices able to send alarms, but without the storage for a "large" (whatever that is) list of alarm recipients.

The basic idea is to have an object that can receive a singular alarm from a small device and forward to many, as shown.

This was complemented by Carl Neilson's "Simple Alarm Distribution" proposal (CN-118), which adds the required properties to the Devicew object of these small devices. In a small irony, the Recipient property comes back to life (removed many years ago from the Event Enrollment object by a Carl Neilson proposal titled "Kill the Recipient").

Unfortunately the possibility of an "alarm loop" soon presented itself, either if the Alarm Forwarder object was in in its own list of recipients, or if one Alarm Forwarder forwarded to another, when then forwarded the alarm back to the first. This kicked off a lot of, um, discussion which ran out the time for considering this effort. We'll be seeing it again, reevised.

The big question was: when? 3 days meeting once a year is too little -- it could take years to churcn through this stuff. So we'll be kicking off yet another series of weekly international (Europe & North American) BACnet teleconferences, and trying to tack on 3 days to the week-long spring BACnet meetings.

Grueling times... I remember when a BACnet meeting occupied one (1) whole day.

Alarm Summit II day 3 -- state machines

Yesterday the group wrapped up our review (for this meeting) of the long list of issues from René Kälin's document and this morning started in on other proposals.

One big issue of this meeting centers on the alarm system's detection/notification algorithm state machines, their graphic presentation (which elements are included and which are not) and the inclusion/exclusion of the FAULT state with the state machines. Long and difficult discussions, but they hold the promise of developing an explicitly clear integration of the disparate elements of the flexible BACnet alarm system. Multiple proposal documents will be harmonized per these discussions for subsequent review.

Saturday, November 7, 2009

Alarm Summit II day 2

We're into day 2 of the second BACnet Alarm Summit. The Alarm Summits are 3-day meetings of BACnet experts meeting to define, revise and enhance the BACnet alarm system, based on our experience of BACnet alarming from our own systems (those of us representing manufacturers) and of others' devices and systems. We have found some elements were not sufficiently clearly defined in the BACnet standard (such as normal/offnormal - fault transitions), and we would like new capabilities not anticipated by the original standard.

Yesterday we went through an exhaustive document titled "General Alarming Concepts" (RK-004-1) produced by René Kälin, discussing the issues, making initial determinations and deciding the items to be on today's agenda. Already two items are resolved.

Thursday, November 5, 2009

Plug vs Plug

Anyone who's traveled much overseas will be rather amused by this piece. Euro adapters now live permanently in my travel kit; it looks like the UK adapter might join them for this spring's European BACnet plugfest.

Wednesday, November 4, 2009


I am out of the office for some Honeywell training, but when I check my e-mail it's clear a meeting of the BACnet committee is about to begin.

A week or two before a meeting there's a flurry of new or revised change proposals being submitted for discussion (hopefully, if there is time for them and there never is for all). Then the working group agendas appear. Finally there is the announcement by the committee chair that material is posted on the BACnet FTP server, usually with a submission deadline (after the deadline, the material is included in a "Meeting Updates" folder).

The last event occurred today. There's a special three-day "summit" of self-selected BACnet experts starting Friday, in advance of the regular meeting of the entire committee Monday through Friday.

Unfortunately, due to the training I will not be flying out to Atlanta tomorrow morning. I had to take a red-eye instead; it will not be a good thing to start the meeting tired.

Saturday, October 31, 2009

BAC home again

Sorry for the silence. Got caught up in material not of interest here that ate up all my time.

Returned home last night from NIST's "Measurement Science Roadmap for Net-Zero Energy Buildings Workshop." This workshop was intended to give NIST directions for future work in terms of what is needed in order to get to net-zero energy buildings. A very interesting workshop -- among other things it turns out there are at least four different definitions of what it means to be a "net zero energy" building.

("Measurement Science" is a term unfamiliar to most of us, but at NIST it is fairly well defined with a broad scope including reference data, measurement methods, (standardized) methods of testing, predictive tools, comparison studies, information models, and so on.)

After the opening session the workshop split into five working groups; nearly all of us (we were not many) representing the building automation controls industry were in the Intelligent Buildings working group. It was interesting to see how a number of points and issues our group raised were also raised by a number of the other working groups (Whole Buildings, Energy Production, Building Envelope, Building Equipment Energy) in the final read-out session.

NIST will be sending us the powerpoints, worksheets, summaries and more in the next couple of weeks; the review is going to be interesting. These may set some long-term goals for BACnet development in order to more fully support net-zero energy buildings.

Here is the Intelligent Building group voting on issues and going on break.

Thursday, October 22, 2009

BACnet and Elevators

Just received a note from Dr. Albert So. Our planned Elevator Summit (a meeting with representatives from a number of elevator manufacturers) is on, set for January.

Tuesday, October 20, 2009

Moving right along

It's always a good feeling when the desk gets cleared of urgent, high-priority tasks so that long-standing (or potentially long-standing) BACnet tasks can be addressed, and I am well into that mode. Unfortunately, these are likely to be controversial.

One is a task from the BIG-EU/WG-Technique (Technical) meeting in Strasbourg, to address the problem of explicitly identifying the version of software/firmware actually tested by a BACnet test lab. There are two properties, Firmware_Revision and Application_Software_Version, that could supply this information, but neither quite fits the bill. I volunteered to address this for discussion by WG-T; looking at it today the best solution seemed to be to refine the description of Firmware_Revision, even noting that the use of this property might be further contrained by a BACnet testing lab's rules for identifying tested revisions. (How about that for punting it into the next court?) It's been sent off; we'll see what happens.

One that's going to be more interesting is a discussion in my "Elevator Monitoring in BACnet" proposal. The last time it was discussed the Objects & Services working group did not like the Building and Room objects (though the Elevator Group, List and Escalator objects seemed okay -- or perhaps we just had not gotten that far). They didn't do anything, they just indicated data structure. Here's how the hierarchy looked:

The committee wanted to use the Structured View object instead -- "structure" is its intended purpose. So I made a stab at it, but found that for a "clean" presentation I needed to use the Character String Value and Positive Integer Value objects currently in public review (until October 26th). Here is how the left-hand side of that structure looks (color-coded functions match the first image):

A lot of extra overhead for a client device. So I tried a "dirtier" approach in which object count goes back down, but it will require changes in the existing standard and has risks:

It will be interesting to see what the committee says.

Ain't BACnet fun?

BACnet Forum Beijing

It's over now, but there appears to be a news item about the BACnet Forum Beijing posted online, complete with a photo that appears to show Mike Newman addressing the hall. Unfortunately it's all in Chinese, which I cannot read, but... check it out.

Monday, October 19, 2009

Wiresharking MS/TP

Steve Karg (he's the guy with this license plate -- now, how do we get BACnet to the moon, and beyond?) sent me an e-mail Thursday, at the end of the PlugFest, with a link to his blog entry about a utility to put received MS/TP frames into PCAP format to use with Wireshark. I haven't had time to try it out yet but thought I would pass it on.

Sunday, October 18, 2009

Countdown to BIG-CN

In a bit under 9 hours from now, the founding meeting of the BACnet Interest Group - China will start, in the Hotel People's Palace Beijing, with 13 founding members to be present. The agenda:

- Greeting from H. Michael Newman

- Founding Big-CN

- Election of the BIG-CN presidency

- Discussion of objectives and action plan

As noted in an e-mail last from from Mike Newman to the BACNET-L mailing list, there is a long list of possible events and activities in China for the new group to discuss. It will be interesting to hear the results of this meeting.

This follows closely after the publication of the second edition of the BACnet China Journal, a PDF of which may be downloaded from here.

Friday, October 16, 2009

Pan-Honeywell PlugFest

As a result of a number of acquisitions Honeywell has come to have a number of independently-developed BACnet protocol stacks. There's been a fair amount of technology and device sharing between the various organizations, but having testing teams from the organizations together in one place is an opportunity not to be missed, so today we have teams from Honeywell Analytics, HBS, Alerton, Phoenix and Tridium (7 teams in all) testing to ensure the various offerings work harmoniously.

Thursday, October 15, 2009

BACnet PlugFest, day three

The "round tables" (group testing, instead of paired companies) are becoming more popular.

Tuesday, October 13, 2009

And they're off!

The 10th annual BACnet International PlugFest is now underway, with 88 testers on 45 teams, a new record. With so many teams moving to new stations during the break, chngeover is going to be pandemonium. (The table in the foreground here is the "round table," for the large group sessions that will start tomorrow.)

The world-renowned Alerton testing team of Phil and Jeff:

Now THAT's dedication!

Waiting in the lobby before dinner last night, I happened across this scene:

A couple of testers here for the plugfest had set up their equipment in the lobby of the hotel (that's where we have free WiFi) and were busy working away on it. It looked rather a bit like they couldn't wait until morning to get started.

Monday, October 12, 2009

Invalid "Invalid Tag"

Rather a shock to hear from Lori Tribble, BTL Lab Manager, a few minutes ago that a number of devices fail the BTL-specified test 7.2.2.X2, "Non-documented Property Test" for property identifiers 255 and 256. It appears a number of new-to-BACnet developers are not conrsidering the tag extension rules in the last slide in my post BACnet tagging rules and when they reach a tag that requires two octets, they simply return "Invalid Tag."

I wonder how many devices that don't have the BTL Mark have similar shortcomings?

Update: Disappointing too to learn that devices are still failing MS/TP tests because of shortcuts in implementing state machines. I posted something related to this a couple of months ago: The machines are simple enough, just implement directly from the standard.

Full agenda

The BACnet Testing Labs Working Group (BTL-WG) is meeting today, in rainy Atlanta, in advance of the plugfest the next three days. We're now through the usual preliminaries (power for the laptops -- hotels are getting better at this) and Internet access (just got the codes, but I'm online through my cellphone). Agenda about to be approved, and even before amendment it looks like a full day ahead:

4. BTL Clarification Request

   a. BTL-CRR-KV05-ObjectID VersionRemotebroadcast - renewed discussion.

   b. BTL-CR-0081-TimeSynchronization.doc

   c. BTL-CR-0082-ReadOnlyTest.doc

   d. BTL-CR-0083-nonDocumentedProperty.doc

   e. BTL-CR-0084-EventEnableLogging.doc

   f. BTL-CR-0085-NewMSTPTest.doc

   g. BTL-CR-0086-ImplGuideChgs.doc

5. Round 5.1 documents

   a. BIP NAT Tests-3

   b. Test Changes per new Error Codes - CN-123

   c. Test Changes Priority-Filter - CN-124

   d. 135-2004b-5 - restart parameters

   e. TLM documents

   f. BTL Specified Tests-Add135-2004b-6-TimeSync-2.doc

   g. BTL Specified Tests-Add135-2004b-9-BroadcastDER-2.doc

   h. BTL Specified Tests-Add135-2004m-1-FDReg-2.doc

   i. BTL Specified Tests-Add135-2004m-4-ReAckAlarms-2.doc

   j. BTL Specified Tests-Add135-2004q-1-UnicastIAm-2.doc

A lot of folks absent today.

Saturday, October 10, 2009

PlugFest Preparations

The BACnet International PlugFest begins Tuesday morning. I'm packed and ready to start my journey to Atlanta Sunday morning (arriving late in the evening), because the BACnet Testing Lab Working Group will meet Monday in advance of the PlugFest, Tuesday through Thursday.

Alerton's world-reknowned PlugFest testers (well, all of us but me) are ready, prepared and armed to tackle, surmount and report on any difficulty we meet. Which doesn't really mean a lot, since many of us at these plugfests are veterans, we pretty well know where the problems could lie, and know that those who do not have BTL Listings for any of their products are the least likely to "play well with others." (Exceptions do occur, I might add.)

Looking forward to a week of combining intense focus and intense boredom, all in the cause of BACnet!

Wednesday, October 7, 2009

BACnet tagging rules

This morning there was an old, familiar question on the BACnet-L mailing list:

"can we assume that values (data types) with application tag will always be enveloped by an open tag and close tag?"

Unfortunately not. BACnet's tagging rules are not that easy to figure out initially and a lot of developers get them wrong at first. But once understood the rules are not difficult.

This is why in my "BACnet for Developers" class I take some extra time to explain the tagging rules, to make sure the developers start off on the right foot. As a service to the BACnet community I have posted the slides on tagging below.

We’ll take a short spin through ASN.1, sufficient for reading productions. There are additional rules for writing BACnet ASN.1 productions, but they are out of the scope of this course.

Taking the production (as it is called in ASN.1) ReadProperty-Request, we identify its various elements as follows:

1) The production’s name, followed by “::=“.

2) The type of structure represented by the production; these seven types are all that are used in BACnet. Most of these should be obvious; “SEQUENCE OF” refers to a list or array, “SEQUENCE SIZE (n) OF” is an array whose size is set by the standard.
3) The name of the datum: a short description of what is represented by the datum.

4) A “context tag”; a numerical tag that identifies (in the context of the production) the particular datum. For several reasons context-tagged data is preferred over data that is not context-tagged, or “primitive-tagged”. (We’ll be looking at tagging shortly.)

5) The datatype of the datum. This can be “primitive” or “application” data (CharacterString, BOOLEAN, etc.), or it can be “constructed” data – another production in this production, or a reference to another production.

6) The optional OPTIONAL keyword. “OPTIONAL” here refers to elements of service requests that may be absent depending upon the form or intent of the service, or absent due to some other condition.

7) Comments, preceded by two dashes.

In BACnet there are only 7 types of structures in ASN.1 productions.

- The BITSTRING datatype should be self-evident: a series of flags, each indicating something.

- CHOICE should also be self-evident: one of the options presented.

- ENUMERATED is also simple: each of the numeric values presented represents something.

- SEQUENCE, as the name suggests, is a series of items. (Note that some of the items could be OPTIONAL.)

- SEQUENCE OF and SEQUENCE SIZE (n) OF are relatively infrequent constructs in BACnet: they represent a series of some item, a list or an array. “SIZE (n)” indicates an array whose size is fixed in the standard.

- Finally, there is the OCTET STRING datatype.

While it’s in front of us, we need to take a moment to look at this complex-looking datatype called “ABSTRACT-SYNTAX.&Type.” All it really means, within the context of BACnet, is that the variable which has this datatype can take on any value. This is stated in Clause 20.2.19.

Looking at the BACnetPriorityValue production, we see a CHOICE with a number of basic datatypes in it. This is a good time to see how the data in such a production is represented “on the wire,” in its binary form and with the identifying tags.

In BACnet there are three kinds of tags (technically BACnet defines only two, but it’s easier to understand if you break them out into three).

- The first is the “application” tag (or “primitive”; both terms appear in the standard). This tag identifies the basic datatype (Unsigned, Double, Date, etc.) and its length.

- The second is the “context” tag. This conveys the “context number” from the production, the number in square brackets, and the length of the data contained. The datatype of the tagged data is determined by the context (production) in which it appears; without the context one cannot tell if a data item with four bytes is an INTEGER, Unsigned, REAL, Date, or Time, for example.

- The third type are two variants of the context tag we call a “PD Open” and “PD Close” tags (or together “PD tags”), based on some terminology in the standard. As their names imply, these tags always appear in pairs, carrying the context number but with no length information. These are used in encoding lists, arrays and ANY datatypes and contain zero or more tagged items.

Which kind of tag would be used on “constructedValue” in the production here?

The application/primitive tag is used to encode the basic underlying BACnet datatypes, of this there are 13. These are defined in the standard in Clauses 20.2.2 through 20.2.14, with the rules and examples of their encoding.

Let’s quickly go through the exercise of encoding a REAL value of zero (4 bytes of zero). Looking at the initial octet of the tag, we assign the datatype to the “Tag Number”, the class is zero (application tag) and the length of the data following is 4. Therefore the tag is X’44’ and the entire data item is X’4400000000’.

There is a special case when encoding the BOOLEAN data with an application tag:
FALSE is encoded X’10’ and TRUE X’11’. This rule does NOT apply when a BOOLEAN is encoded with context tags. (See Clause 20.2.3.)

The context tag (my term) is used when you see a square bracket with a number in it in a production, and a primitive datatype specified. To encode a ‘deadband’ value of zero in this production (the values sent with an OUT_OF_RANGE event notification), one would encode the tag number in ‘Tag Number’, set the ‘Class’ bit to 1, and set ‘Length’ to 4, giving a tag of X’3C’.

The PD Open / PD Close (my term, based on the standard) tags are a subclass of context tags in that they convey the context tag number. These always appear in pairs.

In the examples given, it should be noted that in BACnet the first day of the week is Monday.

No doubt you will have noted there are some apparent limitations to the data tag. The tag number can only go to 15, and the length to 5 on context-tagged data (7 on application-tagged data). This is not the case. Tag numbers can go up to 254, and length up to 232-1; these are done by extending the tag per Clause 20.2.1.

Rule 1: Tag numbers 0 through 14 are encoded in the tag number field. 15 through 254 is encoded with X’F’ in the Tag Number, and the byte following holds the length.

Rule 2: Length 0 through 4 is encoded in the length field. Length 5 through 253 have the length field value X’5’, and the byte following this byte, or the length extension if it is present, has the length. For lengths 254 through 65535, set the extension to 254 and the subsequent two bytes hold the length. For lengths 65536 through 232-1, set the extension to 255 and the subsequent four bytes hold the length.

And there you have it.

Monday, October 5, 2009

BACnet IT-WG launched

A few minutes ago I received an e-mail from Jim Butler announcing the formation of a new BACnet working group, the IT-WG. As he describes its charter:

Since the design of BACnet began in 1987, much has changed in the world of computers, networking technology, and building automation systems. BACnet has been sufficiently flexible to handle many of these changes, but more changes are coming that may further challenge BACnet’s architecture. Here are some of the changes that could affect the requirements for building automation systems:

1. The trend toward convergence of IT and building automation

2. Network security policies and standards

3. The increasing use of battery-powered and wireless networked devices

4. “Smart Grid” applications that involve building automation systems

The BACnet IT working group’s primary task will be to enumerate the general communication requirements of building automation systems that will be deployed over the next several years and evaluate BACnet against those requirements. To the extent that BACnet does not meet those requirements, the working group will discuss, at a high level, how BACnet could be modified or redesigned in order to better meet those requirements. Based on the outcome of those discussions, the working group members might initiate projects to investigate various design options.

He also notes:

I have set up a Yahoo Group that we will use for e-mail exchange. If you are interested in participating in the BACnet IT working group, you should join that Yahoo Group:

It is my intention that the working group will use collaboration tools that have not been used by other BACnet committee working groups. I believe that those tools can help us to do a better job of documenting issues (and related documents) that we discuss. An announcement about this will be made in the near future.

The working group’s first face-to-face meeting will be held on Tuesday November 10, 2009 from 1:00 to 3:00 p.m. at Georgia Tech.

Friday, October 2, 2009

NFMT speaker confirmation

This morning while I was writing up my weekly status report for my two bosses, one American and the other German, a bonus item to be included arrived in my e-mail: I have been selected as a speaker for next year's The National Facilities Management & Technology Conference & Expo, Maintenance Solutions Conference & Expo, GreenTech Conference & Expo and Safe Buildings Conference & Expo, four shows under one roof. My topic: what ASHRAE and LEED standards and guidelines say about how you can save energy (and money!) with your building automation system, while keeping the occupants comfortable in a high-quality indoor environment.

I've seen lots of strategies presented in articles and talks over the past three years (when I first became interested in this topic), but in my review of this literature I found that all of them (plus more) have already been published. But you really have to know where to look; this took a bit of money to buy the necessary books, and a fair amount of time and patience to read them all cover to cover.

In my talk I will present the results of this review -- and one additional strategy that's not in these books, I assure you. At least not yet.

This is going to be fun!

Thursday, October 1, 2009

Neutral plugfest hosting

During the BIG-EU discussion regarding next year's European plugfest, Britta noted that we have a host for the plugfest but that (of course) the plugfest will be conducted offsite. That got me reflecting on this year's plugfest which was held onsite at ABB, and I realized that although the plugfest was held within an ABB facility, it was structured within such a neutral, contained environment that concerns of "privacy" never arose. For just one example, the only ABB employees we saw in the plugfest were those directly involved -- no sales, marketing or uninvolved R&D folks were there.

I know from Alerton's experience some years ago that hosting an offsite plugfest can be quite expensive. If we could learn the lessons from ABB's hosting, I think we could reduce the cost of future plugfests, in both Europe and North America.

Tuesday, September 29, 2009

Increased capacity

Just announced that the demand for BACnet testing in Europe has been growing, and to meet that demand a new tester has just been hired by WSPLab to expand their BACnet capability. This is the first I have heard of a BACnet testing lab having to grow beyond its initial capacity, though it's been clear for a while that both labs have been close to that point.

Automatically testing workstations

Under the topic of testing workstations, going on right now, it was noted that the new BTL workstation tests are predominantly manual, and thus slow and not inexpensive.

Klaus W. put forward an intriguing idea of defining some kind of standardized interface that would allow a machine (future version of BACnet Test Framework, BTF?) to have an operator-like interface into the workstation so that one does not need to have the tester operate mouse and keyboard, and read the displays, to perform the tests. His concept is similar to the automobile testing interface.

European PlugFest in 2010?

In this morning's Executive/Advisory Board meeting (still underway) there was clarification of an item mentioned yesterday -- the possibility of an EU Interoperability Workshop (aka plugfest) in 2010 springtime. Apparently a potential host has been identified and discussions on arrangements are underway with an official announcement to follow if everything works out.

This came as a surprise to me because BIG-EU had earlier decided that having a European plugfest every other year would be sufficient. But if an annual plugfest will have sufficient draw, I am all in favor of it. In the world of BACnet development, two years is a LONG time.

And BIG-EU will continue to hold our plugfest in the spring, opposite BACnet International's autumn plugfest, for maximum participation. At the very least, I'd encourage all manufacturers planning to sell in Europe to attend the plugfest.

Monday, September 28, 2009


A few days ago I was called into a videotaping session, part of the preparations for Alerton's upcoming annual sales meeting. It seemed simple enough, just answer the questions "Why is BACnet great?" and "What does 'Native BACnet' mean?" And yet, the first time went really poorly (in my opinion, though a big feature of the retaping was a completely different lighting setup). The videographer was so happy with the first run he almost didn't record any subsequent "just in case" repeats. He said these would likely be posted on the Alerton website soon.

All of which brought back earlier BACnet-related tapings. I don't have one of an audience with the vice-mayor of Shenzhen, China -- though that was organized so differently from what my hosts expected I may be glad I don't have a copy. We thought I was going to make a presentation, but instead it seemed we made short speeaches to each other via translators, television cameras rolling. And it was aired on Chinese television that evening.

Another occurred a couple of years ago for a conference in the SF Bay Area. This was arranged in advance and done on a quick one-day trip to San Francisco. It was subsequently posted on YouTube. I had to e-mail the filmmaker, Aron Ranen (who is really good at this stuff), for the URL. Hr replied:

...I have cc'd Bob & Kyle Brown.

Part one

Part two

You are on part around five minutes

Live from the BIG-EU WG-T meeting

Hotel meeting rooms pretty much all look alike, wherever you are. (In this case the Hotel Hannong, Strasbourg, France.) And the same is generally true for BIG-EU's Working Group - Technique (Technical) meetings. The interest is obviously not in the setting, as shown here, but instead in the material being discussed, whether it's whether BIG-EU should be approving national requirements, discussions of listing and certification issues and harmonizing BACnet lab operations, or BACnet addenda in public review and the take of committee on material therein. Somehow one day, 9 AM - 4 PM is not enough time.

Next up on the agenda: BIG-EU annual general membership meeting.

Saturday, September 26, 2009

"Where in the world is BACnet Bill?" a topic suggested by a blog reader here at Alerton. It's not my imagination that I'm traveling more -- my frequent flyer mileage accumulations show it too. So right now I am in Paris, in transit to Strasbourg for the annual meeting of BIG-EU, having been up for 22 hours already and it's at least 4 more before I will reach the hotel.

9/27 Update: Finally got there, of course. A bit of a scenic view from the train station at the airport in Strasbourg, out in the middle of large fields with just a hint of a nearby town. (Blogger is not displaying it correctly. Hm.)

Tuesday, September 22, 2009

(Almost live) from Facility Decisions Conference

The first day of the Facility Decisions conference, co-sponsored by BACnet International, here in Las Vegas has ended. It looks well organized, especially running 8 different tracks concurrently and keeping all on time! Several people remarked this morning that the attendance was pretty good, and that there were some from all across the country.

One interesting thing I had not seen before were the number of side or extra "events' -- the B.I. awards ceremony (congratulations, "Ray" Kolasa!), the ice-cream social, the various drawings and many more things going on around the periphery such as filming 2-1/2 sales spiels by the exhibitors.

I have photos to go with this posting (including ABB's Mike Olson giving his spiel, eventually without the reflective faceplate that showed me in the background!), but my SD card reader seems to have died. Maybe later -- stay tuned.

9/26 Update: Photos at last! A very busy week and it wasn't until some down time in Paris Orly airport that I was able to get them posted. Including the following from the BACnet International booth, with President And McMillan, Marketing Chair Mike Wilson, and office director Natalie Nardone.