Module 26 - A306a

A306a: Understanding User Needs for Electrical and Lighting Management Systems (ELMS) Based on NTCIP 1213 Standard

HTML of the Course Transcript

(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)

Ken Leonard: ITS standards can make your life easier. Your procurements will go more smoothly, and you'll encourage competition, but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems. I'm Ken Leonard, the director of the U.S. Department of Transportation's Intelligent Transportation Systems Joint Program Office. Welcome to our ITS standards training program. We're pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this approach to training that combines web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself. This combined approach allows interested professionals to schedule training at your convenience without the need to travel. After you complete this training, we hope you'll tell your colleagues and customers about the latest ITS standards and encourage them to take advantage of these training modules as well as archived webinars. ITS standards training is one of the first offerings of our updated Professional Capacity training program. Through the PCB program, we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter, and greener. You can find information on additional modules and training programs on our website at www.its.dot.gov/pcb. Please help us make even more improvements to our training modules through the evaluation process. We will look forward to hearing your comments, and thank you again for participating, and we hope you find this module helpful.

James Frazer: Welcome to Module 26. This course is titled A306a: Understanding User Needs for Electrical and Lighting Management Systems Based on the NTCIP 1213 Standard Version 3. The purpose of this module is to introduce the National Transportation Communications for ITS Protocol Standard Version 3, and to help users to be able to specify systems and equipment that use this NTCIP standard. In addition to the introduction, the module will focus on user needs for these particular systems.

James Frazer: I am your instructor today, Jim Frazer. I'm president of Gridaptive Technologies. I've been the working group chair of the NTCIP 1213 committee, as well as the contracted systems engineer for version number three.

James Frazer: Our learning objectives for today are, number one, to understand the structure of the NTCIP 1213 Version 3 standard for electrical and lighting management systems. Number two, to identify specific ELMS user needs. Number three, to use and understand the Protocol Requirements List, the PRL, to select the user needs and to further trace them to requirements. And lastly, number four, we'll explain how to use the ELMS PRL table to create a project-specific ELMS specification.

James Frazer: Learning Objective 1: Understanding the structure of the NTCIP 1213 Version 3 standard for electrical and lighting management systems, also known by the acronym ELMS.

James Frazer: What is an ELMS? An ELMS is defined as a system or a device that senses and communicates near real-time data. It focuses on electrical, lighting, Smart Grid, connected vehicle, and electric vehicle charging parameters, and most importantly, it uses the NTCIP protocol.

James Frazer: Why should you use an ELMS? Well, user needs are supported by the standard. One example is implementation of a roadway lighting plan based on a time schedule. Later, in further courses, we'll examine these functional requirements that are also supported by the standard. It also supports interoperability by providing standardized functionality not only within the ITS NTCIP domain, but also with Smart Grid systems, connected vehicle systems, and other technologies related to this particular ecosystem.

James Frazer: To explain it in a little more detail, we'll embark now on a case study.

James Frazer: Let's assume that you're the public works manager for a city, Anytown, USA-- responsible for traffic signals, roadway lighting, and other related infrastructure. Your users include the finance director, the field maintenance staff, and others, including public users like pedestrians and bicyclists and vehicular drivers. You've determined, by polling and querying these stakeholder communities, that you need to deploy dimmable LED street lighting; you need to prepare for adaptive, dynamic roadway lighting systems of the future; and you'd like to minimize ground fault injuries caused by electrical leakage conditions. You may have as an example, in querying these stakeholders, your finance director may be asking you to reduce energy usage. Your field maintenance staff may want instant notification of power outages. Additionally, you may have heard stories of older or poorly maintained electrical equipment leading to injuries and even deaths caused by dangerous electrical leakage and you'd like to do what you can to prevent these occurrences in the future.

James Frazer: Thus the user needs, more succinctly stated, of Anytown, USA, are that energy use must be controllable; power outages must be communicated in near real-time; dimmable LED lighting must be deployed; adaptive control of lighting using vehicular and pedestrian traffic information must be deployed; and ground fault conditions must be communicated in near real-time to the traffic management center.

James Frazer: So you've reviewed the ELMS standards-based solutions within NTCIP 1213 and you consider ELMS-based solutions very promising. You then ask yourself: Can an ELMS system satisfy these five wide-ranging user needs? Well, the answer is yes, and the goal of this course is to provide the domain knowledge to achieve these goals. ELMS is a very broad standard that supports adaptive roadway lighting, revenue-grade power metering, ground fault detection, and some of the other features we've already discussed. For more information, you should examine the Student Supplement, which includes links to various white papers and application stories for further review.

James Frazer: So, the NTCIP 1213 ELMS Version 3 standard supports user needs, including implementing a roadway lighting plan based on the time schedule, functional requirements such as controlling roadway lighting levels based on time of day, and supports interoperability by providing standardized functionality within and outside of the ecosystem.

James Frazer: What is different in Version 3 compared to Version 2 and Version 1? Well, Version 1 was not the product of the systems engineering process and was not published. Version 2 was published in 2011 and it includes primary support for lighting systems, individual lighting fixtures, etcetera. It includes support for branch circuits and electrical services, and it includes the scheduling and logical grouping and the business rules for the control of the fixtures, the circuits, and the electrical services.

James Frazer: Version 3 supports all those features in Version 2 plus some very exciting updates. The first is support for connected vehicles as well as connected pedestrians and connected bicyclists, for safety as well as for the development of adaptive dynamic roadway lighting applications. It also includes a standardized communications protocol for electrical vehicle charging stations, also known as electric vehicle service equipment, or EVSEs, to create new revenue streams for local, state and federal governments. This allows the back office billing network of a city, county or state to be used to generate revenue for that entity.

