by C. Webster Marsh, CLCP and Craig DiLouie, LC, CLCP, the Lighting Controls Association
In Part 1 of this Lighting Controls System Design series, we learned about key documentation including the Content Intent Narrative (CIN), Sequence of Operations (SOO), and Owner Project Requirements (OPR). The next step in design development is to turn these requirements and conceptual design into a realized design. This step typically requires flexibility as the architecture and lighting requirements change, necessitating maintaining the CIN and SOO to keep them up to date with any project changes. In this article, we will learn how to plan and coordinate the lighting control system defined in Part 1.
USING A CIN AND SOO
The CIN and SOO are “living” documents, which means they are updated throughout the project to provide a continuous roadmap for the lighting controls designer. As such, any updates to the control intent should be reflected in the CIN and SOO and communicated to the project team, particularly the owner. And because the CIN needs to be understood by all participants, it should be written in simple, plain language.
Using the CIN and SOO to design a lighting control system can be as simple as issuing their final versions to a manufacturer. From these, the manufacturer can produce a submittal that includes a bill of materials, formal documents that detail equipment, mounting locations, and any services. The lighting control systems designer then reviews the submittal. For larger, complex projects, this review can be demanding, and as such, development of diagrams, zoning plan, manuals, schedules, and performance testing criteria is recommended to supplement the CIN and SOO.
LIGHTING CONTROL SYSTEM CONTROLLER
The term controller evolved with the industry and therefore has taken on a number of meanings that may be specific to manufacturers or types of control systems. Its primary, most common definition is a point (such as a device or component) from which a command is given to the lighting control system. Specifically, this is a lighting controller, where a mechanism—or, more commonly in today’s control systems, a microprocessor—receives an input, decides what action is needed, and then changes the lighting in response. The device that directly changes the lighting may be separate from the lighting controller (e.g., a relay or dimmer), differentiating it as a power controller. Lighting and power controllers are commonly separate elements in modern control systems, but both are required to properly control the lighting.
The lighting controller is a critical consideration in design as it heavily influences the architecture of the lighting control system. The best way to determine the architecture of system controllers is to identify, for each control action required by the SOO, where the trigger (control signal) originates and then follow its path to its destination, while identifying each device along the path. The appropriate architecture is the one in which the lighting controller can properly provide all required control actions.
Questions to ask when identifying the controller:
- How does the controller communicate with the system?
- Are controllers that are visible to occupants (e.g., wall switches, keypads), aesthetically acceptable to the owner?
- How are the controllers mounted? Are there special considerations?
- What options or features are available?
- Do the controllers have a range or a capacity? For example, how many buttons does the keypad have?
SYSTEM ARCHITECTURE
As described in Part 1 of this course, lighting control system architecture refers to how devices and luminaires are physically organized. Defining the system architecture determines how the system will be distributed throughout the building, how it will communicate with devices and luminaires, and what, if any, connections to non-lighting systems are needed.
In the below SOO for a lobby, there are several controllers and triggers. Prominent triggers include various time events, necessitating a timeclock as the controller.
SYSTEM ARCHITECTURE
Another important aspect of system architecture is whether the solution will be standalone, room-based, networked, or a combination of these, either side-by-side or in a layered approach. This will determine whether control signals and data are shared between devices, and if so, how they are shared.
Standalone defines a system that operates independently of other systems. An example is a timer switch that controls a utility closet’s lighting or a private office with a ceiling-mounted motion sensor and wall-mounted dimmer. The devices control only the lighting in their assigned space and communicate only with devices installed in that space.
Room-based systems include devices within an enclosed area that communicate and coordinate control actions. These systems are sometimes called “distributed intelligence” systems because the lighting controller is in or near the controlled space instead of a central location. An example is a classroom with a vacancy sensor for automatic shutoff, light sensors for daylight response, and manual controls for the teacher. These systems may be digital with preconfigured sequences of operation that might be adapted during programming but are typically not further modified once the project is complete.
Building- and enterprise-based systems unify room-based systems to layer global control (programming, reprogramming/rezoning, data) atop the system and potentially integrate it with a building management system (BMS). Building- and enterprise-based systems are typically networked, with initial and future programming and zoning accomplished via software (versus hardwiring). As such, they offer dynamic control capability to the system operator, along with the potential for collecting building performance data in a central server or the cloud for analysis.
TOPOLOGY
While architecture describes how devices and controlled luminaires are physically organized, topology refers to how they are connected to share data and receive power. All topologies require a trigger. Sometimes, a trigger may be sent via a central lighting controller such as a PC, but other times, triggers are sent by a device in the system.
Now is also a good time to determine whether the system will deploy wired or wireless communication or a hybrid of the two. The table below provides a summary of the types of topologies used in different system architectures. There are many pros and cons to both options.
WIRED TOPOLOGIES
Wired topologies include daisy chain, bus, and star. The system may also be “topology-free,” meaning it does not impose specific requirements for how to connect devices so that any topology can be implemented.
Daisy Chain: A trigger is passed along to devices in a line. The first device receives the trigger and then repeats it to the next device until the trigger reaches its target.
Bus: A single line connects all devices, this topology is similar to a daisy chain except all devices receive the trigger simultaneously.
Star (aka, Hub and Spoke): A hub distributes triggers to multiple connected devices simultaneously. Multiple hubs may be used in a daisy chain topology to increase the overall distance covered or the number of connected devices.
WIRELESS TOPOLOGIES
Wireless topologies include point-to-point, star, and mesh.
Point-to-point: Two devices within wireless communication range can send triggers to each other.
Star: A hub distributes triggers to multiple wirelessly connected devices simultaneously. Multiple hubs may be used in a daisy chain topology to increase the overall distance covered or the number of connected devices.
Mesh: Devices are connected in a mesh network, which allows triggers to be distributed along the most efficient path to their destination.
PROTOCOLS
Protocols impose design standards enabling interoperability and communication between devices. In lighting, protocol refers to any form of communication, whether a coded digital message or an analog signal. These rulesets may be proprietary, an open standard (i.e., available to the public), or a proprietary standard licensed to other manufacturers to create a de facto open standard. Regarding a lighting control system, there are two major protocol types: front-end and back-end. More kinds of protocols may be implemented in a fully networked and integrated lighting control system, such as a networking or BAS protocol. For more information about lighting control protocols, see EE305: Lighting Control Protocols.
FRONT-END PROTOCOL
A front-end protocol will be utilized when a networked lighting control system is specified. Each system has its own front-end protocol with particular requirements, capabilities, and limitations. The control system designer will need to understand how the front-end protocol will affect the system’s performance. Because protocols are not interchangeable, careful specification can help prevent inappropriate systems from being implemented.
Questions to ask about Front-End Protocols:
- How many devices can the system have connected?
- Is the system wired, wireless, or hybrid?
- How do the devices connect and communicate (topology)?
- Are there specific types of wires or cables that the system components need to use?
- Is there a maximum distance one device can be from another or overall length the system can span?
BACK-END PROTOCOL
The luminaire receives a controller signal via a back-end protocol (also called the “dimming protocol”). This protocol communicates the required intensity level to the luminaire (typically the LED driver). Advanced functions such as color/CCT are possible with more complex back-end protocols. One of the most straightforward protocols is 0-10V, which adjusts the output of a luminaire by increasing or decreasing the voltage on a pair of control wires. On the more complex side is DALI, which sends commands to the luminaire, such as “Go to full output over 5 seconds,” and may store operating data to send to a central server or the cloud.
Simpler protocols require more powerful controllers and more infrastructure to support advanced functionality. For example, a tunable-white 0-10V luminaire will require two control circuits and two wired zones of control. The system will need to calculate and adjust the two zones to maintain hue while dimming intensity.
The more complex the protocol is, the more advanced the functionality the system may natively provide without added devices or infrastructure. Compared to the example above, a tunable-white DALI luminaire will require one control circuit with two programmed zones of control. The driver will calculate the balance required to dim the two zones to maintain hue while dimming the intensity.
ENERGY CODE REQUIREMENTS
Compliance with commercial building energy codes, mentioned in Part 1 of the course, is generally required in the United States and many other countries. Each jurisdiction has its own requirements, but the documentation should make note of which code is applicable, reflect the correct terminology used in the code, and identify which requirements the lighting control system is adhering to or taking an exemption to. Common requirements include:
Full Automatic On (Occupancy): the ability to turn the lighting On to full output in response to an automatic device such as a motion sensor. This is also known as Occupancy Sensor mode.
Partial Automatic On (Occupancy): the ability to turn the lighting On to an output that is less than full (typically 50%) in response to an automatic device such as a motion sensor. This requires a switch or button that turns the lighting on to full output.
Manual On (Vacancy): an application that cannot have an automatic-On (such as a motion sensor). This requires a switch or button that turns the lighting On. This is also known as Vacancy Sensor mode.
Partial Automatic Off: the ability to dim the lighting to an output that is higher than off (typically 50%) in response to an automatic device such as a motion sensor. This requires a switch or button that turns the lighting Off.
Full Automatic Off: the ability to turn the lighting Off in response to an automatic device such as a motion sensor or time switch.
Automatic Demand Response (ADR): the ability to decrease the total lighting load in a building when a signal is received from the building’s electric provider.
Light Reduction Controls: the ability to automatically reduce the lighting in a space in response to occupancy or manual input.
Automatic Receptacle Control: a means of automatically disconnecting certain receptacles from power, typically based on occupancy.
LUMINAIRE SELECTION
Alongside the lighting control design, a formal lighting design will of course be required. It is essential to coordinate the lighting control system with the luminaire selection and layout.
A luminaire is defined as a complete lighting unit consisting of the following parts:
- Lamp such as an LED module
- Driver, or power supply
- Housing, or extrusion
- Optical system to distribute the light, such as a lens
- Connection to power
The luminaire driver, housing, connections, and mounting locations are often considerations for the lighting controls designer.
LUMINAIRE SCHEDULE
A lighting controls designer may be asked to supplement the lighting schedule provided by the lighting designer or to provide a separate schedule for coordinating the lighting controls. Below is an example of a luminaire schedule that includes information needed by the lighting control system (omitting information not pertinent to lighting controls, such as lenses or fixed color temperature).
ADVANCED FUNCTIONALITY
Luminaire “advanced functionality” is a generic term often used to refer to the various non-basic capabilities, such as color tuning. Advanced functionality can range from tuning from a warmer shade of white to a cooler white to panning and tilting the luminaire’s aim on a theatrical stage.
In contrast, the common basic functionality of a luminaire is that it turns On when energized, Off when de-energized, and dims in response to a protocol. A luminaire that lacks dimming is often referred to as a “non-dimming luminaire” because most modern luminaires are expected to be able to include dimming as a standard feature.
Luminaire advance functionality should be identified and defined in the SOO or the luminaire schedule so that this functionality is not overlooked. An example is a linear color-changing luminaire requiring a “chase effect,” able to change from one color to another with the effect traveling along a line of light. If the chase effect is not defined, it may be assumed that the luminaire needs to change color only, and so the system provided may be inappropriate for the intent.
Regardless of how minor it may seem, specifying the intent ensures that it is communicated and implemented.
DRIVER
The driver is often the connecting point of a luminaire to a lighting control system, as it receives a signal via the back-end protocol and directly controls the luminaire’s output. Not every LED system uses a driver, but most commercial luminaires do. While commonly, it is the lighting designer’s responsibility to identify the driver, it is the lighting control designer’s responsibility to ensure that the system provides a compatible back-end protocol to control the driver.
Compatibility is sometimes easy to ensure by using an open protocol, but this is not a guarantee. For example, 0-10V is an open protocol, but the way it is implemented by various manufacturers and standards organizations may result in inconsistent results if using products from different manufacturers or different industries in the same controlled space. DALI is an open standardized protocol, but as there are different versions of it, it is important nonetheless to identify which version being used to ensure compatibility.
Additionally, the driver may serve as the power supply for lighting control devices such as integral sensors. It is important to identify whether the driver can provide dedicated (auxiliary) undimmed power to attached devices.
Adding driver information such as protocol, mounting location, and auxiliary power to the luminaire schedule ensures compatibility between the luminaire and the lighting control system.
ORIGINAL EQUIPMENT MANUFACTURER (OEM) DEVICES
Original equipment manufacturer (OEM) refers to parts that a manufacturer sources from another manufacturer. An example is a manufacturer that buys drivers from a different manufacturer to include in its luminaires, making the driver an OEM component.
When discussing control devices, a motion sensor from one manufacturer can be installed in the housing of another manufacturer’s luminaire. How and when it is installed is important information, as some luminaire manufacturers will install the sensor at the factory while others require an electrical contractor to install it in the field. The lighting control designer’s responsibility is to ensure that any OEM parts are compatible with the connected equipment and that any onsite labor expected by the contractor is clearly defined.
DEVICE SELECTION
Device selection occurs at the end of control system design. One of the primary reasons for this is to ensure that the selected equipment can satisfy the functionality of the specifications. Most systems used in North America make use of a proprietary front-end protocol, which means that all devices on the system must come from the same manufacturer or be approved by the manufacturer for use on their system. For example, a Bluetooth Mesh system, while using the Bluetooth Mesh open protocol, may still be incompatible with other Bluetooth Mesh devices not approved by the manufacturer of the device.
Once all other required work is completed, selecting devices is fairly straightforward, though there are still important things to consider. Here is a short list of questions to ask before selecting devices:
- What is the system architecture?
- What back-end protocols are required to control the luminaires?
- Are there remote drivers for some of the luminaires?
- Will the luminaires have integral devices?
- Will the lighting control system be required to integrate with other building systems?
- Are there specific owner requirements regarding programming, settings, special features, preferred manufacturers, and warranty?
LAYOUT
The physical layout of the system needs to be thought through, but a thorough CIN and SOO may provide enough information so that a layout drawing, by the designer, may be unnecessary. There are some considerations to keep in mind, however, when deciding where equipment is to be installed.
- Where will user interfaces be mounted?
- Is there additional equipment (such as back boxes) the installers need to provide that will not be included with the equipment?
- How will the luminaire layouts impact mounting locations of control devices?
- What are the distance limitations for the control devices?
WALL STATION
Like the term “controller,” switch no longer means what it once did; wall station has taken its place. Switches like the rocker switch have been replaced by user interfaces such as scene controllers (aka keypads). Part of this change is due to the requirements of energy codes; commercial buildings are rarely allowed to leave their lights On indefinitely, and so more intelligent controls are now required to turn lighting Off after a space has been vacated. Another reason for this change is the increased capabilities of modern wall stations; in the past, it was common for each switch to represent a zone of control, which resulted in banks of switches. Modern systems using a single scene controller can control multiple zones independently or simultaneously.
Wall stations come in a variety of styles and capabilities, but they are often categorized into the following groups:
Standalone Station (Wallbox): a device that includes an interface (button or slider) and a relay. This controller may also include a back-end protocol for dimming and a sensor for automatic shutoff. A wallbox is a standalone device with all the necessary components included. Often, it is designed to upgrade an existing switch by replacing it without cutting additional holes. Still, it is limited in capabilities, except if it can connect to a smarter device or system.
Programmable Station: a device resembling a wallbox but rarely includes a relay or any other direct control of luminaires. A programmable station will communicate (wired or wirelessly) with other devices to switch and dim the lighting and may even be used to control multiple spaces.
Scene Controller: a device that often includes more advanced functionality than wallboxes and programmable stations. Scene controllers allow for the control of multiple scenes and zones, usually by providing additional buttons or sliders. Scene controllers may include relays and back-end protocols (like a wallbox) or function like larger programmable stations. They also may include mechanical buttons or programmable touchscreens. More complex scene controllers offer greater functionality to the user but require more end-user training.
SENSORS
Many different types of sensors may be used on a project, but with a comprehensive SOO, it should be clear what kind is required in each space. The most common types of sensors include:
Light sensors (daylight sensors, photosensors) measure light falling on the sensor lens to determine the light level in the sensed area.
Power Sense Relays are devices designed to detect the presence or loss of power in emergency conditions. While not often referred to as a “sensor” in the conventional meaning, it is critical to meeting electrical and life/safety code requirements.
TIMECLOCKS
Timeclocks (time switches) come in different varieties, but they all have the same purpose: control of the lighting based on time of day.
Timer Switches and Simple Timeclocks issues signals based on a programmed time, either as a countdown (e.g., after 5 minutes, switch the lights Off) or as a scheduled event every day (e.g., at 6 PM, switch the exterior lights On).
Astronomic Timeclocks calibrate operations to geographic location and can be used to align lighting system operation with sunset/sunrise or daylight-saving time.
Programmable Timeclocks allow scenes or conditions to be scheduled within the timeclock itself so that they can be triggered based on time of day. While this feature is often included in a more robust controller such as a touchscreen, this feature should still be identified if required by the SOO. With programmable timeclocks, a lighting controls designer can provide conditional logic, such as use of motion sensors after business hours.
REMOTE DEVICES
Remote devices may need to be installed separately from the luminaire. This requires the electrical contractor to do additional work and may require more equipment to complete the installation. The lighting controls designer should think of the lighting control system as a collection of “factory-installed” and “field-installed” assemblies so that labor can be identified as provided by the manufacturer or the installer.
Factory-installed Assemblies are put together at the factory and may even be programmed to specifications before shipping.
Field-installed Assemblies are assembled in the field and may require additional hardware such as panels or specialty junction boxes.
INTEGRATION
Integration refers to connecting unrelated devices or systems for the purpose of making them act as one. A common and simplistic example of integration is use of a touch screen in a conference room to control both the lighting in the space and the volume of the TV. The A/V system is often provided by a non-lighting manufacturer and so creating an integration “handshake,” which is an action that both systems participate in, is required to coordinate the lighting control system and the A/V control system to allow for a seamless experience when a user is controlling the space.
Without integration, multiple devices with the same purpose may be required. A common result of unintegrated systems is having multiple motion sensors in one space, each reporting to a different system. If the systems were integrated, only one sensor would be required.
It is important to note in the SOO where integration is required and what that integration “handshake” will look like. In the SOO matrix below, integration with HVAC has been added. While it is not necessary to know what happens when the HVAC relay opens or closes, it is important to be clear what action the lighting control system is performing. Coordinating HVAC integration requires more than just an SOO, however. Careful planning should be done with the designer of the HVAC system to ensure that the integration will work. The HVAC programmer will then decide how to program their part of the “handshake.”
EMERGENCY LIGHTING CONTROL
Emergency control is an involved topic. The designer of the emergency lighting controls should be a professional engineer or work closely with a professional engineer to ensure the design adheres to code. It is still important for the lighting controls designer to understand how emergency lighting controls will work, however.
Modern lighting systems often utilize the same luminaires that illuminate a space under normal conditions to illuminate the space under emergency conditions, such as when normal power is lost or a fire alarm is activated. This is often achieved by providing a separate power circuit (normal/emergency circuit) that receives normal power under normal conditions and emergency power under emergency conditions. Additionally, an override is required when an emergency condition is triggered.
There are other ways to provide emergency lighting controls, either locally to the luminaire via an integral battery backup or centralized in the building via an inverter with power loss detection, which also adhere to the code requirements.
PREPARING FOR CONSTRUCTION
You’re almost done with the Construction Documents phase of the project, but there’s one last thing the successful lighting controls designer should do before issuing the drawings: a thorough review of the lighting control system with the pertinent design team members. It is easy for intended design changes to get lost or forgotten as design activities conclude. One final coordination meeting can prevent scope gap and additional costs that can arise during the construction phase.
In smaller projects, this review may be a meeting with the lighting designer, the electrical engineer, and the architect, but for larger projects, it may include other engineers, consultants, and representatives. The purpose of this meeting is to ensure that the most recent version of documents, such as the CIN and SOO, are reviewed and that they align with the scope and design of the project.
MOVING ON
You are now ready to proceed to Part 3, covering the installation and post-occupancy phases of the project.
