BACnet International Foundations by BACnet International

JANUARY 2017 INCLUDED INSIDE:

Lighting as Equal Player in BACnet Network Port Object iPv6 BACnet Developers Q&A New BTL Certification Program Golden Week

www.bacnetinternational.org

FOUNDATIONS â&#x20AC;&#x201D; A BACNET INTERNATIONAL PUBLICATION

Overview The Foundations publication is an educational resource produced by BACnet International for its members. BACnet International is the cornerstone of your success, and Foundations builds on that 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 associationâ&#x20AC;&#x2122;s monthly enewsletter, Cornerstones.

For more information on BACnet International, please visit www.bacnetinternational.org.

Questions or article submissions may be directed to BACnet International Association Manager Natalie Nardone, at natalie@bacnetinternational.org

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

Table of Contents Lighting Becomes an Equal Player to HVAC with BACnet By Scott Ziegenfus Manager, Government and Industry Relations, Hubbell Lighting................................................................................4

Network Port Object By Duffy O’Craven BACnet Testing Laboratories (BTL) Manager ...............................................................................................................6

BACnet/IPv6, Finally By Coleman Brumley Senior Software Developer, PolarSoft.........................................................................................................................10

BACnet Developers Q&A By Steve Karg Principal Engineer, Legrand BCS & Member, ASHRAE .............................................................................................13

New BTL Certification Program By Andy McMillan President & Managing Director, BACnet International .............................................................................................15

BACnet Golden Week...............................................................................................................................16

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

Lighting Becomes an Equal Player to HVAC with BACnet By Scott Ziegenfus

Manager, Government and Industry Relations, Hubbell Lighting

ACnet was started in the 80s as an open protocol to establish harmony among different building environmental systems with the major emphasis on the HVAC industry and its components. Lighting was not thought of until much later, which was evidenced by the fact that the first meeting of the lighting subcommittee was not for another 14 years. In the late 90s and early 2000s HVAC’s dealings with the interrelationship of thermal comfort, ventilation and humidity were a greater control challenge to facility teams than lighting in the buildings environment. Lighting was first considered starting with the electric shortages of the mid 2000s since it makes up 1/3 of the electric usage in a commercial building. Monitoring was a want, but still lighting was thought of as an ancillary system for the BMS, but that has changed with the emergence of LEDs. The LED fixture is a complex electronic circuit whose primary purpose, at first glance, is to illuminate the indoor environment. This electronic circuit, however, can easily be expanded to exchange data, incorporate sensing technologies, and employ other technical assets with the added benefit that these circuits directly cover every usable square foot of the building footprint. LED lighting is the perfect mechanism to be the primary communication medium for the building environmental conditions and occupant information with applications for indoor positioning, energy management, property management, asset management, occupant comfort, space usage and more. To take advantage of this new revelation, the BACnet committee’s efforts are underway to enhance the data exchange within the BACnet standard for Networked Lighting Systems. The first step was the addition of objects specifically set for applications in lighting. In addendums found within the 2016 BACnet published standard, lighting added the Analog Lighting Output Object and the Binary Lighting Output Object. Both lighting objects added functionality specific for Networked Lighting Systems, which, in the past, required a string of generic objects plus extra programming from the EMS/BMS. Functions specific to lighting, such as Blink-Warn for after-hours, are embedded in the single object. Blink-Warn, for example, is a function in all lighting systems required by all three energy codes: IECC, ASHRAE 90.1 and Title 24 Part 6. Energy codes put a maximum manual override action after automatic shutoff by a time clock in after-hours to be two hours. This is so a person can’t override the time clock and then forget to turn off the lights and simply leave. The action has someone entering the space and manually turning on the lights. This starts a preset timer that is less than two hours. Once that timer hits its end, the lights will blink a predetermined number of times informing the occupant that lights will be turning off soon. After the Blink-Warning, a second timer is started that allows the occupant to either leave the space or hit the manual override again to restart the sequence. The entire programmed sequence of timer setting before blink warning, number of blinks and timer setting after blinks is already built into the object. It would take an extensive number of generic objects with significant programming within the BMS to achieve the same result of a single property of the lighting object. This is one sample of lighting specific functionality built into the lighting object along with continuous control of lighting level, ramping to a level at a fixed rate of change, fading to a level over time, incremental stepping values up and down, feedback for actual value of light level, total Power and instantaneous power of loads and Min - Max value for High and Low end trim. These are all properties within the Lighting Output Object. Along with the Analog Lighting Object, the Binary Lighting Output Object included those functions, plus added functions found in an intelligent DALI-based LED driver such as elapsed time. This indicates accumulated number of seconds that the light was ON and strike count for the number of times the light has transitioned from OFF to ON.

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