James Frazer: Version 3 also supports electric load demand response to support and facilitate greater integration to the intelligent electrical distribution, generation, and market efforts known as the Smart Grid. It includes support for two-way, bidirectional communications needed to support Automated Demand Response activities by electric utilities, whether they be investor-owned or municipally owned, as well as renewable electric sources such as wind and solar-based photovoltaic distributed energy generation and storage.

James Frazer: So what's in the standard? As we go through this presentation today, we will examine the Concept of Operations, which is a table, a listing of textual user needs-- what do you need the system to do? We'll move to functional requirements, which are the measurable definitions of those user needs contained in the Concept of Operations. We will then, through these courses, examine the dialogs, the actual message structures and in actual messages that are exchanged. Those messages are contained in an organized manner in hierarchical tables in a Management Information Base. So we'll examine the MIB in detail. Next, the PRL and the RTM. The Protocol Requirements List is an integral part of not only the NTCIP 1213 standards, but all of the NTCIP center-to-field standards. It has a relationship between the user needs and the dependencies of the measurable functional requirements. There is a distinct link between that user need, of the Concept of Operations, and the functional requirement, and that is communicated in a succinct way within the PRL. Similarly, the Requirements Traceability Matrix has the same relationship between the functional requirements and the actual message structure contained in the MIB. We'll examine both of those, the PRL and the RTM, as the course continues.

James Frazer: So, first we'll move on to user needs and the architecture. This standard, as well as this course, describes the Systems Engineering Process. It's dependent upon the V diagram lifecycle process that is inherent in the SEP effort. We will also look at the generic architecture model of what is an ELMS.

James Frazer: Sections within the document. Section 1 is the introduction. It's stated as General. Section 2, again, is the Concept of Operations with its included user needs. Section 3 contains the measurable functional requirements, the range of the units of those attributes. Section 4 defines the messages. Section 5 is the data table, the Management Information Base, and the arrangement of all those objects within that table. Annex A is the Requirements Traceability Matrix. The Object Tree is in Annex B, and test procedures are in Annex C.

James Frazer: The Generic Architecture Model. NTCIP is a family of standards for the ITS industry from the USDOT. The standards fall into two areas. One is center-to-center communications between adjacent traffic management centers, and the second, the focus of this family of courses, is the center-to-field standards. The center-to-field standards are all in the NTCIP 1200 series, from 1201 up through 1213 and beyond. They provide rules for communicating called protocols. It provides the vocabulary, called objects, necessary to control and monitor ELMS field equipment, such as roadway lighting, ground fault equipment, revenue-grade power metering, connected vehicle information, electric vehicle charging equipment, as well as automated demand response.

James Frazer: This is a pictorial representation of a generic architecture model. On the right-hand side of the screen you will see, first, an ELMS management station, represented by a small computer. It's connected by a line over to the field device in the box on the most right side of the image. On that side, we see a number of functions; a data logger, a luminaire, an electrical service, a branch circuit, electric vehicle chargers, for example. If you notice, within the graphic, between the management station and the field devices, the line has a denotation of NTCIP. The NTCIP communications are between that traffic management center called an ELMS Management Station here in our graphic, and the field device, and in our representation here it's called an ELMS Device. Additionally, an ELMS Management Station does not necessarily need to be always at the traffic management center, at the management center location. You can also have an ELMS Management Station in the field to aid you in maintenance and configuration while your maintenance folks are in the field. New in this graphic-- it's been adapted from Version 2-- are the additional field equipment that's supported by Version 3 of the standard. This includes adaptive lighting systems through supportive connected vehicles, the Smart Grid demand management systems, and electric vehicle chargers. Notice the electric vehicle charger has been added to this graphic on the lower right.

James Frazer: The NTCIP family of standards are known as objects. We've discussed how they are collected and aggregated in a data table known as a MIB. The underlying communication standards are called protocols, and NTCIP 1213 is an information content standard. This is a review slide, and further information about this can be found in the Student Supplement.

James Frazer: So, what exactly is NTCIP 1213? It standardizes the communications interface between the field device and the management center. The ELMS Management Station, in a little more detail, is one or more host computing platforms that control the field devices. The ELMS device is defined as a device, a module, or a piece of equipment that contains an SNMP, a Simple Network Management Protocol agent. This agent is the interface between a component of the ELMS system and the NTCIP communication system. The device may be integral within a component of the illumination system. So as we can see on the right-hand side of the slide, we have an ELMS Management Station physically located at a public works department, for example. We have an ELMS device in the field. In between those two, we have NTCIP communications. The ELMS device then supports other field devices that don't necessarily speak NTCIP, such as power metering, roadway lighting, electrical services, branch circuits, ground fault equipment, power quality, electric vehicle chargers, Smart Grid. All of these are listed in the lower right-hand portion of the image on this slide.

James Frazer: The ELMS standard began in 2004. It was accepted as a User Comment Draft in February 2004. In 2005 it was accepted, Version 2, subject to the product of a strict and rigid systems engineering process; it was accepted as a recommended standard in 2005. In 2011, it was published, and the NTCIP 1213 Version 3 was approved by the NTCIP Joint Committee in May 2016.

James Frazer: And now it's time for an activity.

James Frazer: Question: Which of the following statements is true? Your answer choices are, A, NTCIP 1213 is an Information Content standard; B, NTCIP 1213 is an Application Level standard; C, NTCIP 1213 is a Transport Level standard; or D, NTCIP 1213 is a Plant Level standard. Please select the correct answer.

