August 10, 2022

By Craig DiLouie

As lighting controls become more sophisticated in application and capabilities, properly documenting the system’s intent and settings becomes critical. One of the most important documents is the control narrative joined to a detailed sequence of operations. Though required by commercial building energy codes as documentation for many new construction and major renovation projects, aside from the Lighting Controls Association, manufacturers, and a few other sources, there are few resources providing guidance about how to write them.

Enter the Illuminating Engineering Society (IES), which took on the challenge by publishing ANSI/IES LP-16-22, Documenting Control Intent Narratives and Sequences of Operations in June 2022.

Intended for a variety of users in the lighting community, this document provides guidance on the documentation of control narratives and sequences of operation. It is not intended to be a design guide, but rather a reference manual of best practices on how the design—once formulated—is included in the project documentation and communicated to the construction and commissioning teams.

This article provides background on the importance of the control narrative and then explores the new IES document to summarize some of its best practices.

Controls documentation

There are several possible major documents produced during the design of a lighting control system:

One-line wiring diagrams: visually depict how all control devices connect and their relationship with each other.

Control zoning plan: reveals what control devices control what loads.

Written specifications and cut sheets: describe the products and their desired performance.

Operating, maintenance, and installation manuals: provide information about installing and owning the system.

Panel schedules: assign loads to specific dimmers and switches residing in the panel, if panels are to be installed.

Performance testing criteria: informs the contractor and commissioning authority what and how to test after installation, along with criteria for acceptance.

While all these are important to characterize a control solution, possibly the most important is the control narrative and sequence of operations.

This control narrative describes the lighting controls and their intent, and it provides a basis and context for a detailed sequence of operations, or description of outputs in response to various inputs for each control point. The narrative should demonstrate how the control solution satisfies the owner project requirements (ideally expressed in writing) or justify deviations.

The reason the narrative is so important is because it informs all other documentation, going beyond what drawings can communicate to provide a common guide and reference for the project.

Energy codes: Since as early as the 2010 version of the ANSI/ASHRAE/IES 90.1 energy standard and the 2012 version of the International Energy Conservation Code (IECC), commercial building energy codes based on them have required that certain documentation be turned over to the owner by the conclusion of the project.

For lighting controls, required documentation includes:

Drawings showing luminaires, controls, and circuiting.
Submittal documentation.
Operation and maintenance manuals.
Equipment warranties.
Recommended schedule for inspecting and recalibrating controls.
A control narrative, including recommended settings.

These requirements were included in the standard and model code to ensure energy savings are delivered and persistent and also to enable the owner to maintain the control system.

Distinguishing CIN from SOO

In LP-16, the IES strongly differentiates the control narrative, which it calls the control intent narrative (CIN), and the sequence of operations (SOO).

As part of the Basis of Design or stated design intent for the control system, the CIN is general and serves as a foundation for the SOO, which includes detailed settings that can be used to calibrate and program the control system. While the CIN language may be so general as to be unenforceable, the SOO is written in language that is contractually enforceable.

As such, the CIN is descriptive, while the SOO is prescriptive. An example is shown below:

Image courtesy of the Illuminating Engineering Society.

Building the CIN and SOO

In LP-16, the IES outlines four major elements of a CIN:

General description of the project goals.
Control strategies to be delivered to satisfy these goals.
Description of the lighting control system.
A basic sequence of operation for each general space type or specific space, depending on the project characteristics.

Possible elements include overall project goals, the project or system scale (room-based, building-based, etc.), control strategies, system topology, integration, user interfaces and control, sensors, and general or preliminary approaches to scene controls, settings, emergency lighting, night lighting, etc. The SOO carries this forward to describe how each will specifically be accomplished.

Simple: In a marked contrast with the final SOO, the CIN should be written in non-technical language that is easily understood by the owner, which allows the owner to review, approve, and maintain the control system. As such, it should show how the control solution will satisfy the owner’s project requirements.

Living: As the CIN expresses the design intent of the control system, it should be considered a living document, revised and given more detail as needed across each phase of the project until finalized. LP-16 provides in-depth discussion about conceptually fleshing out the CIN during each major construction phase and how it coincides with similar strengthening production of the SOO.

Complementary: Because it contains a basic preliminary sequence of operations, the final versions of the CIN and SOO should obviously agree in terms of basic descriptions, strategies, and settings, with the CIN seeming to hand off to the SOO in terms of specificity and measurable outcomes. Ideally, the two should work together to provision an actionable controls solution that will satisfy owner requirements as well as both the conceptual and functional design requirements.

In LP-16, the IES defines a series of steps to producing a CIN, summarized:

Review owner requirements: First, the design team must review the owner project requirements to determine exactly what it is being tasked to provide. Presumably, this will include external factors such as commercial building energy code requirements.

Review project characteristics: Next is a review of the project characteristics, notably evaluating space types for function, schedule, and other characteristics such as available daylight.

Review control solutions: The design team should now evaluate how each space type should be addressed by the control solution.