More lighting type objects are either in public review or committee, like the Color Temperature Object for Correlated Color Temperature (CCT) color tuning within the Planckian locus, which changes the lighting from a cool blue white to a warmer temperature color with yellows and reds. New research has shown lighting color has major implications on human health and the natural circadian rhythm of the body. The Color Value Object is made for theatrical type dynamic color changes for any number of architectural looks. The Stage Value object is designed for changing between lighting scenes with a deadband for daylighting adoption. These efforts are made specifically for lighting applications and will allow more poignant and efficient programming and functionality with respect to lighting. With lighting objects comes lighting specific BACnet Interoperable Building Blocks (BIBBs) specifically created to service the Lighting Objects. Lighting specific BIBBs are currently in public review. Lighting Specific BIBBs Data Sharing • Lighting Output-A (DS-LO-A) • Advanced Lighting Output-A (DS-ALO-A) • Lighting Output-B (DS-LO-B) • Binary Lighting Output-B (DS-BLO-B) • Lighting View-A (DS-LV-A) • Lighting Advanced View-A (DS-LAV-A) • Lighting Modify-A (DS-LM-A) • Lighting Advanced Modify-A (DS-LAM-A) Device Management • Lighting Output Management-A (DM-LOM-A) These lighting device BIBBs allow for new Lighting Specific Device Profiles. Each piece in a Networked Lighting System can be modeled with lighting specific Device profiles. Lighting specific Device Profiles are currently in public review. Lighting Specific Device Profiles Lighting Operator Interfaces • Advanced Lighting Workstation B-ALWS • Lighting Operator Display B-LOD Lighting Control Stations • Lighting Control Station B-ALCS • Lighting B-LCS Lighting Controllers • Lighting supervisor B-LS Lighting Device B-LD Generic Device Profiles did not have the properties to model all the individual components that make up a Networked Lighting System. They could not specify items such as Ballast and drivers, keypads, lighting controllers, smart switches, touchscreens, and control and monitor software unique to lighting. Now every item within the Networked Lighting System will be able to be identified and specified using BACnet device profiles: • • • • • •

Intelligent lighting fixture can be modeled as a Lighting Device (B-LD) Lighting processor modeled as Lighting Supervisor (B-LS) Smart lighting switch modeled as a Lighting Control Station (B-LCS) Lighting keypads modeled as an Advanced Control Station (B-ALCS) Lighting touchscreen modeled as a Lighting Operator Display (B-LOD) Lighting control and monitor software modeled as an Advanced Lighting Workstation (B-ALWS)

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

This helps allow BACnet to be the fundamental open protocol used internally by a Networked Lighting System which would make external integration to BMS intrinsic and seamless. As stated earlier, LED lighting is the perfect mechanism to be the primary communication medium for the building environmental conditions. This means it is naturally set for BIG data collection. You cannot attend a connected lighting seminar without hearing about the communication possibilities and coverage of lighting and distribution for IoT (Internet of Things) over the building environment. That is perfectly in sync with one of the newest and biggest changes in the 2016 publication of the BACnet standard, which is BACnet Web Services. BACnet/WS was not developed specifically for Networked Lighting, but this methodology allows Networked Lighting Systems to exchange data in ways suited for the world of IoT communications. Made for Enterprise-level architecture, BACnet/WS uses a REST (Representational State Transfer) based service model. The standard developed a Control System Modeling Language (CSML) using a choice of XML (Extensible Markup Language) or JSON (JavaScript Object Notation) as a common data format for defining, transmitting and storing data. The standard also presents a clear path and guide for modeling the traditional BACnet devices and objects we know today while adding semantic tagging and descriptions represented in the data model. Since the beginning, lighting was secondary to HVAC for control by the BMS. Objects, BIBBs and device profiles were all HVAC-based and lighting had to adapt. The capability and coverage of the LED, however, has changed the value of lighting to the building environment. To complement the emphasis on lighting the SSPC 135 BACnet committee has moved to provide specific Lighting Objects, BIBBs and Device Profiles, expanding the BACnet capability into the Networked Lighting world. ABOUT THE AUTHOR Scott has been a member of the lighting industry since 1994, is presently co-chair of the BACnet International Education Committee, and was a 2015 BACnet International Leader of the Pack award recipient. His other industry participation includes ASHRAE committee member for SSPC 135, BACnet committee as Chair/Conviner of the Data Modeling Working Group and SPC 201P, Facility Smart Grid Information Mod, NEMA High Performance Building Council serving on Codes and Standards Review Committee and Title 24 subcommittee, ANSI C137 Lighting Systems committee, Educational reviewer for the USGBC Greenbuild Expo, IES committees for Controls & Protocols and Energy Management.