James Frazer: Let's review our answers. Choice A is correct because NTCIP 1213 addresses the information level of interoperability. This level contains standards for the data elements, objects, and messages to be transmitted; for example, the NTCIP 1200 series of standards. B is incorrect because NTCIP 1213 does not address the application level. This level contains standards for the data packet structure and session management; for example, SNMP, STMP, CORBA, FTP. C is incorrect because NTCIP does not address the transport level. This level contains standards for data packet subdivision, packet reassembly, and routing when needed; for example, TCP, UDP, and IP. And lastly, D is incorrect because NTCIP 1213 does not address the plant level. The plant level consists of the physical transmission media used for communications; for example, copper wire, coaxial cable, fiber optic cable, or wireless. It should be noted that the plant level is an infrastructure choice and not a standard selection choice. However, the plant level selection will have an impact on the subnetwork level selection to which it must eventually interface.

James Frazer: So what are the major benefits of ELMS NTCIP 1213? Well, it defines user needs supported by the standard; for example, monitoring the status of the ELMS luminaire switch status message. It defines measurable functional requirements supported by the ELMS standard; for example, monitoring the luminaire current status, or the current used by an individual street lighting fixture. These requirements are traced back from the requirement back to the user need, monitor the status of the ELMS message. It's important to remember that a single design exists for each requirement and each design is traced back to a user need.

James Frazer: Advantages us using ELMS NTCIP 1213 Version 3, as well as all of the NTCIP 1200 series of standards, are that it enables solutions that are easier to use, easier to specify, and far easier to test. Agencies and specification writers can use this standard to easily determine what ELMS user needs and requirements the standard supports. They can also easily specify their ELMS requirements for the proposed implementation by quickly selecting unambiguous user needs and the dependent requirements, and based on the ELMS requirements selected, the standard provides the definition of the design. Thus agencies can consistently test for conformance if accompanied by validating test procedures. By using the standard, you would go through a sequence of first determining your project needs, your user needs, as defined in Section 2. You would then write a specification using the measurable functional requirements within the PRL within Section 3, and then as you deploy, you would develop and deploy your test plan.

James Frazer: Let's discuss the advantages of the Systems Engineering Process, SEP, and its relation to ELMS NTCIP 1213. It supports off-the-shelf interoperability. Based on the requirements, the standard specifies the design unambiguously, ensuring consistency between implementations. It provides standardized user needs, requirements, and design content to fully support project engineering activities using the Systems Engineering Process. The System Engineering Process is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on specifically defining customer needs and the required dependent functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation. A systems engineering process is a process for applying systems engineering techniques to the development of all kinds and types of systems. Systems engineering processes are related to the stage in a system lifecycle. The process usually begins at a very early stage of that lifecycle and at the very beginning of a project. The standardized user needs and requirements allow creation of project-specific design content that allows specifiers to drop in these requirements into a project-specific implementation and specification.

James Frazer: The image on the screen is the systems engineering process V model. You'll notice that there's a timeline that moves into the future as we go left to right. It starts with regional architecture, feasibility study, and concept exploration, and it moves through concept of operations, systems requirements, high-level design, lower-level detail design, and at the bottom of the V is software and hardware development and field installation. Then, as we move up through the right-hand side of the V, there is unit and device testing, subsystem verification, system verification and deployment, system validation, operations and maintenance, changes and upgrades, and eventual retirement and replacement. The two parallel sides of the V allow you to create test plans. So in the center part of the graphic, working from the bottom to the top, the V model allows you to create a unit and device test plan, a subsystem verification plan, a complete system verification plan, and a comprehensive system validation plan. And as you can see, we have some animation where user needs are in the upper left-hand part of the V. They are refined into requirements as you work your way down the V, and as you ascend the right-hand side of the V requirements allow comprehensive system verification and deployment, and the creation of a test plan.

James Frazer: And it's time for our second activity.

James Frazer: Which of the following is not an advantage of using the Systems Engineering Process for the ELMS NTCIP 1213 standard? The answer choices are, A, supports interoperability; B, allows multiple designs for each requirement; C is allows clear development of test procedures based on the requirements selected; or D, determines what user needs are supported. Please select the correct answer.

James Frazer: Let's review our answers. The correct answer is B. NTCIP does define a unique design for each requirement. A is true, but incorrect. NTCIP 1213 SEP process supports the information level of interoperability. Answer C is true. NTCIP 1213 does describe clear test procedures. And D is true. NTCIP 1213 does determine the user needs to be supported.

James Frazer: That concludes our first learning objective, understanding the structure of the NTCIP 1213 Version 3 standard for electrical and lighting management systems. Now we'll move on to Learning Objective 2, identifying specific ELMS user needs.

James Frazer: Identifying specific ELMS user needs, Learning Objective 2.

James Frazer: We'll continue with our case study.

James Frazer: What are you trying to do as an ELMS? Here's an actual ELMS case study from Minneapolis, Minnesota. During a downtown reconstruction project, these user needs were identified: lighting system attributes must be monitored; ground fault conditions must be communicated in near real-time; and selected lighting fixtures must be turned off during nonpeak periods.

James Frazer: Once we identified those user needs, we can state them more concisely as roadway lighting system attributes are monitored; ground fault conditions are communicated in near real-time; and selected fixtures are turned off during nonpeak periods. And at the right we show an informational graphic that shows a pictorial representation of downtown Minneapolis with an image that has yellow lights for operational lighting fixtures in this application, where red ones represent inoperable fixtures.

James Frazer: Another case study is from Miami-Dade County, Florida. Due to the severe and fatal injuries of people and animals, a number of user needs were recognized. Ground fault conditions must be communicated in near real-time; data must be logged; and reports of alarms must be generated. On the right-hand side of the screen there's an image of a young boy on a skateboard pressing a crosswalk button.

James Frazer: From these user needs, in this particular application, once deployed, ground fault conditions are communicated in near real-time; data is logged; and reports of alarms are generated; and on the right-hand side of the screen an ELMS communication panel is shown being installed onsite.

