10 reasons lighting controls commissioning goes bad
- Understand the electrical engineer’s role in the commissioning process for lighting controls and the importance of communication during the process.
- Identify the core concepts associated with common causes for poorly executed commissioning projects.
- Understand why the owner’s project requirement statement is critical for anchoring the design and commissioning process.
- Understand the amount of detail that should be included in a sequence of operation to allow a commissioning agent to develop a functional checklist.
Modern lighting control systems can provide a level of functionality that was unheard of 20 years ago. However, increased functionality goes hand in hand with increased complexity. To ensure that complex systems function as intended, a formal commissioning process needs to be established.
While most electrical engineers have some level of exposure to the commissioning process associated with lighting controls, either through U.S. Green Building Council’s LEED program or the prevailing energy codes, the process can seem unnecessarily prescriptive in the steps that must be performed. Oftentimes, that process may seem disconnected from the realities of design and construction.
This article, through a series of illustrative examples, is intended to provide perspective on steps in the process and highlight the importance of the role of communication. This article assumes that the reader has a basic understanding of the commissioning process as defined by ASHRAE Guideline 0-2013: The Commissioning Process, which forms the basis for both LEED’s commissioning prerequisite and Illuminating Engineering Society (IES) DG-29-11, Design Guide for The Commissioning Process Applied to Lighting and Control Systems.
Most of the following narrative focuses on the electrical engineer’s role in the commissioning process. However, it should be clear that when commissioning goes bad, it is usually a group effort. The formal commissioning process is intended to be systematic and collaborative with multiple parties involved in each step, and by that very fact, inherently self-correcting. But this can be in conflict with the realities of modern construction where the norms are ever-decreasing construction budgets and tighter construction schedules.
With those types of pressures, the natural tendency is to focus only on quickly executing your own assigned roles and, as a result, lose sight of the collaborative portion of the process. A common thread in all of these examples is the failure of team members to properly communicate with each other. With the ever-increasing complexity and proprietary nature of lighting control systems, it is unusual that any single team member has expertise to do it all alone. This only serves to emphasize the fact that effective communication is the key to successful project delivery.
Here are 10 reasons why lighting control commissioning goes bad:
1. The electrical engineer didn’t consult with the owner/pertinent stakeholders to confirm project requirements prior to developing the basis of design.
You can’t determine what the most appropriate design solution is for the owner without actually consulting with the owner. It is understood that discussing the details of lighting controls with an owner can be a frustrating experience. The vast majority of owners have limited familiarity with code requirements and the capabilities of modern lighting control systems. After all, most aren’t involved day-to-day in the design and construction business.
Often, a significant time investment is required to educate the owner before an informed decision regarding system functionality can be made. Although providing that education may seem inconvenient, the entire commissioning process must be anchored in a clear owner’s project requirements (OPR) statement.
If the owner isn’t given clear expectations regarding what the system can and cannot do, the entire commissioning process could be jeopardized. While, in theory, the owner should be intimately involved throughout the entire commissioning process, that is seldom the case. Unfortunately, this means that there are fewer chances to identify incorrect OPR assumptions, and those errors only get further reinforced in each step of the commissioning process. As a result, the final look, feel, and functionality of the as-installed lighting controls often end up being an unpleasant surprise to the owner.
Ideally, OPR development needs to happen during the architectural-space programming in the predesign phase, and not as an afterthought following the creation of the basis of design (BOD). If the system that is delivered at the end of the project performs in a way other than what the owner expected, the owner will most likely disable or modify the system after the fact in a way that substantially changes the functionality of the system, potentially invalidating any commissioning efforts.
2. An unclear sequence of operation (SOO) for the equipment that was specified.
Most engineers are reasonably proficient in selecting lighting control equipment that is capable of functioning as intended. However, that same equipment is often incredibly flexible and can be configured in numerous ways. More complex, interconnected systems create more chances for
uncertainty in configuration. Without a clear SOO, the contractor/vendor will often select the equipment’s default settings or use their best judgment, which may or may not meet the engineer’s design intent.
For example, in a demand-response situation, a generic sequence might state that the “system shall automatically reduce lighting power by a minimum of 15% below the total installed lighting power in response to a demand-response signal.”
The first question in this particular example is whether this applies to all areas or if certain critical areas are exempt. If a particular type of light cannot be dimmed, should it be turned off? Should only certain lights be turned off, such as accent lighting, while other lighting remains on? Is the demand-response signal from the building automation system (BAS) or directly from the utility company? The questions go on and on.
While the expectation is that these types of issues will get addressed during submittal review or be resolved
as a request for information (RFI) from the commissioning authority (CxA) or contractor/vendor prior to installation, it rarely happens this way. The CxA’s functional test scripts have a habit of being exactly as precise (or vague) as the OPR, BOD, and construction documents that they are based on.
Light fixtures typically are one of the last things to show up on a job site, and final lighting control system setup/programming typically doesn’t happen until all the light fixtures are installed. As such, these types of issues with the SOO aren’t identified until system setup, and as such, occur very late in the construction schedule when the entire construction team is scrambling to complete the project.
3. The electrical engineer didn’t understand the capabilities of what they specified or approved as a substitution.
Lighting controls often are treated as commodity-level products, where they are all assumed to be functionally interchangeable. It’s not particularly unusual to see a specification where a manufacturer and model numbers are listed but then “or equal” is stated, or a throwaway reference to another manufacturer is given without specifying any model numbers.
At this point, the manufacturer and model of controls to be installed as part of a project are ultimately at the contractor’s discretion. Even worse, a three-name specification that includes controls using vastly different technologies (intermixing wireless devices with hardwired, dual-technology sensors with passive infrared (PIR)-only sensors, self-programming versus dip-switch configuration, cloud-based server versus a local network controller, etc.) demonstrates a basic disregard to how such substitutions can impact the functionality of a lighting control system. If you’re specifying an “equal,” provide full model numbers where possible.
While it is possible to specify control devices that have similar functionality from different manufacturers, careful consideration has to be given to how a change in the model or manufacturer can either impact setup/programming or how the CxA writes the associated functional test scripts. It is not the CxA’s responsibility to determine what level of functionality is required if a different control device doesn’t have thesame configuration options as what was originally specified. Don’t assume that the manufacturer will take care of the details of how it should work directly with the CxA without your input.
While the CxA should perform a concurrent review of any equipment submittals, they are not responsible for determining the lighting control’s suitability of use to meet the owner’s functionality requirements. The specifying engineer is responsible.
4. The engineer didn’t specify source-control requirements.
Don’t specify or let contractors mix and match control manufacturers unless there is a very compelling reason. Equipment substitutions to meet a budget or schedule are a fact of life, and this often manifests itself in a request to break up the lighting control package. But while many lighting control manufacturers have a niche product that has a level of functionality and/or price point that other manufacturers can’t duplicate, recognize that each manufacturer also will have proprietary installation and start-up procedures.
Even seemingly simple differences in the look and feel of controls from different manufacturers can confuse end users and impact their perception of how well the system works, regardless of whether the device meets the functional requirements. The bottom line is that the greater the number of manufacturers and models involved, the greater the chance for misconfiguration, compatibility issues, and a bunch of finger pointing.
Include a simple statement, such as “all lighting controls shall be from the same manufacturer; and where interface to other systems such as a BAS is required, those devices shall be certified by the manufacturer and/or a nationally recognized third party, such as BACnet Testing Laboratories, for full compatibility and functionality as defined in the basis of design.”
5. Lack of communication/coordination when integration with other systems is required.
In the past, BAS and lighting control systems were mostly stand-alone with minimal coordination requirements. Now, one of the major challenges with lighting control systems is that convergence with other systems is inevitable to achieve modern functionality requirements. That functionality often goes well beyond traditional status annunciation (on/off) or time-of-day scheduling.
Modern functional requirements that are commonly demanded by owners include energy-usage monitoring, combined web analytics, occupant control of both lighting and HVAC from a common mobile app, space management, etc. Simply specifying a “BACNet gateway” as a magic bullet without either clear functionality requirements or defining the role of each contractor usually ends up in disaster. Very few contractors volunteer to perform extra work, and without proper guidance, the most likely outcome is that the electrical contractor will think it’s the BAS contractor’s problem and vice versa.
The CxA normally gets assigned the role of being the grand coordinator, bringing all the different parties together to facilitate the exchange of information in a collaborative process-but ultimately, the issue will find its way back to the engineer. By the time this happens, it’s usually close to the end of construction when the contractors want to start demobilizing manpower. Remember, bad things typically happen when people are rushing to complete unexpected work at the end of a project.
6. The controls manufacturer was not involved during preconstruction, doesn’t create project-specific installation drawings, or doesn’t assist during creation of the prefunctional checklist and functional test scripts. The CxA and/or contractor says, “I can do it without the manufacturer’s help.”
Most electrical contractors excel at work that we traditionally associate with electricians-pulling wire, bending conduit, installing electrical panels, etc. That same expertise often does not extend to anything that has a proprietary technology component, like modern lighting controls.
Manufacturers are adopting common plug-and-play methods, such as interconnecting devices using unshielded twisted-pair (UTP) patch cords with RJ45 connectors, that can dramatically reduce the chance of physical installation errors. But in most cases, the critical setup and configuration process still isn’t particularly intuitive.
Manufacturers are quite aware of this problem-many have resorted to creating “how-to” videos to address this issue. Admittedly, most contractors do like the convenience of being able to watch (and rewind) installation videos in the field on their smartphones instead of reading printed paper manuals.
However, this cannot replace a simple one-on-one interactive training environment. Most lighting control manufacturers will offer a pre-installation meeting with the installing electrician to walk through the installation of their equipment. This type of interactive setting can be incredibly helpful in heading off common installation and configuration issues.
Again, the CxA’s prefunctional checklists and functional test scripts are intended to be somewhat generic-the majority of the CxA’s checklist consists of questions that can be simply answered with either “yes,” “no,” or some numerical value. Don’t expect them to capture every nuance of the installation and configuration that is unique to that manufacturer’s equipment. The CxA’s checklist isn’t intended to replace the manufacturer’s checklist and setup instructions.
But that doesn’t mean that some pertinent information from the manufacturer to help identify common configuration and installation issues shouldn’t be included. The ASHRAE commissioning guidelines stipulate that the checklist shall be reviewed by the owner and “appropriate team members,” which adds emphasis to this point. Make it a requirement that the manufacturer be involved at very specific points in the construction schedule.
7. Attempting to shorten the schedule by combining prefunctional inspections and functional testing.
There is a huge difference between prefunctional inspections and functional testing. The goal of a prefunctional inspection is to confirm that the equipment has been installed properly and basic calibration/programming is complete. This is commonly performed concurrently with the manufacturer’s start-up services, when the contractor needs technical assistance with system setup. Ideally, the prefunctional-inspection checklists should be completed and approved by the
appropriate team members before any functional testing is performed.
Functional testing isn’t intended to confirm that the equipment has been installed properly-that should have already been done as part of the prefunctional inspections. Rather, it’s intended to demonstrate through execution of the CxA’s test scripts that the system can accomplish the sequence of operation that was developed by the engineer during the design phase.
To save time, there is a temptation to have prefunctional inspections transition directly into functional testing. The pressure to do this becomes greater with smaller control systems/projects, where it is harder to justify the additional expense of mobilizing manpower multiple times to the job site. Inevitably, when those two tasks are combined, they get scheduled closer to the completion date for the project. However, unless the contractor already has familiarity with the specified manufacturer and model of lighting control equipment, it’s expected that some issue will be discovered during prefunctional testing that requires time to correct.
As an example, imagine a 30,000-sq-ft project where the lighting control system consists of numerous “room controllers,” some of which were interconnected via a proprietary network bus to consolidate lighting control functions in large common areas. The contractor had successfully installed this particular manufacturer’s room controllers before, but only on smaller projects. While the room controllers were to be interconnected for large areas, the BOD for individual rooms was that they should be configured as stand-alone without any functional requirement for interconnection to the other rooms.
With the best intentions, the contractor connected every single room controller in the project to the same network bus. His assumption was that it would provide some type of unquantified functionality at some point in the future. What the contractor didn’t understand was there was a limitation in the quantity of control devices that could be connected to a single network bus. While specific devices or individual rooms might work properly, the overall system would respond erratically.
The magnitude of the issue wasn’t understood because no formal prefunctional checklists were performed. The contractor expected that the manufacturer would be able to take care of these issues during their startup services and would perform functional testing at the same time. Although the lighting controls were installed with several weeks left in the construction schedule, the start-up services were scheduled mere days before the owner was to take possession. It took a few days to track down the source of the issue, and the finalfunctional testing didn’t occur until well after the owner moved in. The owner vowed never to use that controls manufacturer again.
8. The CxA and contractor attempted to perform functional testing post-occupancy.
Functional testing is inherently disruptive to the normal operation of an occupied building. After all, one of the most basic human needs is to be in control of your own environment. Testing a lighting control system by turning lights on and off when the occupants aren’t expecting it typically isn’t welcomed.
As such, it isn’t particularly unusual for the CxA and installing contractor to experience something bordering hostility from the occupants when trying to access occupied areas to perform testing. However,
commissioning guidelines demand that a sufficient quantity of devices be tested to qualify as a statistically valid, representative sampling. The options to this problem are either attempt to perform all the testing outside of normal business hours or, the more likely scenario, try to rush through the test scripts as quickly as possible.
Under this type of pressure, even the most methodical of CxAs will start to edit test scripts on the fly, attempting to remove steps that aren’t perceived as being absolutely required. The resulting documentation then becomes inconsistent, which defeats the point of the systematic commissioning process.
The solution to this is to ensure that the initial commissioning plan clearly communicates the importance of having sufficient time for prefunctional and functional testing prior to occupancy, and that this time is included in the construction schedule.
9. Inadequate user training and documentation in the operation and maintenance (O&M) of the lighting control system.
What happens if the owner has an after-hours gala celebrating the opening of their new corporate headquarters, and the lights turn off halfway through the event because the O&M staff wasn’t aware they had to program a temporary override to the lighting control system’s automatic time-of-day schedule?
Training requirements, and the information to be included in the specific O&M plan and overall system manuals, should be defined during the design phase of the project by the CxA in collaboration with the owner.
The challenge with determining the exact scope of the training and documentation is that the intended audience, the building’s O&M staff, typically isn’t directly involved in the design and construction phases of the project. Although it is recommended that O&M staff members witness any functional testing (and potential troubleshooting when the testing does not proceed as expected), this also happens infrequently.
While it is to be included as part of the reference documents in the systems manual, unless explicitly addressed during training, the O&M staff may not clearly understand the general design intent (OPR) and/or how the installed equipment was intended to accomplish that (BOD). This background information must be communicated to the O&M staff to provide appropriate context before any in-depth instruction on a component or system level can be performed. With this knowledge, staff will generally be less likely to modify the system in a way that fundamentally changes the functionality of the system without a good reason.
10. A post-occupancy evaluation visit never happens.
If a tree falls in the forest and no one is around to hear it, does it make a sound? More often than not, the commissioning team moves on to the next project and a post-occupancy visit at the end of the warranty period doesn’t occur. There usually is no contractual obligation for these types of visits after the final commissioning report has been submitted and accepted.
However, it is expected that, as the O&M staff gains additional experience in use of the lighting control systems, those systems will be altered to address new issues that are encountered during day-to-day usage. This is not necessarily a negative reflection on the design and commissioning team’s competency-there is always something that works other than expected.
However, the primary intent of commissioning is to assure that the installed systems consistently perform in a way that satisfies the owner’s requirements throughout that system’s lifecycle. The O&M training and systems manual are intended to establish the basis for maintaining that functionality. However, if the system is modified and the intended level of functionality changes, how do you ensure that the new baseline functionality is maintained without properly documenting it?
LEED Enhanced Commissioning requirements include a 10-month post-occupancy review of operations and development of an ongoing commissioning plan. Implementing an ongoing commissioning plan is the most effective way to ensure persistent energy savings and continued functionality.
Sequence of operation format: The format of a sequence of operation (SOO) needs to be clear and well-written
While a well-written narrative sequence of operations (SOO) is critical, suggested SOO formats from some controls manufacturers are in the form of a spreadsheet. This type of format makes sense when you consider that, on the most rudimentary level, an SOO is nothing more than a conditional logic exercise.
Basically, you’re defining how the controls in any given area should react (turn on, turn off after a certain time period, dim to a specific preset level, etc.) based on a given input (photocell light level, occupancy sensory, time clock, override switch, etc.). With this in mind, assembling a list of lighting control system inputs and resulting outputs should be relatively straightforward.
The inputs/outputs list is usually repetitive, with the same basic items applying to several different room types. The key part is making sure the number of unique area types that you define (private office, conference room, open office, corridor, etc.) is adequate to capture every potential control scenario. This may mean further subdividing certain areas based on different control requirements for different types of lighting (i.e., making a distinction between control zones for general lighting, accent lighting, and emergency lighting).