Identify integration and interactions: The design team should consider how devices will need to work together within the control system and potentially with other building systems.

Define control purpose and strategies: From the above foundation, the design team can now define the control system’s purpose for each space type, accounting for the scale of the system and whether it will respond to building-level inputs and inputs from other building systems as well as local lighting control inputs. This involves identifying control strategies that will be applied.

Identify desired control inputs, outputs, and behaviors: A list of actions and responses (inputs and outputs) is identified, along with defining behavior for each output, which involves settings.

Review: At the conclusion, the design team reviews to ensure the concept is comprehensive.

When the design team is ready to develop the SOO from the control concept, LP-16 recommends another series of steps, summarized:

Start with code: A good place to start is to ensure all strategies, control zoning, and sequences of operation required by applicable codes and standards are represented and enacted.

Identify the spaces: List all spaces, which can be grouped as space types and the space types in turn also groupable for larger-scale sequences of operation all the way up to the building or campus level.

Ensure compliance with owner requirements: The lighting control design should satisfy both statutory requirements such as local energy codes as well as the other owner project goals.

Define system behavior: For each space and control point, define what actions occur and how those actions occur. This is followed by identifying settings that will be needed to achieve the desired actions.

Review: The design team reviews to ensure the SOO addresses all functional and integration requirements.

Organizing the Material

Distilling projects into easily digestible and understandable CINs can be challenging, notably in how to organize the material. The first step is to evaluate the spaces and the scale of the control system, along with integration points.

Spaces: Theoretically, every space could be identified with a room number and assigned one or more control strategies. Often, however, individual spaces receiving the same control strategies can be aggregated by type.

For example, all private offices may be served by a vacancy sensor coupled with a user keypad enabling On/Off control as well as dimming. Separately, windowed private offices may also be served by a daylight sensor with its own behavior and a point of interaction with the keypad.

The resulting narrative would identify the lighting type (general lighting) in the space (windowless private offices) and then identify what happens and when (occupant enters the room, activates and adjusts light level to preference, and then when the occupant leaves the lights automatically turn Off). Preferred control behaviors and other parameters are then called out (keypad is located and clearly labeled for user convenience, vacancy sensor turns Off the lights at the maximum time delay allowed by the local energy code).

Scale of the control system: If the lighting control system contains elements that have inputs and outputs at a larger level such as a floor or building, this can be called out separately. For example, if it is understood the building will participate in a demand response program, the behavior of the strategy (type of input signal, resulting load shedding, what loads are affected, what happens if general lighting has already been adjusted lower than the load-shed level) is defined.

Additionally, any integration aspects should be covered either globally (e.g., all automatic window shades integrated with local electric lighting controls) or for space types (e.g., all open offices featuring automatic window shading, all lobbies featuring it, etc.). The project characteristics usually convey the right approach.

As a time-saving measure, designers may develop boilerplates for various building and space types with minimum energy code compliance as a starting post, which can then be customized for future projects.

The SOO matrix: The SOO contains a lot more specific information and therefore requires more detailed organization. LP-16 identifies a matrix as a suitable tool for its expression. Vertically, we see a list of spaces or space types cast against a horizontal list of control strategies and components such as emergency lighting control, with checkmarks in the resulting matrix indicating in what spaces or space types the control strategies will be applied.

This is the basic start, developed during the conceptual (schematic) design phase. In the next phase, design development, the SOO matrix is refined with the inclusion of design light levels and initial settings, along with notes providing more detail about operation and hardware. During construction (construction documents phase and installation and programming phase), all sequences and settings are clarified, reflecting any design changes.

By the end, the SOO is tied to lighting control designations with detailed text sequences, notes, and room numbers on the plans. Below is an example of an SOO matrix refined to pre-installation and programming conclusion:

Image courtesy of the Illuminating Engineering Society.

The SOO matrix is useful in that it provides a built-in checklist and can be adapted readily from project to project should boilerplate sequences are developed. Note, however, it has its limitations when the project involves building-level control or integrative strategies (such as integrating plug load control), highly sophisticated sequences, and detailed scene control. In these cases, the SOO approach should be adapted (such as references in the matrix to a more detailed written SOO, as shown in the “Other Notes” column in the above example) to accommodate these more sophisticated needs.

Best practices

At 80 pages, ANSI/IES LP-16, Documenting Control Intent Narratives and Sequences of Operations provides detailed discussion about and proposes best practices for producing these highly important design documents related to lighting control systems. In this publication, the IES committee defines the CIN and SOO, relates their development to the project timeline, identifies roles and responsibilities, investigates lighting control strategies and integrations with other systems, and presents the SOO matrix. Helpful appendices provide boilerplate forms complete with questions as prompts. Whether taken as guide or inspiration, LP-16 should be in every designer’s toolbox.

Click here to get a copy of Documenting Control Intent Narratives and Sequences of Operations.

This article is published with permission from the Lighting Controls Association

Source