Network Port Object By Duffy O’Craven

BACnet Testing Laboratories (BTL) Manager A Common Question: I’m curious what advice you’d have for the case where using the Network Port object is desirable, but the Protocol Revision for the device is only 14. Would you recommend implementing the Network Port as a proprietary object, or some other strategy? Some Insight: BACnet evolves continuously, and the Next Big Thing you are going to see is devices that implement the Network Port object type. This object type, first adopted into BACnet at Protocol Revision 17, and then modified in Protocol Revision 18, provides a network visible representation of the data-link topology supported by each device. There will be one Network Port object instance for each port that the device possesses, and many - perhaps most - devices will support an interoperable networked solution to configuration and reconfiguration of the device ports, enabled options, and addresses. It is recommended to take your device to the Protocol_Revision property value of 18. That also involves adjusting the Protocol_Object_Types_Supported property, adjusting that constant bitstring property value to indicate nine octets,

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

with four unused bits, then added octets full of trailing 0’s, except set one bit for the Network Port object type at bit56 (lowest bit position of the final byte). The Protocol_Services_Supported bitstring property becomes 41 bits in length in Protocol_Revision 17, or 44 bits in length in Protocol_Revision 18 or 19. When adjusting Protocol_Services_Supported for length, also keep in mind that if the ReinitializeDevice ACTIVATE_ CHANGES parameter execution will now be executed, even if ReinitializeDevice service execution was previously not supported, then ReinitializeDevice service execution bit20 will be set. By setting the Protocol_Services_Supported and Protocol_Object_Types_Supported property values appropriately, and setting the Protocol_Revision property value to 18, your device will advertise its ability to interoperate with the configuration and device-binding status reporting in configuration utilities that are sure to crop up. These are the main benefits of the Network Port object. It wouldn’t be wise to implement configuration nor device-binding status reporting that are out-of-standard. That would result in frustration when one tool can configure and report status for other BACnet devices, while yours is only abled using a special utility that recognizes your out-of-standard approach. The generality of the Network Port object’s specifications, and the ability to self-advertise each device’s capabilities through Protocol_Services_Supported and Protocol_Object_Types_Supported and the Protocol_Revision property values, will make it effortless to integrate general-purpose utilities into a mixed environment of BACnet devices with varying implementations and varying Protocol_Revisions. Going up in Protocol_Revision to 17 or higher requires supporting all of the Network Port-related pieces, since one Network Port-object per supported port is required in BACnet devices claiming Protocol_Revision 17 or higher. There are several required behaviors that constitute the addition of Network Port objects, which are worth detailing. A careful reading of Addendum-135-2012ai is a pre-requisite, but here also are some subtle considerations in Network Port support where details might be missed. 1. In devices claiming Protocol_Revision >= 17, the Device object is required to abide the removed / revised properties according to http://www.bacnet.org/Addenda/Add-135-2012ai.pdf and have a Network Port object for each supported port. Many properties in that object are required according to which data-link layer technologies are supported in the device. 2. If BACnet/IP is one of the data-link layer technologies supported in the device, note that in devices claiming Protocol_Revision >= 17, the Write-BDT service is required to return Write-BDT-NAK. The operation and manipulation of Broadcast Distribution Tables in devices claiming Protocol_Revision >= 17, is performed through operations on a Network Port object for each supported port. 3. In clause 12.11.33 Max_Info_Frames, note that the value of this property shall reflect the value of the Max_Info_Frames property of the Network Port object with the lowest object instance whose Network_Type is MSTP and whose Out_Of_Service is FALSE. The value of this property is a local matter if there are no MS/TP Network Port objects with Out_Of_Service set to FALSE. 4. In clause 12.11.33, if Max_Info_Frames in the Device object is writable, writing to this property shall cause the new value to take effect immediately, bypassing the activation functionality of the Network Port object. 5. Note the properties formerly in clauses 12.11.40 - 12.11.43 in the Device object, instead are relocated to one or more Network Port objects. 6. If the device supports a Network Port object using the pending changes functionality, then the ReinitializeDevice restart choice ACTIVATE_CHANGES shall also be supported. 7. If the value of the Changes_Pending property of a Network Port object is TRUE, writing a value other than DISCARD_CHANGES (if supported) to the Command property of that Network Port object shall result in the return of a Result(-). 8. While executing any Read service requests received specifying ‘Object Identifier’ = (Network Port, 4194303), the responding BACnet-user shall treat the Object Identifier as if it correctly matched the local Network Port object representing the network port through which the request was received.

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