James Frazer: One additional case study is Route 520 in Washington State. It's the world's longest floating bridge, from Seattle to Bellevue, Washington, over Lake Washington. During this recent Route 520 tunnel and bridge project, a number of user needs were identified. Energy usage must be controlled; power outages must be communicated in near real-time; and adaptive control of lighting based on ambient light levels is deployed. On the right we have an image of a highway representing the Route 520 project.

James Frazer: In this project, once the ELMS system was deployed, energy use is controlled, power outages are communicated in near real-time, and adaptive control of lighting based on ambient light levels is also enabled. There are a number of tunnels as part of this, and there is an analog light level sensor at the opening of each tunnel. These, depending on time of day, are used to drive the adaptive lighting levels on the circuits that control the lighting fixtures. On the right-hand side of the screen is an actual cabinet, an ELMS control cabinet, that was installed onsite for the Washington State DOT project.

James Frazer: So let's delve in a little more detail into the standard itself. Section 2 is the Concept of Operations. What is it? Well, its focus is on a system and its users. The time frame, as we saw within the V model a few slides ago, is the entire lifecycle of the system, from its envisioning to its retirement. It defines the user needs supported by the standard and it provides an operational context for the system.

James Frazer: The primary uses of an ELMS NTCIP 1213 system is for control and monitoring of roadway lighting, including scheduling and zoning-- zoning as in aggregating physical devices in the field for supervisory control as a group; safety, for ground fault and other electrical leakage anomalies; revenue-grade power metering-- in essence, billable metering; and integration with other related systems, including vehicle-to-grid infrastructure-- essentially connected vehicle technologies for connected pedestrians, connected bicyclists and connected vehicles.For integration with the electrical distribution network, the Smart Grid, using automated demand response objects, and electric vehicle charging infrastructure, traffic signal power usage, dynamic message sign power usage, photovoltaic energy sources, wind sources as well.

James Frazer: So, continuing on with our examination of Section 2, the Concept of Operations, what is a user need? A user need describes the major capability provided by a system to satisfy an operational need. A system should not be procured or built without knowing exactly what it's expected to do, such as controlling roadway lighting, monitoring ground fault conditions, or monitoring electric power usage. These user needs describe what the system is intended to do. They're one of the main design inputs for the system requirements. Sometimes these two get confused or merge into one, and it's useful to distinguish between them. User needs are the basis of agreement amongst your team on what the thing you're building is supposed to do. A project team with no documented user needs most probably also lacks agreement on what the exact purpose of the project is, and this is a major reason why many projects do indeed fail.

James Frazer: Who and what can generate user needs? User needs describe the major capability provided by a system to satisfy an operational need. People have user needs. These user needs are driven by the stakeholder communities, of travelers, whether by bike or foot or in a vehicle; TMC operators; maintenance personnel, perhaps the electric utility. Additionally, in some contexts, a system may generate user needs, as in, "The management station may need to automatically modify operational parameters." In order to develop these user needs, you really must go beyond internal and external experts to get information from the user community. Focus groups of current and potential users can provide useful insight and feedback about these system attributes. Reaching out to other groups that represent current or potential users is very valuable. This needs assessment engages users in the target audience not only in developing and testing a project specification, but also in becoming faithful users of the intended solution. A variety of techniques, such as surveys, focus groups, and feedback from advisory and interested community groups can provide very useful information for determining these user needs.

James Frazer: ELMS NTCIP 1213 User Needs. The problem statement for ELMS includes the need to manage generic information; for example, a device identifier; the need to detect and sense device information from sensors in the field; the need to control field sensor attributes; and the need to integrate to other ELMS systems as well as other communications platforms, such as the Smart Grid, connected vehicles, electric vehicle charging systems. An ELMS is defined as any system that is able to automatically control and manage roadside electrical devices using NTCIP. In general, an ELMS is comprised of a set of field devices that are controlled by one or more management stations. Some of the key concerns for transportation agencies that may be addressed by implementing an ELMS are citizen and maintenance personnel safety by reducing the potential for electrical shock hazards to citizens through automated detection of electrical and lighting equipment faults. Another concern is light pollution and light trespass regulatory compliance. ELMS allows conforming to national, state, and local laws, regulations, and voluntary programs on light pollution and light trespass to improve citizens' quality of life. Another concern that ELMS addresses is operations and maintenance by reducing resources used to monitor roadside electrical and lighting devices through remote detection of equipment failures and also to allow the ability to improve the re-lamping process. A further concern is energy utilization, by optimizing energy consumption of electrical and lighting devices through automating monitoring and control. And lastly, homeland security, incident and event management, by providing flexible and timely control of roadside electrical and lighting devices to assist law enforcement officials in homeland security and/or specific incident and event management operations.

James Frazer: Our next slide has a basic description, an image, of an ELMS architecture and it's entitled Simple Architecture. So as we saw in a preceding graphic, on the left-hand side of the screen we have an NTCIP ELMS management station located at the management center location, and on the right side of the screen we have an ELMS device, located at the field location. In this simple architecture, we notice that there are some non-NTCIP devices that are connected to the field-located ELMS device. These include the logging mechanism; luminaires, or street lights, numbered 1 to N; electrical services; branch circuits; electric vehicle chargers; demand response equipment; as well as connected vehicle interface equipment. Notice in the center we have the ELMS device. On the left, again, we have the ELMS management station. We have a portable ELMS management station that in this graphic is located at the field location. And again we have the collection of non-NTCIP terminal devices that are supported by the ELMS device. The NTCIP communication, as a review, is only between the management-center-located management station, and the ELMS device within the field, as well as between the ELMS management station in the field and the ELMS device that's located in the field. There are no NTCIP communications between the proprietarily communicating devices in the field and the ELMS device.

