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: http://tech.groups.yahoo.com/group/bacnet-it-wg/


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.