9. There are some properties that had Conformance code “Required” in Protocol_Revision 17 whereas in addendum http://www.bacnet.org/Addenda/Add-135-2012bf.pdf in Protocol_Revision 18 and higher, Table 12-74, “Properties of the Network Port Object Type Only Used when Protocol_Level is BACNET_APPLICATION” these properties became listed as optional (not present in Network Port object whose Protocol_Level is not BACNET_APPLICATION). See http://www.bacnet.org/Interpretations/IC135-2016-1.pdf for details. 10. Upon receipt of a BVLL Read-Broadcast-Distribution-Table message, a B/IP device that is a BBMD shall load the contents of its BDT into a BVLL Read-Broadcast-Distribution-Table-Ack message and send it to the originating device. If a table entry contains a host name, then the corresponding entry in the Read-Broadcast-Distribution-Table-Ack message shall contain the B/IP address of the resolved host name or X’000000000000’ to indicate that the host name has not been resolved. If the BBMD is unable to perform the read of its BDT, it shall return a BVLC-Result message to the originating device with a result code of X’0020’ indicating that the read attempt has failed. A B/IP device that is not configured as a BBMD shall always return a BVLC-Result to the originating device with a result code of X’0020’ indicating that the read attempt has failed. 11. A B/IP device which is not configured as a BBMD shall upon receiving a Read-Foreign-Device-Table, Delete-Foreign-Device-Table, or Register-Foreign-Device message, always return a BVLC-Result message containing a service specific NAK result code indicating that the corresponding Read-Foreign-Device-Table, Delete-Foreign-Device-Table, and Register-Foreign-Device messages are not supported. Moving up in Protocol_Revision also requires implementing the required behaviors that were adopted in other addenda accordingly. 12. The length of Protocol_Object_Types_Supported property value changes at various Protocol_Revisions.

REVISION

SIZE (BITS)

NOTES

Added Averaging(18), Multi-state Value(19), Trend Log(20)

Added Life Safety Point(21) and Life Safety Zone(22)

Added Accumulator(23) and Pulse Converter(24)

Added Structured View(29), and reserved bits for several other objects in review.

Added Load Control(28), Access Door(30)

Added Event Log(25), Global Group(26), Trend Log Multiple(27)

Added Access Credential(32), Access Point(33), Access Rights(34), Access User(35), Access Zone(36), Credential Data Input(37), and reserved bit 31 for a future object type

Added Network Security(38), BitString Value(39), CharacterString Value(40), Date Pattern Value(41), Date Value(42), DateTime Pattern Value(43), DateTime Value(44), Integer Value(45), Large Analog Value(46), OctetString Value(47), Positive Integer Value(48), Time Pattern Value(49), Time Value(50)

Added Notification Forwarder(51), Alert Enrollment(52)

14 – 15

Added Channel(53) and Lighting Output(54)

Added Binary Lighting Output(55)

Added Timer(31), Network Port(56)

Added Elevator Group(57), Escalator(58), and Lift(59)

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

13. The length of Protocol_Services_Supported property value changes at various Protocol_Revisions. REVISION

SIZE

NOTES

Added ReadRange(35), UTCTimeSynchronization(36),

2 – 13

LifeSafetyOperation(37), SubscribeCOVProperty(38), GetEventInformation(39)

14 – 17

WriteGroup(40)

18 – 19

SubscribeCOVPropertyMultiple(41), ConfirmedCOVNotificationMultiple(42), UnconfirmedCOVNotificationMultiple(43)