James Frazer: Our next slide is another image with an alternate architecture. It again has an ELMS management station at the management center location, a portable ELMS station at the field location, and two ELMS devices. This representation has the ELMS device located within the streetlight. So as opposed to the previous slide, the ELMS device can be a gateway with middleware inside it that performs the communications protocol conversion, or it can be natively placed within a device, such as a luminaire, an electric vehicle charger, or other equipment. Notice again there's NTCIP communications directly between the ELMS device and the management station, whether the management station is at the traffic management center or in the field.

James Frazer: One last architecture we will examine is the concept of zoning. The graphic is the same as the previous slide. It's only been modified by the inclusion of a zone object, multiple zone objects, within the ELMS device. The zone object allows aggregation of the non-NTCIP field devices for logical operations, so that a schedule or a simple on/off command can be applied to a group of non-NTCIP field devices such as an electrical service, a branch circuit, an electric vehicle charger, or other devices. Notice again NTCIP communications are solely between the ELMS device and the management stations and not between the field devices and the ELMS device.

James Frazer: So continuing on with, "What are you trying to do as an ELMS?" Section 2.5 in the standard describes the major user needs that are related to the definition of the interface between the management station and the ELMS field device. These user needs are considered to be the high-level capabilities for NTCIP 1213 Version 3, and they form the basis for defining the detailed functional requirements of the interface. The user needs are the underlying basis for the detailed functional requirements. They are the deliverable that drives the use of the functional requirements. The requirement is a description of a condition or capability to which a system is obligated to conform, either derived directly from the user needs, or stated in a contract, a standard, a specification, or other document. It's a desired feature, property or behavior of the system, and it's measurable, so you can create a test plan around it.

James Frazer: The user needs-- again, in the Concept of Operations-- are organized in two groups. The first is operational, which define the basic modes of operation for communications between the management station and the field devices; and features, which describe the essential data communications functions and message elements to be supported by the interface. Within the definition of operational needs are functions such as providing live data, providing offline logged data. Operational user needs include support of getting data and setting data logical operations. Features, on the other hand, describe the essential data communications that need to be supported. It can be thought of as the behavior of an ELMS device.

James Frazer: So let's examine one such operational user need, Provide Live Data. One operational environment allows the management system to monitor and control the device by issuing requests to access information, alter information, or control the device. In this environment, the device responds to requests from the management station immediately, for provision of live data or success or failure notice of information alteration, or simply success or failure of the command itself. This provision of live data is important to a user because it provides the most basic needs for requesting data or commanding actions. The NTCIP design provides for three basic commands to fulfill this user need-- get, set, and get next. This user need is mandatory for all NTCIP 1213 deployments.

James Frazer: Providing offline log data is also an operational user need. Some operational environments do not have always-on connections. In such environments, a transportation system operator may wish to define conditions under which data is placed into a log, which can then be uploaded and accessed at a later time. For example, the operator may wish to manage the ELMS device so that it autonomously maintains a log of whenever a specific luminaire is turned on or off.

James Frazer: Features. Features relate to the informational needs of the users. Control, monitoring, and managing are specific attributes of features. Within ELMS, we already discussed and introduced electric power metering, electric safety and ground faults, electric vehicle charging, as well as Smart Grid demand management operations, and connected vehicle driven adaptive lighting scenarios. Additional information on this can be found in the Student Supplement, in particular the glossary, the PRL table, and the included white papers.

James Frazer: So, let's examine the feature of managing roadway lighting. It includes several subneeds: implementing a lighting plan based on an ambient light level; implementing a lighting plan based on a time-based schedule; creating of a zone and configuring of a zone. Implementing a lighting plan based on a time-based schedule may be employed when business districts may choose to alter lighting levels when businesses are open or closed. It's a schedule, a mechanism by which an operator can define times in the future at which the luminaire performs an action. A zone, as we introduced earlier, is a logical grouping of luminaires and/or services used for control and reporting. Creating a zone can be as simple as grouping lighting fixtures into zones for sections of a highway or for a downtown business district. Configuring a zone is the function of placing individual lighting fixtures into a particular, previously defined zone.

James Frazer: Managing roadway lighting includes several other subneeds: configuring a schedule, applying a schedule to a zone, and configuring a roadway lighting dim level. Configuring a schedule includes choosing dates and times of the day for initiation of system inputs. A schedule can include ambient light level as a logical input. It can also include astronomical clock functions where latitude, longitude and the day of year inputs provide sunrise and sunset time. Applying a schedule to a zone allows group scheduling by ambient light or time-based schedule. And configuring a roadway lighting dim level-- dim levels can also be dimmed according to a schedule.

James Frazer: Managing roadway lighting includes some luminaire-specific subneeds: configuration of luminaire switch state logging; lamp condition logging; burn condition logging; and pole condition logging. Logging, again, is the process for recording ELMS data in an ELMS file for later review. Any ELMS attribute can be logged on a variable time base. Parameters typically logged in an ELMS installation include energy usage, which may be recorded nightly. Pole knock-down status may be reported on a shorter time basis, or near real-time. The junction temperature of an LED roadway luminaire can be logged hourly or upon change of a commanded state.

James Frazer: Additionally luminaire subneeds under the feature of Manage Roadway Lighting are configuration of luminaire switch state, configuration of luminaire identification, configuration of dim level, and overall control of luminaire. Luminaires can be configured for various modes of operation, including definition of identity, light-activated operation, or scheduled operation.

James Frazer: Managing electrical power has several subneeds: configuring and monitoring the power meter switch state; power meter switch state logging; power meter condition logging; and power meter periodic measurement logging. The power meter possesses multiple configuration options in addition to these. It allows you to determine whether the meter is on or off, or allows you to log when the meter switch is on or off. It allows you to log the condition of the meter. It allows you to configure the time base about when you record or log this energy usage information.

