September 29, 2022

Integrating Lighting Controls into Building Automation Systems

Author: C. Webster Marsh, contributor to the Lighting Controls Association

How Do BAS Protocols Fit into The Lighting Controls Equation?

Here’s the scenario: you are a lighting controls designer working on a project with a Building Automation System (BAS) that uses BACnet. The intent of the project is to provide a holistic BAS that reduces the quantity of devices so that each space will have just a handful of devices to control multiple systems. The lighting control system will provide the user interfaces (keypads, sensors, touchscreens) that will communicate with other systems that will use BACnet, a BAS protocol, such as the HVAC system. This is becoming a more common request in projects and the success of the project relies upon a Networked Lighting Control (NLC) system with BACnet integration. So how does a lighting controls designer ensure the success of the project?

The first thing we need to look at is how lighting control protocols work in an NLC. Starting with the NLC system user interface, the keypad, a signal is sent from the keypad to the system processor which typically utilizes the manufacturer specific communication, oftentimes a proprietary protocol, which is referred to as the Front-End Protocol.

This proprietary protocol is not the same protocol that will be used to dim the luminaires. On the other end of the NLC where the luminaire is connected, a Back-End Protocol, such as 0-10V or DMX512 is used to dim the luminaire.

The place where the Front-End and the Back-End connect is the Networking of an NLC and where the BAS integration interface lives, between the NLC and the BAS.

NLCs can use multiple Networking Protocols within their system to communicate between devices. The Front-End Protocol may be from keypad to room controller, but the room controller may convert that Front-End Protocol into a Networking Protocol to be able to speak with other room controllers or a system server. With this setup, an NLC can have two or more protocols, though there are many systems that try to reduce this number as much as possible. NLCs that use wireless devices integrated into their luminaires are an example of efforts to keep this number low, but typically there are still Front-End and Back-End Protocols that are rarely the same. It’s important to understand this, because BAS protocols are exclusively Front-End protocols, which means the BAS protocol needs to be translated to the luminaire’s protocol.

Additionally, BAS protocols are not “plug-and-play” protocols: protocols that let you connect devices without programming afterwards; rather, they require skilled technicians to program and commission – also known as Integrators. In the mechanical divisions, an Integrator is a necessity for this reason and many others. With BAS protocols, you cannot function without a dedicated Integrator, with NLC protocols you can… sometimes. It is still good practice to specify a skilled technician for your lighting control system, but most systems can function as soon as they are connected.

The reason for this difference is that a BAS protocol is often an Object-Oriented protocol whereas NLC protocols are often Procedure-Oriented. I won’t belabor the differences between the two as that can be its own research paper, but here’s a simple breakdown:

Object-Oriented means:

Each device (sensor, keypad, luminaire) on the system needs to be uniquely identified
Each device’s parameters need to be defined (such as: type of device or outputs)

Procedure-Oriented means:

Devices do not need to be identified or defined
Parameters have a strict input-output format

Here’s an example: you are programming an occupancy sensor to control a space on an NLC that uses a Procedure-Oriented protocol. You want a group of occupancy sensors to control the lighting in a space and so you assign them to that space (Space 1 in this example). Then you assign a room controller to the same space as the occupancy sensors where it will listen for the command “Space 1 is Occupied” from any sensor, then turn the lighting on and keep it on as long as that command is present. Once the sensors timeout or the command “Space 1 is Occupied” is no longer sent, the room controller will turn the lighting off. The shared group “Space 1” and the procedure “Occupied” are what define the action taken.

Looking at the same scenario with a BAS that uses an Object-Oriented protocol, each occupancy sensor must be identified with a unique identifier, such as “Occ1_Space1,” “Occ2_Space1,” etc. and given parameters “Occupied” and “Vacant.” Additionally, the room controller needs an identifier “RoomController1_Space1” and parameters “Lighting On,” “Lighting Off.” Then, the parameters of each occupancy sensor and the room controller need to be associated, so that when “Occ1_Space1” is in an “Occupied” state, “RoomController1_Space1” activates the “Lighting On” parameter. This is a gross oversimplification of the programming that goes into each device on a BAS, but suffice it to say, a BAS protocol is more complex than an NLC’s protocol. There is a good reason for this, as Building Automation Systems require a robust programming language to be able to coordinate between multiple unrelated systems, but as a result it is not as simple to set up as an NLC.

NLCs will often use their own Back-End protocol between their devices and a protocol interface to communicate with the BAS protocol. The devices on the NLC still need to be defined in the BAS, but only for simple cross-communication purposes, such as sharing an occupancy sensor. This way, the whole NLC does not need to be defined in the BAS and so programming takes less time to complete. It’s typical that the BAS Integrator, specified by the division in charge of the BAS design, will do this work since they are already programming everything else in the BAS. This still applies to lighting control systems that are “BACnet native” because all this term means is that they have a device that speaks BACnet, but there is still a lot of additional programming required to connect a BACnet native NLC to a BACnet system.

Networked Lighting Control systems often require “quick and dirty” programming while a Building Automation System will often require deliberate and specific programming. This choice to make NLCs this way means installation time is quicker, more efficient, and can be more easily programmed, but it does make the integration with a BAS more opaque to the specifier.

So back to our scenario, the best practice for a specifier to ensure integration between an NLC and BACnet is to:

Design an effective NLC with BACnet integration capabilities (or “native BACnet”)
Specify at which devices the BACnet integration will happen
Identify the BACnet devices that the NLC is integrating with
Specify which NLC devices will be communicating with the BACnet system, with a thorough sequence of operations for each device
Specify who the integrator for the NLC is and what their responsibilities will be
Specify who the integrator for the BAS is and what their responsibilities will be

NLCs are growing in complexity and it may be that one day the above steps will become commonplace for all projects but, as with any lighting controls design, careful and deliberate specifications are the best way to ensure that your project is a success.

The Lighting Controls Association is a council of the National Electrical Manufacturers Association that provides education about lighting control technology and application, including articles, videos, design awards, news, resources, and Education Express, a free, 24/7 series of online courses covering everything from technology to design to commissioning.