IN THIS ISSUEAll Together Now

BACnet Developers Q & A

BACnet/IPv6

Foundations is an educational resource produced by BACnet International for BACnet International members. BACnet International is the cornerstone of your success, and Foundations builds from that cornerstone by providing the ground level knowledge in connecting the dots in building automation.

Foundations is written by volunteers from the BACnet community for integrators/installers/appliers and specifiers/consultants. It complements the BACnet International Journal and the monthly newsletter Cornerstones. For more information on BACnet International, please visit www.bacnetinternational.org.

Questions or article submissions may be directed to info@bacnetinternational.org.

June 2014

FOUNDATIONSA BACn e t IN TE R N AT I O N AL P UBL ICAT ION

With every carrot, however, there is always some aspect of a stick to go with it. That will first arise for many devices when they ask: “My device currently holds a BTL Listing, and claims a lower Protocol_Revision less than 7. Can I retest, and stay at a Protocol_Revision lower than 7?” The answer to that is: No. Every existing BTL Listing remains valid perpetually, because each already bears a statement of the Testing Date, of the claimed Protocol_Revision, and of the version of the Test Requirements which were applied during the testing. Nothing of what the BTL Listing states ever fades with time. But no new BTL Listing based on fresh testing of a device claiming Protocol_Revision less than 7, will ever be issued. To the questions: “Can a BTL Listed product on the market stay at a Protocol_Revision lower than 7?” the answer is: Yes. And “Can a device which currently holds a BTL Listing, and claims a lower Protocol_Revision less than 7, request Listing updates that do not involve any fresh testing.” the answer is: Yes.

“Should specifiers only permit bids for devices at Protocol_Revision 7 or higher?” is another good question. The policy absolutely does not say that. But the motivation *in* the policy and for having created the policy, certainly should put that idea into specifiers’ minds. Devices which implement a version of BACnet outside of the window which BTL considers suitable for compatibility between versions of the standard, are at higher risk of problems with interoperability. Testing does not catch everything. The primary purpose of the policy is to serve as a second measure, so that implementors are not as likely to inadvertently produce non-interoperable behavior nor to make coding assumptions that lead to problems with interoperability.

The past five years, prior to 01-Jan-2014, make a good window. For all intents and purposes, every workstation BTL Listing is included. The first workstation Listings were granted in June 2009. These have all been tested according to essentially the same Test Plan. Though workstation testing did partly take place prior to ratification of Test Plan-5.0, this was done--intentionally--with the whole of Test Plan-5.0 in mind, to ensure that the Test Plan then under preparation would be practical when applying it. Basically, a shake-down cruise.

With the turning of the year comes a moment that BACnet is passing into a new era. A better era in my opinion. ASHRAE 135-2004 does passeth, as it should, into the dustbin of history. ASHRAE 135-2008, ASHRAE 135-2010, and ASHRAE 135-2012 will serve us going forward. There is no need to perpetuate backwards *four* different standards.

The role of BTL is to keep the community interoperable. That includes whatever is needed to keep the community not just interoperable at a single point in time during the testing, but also over time as the standard evolves. BACnet International, through its BTL testing, and the policy encourages everyone to make their devices at minimum Protocol_Revision 7, the version which was published as standard 135-2008. If a device is only at the minimum according to that policy, then two years later the device would again need to advance, to at least Protocol_Revision 9 or higher by 01-Jan-2016.

The policy continually mandates that devices be within a moving window of Protocol_Revisions to co-exist in the community. Protocol_Revision 12 (135-2010) becomes the minimum on 01-Jan-2017. Later milestones will be established, always with a minimum of four-years notice, as the BTL advances the Test Plan which governs BTL testing. The rationale for this ever-increasing minimum Protocol_Revision is explained within the policy itself, and I have expounded upon the rationale in a Foundations Oct/2013 article: Why We Need to Limit the Protocol_Revision Divergence. Keeping all devices in the community within a narrow range of Protocol_Revisions is a compelling necessity for the health of the industry.