James Frazer: The feature entitled Manage Electrical Safety has subneeds for configuring and monitoring ground fault switch state logging, ground fault measurement logging, and configuring and monitoring the electrical service. Similarly to power meter configuration, the ground fault attributes can be configured, controlled and monitored. Ground fault levels can be monitored in near real-time, and as a result safety issues can be addressed quickly and efficiently.

James Frazer: Manage Electrical Safety allows for configuring and monitoring of circuits, monitoring of the circuit breaker, and monitoring arc fault status. The circuits, circuit breaks, and arc fault sensors can be configured, monitored and controlled. Alarms can be created and enabled, and these attributes can be logged and real-time values can be reported. This might allow you to learn when has a breaker tripped, what's the current draw through the breaker, has a breaker alarm been activated.

James Frazer: EV chargers can be comprehensively managed and controlled in near real-time. This allows cities, counties and states to generate electric vehicle charging revenue by using this data to create a revenue stream. A management station may need to retrieve information from these electric vehicle charging devices, such as ground fault current status, charge current, proximity resistance to ground, the EV charger temperature, the EV charger activation, as in is it active or not, and the operational status, whether it's operational or has a fault occurred.

James Frazer: Managing Smart Grid Demand Management is a feature of ELMS NTCIP 1213. True automated demand response is supported by this group of features. Upon a price signal from utility, lighting levels could conceivably be lowered or raised. Electricity price, energy price, demand charge, bid price, load, and energy levels, as well as load dispatch, load control capacity, load control offset, load control setpoints, and load control percent offset are all supported.

James Frazer: Connected Vehicle Support is a feature. Connected vehicle, connected pedestrian, and connected bicyclist attributes can be configured so that a true adaptive lighting plan can be implemented. An adaptive lighting plan uses the speed, direction, location, and other objects to alter the lighting levels. Some examples of the objects that are supported within ELMS Version 3 are connected vehicle speed setpoint, direction setpoint, location setpoint, and the setpoints for ambient light level, headlight status, and even road friction. All of these can be used to dynamically alter the lighting levels on a particular section of road or a zone.

James Frazer: It's time for our third activity.

James Frazer: Our question is: Which of the following user needs cannot be satisfied by an ELMS system? Our answer choices are, A, need to inform the TMC manager of electrical leakage; B, need to control traffic flow at an intersection; C, need to inform the TMC manager of energy usage; or D, need to control lighting levels by dimming. Please select the correct answer.

James Frazer: Let's review our answers. The correct answer is B. NTCIP does not support traffic flow. A is incorrect because NTCIP 1213 does support the communications of electrical leakage information. C is incorrect because NTCIP 1213 does support the communications of energy usage information. And D is incorrect because NTCIP 1213 does support the communications of dimming information.

James Frazer: With that, we have finished Learning Objective 2 and we will be moving on to Learning Objective 3, using the Protocol Requirements List to select user needs and tracing them to requirements.

James Frazer: Learning Objective 3, using the PRL to select the user needs and tracing them to the dependent measurable requirements.

James Frazer: The PRL is a tool. In this section, we will understand the parts of the PRL; we will use the PRL as a tool for your project-specific implementation, in order to reduce the risk of failure. The PRL is a table that truly is a tool included in the standard for use by system developers, agency specifiers and producers of ELMS equipment. It is found in Section 3, Requirements of the Standard. We'll step through the structure and components of the PRL; we will discuss tailoring the PRL for use in specifications; and we will discuss reducing risk by having interoperable and interchangeable ELMS equipment on a system.

James Frazer: Section 3 of the ELMS NTCIP 1213 Version 3 standard defines the requirements based upon and dependent upon the user needs identified in Section 2, and it defines the interrelationship of user needs and functional requirements. The PRL includes operational environment requirements, functional requirements, and supplemental requirements. In the next few slides we'll examine these types of requirements in detail.

James Frazer: The purpose of the ELMS Protocol Requirements List is to be a table that maps the user needs to the requirements; it must be part of the agency's specification; it references the standard to define the communications interface, an unambiguous communications interface; it's designed to help you define what you want the interface to do; and it's used to identify what requirements will be selected to address a specific set of user needs.

James Frazer: In this slide, we have an image of the Protocol Requirements List, the PRL. It's included in Section 3. There is within the supplement, the full PRL is published and you could look at that for additional information.

James Frazer: Within the PRL, you will notice on the left-hand side of the image, are user needs, functional requirements, and some additional columns. User Needs-- we've highlighted within this table 2.5.1, Operational User Needs. Below that is a dependent user need defined by 2.5.1.1, provide live data. Similarly, a second dependent user need under Operational User Needs is 2.5.1.2, provide offline logged data. Within the table, the first column, User Need ID, has a numerical representation. It is directly related to the second column, which is a textual representation of that user need.

James Frazer: The ELMS functional requirements in the PRL are in successive columns 3 and 4. Within Column 3, the functional requirement identification number is listed, and in Column 4, the textual representation, a title, for each functional requirement is listed. In this image, we're highlighting 3.5.1.1, retrieve data, as a functional requirement. And as you see, there are a number of these. We can scroll down. Each of these functional requirements are dependent on the user need above.

James Frazer: ELMS conformance in the PRL. Column 5 defines conformance, indicating which of the items, user needs and requirements, are mandatory, conditional, or optional. Note the choices of M or O-- M for mandatory, O for optional-- in the column. These requirements are conditional upon the conformance of the user need. Thus, if the user need is chosen to be required for a particular project, the dependent functional requirements must also be supported in the project.

James Frazer: In Column 6, Support, defines whether these features and user needs are requirements for your particular project. Note the choices of yes or no for the requirements that are defined as optional in the conformance column. These requirements are conditional upon the conformance of the user need. Thus if user need 2.5.1.2 is chosen to be required for a particular project, the dependent functional requirements must also be supported in the project column. So for an example, we circled Yes for a number of these. We circled Yes for provide offline data of the user need, and we have determined that configure number of events in event logs, configure number of event classes, and configure number of event types are in fact required for our project.

