Networked Lighting Control System Technical Requirements Version 5 (NLC5)
Scope of Technical Requirements
These are requirements for interior and exterior networked lighting control (NLC) systems associated with commercial and industrial buildings, roadways, and exterior environments. Note that while the DLC accepts exterior NLC systems, these systems are not addressed comprehensively at present. NLC systems are defined for the purposes of these requirements as the combination of sensors, network interfaces, and controllers that effect lighting changes in luminaires, retrofit kits or lamps. Luminaires, retrofit kits and lamps are qualified separately by the DLC’s Solid-State Lighting Technical Requirements and Qualified Products List.
DC and PoE networked lighting control systems are eligible to be qualified, in conjunction with the SSL Testing and Reporting Requirements for DC and PoE Lamps, Luminaires, and Retrofit Kits.
Building Management Systems that control networked lighting plus other building systems, such as HVAC, are eligible to be qualified as NLC systems and listed on the QPL, provided that they meet all of the DLC’s requirements for NLC. Note that the DLC does not claim to qualify any HVAC-specific capabilities of these systems at this time.
Horticultural control systems are not eligible to be qualified at this time.
Definition of “Required” vs. “Reported” Capabilities
The Technical Requirements are built on “Required” and “Reported” system capabilities.
Required capabilities shall be available in all systems to be listed on the QPL. Systems that do not offer these capabilities are not eligible to be listed. A successful application will provide information on the availability of these capabilities and characteristics. Key information provided by the manufacturer will be published on the QPL.
Note: While the DLC requires systems to offer a particular capability, the DLC does not specify whether a capability must be installed on a project. For instance, while the DLC requires systems to have daylight harvesting/photocell capability, the DLC does not specify which rooms or luminaires on a project must be installed with daylight harvesting/photocell capability. Project-specific requirements for rebates and incentives are determined by individual efficiency programs.
The DLC will report on the presence or absence of, type, and/or characteristics of each Reported capability for qualified systems. While systems are not required to include these capabilities, a successful application will provide information on the presence or absence of these capabilities and their characteristics. Key information provided by the manufacturer will be published on the QPL.
Additional Requirements (in addition to Tables 1, 2, 3)
“Customer Available Information”:
In order for an applicant to claim a capability listed in Tables 1 and 2, the manufacturer’s customer literature must specify that the system has the capability, with instructions for how to configure and/or use this feature.
“Customer available” means the documentation is for a finished product available publicly on a website, and/or included with the product packaging, and/or provided to the customer upon request. It should not be a document produced for the sole purpose of obtaining DLC qualification without further use for customers. The DLC reserves the right to accept, reject, or require changes to documentation to satisfy this requirement. Any documentation provided to the DLC will be used for the purpose of verifying compliance with DLC Technical Requirements and will not be made available publicly or distributed.
The following capabilities from Table 1 and 2 are exempt from this requirement:
- Continuous Dimming
- Individual Addressability
- Luminaire Level Lighting Control (LLLC, integrated)
- Ease of Implementation
- Type of User Interface
- Control Persistence
The DLC requires a minimum warranty of at least 5 years for all components of the system addressed by the requirements, with the exception of software, on-premises computer server, and cloud service. An optional warranty extension to 5 years is acceptable for meeting this requirement; however, the QPL will identify that an extended warranty must be purchased to meet the requirements.
Commercial Availability and Verification:
All systems must be fully commercially available in the U.S and/or Canada, able to be purchased, and with complete, final documentation and literature readily available on the manufacturer’s website before they can be listed. The DLC requires that a qualified system has been installed and operated successfully in at least one actual field installation at a third-party site (not occupied by the applicant or an agent of the applicant). The DLC will verify this through a case study and/or a customer reference. The facility can be of any size where all of the required capabilities are functional. Multiple sites may be used; for instance, occupancy sensing may be implemented at one site and high-end trim at another. If daylight harvest is not available at a third-party site, then it can be demonstrated in an installation at a building owned by the manufacturer, in a live webinar. Daylight harvest is the only required capability eligible for this exception.
System Overview Presentation:
As part of the application review process, the DLC requires a system overview to be presented via webinar or in-person to the DLC. See the application form for more information. For annual re-listings of a previously qualified system for which a recording of a prior presentation is available and the system has not changed extensively, this requirement may be waived or shortened.
All requirements documents, including the application form, instructions, and supporting documentation can be found on the DLC website here.
In order to serve the needs of stakeholders for long term planning, the DLC has included multi-year plans for energy monitoring and cybersecurity in versions 3.0, 4.0, and now 5.0 of the Technical Requirements. These plans have outlined a general direction for each topic, subject to refinement through the stakeholder input process. After the release of NLC5, the DLC will develop a new multi-year plan for NLC. The process will involve extensive stakeholder engagement, including virtual and/or in person event(s).
Building systems, including networked lighting control (NLC) systems, increasingly need to cooperate and communicate with other systems beyond their boundaries to achieve a higher level of operational efficiency and energy savings. This communication of systems or system components and the ability to act upon the communicated information is called “interoperability”. Interoperability among building components and systems is the key enabler for unlocking the benefits from multi-system operation and optimization. For background context, please see a report by the DLC, “Interoperability for Networked Lighting Controls”, published May 2020.
Interoperability is recognized in NLC5 as a new type of NLC capability. The interoperability capabilities shown in Tables 1.1 and 2.1 below will assist in selection of products that support interoperability in relation to specific use cases. Over time, the DLC plans to recognize additional use cases and to report the system capabilities that support these use cases in order to assist end users in choosing appropriate systems for various uses. As a starting point, the DLC has identified three use cases for initial priority in reporting interoperability. These three use cases are addressed by three corresponding capabilities: External Systems Integration, Load Shedding/Demand Response, and Energy Monitoring. Within the interoperability umbrella, the basic energy monitoring capability is “Required”, while advanced aspects of energy monitoring, such as data content and format, are “Reported”. Other capabilities are “Reported”, but not “Required”, as described in the section above ‘Definition of “Required” vs. “Reported” Capabilities’. The DLC continues to track relevant standards as they develop.
Descriptions of the 3 initial interoperability use cases:
- External Systems Integration
Description: Data from NLC components, such as luminaires, sensors, and controllers, is made available through an Application Programming Interface (API) or BMS1, and can be utilized by other building systems to improve their operational efficiencies. Accessing the NLC component data using the API or BMS allows integration with other building systems, including the Heating Ventilation and Air Conditioning (HVAC) system, energy management system, security system, etc. For example, an HVAC system might use occupancy data from an NLC system.
Reporting: An example of data about external systems integration that already exists in the DLC database is occupancy data granularity. Under NLC5, this data will be presented on the QPL as an aspect of interoperability. The NLC5 application will include additional “Reported” questions regarding communications with external systems through APIs and reporting frequency/latency/format.
- Load Shedding/Demand Response (LS/DR)
Description: Basic/1-way: A demand response signal is received by an NLC system, and the energy consumption of the system is reduced in a pre-defined way, on a temporary basis, without manual intervention.Advanced/2-way:A control feedback loop and communication is established between a building’s demand response server and a demand control originator (such as a grid operator, energy provider, microgrid, or onsite Distributed Energy Resource), so that the building modifies its real-time energy consumption in response to the originator’s needs, and reports the results to the originator. The NLC participates in this ecosystem as one of the load-responding building systems.
Reporting: Examples of data about communication for LS/DR2 that already exist in the DLC database include power data availability, granularity, and accuracy; and supported versions of OpenADR. The NLC5 application may include additional “Reported” questions regarding LS/DR. The DLC will work with a multi-stakeholder group to explore LS/DR 1-way and 2-way communication, and to promote an ecosystem of load responding building systems that meet the requirements of Table 3, Row 16.
- Energy Monitoring (EM)
Description: Lighting system energy data is reported by the NLC and can be shared electronically (automatically or manually generated email) with authorized entities. For example, utility energy efficiency programs for NLCs can receive the energy data to verify energy savings. The lighting energy data may also be accessed for central display of facility energy end-use status or for a building portfolio management provider to benchmark energy performance. Ideally, the data will use a standardized data model, when available.
Requirement: The basic capability of energy monitoring is “Required”, with an exception for room-based systems. Data is reported via a .CSV file and/or an API. Methods of energy monitoring may include automated measurement methods and methods that require manual input of wattage to measure energy use. As part of the application or re-application process, each product that qualifies for energy monitoring must provide the DLC with a sample .CSV file or API documentation.
Energy monitoring capability is not required for room-based systems. A “room-based system” is defined as follows: A system that is designed to control lighting in a single room or space, and where the control, configuration, and management of the system is contained within the room or space illuminated by the system. In order to interact with the system, (for instance, to change any settings or to download any data), a user must be physically present in, or in close proximity to, the room or space illuminated by the system.
In order for a system to qualify for this exemption, the DLC review process confirms that the product claims only “Room or Zone” for interior scope as listed on the DLC QPL; and that if a room based system is capable of being upgraded with an internet connection, then that upgraded system shall meet all of the required capabilities of the Technical Requirements and be listed on the QPL.
The basic capability of energy monitoring is loosely aligned with ASHRAE 90.1-2016 Section 8.4.3 “Electrical Energy Monitoring”, as outlined below in Table 3, Row 11.
Advanced capabilities of energy monitoring are “Reported”.
In the absence of a more detailed applicable standard (beyond ASHRAE 90.1) describing energy data reports, details about data content in the following tables are “Reported”, not “Required”.
Tables EM-1 and EM-2 describe the recommended (but not required) contents of an energy monitoring data report. The Online NLC QPL will report which systems offer these contents. This table is derived from the DLC report “Energy Savings from Networked Lighting Control (NLC) Systems”, 9/21/2017, Appendix A, Tables 8 and 9. The DLC is participating in the ANSI/NEMA C137 Committee to develop more specific data requirements. In the meantime, the required content of an energy monitoring data report is described in Table 3, Row 11.
1 While open BMS protocols can be used instead of API, the need for extensive customized site-specific programming may limit the scalability of integration.
2 For a recent exploration of this topic, see “The Value Proposition for Cost-Effective, Demand Responsive-Enabling, Nonresidential Lighting System Retrofits in California Buildings”, April 2019, Peter Schwartz et al, ttps://www.energy.ca.gov/2019publications/CEC-500-2019-041/CEC-500-2019-041.pdf
Table EM-1: Recommended Energy Data Reporting Guidelines for .CSV or API; Static Data
|1.1||Headings||For each field||Each type of data element is identified by a heading.||Text such as “Manufacturer”, “Product”, etc.|
|1.2||System||Manufacturer||The manufacturer of the NLC system||Text|
|1.3||System||Product||The name of the NLC system||Text|
|1.4||Site||Building/Business Type [*Note A]||The main business function in the portion of the building where the NLC system is installed||From ASHRAE 90.1-2016 Table 9.5.1|
|1.5||Baseline for NLC||Maximum Rated Power with no control strategy enabled||The maximum possible power consumption of the lighting system without any control strategy in effect. If a luminaire retrofit has occurred, this value is equal to the maximum rated power of the new luminaire(s). The spatial granularity matches the energy measurements. For instance, if energy is reported at each luminaire, then the baseline power is reported at each luminaire.||
Separate data for interior vs. exterior.Units = kilowatts
|1.6||Energy||Energy Reporting Interval [*Note B]||The frequency an energy measurement is reported (15 minutes or less)||Units = minutes|
|1.7||Energy||Data method||How is energy interval data calculated?||Text such as “15 minute average from 3 samples spaced 5 minutes apart”|
|1.8||Energy||Energy Data units||Energy data is in Wh or kWh?||Units = text such as “Wh” or “kWh”|
Table EM-2: Recommended Energy Data Reporting Guidelines for .CSV or API; Dynamic Variables
|2.1||Headings||For each field||Each type of data element is identified by a heading.||Text such as “Unix Time”, “Energy Data kWh”, etc.|
|2.2||Energy||Timestamp||Date and time of each energy measurement||Unix time or RFC 3339 time|
|2.3||Energy||Energy Data||The actual energy readings that are recorded for each luminaire or group of luminaires||Units = kWh or Wh|
|2.4||Energy||Confidence Level||The percentage of all possible samples expected to include the true population parameter.||Units = %|
|2.5||Energy||Nominal Accuracy||% accuracy of the energy data [*Note C]||
Text such as “+/-3% or 0.005 kWh, whichever is larger”
|2.6||Energy||Recorded Period||Months of 15 minute interval data in this particular record||Units=months|
Note A: For Building/Business Type, ASHRAE Standard 90.1-2016, “Energy Standard for Buildings Except Low Rise Residential Buildings” Table 9.5.1 can be freely viewed at https://www.ashrae.org/technical-resources/standards-and-guidelines/read-only-versions-of-ashrae-standards, PDF page 155.
Note B: The need for 15 minute interval data is derived from the IPMVP Options A and B, as typically implemented by utility programs (International Performance Measurement and Verification Protocol: Core Concepts and Options for Determining Energy and Water Savings EVO-10000-1.2016, Efficiency Valuation Organization, evo-world.org.)
Note C: The accuracy of the energy data as defined by the manufacturer. In the future, the DLC expects to recognize standards of accuracy as they become available from ANSI C136 and C137.
Future plans for interoperability:
- Additional Use Cases
Use cases in the future may involve additional capabilities beyond the three in NLC5.
In alignment with the multi-year cybersecurity plan previously published in versions 3.0 and 4.0 of this document, the DLC is taking the next step to help ensure qualified systems utilize best-practice standards for cybersecurity. The cybersecurity capability is “Required” under NLC5. The criteria have been expanded from NLC V4.0 to offer more options for compliance.
- While the standards in Table CS-1 and services in Table CS-2 can be applied to NLCs, not all of their requirements may be relevant for various applications of lighting control systems.
- Manufacturers and their certification bodies should review each option to identify the appropriate requirements for each system being qualified, and customers should select product requirements based on the risk profile of each project.
- In order to claim the cybersecurity capability, a system must, at the time of qualification, have a valid certification for one or more of the specified standards in Table CS-1, or services in Table CS-2.
- The list of applicable standards in Table CS-1 and services in Table CS-2 will be reviewed for each incremental revision to the Technical Requirements, or annually, whichever comes sooner. Applications referring to a potential new standard or service will only be accepted for review after the new standard or service has been vetted, and an updated set of Technical Requirement has been published. The addition of a new standard or service may only warrant a minor Technical Requirements update, such as from NLC5 to NLC5.1.
- Certification in any one of the four categories of Table CS-1 (Process, Components, System, Cloud Services) is sufficient.
- Table CS-3 describes how DLC reviewers will confirm compliance.
- The DLC will confirm that cybersecurity certification will be valid for at least 12 months after the time of application submission. If the certification will expire within a year, the NLC manufacturer will need to submit a letter of intention of renewal with the application and will need to provide an updated certificate upon its expiration, in compliance with Table CS-2 or CS-3, to avoid being delisted.
- The DLC will confirm cybersecurity certification once a year in July, whether or not a system updates data to the next Technical Requirements version. If a certificate has lapsed, a system will need to recertify in order to avoid being delisted.
- Some cybersecurity certifications offer different levels of compliance based on risk management. For instance, some standards offer lower performance requirements for room level systems that cannot be upgraded to add a permanent internet connection. Therefore, the DLC cybersecurity requirement applies to all systems—with the understanding that comprehensive systems with many capabilities are subject to more rigor, compared to simple systems with few capabilities.
- The grace period for renewals is described below under “Delisting and Next Release”. For the new cybersecurity requirement introduced with NLC5, the same grace period is extended to products that have not been previously listed on the DLC QPL.
Criteria for acceptable cybersecurity standards:
The DLC recognizes the cybersecurity standards listed in Table CS-1 that meet criteria 1-3 below, and the cybersecurity services listed in Table CS-2 that meet criteria 2-3 below:
- Certifiable with a methodology established through either:
- A voluntary consensus process such as ANSI, ISO, IEC, etc.
- A federal agency of the USA or Canada
- A collaborative multi-stakeholder engagement process such as the Cloud Security Alliance
- Applies to one or more of the following:
- Product development process lifecycle
- Components/Embedded Devices
- Cloud Services
- Includes at least 3 of the following technical content, for (2. b, c, d) above:
- Penetration testing
- Communication robustness testing
- Vulnerability identification testing
- Multiple levels of security
- Cybersecurity: The practice of defending networked systems and data from malicious attacks.
- Process: Standards that address the development process in order to reduce the number of cybersecurity vulnerabilities that are designed into components, systems, and services, and that manifest over the product lifecycle.
- Components: Standards that address the cybersecurity of each individual physical end device in a networked system.
- System: Standards that address the networked system, including aspects such as authentication, data confidentiality, system integrity, service availability, protocol converters, firewalls, gateways, web servers, and web services interfaces.
- Cloud Services: Standards for cloud services that address secure integration with services from a remote cloud computing provider.
List of certifications:
Certifications that meet the criteria are listed in Tables CS-1 and CS-2. Once a certification is on this list, the DLC does not expect to remove it with less than two years of notice.
Future plans for cybersecurity:
The DLC plans to maintain cybersecurity requirements similar to NLC5 for at least two years, with the possible addition of new standards as they become available, and minor changes in language if needed for clarification. In the meantime, development efforts will explore the potential for more substantial updates after two or more years, to keep pace with the fields of cybersecurity and cyber privacy.
Table CS-1: Cybersecurity Standards Recognized by the DLC
|Standard||Process||Components / Embedded Devices||System||Cloud Services|
|ISO 27017 (with 27001)||y|
Table CS-2: Cybersecurity Services Recognized by the DLC
|Service||Proof of Compliance|
|UL IoT Security Rating (UL 1376)||Copy of certificate or letter from UL|
|CSA Cybersecurity Verification Program (CVP) (CSA T200)||Copy of certificate or letter from CSA|
|Intertek Cyber Assured||Copy of certificate or letter from Intertek|
Table CS-3: Proof of Cybersecurity Standard Compliance
Renewal is required at least every 3 years in order for a certificate to remain valid.
|Standard||Proof of Compliance|
|ANSI/UL 2900-1||Certification claim listed on applicant’s website, plus a compliance letter or copy of certificate issued by an accredited certification body.|
ISASecure registry of a component, system, or Certified Development Organization at https://www.isasecure.org/en-US/End-Users/
Copy of IECEE certificate, or listed at https://certificates.iecee.org/ods/cb_hm.xsp
orCopy of certificate from other accredited agency, such as UL, VDE, DEKRA, etc.
|SOC 2||Certification claim listed on applicant’s website, plus a compliance letter from 3rd party auditor.|
|ISO 27001||Copy of an accredited certification from a member of the ANSI-ASQ National Accreditation Board as listed at http://anabdirectory.remoteauditor.com/|
|ISO 27017 (with 27001)||Copy of an accredited certification from a member of the ANSI-ASQ National Accreditation Board as listed at http://anabdirectory.remoteauditor.com/|
|FedRAMP||“Authorized” at https://marketplace.fedramp.gov/#/products?status=Compliant;FedRAMP%20Ready&sort=productName|
|CSA STAR||“Certification” or “Attestation” at https://cloudsecurityalliance.org/star/registry/|
|ioXt||Copy of ioXt certificate or letter from accredited testing organization or certified at https://compliance.ioxtalliance.org/products|
Delisting and Next Release
NLC Version 3.0 delisting:
NLC3 listed systems were delisted on October 31, 2020, unless they have been updated to NLC5 with cybersecurity.
NLC Version 4.0 delisting:
Any NLC4 systems that have not been updated to NLC5 (that is, that do not have DLC-recognized cybersecurity) will be delisted on February 28, 2022. (This date has been extended from October 31, 2021 because of COVID-19-related complications in product development.) Before February 28, 2022, if a new system applies without cybersecurity or a listed system reapplies without cybersecurity, the system will be listed as NLC4 until proof of cybersecurity is submitted. When cybersecurity proof is accepted by the DLC, the listing version will be updated to match the application version most recently submitted for that system.
Timeline of the next Technical Requirements release:
The current plan for the timeline of future releases is shown below. The releases are moving to a 2-year cycle rather than an annual cycle. Delisting of products without cybersecurity will occur on February 28, 2022.
Requirements for Interior Lighting Systems
For interior lighting systems, Table 1 summarizes general “Required” and “Reported” system capabilities, and Table 1.1 summarizes “Required” and “Reported” system capabilities pertaining to Interoperability.
Table 1: “Required” and “Reported” Capabilities for Interior Lighting Systems
|'Required' Interior System Capabilities||'Reported' Interior System Capabilities|
|Networking of Luminaires and Devices||Control Persistence|
|Daylight Harvesting/Photocell Control||Device Monitoring/Remote Diagnostics|
|High-End Trim||Type of User Interface|
|Zoning||Luminaire Level Lighting Control (LLLC, integrated)|
|Individual Addressability||Personal Control|
|Continuous Dimming||Plug Load Control|
|Ease of Implementation|
Table 1.1: Interior Lighting System Capabilities Focused on Interoperability
|'Required' Interior System Capabilities||'Reported' Interior System Capabilities|
|Energy Monitoring (except room-based systems)||Energy Monitoring (room-based systems)|
|Load Shedding/Demand Response|
|External Systems Integration|
Requirements for Exterior Lighting Systems
For exterior lighting systems, Table 2 summarizes general “Required” and “Reported” system capabilities, and Table 2.1 summarizes “Required” and “Reported” system capabilities pertaining to Interoperability.
Table 2: “Required” and “Reported” Capabilities for Exterior Lighting Systems
|'Required' Exterior System Capabilities||'Reported' Exterior System Capabilities|
|Networking of Luminaires and Devices||Control Persistence|
|Occupancy Sensing AND/OR Traffic Sensing||Device Monitoring/Remote Diagnostics|
|Daylight Harvesting/Photocell Control||Type of User Interface|
|High-End Trim||Luminaire Level Lighting Control (LLLC, integrated)|
|Individual Addressability||Color Changing/Tuning|
|Continuous Dimming||Ease of Implementation|
Table 2.1: Exterior Lighting System Capabilities Focused on Interoperability
|'Required' Exterior System Capabilities||'Reported' Exterior System Capabilities|
|Energy Monitoring||Load Shedding/Demand Response|
|External Systems Integration|
Capability and Requirement Definitions
Table 3 provides a definition of each capability. This table applies to both Interior and Exterior systems, except where noted. If an applicant answers ‘yes’ to a capability definition in Table 3, that capability can be claimed. If an applicant answers ‘no’, then the capability cannot be claimed. The DLC NLC application form specifies in more detail the information the DLC asks about each capability, and the information that will be published on the QPL. Beyond the basic definitions shown in Table 3, the DLC NLC application contains additional questions about most capabilities. After answering ‘yes’ to the first key question about a capability, an applicant can answer additional questions about that capability with any well-documented response.
Note: Some NLC systems control luminaires and retrofit kits, and some NLC systems control lamps within luminaires. The latter systems use a wireless controller integrated inside each lamp. The “luminaires/lamps” phrase indicates that a requirement applies to luminaires and retrofit kits if an NLC system controls luminaires and retrofit kits; and the requirement applies to lamps if an NLC system controls lamps.
Table 3: Definitions of Capabilities & Requirements
|1||Networking of Luminaires and Devices||The capability of individual luminaires/lamps and control devices to exchange digital data with other luminaires/lamps and control devices on the system. This capability is required at the room, space, or area level, but not at the whole building level or beyond (e.g. non-lighting systems, or the internet).|
The capability to affect the operation of lighting equipment based upon detecting the presence or absence of people in a space or exterior environment.Exterior systems must include either occupancy sensing or traffic sensing. They may include both, but that is not required.
The capability to affect the operation of lighting or other equipment based upon detecting the presence or absence of moving vehicles in an area.
Systems may satisfy this requirement through external systems integration as described below in lieu of in-system sensors if another source of data is used for presence or absence detection.Exterior systems must include either occupancy sensing or traffic sensing. They may include both, but that is not required.
|4||Daylight Harvesting / Photocell Control||The capability to automatically affect the operation of lighting or other equipment based on the amount of daylight and/or ambient light that is present in a space, area, or exterior environment. This capability is typically called daylight harvesting for interior systems, and photocell control for exterior systems.|
The capability to set the maximum light output to a less-than-maximum state of an individual or group of luminaires/lamps at the time of installation or commissioning. High-end trim must be field reconfigurable. This capability is distinct from automatic compensation for lumen depreciation, which automatically increases output as a system operates over time.*While the DLC specifically requires “High-end trim”, some manufacturers refer to this capability as “task tuning” or “tuning” within their system interfaces. Refer to NEMA LSD 64-2014 for definitions of lighting controls terminology.
The capability to group luminaires/lamps and form unique lighting control zones for a control strategy via software-defined means, and not via physical configuration of mechanical or electrical installation details (e.g. wiring).
Interior: Zoning is required for occupancy sensing, high-end trim, and daylight harvesting control strategies except for systems that feature luminaire level lighting control (LLLC) capabilities as defined in these requirements under “Reported Capabilities”, in which case zoning is only required for occupancy sensing and high-end trim control strategies.Exterior: Zoning is required for high-end trim.
|7||Individual Addressability||The ability to uniquely identify and/or address each individual luminaire/lamp, sensor, controller, and user interface device in the lighting system, allowing for configuration and re-configuration of devices and control zones independent of electrical circuiting.|
|8||Continuous Dimming||The capability of a control system to provide control with sufficient resolution in output (100+ steps) to support light level changes perceived as smooth (as opposed to step dimming with a small number of discrete light levels).|
|9||Control Persistence||The capability of a networked lighting control system’s lowest-level (“edge device”) luminaire/lamp controllers to execute three energy saving strategies (occupancy sensing, daylight harvesting, and high-end trim) at a room-level, or finer, resolution in the absence of communications with the next higher networked element in the system’s topology.|
|10||Scheduling||The capability to automatically affect the operation of lighting equipment based on time of day. Scheduling capability is reported for interior systems and required for exterior systems. Exterior systems are required to have time-based scheduling, and "astronomical" scheduling functionality for sunrise and sunset programming, based on geographical location and time of year.|
The capability of a system to report the energy consumption of a luminaire/lamp and/or a group of luminaires/lamps.
|12||Device Monitoring / Remote Diagnostics||The capability to monitor, diagnose, and report operational performance including system and/or component failures.|
|13||Type of User Interface||The type of interface provided by the control system for users to read and adjust control system settings during system start-up, commissioning, and/or ongoing operation.|
|14||Luminaire Level Lighting Control (LLLC, integrated)||
The capability to have a networked occupancy sensor and ambient light sensor installed for each luminaire or kit, and directly integrated or embedded into the form factor during the luminaire or kit manufacturing process.
In addition to these required integrated components, LLLC systems must have control persistence capability as described in this document.To demonstrate commercial availability of the integrated component options, at least one family, luminaire or kit with integrated control must be verified by the DLC. Manufacturers may choose whether or not to list this information publicly on the QPL.
The capability for individual users to adjust to their personal preferences, via networked means, the illuminated environment of a light fixture or group on of light fixtures in a specific task area. The publicly available information must clearly describe a control interface for use by a single individual who does not have access to system-wide settings.
A wireless dimmer switch may only be considered a personal control interface if product documentation:
A software-based interface may only be considered personal control if product documentation:
|16||Load Shedding / Demand Response||The capability to reduce the energy consumption of a lighting system, in a pre-defined way, on a temporary basis, in response to a demand response signal without manual intervention. The method by which the system implements this capability (managed by NLC and/or BMS) must be clearly described in the publicly available reference(s). The method for pre-defining the system behavior for temporary load reduction must be accessible through a user interface. The data the NLC can receive and interpret from other networked systems must include at least a signal that can be used for purposes such as LS/DR.|
|17||Plug Load Control||The capability to control the power delivered to receptacles through scheduling or occupancy sensing. The method by which the system implements this capability must be clearly described in the publicly available reference(s).|
|18||External Systems Integration (e.g. BMS, EMS, HVAC, Lighting, API, Cloud)||The capability to exchange data with other networked systems such as building or energy management systems (BMS/EMS), heating ventilation and air conditioning (HVAC) systems, or other lighting and building systems via BACnet, Modbus, LonWorks or other open protocols, application program interface (API) or other methods. In order to claim this “Reported” capability, the data available from the NLC for exchange with other networked systems must include occupancy status at the zone, space, or area level and energy data at the zone-, circuit- or system-level. The data the NLC can receive and interpret from other networked systems must be digital, that can be used for purposes such as scene control, zones, groups, areas, regions, and/or presets. The method, including formats and languages, by which the system implements this capability must be clearly described in the publicly available reference(s).|
Publicly available documentation illustrating how a system’s luminaires connect with an emergency power source.The QPL will provide the URL(s) for online documentation provided by manufacturers for system designers to refer to. This documentation will identify wiring diagrams, required components, and/or application guides needed to understand design considerations for integrating the system into an emergency lighting system.
A cybersecurity certification that meets the DLC criteria. The current standards are shown in Table CS-1 and listed here:
The current services are shown in Table CS-2 and listed here:
|21||Color Changing / Tuning||The capability to alter the output and color of tunable white and/or variable color output luminaires via a dedicated control interface(s). To demonstrate compliance with this capability, the interface(s) must be clearly described in the product literature and allow for at least two CCT settings. These settings may be described in terms of CCT, such as 3000K or 5000K, or simple descriptive terms for the desired setting such as 'Night' or 'Day'. The product literature must also specify installation and configuration requirements to implement this functionality.|
|22||Ease of Implementation||The QPL will identify the most typical responsible party and their required level of training to start-up and configure the system to the extent that all required capabilities are functioning. Documentation is not required.|
|23||Scenes||The capability of a system to provide two or more pre-programmed light level settings for a group or multiple groups of luminaires to suit multiple activities in a space, and allow for recall of these settings via a switch, control device, or signal from a BMS or API.|