This article is a companion piece to that. Here I will attempt to answer particular questions that you might have, about the specifics of that Policy. Starting January 1, 2014 any BTL testing performed at the laboratory at SoftDEL, or at other labs which provide BACnet testing according to the BTL Test Plan, will only qualify a device for BTL Listing, if the successful testing result is on a device claiming at least Protocol_Revision 7. Lesser devices can contract for testing, but the result will not qualify a device for the publishing of a consequent BTL Listing. This policy is the carrot part of ensuring that at any given time, the community of BACnet devices on the market are all implementing a proximal window of compatible versions of the standard.

All Together NowBy Duffy O’Craven

The market should rapidly vote with its feet over the coming year or two, and consider workstations that only claim Protocol_Revision 4 (or anything less than 7) to be behind the times. Protocol_Revision 7 is 135-2008. Development teams will have had over five full years to get their game faces on. Listings clearly state the Protocol_Revision claimed, on page 1 of the BTL Listing. This is not hidden information. Those listings boldly state that workstations that only claim less than 7 are far behind the times, and readers of BTL Listings in the marketplace are the ones who should notice that.

There is going to be quite a bit of publicity around “Protocol_Revision 7 or higher only” after 01-Jan-2014. It is caveat emptor to look at the Testing Date, the claimed Protocol_Revision, and at the version of the Test Requirements on the BTL Listing, when making a decision about the quality of a device due to its BTL Listing. I predict that readers of BTL Listings are going to start paying a bit more attention to the particulars of what is stated there. I hope this article lays out the facts and the particulars sufficiently, so that readers are well-informed when questions arise, and so that in the natural course of maintenance of products, development teams can make plans to keep abreast of the advancing minimum requirement in the policy. After advancing to a higher Protocol_Revision, consider applying for updated testing to ensure the BTL Listing states the posture that you want to portray in the market: modernity in Protocol_Revision and in the stated Testing Date. Customers will be hearing the buzz loud enough to notice.

Test Plan-5.0 did a good job, and captured almost everything in workstation testing, except Time Master functionality, on the first try. BTL Test Plan-9.0 added Time Master testing, along with a small flurry of minor corrections and clarifications. Workstation testing changed almost imperceptibly between Test Plan-9.0 and 12.0 for devices at less than Protocol_Revision 10. For workstations claiming Protocol_Revision 10 or higher, only Test Plan-12.0 can be applied, because at Protocol_Revision 10 there were added the twelve additional Value object types. Protocol_Revision 11 further added two more object types (Global Group and Network Security).

I particularly mention and emphasize workstation testing here, because it is the workstation device profiles which primarily contain the A-side behaviors that BTL Minimum Protocol_Revision Listing policy is concerned about. Everything that has had testing against Test Plan-5.0 or later, gives me no concerns that some might have lesser adherence to the standard due to weaker testing. Workstations that only claim Protocol_Revision 4 though, or any Protocol_Revision less than 7, had an easier/simpler threshold to conform to the BIBB definition for interoperability. For example the DS-AM-A BIBB states:

“The A device is able to use WriteProperty to modify any standard property of any standard object type ...” But then it has an escape hatch as the BIBB concludes with provision: “... Devices claiming conformance to this BIBB arenot required to support presentation and modification of objects and properties that are introduced in a Protocol_Revision newer than that claimed by the A device.” There have been 27 new object types added to the standard since Protocol_Revision 4. Workstations that claim Protocol_Revision less than 7 do not interoperate at all with Trend Log Multiple, nor Event Log. And workstations that claim Protocol_Revision less than 7 operate in a manner not consistent with the new standard as of 135-2008 for configuration and control of the Trend Log object type. The later 24 new object types added to the standard, and changes in the standard regarding their properties and behavior, similarly would not be supported when they were introduced in a Protocol_Revision newer than that claimed by the A-side device.

About the Author

Steve Karg is a Senior Engineer

at WattStopper, in Birmingham,

Alabama. He has been an

active member of ASHRAE

SSPC 135 (BACnet) since

2001, and convenes their

Lighting Applications working

group. He wrote an open

source BACnet Protocol

Stack hosted on SourceForge.

net, and continues to help

maintain the BACnet decoder

in Wireshark.