James Frazer: Other user needs not in the PRL. This standard, like the entire suite of NTCIP protocols, allows for extensions. The proprietary extensions are not desired because interoperability can be compromised, but are in fact sometimes necessary. These extensions may become part of a future version of the standard. This particular standard supports interoperability for all the features contained within the standard itself.

James Frazer: The ELMS PRL can be used as a checklist to reduce the risk of failure to conform to NTCIP 1213 Version 3. An agency can use the ELMS PRL to indicate which requirements are to be implemented in a project-specific implementation. The protocol implementer can also use it as a checklist to reduce the risk of failure to conform to NTCIP 1213 Version 3.

James Frazer: Similarly, suppliers and end-users can use the standard as a detailed indication of the capabilities of the implementation. The user can use it as a basis for initially checking potential interoperability with another implementation before implementation has actually occurred.

James Frazer: And it's time for an activity.

James Frazer: Which of the following is a true statement? A, ELMS user needs do not describe what features the device needs to support and why; B, ELMS functional requirements are not specifications; C, within the ELMS PRL the relationships between user needs and functional requirements are not standardized; or D, the ELMS PRL promotes interoperability. Please select the correct answer.

James Frazer: Let's review our answers. D is correct. The PRL does support interoperability. A is an incorrect answer. ELMS user needs do describe what features the device needs to support and why. B is an incorrect answer. ELMS functional requirements are not specifications. C is an incorrect answer because within the ELMS PRL the relationships between the user needs and functional requirements are in fact standardized.

James Frazer: How do we select user needs through the PRL? Using the ELMS User Need ID number 2.5.2.2.2., the corresponding text allows determination of the user need and if this user need is desired within your system. This slide and the next three slides describe the process used to select user needs so that the desired operations are supported. So in our application, we have determined, by circling Yes, that this user need is in fact supported in our application, or is required to be supported. Additionally, the optional requirements of control electrical service by transitory override is required. Control electrical service by timed override is not required. Stagger mode is required. Control electrical service by photo cell is required. But control electrical service by adaptive means is not required.

James Frazer: ELMS User Need 2.5.2.2.2, Control Electrical Service, is defined in the ELMS standard as: A management station may need to control an electrical service directly or by enabling or disabling the staggered operation for branch circuits served by electrical service. A management station may need to control the electrical service to allow or disallow the scheduled control by one of the following four states: continuous control, transitory control, time control, or adaptive control. Continuous control is not allowing the schedule to control the current settings for the electrical service. Transitory control is not allowing the predefined schedule to control the electrical service until the next event in the schedule. Timed control is not allowing the schedule to control the electrical service until after a period of time specified in the timed control dialog so the electrical service expires. Adaptive control is allowing the schedule to control the electrical service in conjunction with connected vehicle sensor and status information.

James Frazer: Conformance, mandatory versus optional. Let's examine the Conformance column. Conformance, once again, identifies if the user need or requirement is mandatory or optional. If user need 2.5.2.2.2, Control Electrical Service, is required, the dependent functional requirement is mandatory, while the following are optional.

James Frazer: And it's time for an activity.

James Frazer: Which of the following descriptions of the PRL is a false statement? A, options for conformance are mandatory or optional; B, options for project requirements are Yes or No; C, optional user needs are dependent on project requirements; or D, optional functional requirements are not dependent on project requirements. Please select the correct answer.

James Frazer: Let's review our answers. Choice D is the correct answer, as it is a false statement. Selection of project requirements drives the inclusion or exclusion of optional functional requirements. Choice A is true. The only valid options for entries for conformance are Mandatory and Optional. B is a true statement. The only valid entries for project requirements are Yes or No. And C is true. Selection of project requirements do drive the inclusion or exclusion of optional user needs.

James Frazer: Let's delve a little further into the capabilities of the implementation and the user needs hierarchical relationship. User Need 2.5.1.2 is optional. Thus, if the project definition requires this user need, then dependent requirements are mandatory.

James Frazer: There is a relationship of project requirements. The agency or specifier circles yes or no to indicate the agency user needs for the proposed implementation. To select the project requirements, as we saw earlier, you would circle yes or no in the appropriate cell in the table. In this example, for Functional Requirement 3.5.4.23, Configure ELMS Device for Adaptive Operation, you would select yes or no in the Project Requirement column. Similarly, for Functional Requirement 3.5.4.23.1, Configure Connected Vehicle Speed Setpoint, you would select yes or no again in the Project Requirement column. So since we have chosen the user need Configure ELMS Device for Adaptive Operation, we circle Yes, and we go through and we select the dependent requirements that we need for our project-specific implementation.

James Frazer: Of prime importance is the relationship between user needs and functional requirements within the standard. The user needs describe required features. The functional requirements refine those user needs into detailed specifications. Within that PRL, the relationships between the user needs and the functional requirements are standardized, and use of the user needs and the dependent functional requirements promote interoperability.

James Frazer: So, once again, the Functional Requirements ID is the section number of the functional requirement located in Section 3 of the standard. The functional requirement title, the description of the functional requirement is listed in Column 4. The Additional Specification column deals with performance requirements that are specific to a unique requirement. Column 3 is the Numerical Functional Requirement ID. Column 4 is the textual definition, the title of the functional requirement.

James Frazer: ELMS PRL user needs and functional requirements relationship in detail. A requirement associated with a user need is found under that user need in the PRL table. Each user need must have and does have at least one requirement associated with it. Each requirement within the standard is associated with at least one user need. The result is that the standard has no unnecessary requirements and all user needs are satisfied by at least one requirement. Practically speaking, what this means in implementation is that by using the standard, you will get your user need satisfied, so you won't leave anything out, but also you will not over-specify and receive features that you may not need.

