Understand BACnet communications for control and monitoring of networked lighting

SCOTT ZIEGENFUS explains the basics of BACnet communications, the latest update to the building automation standard, and how the platform can work with networked LED-based lighting.

BACnet is arguably the predominant communication protocol used in so-called building automation and control (BAC) networks. The network platform is used in data delivery between building automation systems (BAS) such as networked lighting systems and building management systems (BMS)/energy management systems (EMS) for monitoring, control, and analytics. This fully open protocol was developed by the American Society of Heating, Refrigeration and Air Conditioning Engineers (ASHRAE) with the first publication in 1995. While BACnet is utilized far more today in applications such as HVAC (heating, ventilation, and air conditioning) as opposed to lighting, the protocol can serve in solid-state lighting (SSL) applications. Let's discuss BACnet technology in detail and consider how it might be used in conjunction with networked smart lighting as we move to the Internet of Things (IoT) era.

Interested in articles & announcements on building systems & networked smart lighting?

The communications in BACnet are object-oriented and based on a client/server relationship, meaning in each data exchange one side takes the role of the client while the other takes the role of the server. In all data exchanges, the client is in charge of what is exchanged, when the exchange happens, and how long the exchange happens with the server. In working with BMS and EMS, networked lighting systems will take the role of the server while the BMS or EMS will take the role of the client. This is an important concept because it sets the data exchange relationship. The BMS or EMS functioning as the client is in charge of the data flow. In taking the role of the server, a lighting system sets the number and functions of the objects offered and the types of services the lighting system has accessible. Fig. 1 depicts the client/server relationship.

The basic "what" the client is controlling is objects within a BACnet device. As of the updated 2016 publication of the BACnet standard, the publication defined 61 object types. Object types are not necessarily a sign of the application's functionality or sequence of operation (SOO) available to the client. Many objects are generic and adapted to an application while others are application specific.

Object-oriented platform

These generic type objects such as Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, and Binary Value are not used for a specific application but can be used for the basic characteristic of a particular part of an application's SOO. This is in contrast to objects added that are application focused and whose properties encompass all the characteristics to achieve the full functionality required by the given application.

FIG. 1. A client-server architecture underlies BACnet communications.

Let's consider an application-oriented example. Say a facility manager wants a building to participate in a demand response (DR) power-utility program and needs the BMS or EMS to shed lighting loads to achieve the kilowatt load agreed to with the utility. An object specifically developed for this function is the Load Control object. Some of the Load Control properties are:

• Start_Time - Start of the shed event

• Shed_Duration - Length of shed event

• Duty_Window - Length of time load is actually shedding during the shed

• Requested_Shed_Level - Amount of shedding requested by client

• Expected_Shed_Level - What the server expects to be able to shed

• Actual_Shed_Level - Amount of power actually being shed

• Shed_Levels - Predefined shed levels

• Time_Delay - Time delay for shed event

To achieve this type of functionality, the lighting system would need to employ at least eight or more generic objects. The logic of how these objects work together to control the DR event now lies on the BMS/EMS system, which is responsible for programming the interaction that would have been built in if the Load Control object were used. Additionally, the Load Control object was meant for shedding loads in DR events signaling to the BMS/EMS during the auto-discovery phase, since the lighting system has the Load Control object and it can work with DR events out of the box. A question for control and monitoring the SOO you are looking for is the capabilities and types of objects that are exposed by the networked lighting system. Are they application-specific objects or generic objects that take more responsibility, time, and programming on the part of the BMS/EMS?

Data exchange

The "how" of data transmission are the services that dictate the exchange of the data. As of the 2016 publication of the standard, there were 41 different services. Services are divided into five interoperability areas or categories: Data Sharing, Alarm and Event Management, Scheduling, Device and Network Management, and Trending (Fig. 2). Below find brief summaries of these services:

• Data Sharing's function is for the exchange of information. It permits the collection of data for items such as reporting and historical archiving.

• Alarm and Event Management's function is the exchange of data when a predefined condition happens, an "event." Events can trigger a certain control action, can simply be logged, or can constitute an alarm requiring human interaction. The BACnet standard defines two different mechanisms for reporting alarms and events - intrinsic and algorithmic. Intrinsic relies on properties that are part of the object to be monitored while algorithmic allows the monitoring of an object that uses different parameters then specified within the object.

• Scheduling's function is the exchange of data in relationship to time and date at which a specific action occurs. The lighting community commonly refers to these services as "timeclock events." Scheduling using BACnet services has the potential, but not requirement, for the lighting system timeclock to be modified by the BMS/EMS.

• Trending's function is to log data values for the accumulation of records in long-term storage and sampling intervals for historical data collection.

• Device and Network Management's function is the operation and status of the devices comprising the BACnet internetwork. This category of services allows for the ability to achieve device discovery, time synchronization, and establish startup/shut down connections.

FIG. 2. BACnet services are divided into five categories or interoperability areas.

An example of an important and often used set of services is Alarm and Event Management, called Change of Value (COV). COV is automatic feedback that can be associated with objects if allowed by the server (lighting system) and will update status and transmit automatically in real time with any change of state. For example, if the client was monitoring a Binary Value object for Occupancy status where 0 = unoccupied and 1 = occupied, every time the Occupancy status changed the lighting system would automatically send out the new status of 1 or 0 without having to be polled. Without COV, monitoring would be conducted by a polling of this object and, depending on the polling rate and required response time, polling could either cause network issues because of excessive traffic or delayed response by the lighting if the rate is too slow. It is the client who says when or if this service starts and for how long this service goes, but it is only up to the server to offer the service.