Over the years while being involved in the BACnet committee and developing BACnet products, I have fielded questions about BACnet product development. Some of those questions are answered by the official BACnet Testing Laboratories “Implementation Guidelines”. However, some questions are beyond the general scope of that document.

Question: Is there some sort of rule or polling technique for MS/TP that I am missing? I have a device that will let me poll a couple of objects at a time without much problem, but when I poll more than a few, I start getting errors from the device. I have contacted the vendor and sent them the same Wireshark captures, but wanted to check with you also, just to make sure I’m not breaking any MS/TP rules.

Answer: There aren’t any polling rules for MS/TP, but there are some facts that may help with polling techniques:

1) each MS/TP segment is only capable of one request at a time (it is a shared bus).

2) most MS/TP devices can only handle one request at a time (only have a single incoming or outgoing buffer).

3) the Token passing nature of the bus, along with the bus speed (baud rate) makes this datalink a lot slower and bandwidth constrained compared to BACnet/IP. The MS/TP baud can be as slow as 9600 bps, and there can be as many as 128 devices passing Tokens in each segment, so it can take awhile to be able to reply to multiple sequential requests.

4) some routers make it easier to poll MS/TP by allowing a large Max_Info_Frames values (number of frames that can be sent when the router has the Token). A router with Max_Info_Frames of 100, for example, can take 100 confirmed requests and queue them and execute them before having to pass the Token.

BACnet Developers Q & ABy Steve Karg, Member ASHRAE

As for the specific device you reference and after reviewing your Wireshark capture, it seems that #2 (number of requests that a device can handle) is hitting its limit (but is certainly more than one!), and you could then back off on the number of outstanding (simultaneous) requests to that device, or wait until the resources (i.e. Complex-ACK is returned) free up.

Each MS/TP device is different since a vendor can choose how many requests each product can support at one time, so it is unknown how many request any device can support, and there isn’t a property in the device that can be read to tell a client what that number could be. MS/TP tends to be used in smaller, lower resource devices since it only needs a microcontroller large enough to encode and decode BACnet data, and an RS-485 transceiver. Having more than one incoming buffer for the PDU (well, I suppose it could really be how many transmit buffers it uses to hold the responses), is the exception, not the norm.

A single outstanding request per device is a good baseline for MS/TP devices, which means waiting for the response before requesting again from the same device. At the MS/TP datalink level, the request is encoded into a Data-Expecting-Reply frame, and the device has up to 250ms to respond, or send a Reply-Postponed frame to the router (or peer MS/TP device). The Data-Expecting-Reply frame will keep all other devices on the bus from communicating during the time it is waiting for a response, so it is pointless to ask for other devices on that MS/TP segment (except if the router has an incoming request queue and a big enough Max_Info_Frames setting).

If the MS/TP device supports ReadPropertyMultiple (read the Protocol_Services_Supported property in the Device object to verify), then the client can request multiple properties from multiple objects in a single request, up to the limit of the APDU size in the device and the datalink layer. The Max_APDU_Length_Accepted property can guide the client, but the response to the request will likely be larger than the request. The maximum APDU size for MS/TP is currently 480 bytes, but could be as small as 50 bytes. Some devices could support larger APDU sizes by using segmented APDUs, as indicated by their Segmentation_Supported and Max_Segments_Accepted properties.

Question: There is a need for me to have an object within another object. I know that the device object already does it, using the object-list property to list all objects. Are there are any BACnet properties that do hierarchy-like object representation?

Answer: A Structured View object, which was added to the BACnet standard in 2006, could present objects in a hierarchy. “The Structured View object type defines a standardized object that provides a container to hold references to subordinate objects, which may include other Structured View objects, thereby allowing multilevel hierarchies to be created. The hierarchies are intended to convey a structure or organization such as a geographical distribution or application organization. Subordinate objects may reside in the same device as the Structured View object or in other devices on the network.” Note that the Structured View object is currently being extended to support Application Interfaces. See the Structured View object addenda at:http://www.bacnet.org/Addenda/Add-2004-135d.pdf

Question: If I have a single BACnet client, then I obviously have 255 invoke IDs I can use. Does that mean I have to stay within that range (255) no matter what, even if I have more than 200 devices on network, or can I have 255 invoke IDs per device to which I am sending a request?