14. In devices claiming Protocol_Revision >= 14, each and every object is required to contain the Property_List property. Object_Name (77), Object_Type (79), Object_Identifier (75), and Property_List (371) itself shall not appear in the Property_List value. Any proprietary properties that are supported for the object shall be in the Property_List. Adding the Property_List property into all objects does not increase the size of the response of ReadPropertyMultiple requests for ALL or REQUIRED. The Property_List property is not returned in ReadPropertyMultiple requests for ALL or REQUIRED. 15. If IUT is a Time Master, then it should be able to transmit both TimeSynchronization and UTCTimeSynchronization services, since the receiving devices can potentially support either. All the time sync properties together form an indivisible bundle. Time_Synchronization_Recipients and UTC_Time_Synchronization_Recipients and Time_Synchronization_Interval and Align_Intervals and Interval_Offset properties of the Device Object Type shall be present only if all of them are present. 16. Expect and execute unicast I-Have messages, as well as the long-established broadcast I-Have messages. 17. Expect and accept BACnetEngineeringUnits which exceed the originally reserved enumeration range of 0-255, as additional enumerations have been specified with values from 47808-49999. ABOUT THE AUTHOR 36 years into a programming career, Duffy O’Craven still loves to make computers work better for people. He chairs the BTL working group, oversees the world-wide BTL Testing program, and works regardless of the boundaries separating one day from the next, on seeing BACnet thrive.

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

BACnet/IPv6, Finally By Coleman Brumley

Senior Software Developer, PolarSoft BACKGROUND Annex U in the 2016 version of the BACnet standard (ANSI/ASHRAE 135-2016) introduces the so-called IPv6 datalink to BACnet. Annex U is the publication of Addendum 135-2012aj. The new datalink, referred to as BACnet over IPv6 or “BACnet/IPv6” or the shorthand “B/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,00 0,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. 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.

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

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. Annex U 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 scope as a common scope. But, to allow the most flexibility and to meet site requirements where they’ve created their own multicast configuration, the B/IPv6 multicast address is 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. 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 Message

Function

Address-Resolution

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

Forwarded-Address-Resolution

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.

Address-Resolution-Ack

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.

Virtual-Address-Resolution

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

Virtual-Address-Resolution-Ack

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

The remaining B/IPv6 BVLC messages are: BVLC-Result, Original-Unicast-NPDU, Original-Broadcast-NPDU, Forwarded-NPDU, Register-Foreign-Device, Delete-Foreign-Device-Table-Entry, Secure-BVLL, and Distribute-Broadcast-To-Network. The functions of these messages are analogous to their functions in B/IP. However, the message lengths are different due to the B/IPv6 address payload and the inclusion of the source and/or destination virtual address in the BVLC. 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 taken steps to have a native IPv6 solution in place when the need arises.

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

This article provided a summary of BACnet/IPv6 as it is defined in ANSI/ASHRAE 135-2016 Annex U. 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”). 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 ANSI/ASHRAE 135 standard, has served as convener of the IP-WG since 2010, has served two terms as an SSPC 135 voting member, and is currently serving as the SSPC 135 committee secretary.

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

BACnet Developers Q&A By Steve Karg Member, ASHRAE

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 (BTL) “Implementation Guidelines”. However, some questions are beyond the general scope of that document. Below are some Q&A addressing common questions of this type., so I take the opportunity to address them here. Question: In an output object, such as an Analog Output, can the priority slot that the internal process writes to always be the same priority, and NOT changeable by user configuration (i.e. Priority 5)? Can the internal process write to the Relinquish Default value instead of a Priority slot? Answer: The BTL strongly encourages a continuous internal process to write to the Relinquish_Default property value instead of a specific priority slot of a commandable property. An internal process that is not continuous and wants to momentarily control a priority slot and then relinquish that control some time later could use any priority slot. Alternately, the lowest priority, priority 16, could be used. There is a reference in the BACnet 135.1 Method of Test Conformance to BACnet in 9.22.1.2 Writing a Commandable Property Without a Priority that “...has no internal algorithm writing to it at priority 16”, indicating that this type of behavior was anticipated and may occur in devices. Question: Why do you say that some PC-based MS/TP tools work poorly for RS485 connection? RS-485 is a simple, well-established thing, used for Modbus, and many other protocols. BACnet is a protocol. Are there additional requirements? Answer: BACnet MS/TP slave nodes are equivalent to Modbus RS485 for their timing requirements. However, they also , but include the additional overhead (and benefit) of the BACnet object data modeling in addition to and a broad range of application services. A BACnet MS/TP master node uses the same RS485 physical layer, but it also combines a timing and state machine requirement not present with Modbus. The timing of MS/TP Token passing must occur within 15ms, and not later than 25ms, and some computers with various operating systems have a very hard time meeting theat timing requirement to their serial port all the timeat all times. Question: We want to implement BACnet MS/TP on our existing Modbus product hardware and re-use our application code. Is that possible? Answer: Assuming you have already filled the flash and RAM with product features and are just replacing Modbus, you will probably need to consider a microcontroller with more flash space (and potentially more RAM), or reduce the feature set of the product. The BACnet network layer and application layer consumes significantly more microcontroller memory resources than Modbus. There may be other hardware requirements for BACnet MS/TP, depending on what you have available (MS/TP MAC address, baud rate settings), but those can be software configurable and stored in nonvolatile memory. There will also be additional nonvolatile storage for a variety of BACnet property values such as the Device ID and Device object name. Question: You suggested that we list our device as a B-ASC (BACnet Application Specific Controller). Would it be more of a B-SS (BACnet Smart Sensor) since our device only measures and doesn’t control? Answer: The choice of which BACnet profile to use for a listing is up to the vendor (you get to choose), but a device must include some minimum BIBBs to support the profile chosen.

