By C. Webster Marsh, CLCP, MIES Penumbra Controls, Lighting Controls Association

Here’s the scenario: you are a contractor bidding 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 do you 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. An Integrator is oftentimes a service technician for the lighting control manufacturer, the cost of which is rolled into the price of the lighting control system, but they can also be a dealer or sub-contractor that is a third-party to the manufacturer, and therefore not included in the price of the system. When putting together a bid, check to make sure that the BAS integration is included in the bill of materials from the manufacturer, otherwise you may need to hire a third-party to provide this service. A dedicated Integrator for the BAS is essential, but sometimes, even with an Integrator for the BAS, a second Integrator is required for the NLC, even if most lighting control systems can function as soon as they are connected.

The reason for this additional Integrator is because 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:

1. Each device (sensor, keypad, luminaire) on the system needs to be uniquely identified.

2. Each device's parameters need to be defined (such as: type of device or outputs).

Procedure-Oriented means:

1. Devices do not need to be identified or defined.

2. 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, hired by the contractor in charge of the BAS system, will do this work since they are already programming everything else in the BAS, but there still needs to be a programmer for the NLC to identify which devices are communicating with the BAS, hence the second Integrator. This need 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 on their own often require “quick and dirty” programming, while a Building Automation System will often require deliberate and specific programming. The choice to make NLCs this way means installation time is quicker, more efficient, and can be more easily programmed, but it does increase the install and programming time of the integration with a BAS.

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

1. Provide an effective NLC with Bacnet integration capabilities (or “native Bacnet”). Not all lighting control systems have this capability.

2. Identify which devices on the NLC the Bacnet system is integrating with.

3. Identify which devices on the Bacnet system the NLC is integrating with.

4. Identify which NLC devices will be communicating with the Bacnet system.

5. Hire an Integrator for the NLC programming, which can oftentimes be the lighting control manufacturer’s service technician. Confirm with the manufacturer that their service technicians can and will provide the BAS integration.

6. Identify who the Integrator for the BAS is and who is responsible for hiring them.

7. Coordinate the programming of both the NLC and the BAS so that when the integration happens, both Integrators are on site and communicating.

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 system, careful and deliberate planning are the best way to ensure that your project is a success. ■

To view the article in its original form, please go to: https://issuu.com/lightingmanagementandmaintenance/docs/_jan_2023_lm_m/16

Lighting Controls Association: The Lighting Controls Association (LCA), a council of the National Electrical Manufacturers Association (NEMA), is dedicated to educating the professional building design, construction, and management communities about lighting control technology, application, and benefits.

The Lighting Controls Podcast: A podcast to promote the adoption of advanced lighting control systems. Lighting controls specialists Ron Kuszmar and Webster Marsh discuss the intricacies and unique challenges of lighting controls for commercial and integrated architectural projects.