Answer: Your client can have up to 255 invoke IDs per device it is sending the request to. It is a matter of being able to match up response with request.

Background

BACnet has a new Addendum, 135-2012aj that introduces the so-called IPv6 datalink to BACnet. BACnet over IPv6 (“BACnet/IPv6”) allows BACnet devices to use IPv6 for transporting BACnet messages.

In the more familiar IPv4, the address length is limited to 32-bits, or 4.3 billion addresses. When IPv4 was originally developed, running out of addresses wasn’t a concern, but in the 1980s it became clear that even 4.3 billion addresses weren’t enough to satisfy the unexpected rate of growth of the public Internet. At that point, techniques were developed to reduce the rate of new address allocation but IPv4 address exhaustion was unavoidable. The last primary pool of IPv4 addresses was assigned on 3 February 2011.

IPv6 Addresses

IPv6, originally proposed in RFC 2460, is meant as a replacement for IPv4 and is the accepted long term solution for many issues with IPv4 including the address space problem. In IPv6, the address length is 2128 bits, which is considerably larger than the 32-bit limit in IPv4. How much larger? The number is so large that the number of available addresses cannot be expressed in words without resorting to math. For reference, 2128 equals 340,282,366,920,938,000,000,000,000,000,000,000,000.

BACnet/IPv6 addresses combine the 128-bit IPv6 address with the 2 octet UDP port. This combination results in addresses that are 18 octets long compared to the 6 octet length for BACnet/IP addresses. If these large addresses were to be used with the existing BACnet Application and Network Layers, then that would cause problems because those layers are limited to a maximum address length of 6 octets. In order to work with these layers as they exist today, BACnet/IPv6 uses VMAC addresses as defined in Clause H.7 and specifically uses the concept introduced in Clause H.7.2. In this scheme, B/IPv6 addresses are represented in the upper layers as a 3 octet address that is derived from the value of the object-identifier of the node’s Device object (i.e. the Device instance). Each BACnet/IPv6 node must contain a VMAC table that is used to match this 3 octet address to the actual BACnet/IPv6 address.

IPv6 Address Notation

IPv6 addresses are comprised of 8 groups, each of which is comprised of 16 bits. Each group is separated by a colon. For example, 2001:0DB8:0000:0000:0000:0000:0000:0001 is a full representation of an IPv6 address.

Luckily, we’re provided with a method for abbreviating these long addresses. Applying this method to our example address results in the shorthand version, 2001:DB8::1. This shorthand method is documented in RFC 5952.

Multicast

BACnet/IP uses IP broadcasts to convey BACnet broadcast messages. IPv6 has deprecated the use of broadcasts in favor of multicasts. So, BACnet/IPv6 by definition uses IPv6 multicasts to convey BACnet broadcast messages.

BACnet/IPv6by Coleman Brumley

In order for IPv6 nodes to receive multicasts, they must join the appropriate multicast group. For example, if an IPv6 node wants to receive all Network Time Protocol (NTP) multicast messages, it would request to join the NTP multicast group. Since nodes will only receive the multicast traffic they’ve requested, this cuts down on the processing overhead required when there are a large number of multicast messages.

The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned IPv6 multicast group identifiers. IANA has assigned the multicast group identifier FF0X:0:0:0:0:0:0:BAC0 (FF0X::BAC0) to BACnet. The “X” in this address is a placeholder that is replaced by the appropriate scope desired. Addendum AJ states that the local scope multicast address, FF02:0:0:0:0:0:0:BAC0 (FF02::BAC0), shall always be available. This means that BACnet/IPv6 nodes can always depend on that group. But, to allow the most flexibility and to meet site requirements where they’ve created their own multicast configuration, the B/IPv6 multicast address can be configurable in each BACnet/IPv6 node.

Multicast Domains

A group of BACnet/IPv6 nodes that can communicate with each other via a single IPv6 multicast address and port combination is referred to as a multicast domain. In order for BACnet/IPv6 nodes to communicate across different multicast domains, they must register with the BACnet/IPv6 Broadcast Management Device (BBMD) that is servicing those multicast domains.