FOUNDATIONS â&#x20AC;&#x201D; A BACNET INTERNATIONAL PUBLICATION

B-SS (BACnet Smart Sensor) requires the following BIBBs: DS-RP-B (Data Sharing-ReadProperty-B) DM-DDB-B (Device Management-Dynamic Device Binding-B) DM-DOB-B (Device Management-Dynamic Object Binding-B) B-SA (BACnet Smart Actuator) requires the following BIBBs: DS-RP-B (Data Sharing-ReadProperty-B) DS-WP-B (Data Sharing-WriteProperty-B) DM-DDB-B (Device Management-Dynamic Device Binding-B) DM-DOB-B (Device Management-Dynamic Object Binding-B) B-ASC (BACnet Application Specific Controller) requires the following BIBBs: DS-RP-B (Data Sharing-ReadProperty-B) DS-WP-B (Data Sharing-WriteProperty-B) DM-DDB-B (Device Management-Dynamic Device Binding-B) DM-DOB-B (Device Management-Dynamic Object Binding-B) DM-DCC-B (Device Management-DeviceCommunicationControl-B) Your device, as implemented, supports the requirements of B-SS, B-SA, and B-ASC. Your device functionality is certainly more of a simple sensor, so B-SS is probably a much better choice than B-ASC. ABOUT THE AUTHOR Steve Karg is a Principal Engineer at Legrand BCS, 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.

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

New BTL Certification Program By Andy McMillan

President & Managing Director, BACnet International On January 2, 2017, a new BTL Certification Program was created by the merger of the BTL Listing and WSPCert Certificate programs. In this new program, a single application to the BACnet Testing Lab (BTL) provides companies with a Certificate of Conformance, a BTL Listing and the right to use the BTL Mark. The BTL Mark is a mark of distinction and has come to represent a high level of quality and conformance based on rigorous independent testing. The BTL Certification Program provides suppliers with a way to highlight products that have successfully completed this testing, while it provides users with assurance that these products have been independently tested and have passed industry standard BACnet testing. Some projects even require a Certificate of Conformance, since many believe BTL tested products accelerate and lower the cost of system integration. Combining the current BTL Listing and WSPCert programs makes it easier for suppliers and users since there is now one integrated global process for BACnet Certification and Listing. Suppliers only have to submit one application and all new products will have a formal certificate. Users and integrators can now look in one place to find information on all tested products. For many this listing will be a primary research tool for BACnet product information. Other supplier benefits of the new program include: • Managing Certificates of Conformance is simpler because new Certificates are valid for five years instead of just one year. There will still be an annual renewal process but the Certificate will not have to be replaced each year. • The whole process is simpler since suppliers no longer have to apply separately to BTL and WSPCert. A single application to BTL results in a BTL Listing, the right to use the BTL Mark and a Certificate of Conformance.

Next Steps for Suppliers