Objects and SOO

BACnet objects need to achieve the desired SOO along with the services to communicate efficiently and properly. A SOO could be how the networked lighting system is expected to perform - the function of services. In an SOO when you state you need real-time feedback, alerts on device failure, or ability to modify the timeclock from the BMS, you need the services as well as the objects to achieve an expected result. This is the reason you will hear a system integrator/installer asking for a Protocol Implementation Conformance Statement (PICS) and a points list.

The PICS consists of the technical specifications for a BACnet device; a points list is a project-specific listing of what each object within the device actually does. The PICS will tell you the device has generic Analog Output and Analog Input objects. A points list will tell the integrator that those are used for dimming a lighting zone where the range is from 0 to 100 and 0-10V control and its range is 0 to 10. It is with these two documents the integrator will gain the knowledge to program the BMS or EMS, interact with the networked lighting system, and achieve the end users' expectations.

Marrying BACnet and lighting

A shift in what data is exchanged is arguably being spearheaded by the lighting industry and moving toward working within a virtual BACnet environment. BACnet devices and objects have always had the ability to be virtual or physical. Historically, physical devices dominated the BACnet landscape. The sheer number of devices in lighting with intelligent luminaires, however, dwarfs the amount of devices in other building systems. Representing a flexible networked lighting system in a virtual environment allows the logical grouping of devices that make sense for minimizing the number of data points the EMS/BMS collects.

This virtualization helps to keep the intrinsic logic already being performed in the lighting system in place, sharing only results to the EMS/BMS, along with the ability to only require software changes for the inevitable change in space use and churn. An example would be grouping occupancy sensors for a given space instead of sending the status of every individual sensor. The BMS/EMS would receive data that a space, not a sensor, was occupied or unoccupied and the AND/OR logic of that grouping would not need to be programmed into the BMS or EMS, saving programming of that function by the BMS/EMS.

The virtual BACnet environment is different from working with third-party gateways that translate from the BACnet protocol to a proprietary or other non-BACnet protocol. In a virtual solution from a BACnet client, it is talking directly to virtual BACnet devices through a virtual BACnet router. Within the lighting controller, a conversion happens from physical product to the embedded software forming the virtual BACnet environment. In essence, the BMS or EMS is linked directly to the networked lighting system's control and monitoring dashboard.

Objects for lighting

Efforts are underway in the BACnet committee to enhance the data exchange for networked lighting systems with the addition of objects specifically set for applications in lighting. In addendums found within the 2016 BACnet standard, added lighting-centric objects include Analog Lighting Output and Binary Lighting Output. Both lighting objects added functionality specific for networked lighting systems and that in the past required a string of generic objects plus extra programming from the EMS/BMS.

The objects include many useful properties for lighting. For example, functions like Blink-Warn for after hours, 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 are all properties within the Lighting Output object.

Additionally, the Binary Lighting Output object included those properties above plus added functions found in an intelligent ballast or driver, such as elapsed time that 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. More lighting-specific objects are either in public review or committee like the Color Temperature object for CCT color tuning within the Planckian locus, the Color Value object for dynamic color changing, or the Stage Value object for changing thresholds between scenes with a deadband for daylighting. These efforts will allow the "what" in data exchange to be more poignant and efficient with respect to lighting.

BACnet web services

One of the biggest changes in the 2016 publication of the BACnet standard was the addition of BACnet Web Services. The addition was so monumental it could have been its own new standard. These services help every BAS, including networked lighting systems, exchange data in ways suited for the world of IoT communications. Made for an enterprise-level architecture, BACnet Web Services uses a REST (Representational State Transfer) based service model. The standard defines 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 data model and services are protocol independent and can be used to model data from any source including support for data types beyond building control system data such as PDFs, CSV (comma separated values), etc. The standard, however, presents a clear path and guide for modeling the BACnet devices and objects within a device using the BACnet communications we know today while adding semantic tagging and descriptions represented in the data model. Then, it uses either a URL or zipped typed files called xdd described within the standard to communicate machine to machine (M2M) or machine to human (M2H).

Conclusion

This article gives a technical overview on how BACnet communication for control, monitoring, and analytics between the BMS/EMS and a networked lighting system might work. The article should give the reader the knowledge to help identify companies that understand the fundamentals of the 1600-plus-page standard, as well as understanding the philosophy vendors use in what and how they choose to communicate their attributes and the optimized path for integration. Unless you are already fully versed on the 61 BACnet objects and 41 services in the BACnet standard, this knowledge will help you achieve the results required by the end user.

A detailed SOO always needs to be specified. That SOO is not for the functionality of the networked lighting system but a separate SOO for how the networked lighting system interacts with the BMS/EMS. The SOO must answer questions like whose timeclock should control lights - the networked lighting system or BMS/EMS, and how much and what data is to be shared between the systems, and will the BMS/EMS poll for that data or will the networked lighting system provide real-time feedback? Basically the SOO answers the question, where does the logic lie for each lighting operation?

SCOTT ZIEGENFUS is manager of government and industry relations at Hubbell Lighting, and was the 2015 BACnet International Leader of the Pack award recipient (hubbelllighting.com).