James Frazer: Mandatory versus Optional. A mandatory requirement is only mandatory if an associated user need is selected. If an optional user need is not selected, its associated requirements are not necessary, unless they're required by another user need selection; for example, 3.5.4.4.4, Configure Devices in a Zone for Light Activated Operation.

James Frazer: The Additional Project Requirements column is provided for requirements that need additional consideration. The additional information is only to subrange the values. If anything else is added, we are extending the standard and interoperability is diminished. It's recommended that the intent of the Additional Projects Requirements column be specifically thought of as simply sub-ranging or reducing the range of the legal permitted range of the units.

James Frazer: And it's time for a question.

James Frazer: Which of the following is a false statement? A, user needs describe what features the device needs to support; B, functional requirements refine the user needs into specifications; C, relationships between user needs and functional requirements are standardized; or D, the ELMS PRL does not promote interoperability. Please select the correct answer.

James Frazer: Let's examine the correct answer. D, the PRL does promote interoperability, thus D is the correct answer. A is a true statement. User needs describe what features are required. B is a true statement. Functional requirements do in fact refine user needs into detailed, measurable, unambiguous specifications. And C, the PRL does define standardized relationships between user needs and functional requirements.

James Frazer: Ensuring interoperability with another implementation. Using ELMS within Smart Grid, EV charging, and connected vehicle systems. Use of the ELMS PRL and the ELMS standard supports interoperability of selected attributes within the ITS Management Center, other ELMS systems, onsite or remote, Smart Grid systems for automated demand management, connected vehicle and connected pedestrians for true adaptive roadway lighting, as well as electric vehicle charging stations.

James Frazer: Benefits of the PRL. What does use of that PRL achieve? Number one, each requirement has a need; no needs are unmet; and extraneous requirements are avoided. For the end-user, for the acquirer of such systems, this avoids purchasing and funding features that are not required by your user needs.

James Frazer: Thus we've reviewed Learning Objective 1, 2, 3, and now we will explain how to use the ELMS PRL table for the ELMS specification.

James Frazer: How to use the PRL table for an ELMS project-specific specification.

James Frazer: From an agency's perspective, a completed PRL must become part of the overall specification-- indeed, part of the RFP or RFQ. A completed PRL indicates the requirements for the communications interface. The agency provides language in the specification so that all selected requirements must be implemented as per the standard in order to support off-the-shelf interoperability. If the agency desires to use commercial, off-the-shelf devices, then the agency should compare its list of selected needs and requirements with commercially available equipment to ensure that it's not specifying something that doesn't exist off-the-shelf. And there's additional information on this topic within the supplement.

James Frazer: From a vendor's perspective, even if a user need and the resulting requirement is not mandatory, a vendor may optionally fulfill that user need and provide that feature as an added service. Vendors can also provide a PRL for their standard products to demonstrate what user needs or what requirements they support.

James Frazer: When it's time for a contract document and the bid process begins, and RFP/RFQ process, an ELMS PRL is only a portion, a part of the overall project specification, in addition to the hardware and software specifications. Hardware specifications can include performance, structural, mechanical, electrical, and environmental requirements. Software specifications also need to be part of the contract documents. NTCIP 1213 Version 3 solely focuses upon communication interface specifications-- functional requirements, the performance requirements, and the protocol requirements. It is a part of the overall project specification.

James Frazer: It's important to examine the difference and understand conformance versus compliance. Conformance means meeting a specified standard. To claim conformance to ELMS NTCIP 1213 Version 3, the vendor shall at a minimum satisfy the mandatory requirements without violating any rules. Vendors that provide additional features beyond the completed PRL are still conformant. However, vendors that replace conformant features with proprietary features are not conforming. Compliance is a bit different. It means meeting a specification for a specific project, for your specific project.

James Frazer: It's time for a question.

James Frazer: Which of the following is a false statement? A, vendors can provide an ELMS PRL for their standard products to show what user needs they support; B, a completed ELMS PRL must become part of the overall specification; C, a completed ELMS PRL indicates the requirements for the communications interface; or D, a completed ELMS PRL describes the entire project specification. Please select the correct answer.

James Frazer: Let's review our answers. D is correct. A completed ELMS PRL describes the entire project specification. No, that's false. It only describes the communications interface. A is a true statement. Vendors can provide an ELMS PRL for their standard products to show what user needs they support. As such, products can be evaluated for standardization. B is true. Project specifications include communications, hardware, and software specifications. An ELMS PRL is only part of the overall project specification. And C is true. A completed ELMS PRL does indicate the requirements for the communications interface. It defines the communications interface.

James Frazer: Thus we have concluded our four learning objectives for Module A306a.

James Frazer: We have now completed A306a in the ELMS curriculum. Module A306a we concluded today, which is Understanding User Needs for Electrical and Lighting Management Systems Based on the NTCIP 1213 ELMS Standard Version 3. Next in the series is Module A306b, Specifying Requirements for Electrical and Lighting Management Systems Based on NTCIP 1213 ELMS Standard Version 3. And the final course in the series is Module T306, Applying Your Test Plan to the Electrical and Lighting Management Systems Based on NTCIP 1213 Version 3.

James Frazer: The next course module is A306b, Specifying Requirements for Systems Based on the NTCIP 1213 Version 3 Standard. The concepts taught in the next module are: We will review the structure of the standard; we will use the PRL and then the Requirements Traceability Matrix to specify the standardized structure of requirements; we will include the requirements from the PRL and the RTM in an ELMS communications interface specification; and we will explain conditions and context for extending the standard should you need functions that are not included in the published version of the standard.

James Frazer: Thank you for completing this module. Please use the Feedback link below to provide us with your thoughts and comments about the value of this training.

James Frazer: Thank you very much for attending and we look forward to seeing you on course A306b.