For suppliers with existing Listings: These suppliers will receive Certification program information with their annual BTL Listings renewal packages and the renewal process will be similar to prior years. For suppliers with existing Certificates: Information including program details, costs and an application for BTL Certification will be sent in February/March 2017. The existing WSPCert program is being discontinued. Therefore, it will not be possible to renew existing WSPCert Certificates when they expire on A pril 1, 2017. Instead, these suppliers must apply to the BTL Certification program. For questions about the new BTL BACnet Certification Program, please visit our FAQ page or contact David Nardone at david@bacnetinternational.org. ABOUT THE AUTHOR Andy McMillan is President and Managing Director of BACnet International, where he works with users and suppliers to expand and enhance the BACnet community. Previously he served as President of a building automation and energy management business unit of Phillips Lighting.

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

Second BACnet Golden Week by BACnet Interest Group China and Asia (BIG-CA) a Great Success

The BACnet Interest Group China and Asia’s (BIG-CA) second annual BACnet Golden Week was held in Beijing, China, November 14 – 18, 2016. The theme of this year’s event was “From Green Buildings to Green Cities” and was hosted by the National Technical Committee 426 on Digital Technique of Intelligent Building and Residence Community of Standardization Administration of China (SAC/TC426), organized by the Instrumentation Technology and Economy Institute (ITEI), and, along with BACnet International, supported by BACnet Interest Group Europe (BIG-EU) and ASHRAE SSPC135. BACnet Golden Week followed a similar format to last year’s well received event and included a technology educational forum, BACnet training and a BACnet PlugFest interoperability event. Companies represented include Siemens, Delta Controls, PcVue, Schneider Electric, Smart IO, Johnson Controls, Shanghai Biens and more than 60 other industry leading organizations. The educational forum was held on the first day of the event and showcased the latest updates to BACnet technology. Presenters included Andy McMillan, President of BACnet International; Bernhard Isler, Chairman of ASHRAE SSPC 135; Raymond Rae, Chairman of BIG-CA; Douglas Chan, Treasurer of BIG-CA; Nicolas Trang, Vice-Director of The Research Institute of Building Environment and Energy Conservation; Cao Yong, Dr. Zhou Xiaolin and Dr. Zhongyongwei from the prestigious Fudan University; and Li Yumin, Vice-Chief Engineer of ITEI. Topics covered included BACnet development in China and abroad, the new 2016 BACnet standard, what the future holds regarding BACnet and IoT, updates to BACnet certification, and excellent success stories showcasing BACnet implementations.

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

One such new project is the installation at The Chinese University of Hong Kong, which took home BACnet International’s Project of the Year award. This award represents the recognition by the BACnet community of excellence in the design and execution of BACnet, and is the first time it has been presented to a project in this market. Bernhard Isler conducted BACnet technology training on the second day, providing participants with a deeper understanding of the future of the BACnet protocol. Material covered included an overview of the 2016 update to the BACnet standard, which includes BACnet/IT, BACnet Security, new BACnet RESTful web Services, and BACnet IPv6. The training session, which is a BIG-CA certified program, also gave participants the opportunity to share and discuss their progress, wins and challenges faced implementing BACnet in their products. Training was followed by a BACnet PlugFest event, under the guidance of Mr. Isler, which provided an opportunity for companies to perform interoperability testing for their BACnet®-enabled solutions in a vendor neutral environment. This event followed the format of other international PlugFest events and included one-to-one testing, round table tests and free tests. BACnet Golden Week has officially become the BIG-CA association’s biggest event of the year.

FOUNDATIONS â&#x20AC;&#x201D; A BACNET INTERNATIONAL PUBLICATION

FOUNDATIONS — A BACNET INTERNATIONAL PUBLICATION

DISCLAIMER OF ENDORSEMENT Foundations is a publication which is designed to be as inclusive as possible in the 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 Roland Laird, Reliable Controls - CHAIR Jonathan Fulton, BCI – Building Control Integrators Brad Hill, Honeywell International Raymond Rae, Delta Controls Nancy Stein, Siemens Building Technologies Dennis Swoboda, Blue Ridge Technologies Michael R. Wilson, Automated Logic A special thank you to all volunteers in the BACnet International community. COPYRIGHT © BACnet International 2017 Further editorial use of articles in Foundations is encouraged. Please send a copy to the BACnet International office at natalie@bacnetinternational.org. © BACnet is a registered trademark of the American Society of Heating, Refrigerating and Air Conditioning Engineers, Inc. (ASHRAE).

1827 Powers Ferry Road Building 14, Suite 100 Atlanta, GA 30339 p: (770) 971-6003 f: (678) 229-2777 w: www.bacnetinternational.org