BACnet/IPv6 BBMDs work similarly to BACnet/IP BBMDs in that they have “broadcast” distribution and foreign device tables. When a BBMD receives a request to forward or distribute a BACnet/IPv6 message, it will convey that message to the nodes listed in those tables. BACnet/IPv6 foreign devices must register with a BBMD in order to transmit and receive these messages.

About the Author

Coleman Brumley is a

Senior Software Developer

at PolarSoft Inc., the leading

developer and supplier of

third party BACnet stacks,

tools, routers, development,

consulting, and pre-testing

services. Coleman has

been active in the BACnet

community for 14 years.

During that period, he has

contributed technical content

to the ASHRAE/ANSI 135

standard, has served as

convener of the IP-WG since

2010, and has served two

terms as an SSPC 135 voting

member.

BACnet/IPv6 Message Types

BACnet/IPv6 introduces several new BVLC message types, mostly to deal with VMAC address resolution at the datalink layer. These new messages and their respective functions are listed in the following table.

BVLC MessageAddress-Resolution

Forwarded-Address-Resolution

Address-Resolution-Ack

Virtual-Address-Resolution

Virtual-Address-Resolution-Ack

FunctionThis message is used to lookup the B/IPv6 address of known VMAC address. This message is sent via multicast.

This message is used by BBMDs to forward an Address-Resolution message to nodes in its broadcast distribution and foreign device tables. This message is sent via unicast.

This message is sent in response to an Address-Resolution message. This message is sent via unicast and is directed to the node which originally sent the Address-Resolution message.

This message is used by B/IPv6 nodes to lookup the virtual address of known B/IPv6 addresses. This message is sent via unicast.

This message is sent in response a Virtual-Address-Resolution message. This message is sent via unicast to the node which originally sent the Virtual-Address-Resolution message.

The other B/IPv6 BVLC messages are analogous to their B/IP counterparts. Conclusion

The need for supporting IPv6 has been well-known for almost two decades. With the recent talks of Smart Grid and the Internet of Things, it’s finally become an urgent priority for the building automation community. BACnet has been taking steps to have an IPv6 solution in place when the need arises.

This article provided a brief summary of BACnet/IPv6 as it is defined in Addendum 135-2012aj. As a BACnet vendor, I ask that you get involved by researching IPv6 concepts and participating in BACnet activities such as the annual interoperability workshops (aka “PlugFests”). At this year’s North American PlugFest, I ask that any interested implementers of BACnet/IPv6 bring a sample that can be tested during at an IPv6 round table.

Building Better with

© BACnet International 2014 – further editorial use of articles in Foundations is encouraged. Please send a copy to the BACnet International office atinfo@bacnetinternational.org.

© BACnet is a registered trademark of the American Society of Heating, Refrigerating and Air Conditioning Engineers, Inc. (ASHRAE).

DISCLAIMER OF ENDORSEMENT:

Foundations is a publication which is as designed to be as inclusive as possible in

sharing of views and information. As such, there may be references to resources,

products, companies or services that have not been vetted or endorsed by

BACnet International. BACnet International provides these resources solely for

your information. Responsibility for accuracy lies ultimately with the individual

authors. Special Thanks:

Foundations is an educational resource produced by BACnet

International for its members. BACnet can be a cornerstone of

your building automation success and Foundations builds on that

cornerstone by providing a wide variety of timely and relevant

articles.

Additionally, Foundations is supported by the BACnet International

Board of Directors:

Andy McMillan, BACnet International

Brad Hill, Honeywell International

Paul Jordan, American Auto-Matrix

Roland Laird, Reliable Controls

Raymond Rae, Delta Controls, Inc.

Nancy Stein, Siemens Industry, Inc.

Michael R. Wilson, Automated Logic

A special thank you to all volunteers in the BACnet International

community.

BACnet International Executive Office

PMB 321 • 2900 Delk Rd, Suite 700 • Marietta, GA 30067-5350

770-971-6003 (ph) • 678-229-2777 (fax)

www.bacnetinternational.org • info@bacnetinternational.org