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.)

 

Announcer-Nicola Tavares: This course is sponsored by the U.S. Department of Transportation ITS Professional Capacity Building Program. The ITS PCB Program is part of the Research and Innovative Technology Administration’s ITS Joint Program Office. You can find information on additional modules and training programs on this website www.pcb.its.dot.gov. Thank you for participating and we hope you find this module helpful.

Announcer-Nicola Tavares: This module is A306a, “Understanding User Needs for Electrical and Lighting Management Systems Based on NTCIP 1213 Standard”. Throughout the presentation this activity slide will appear indicating there is a multiple-choice pop quiz following this slide. The presentation lecture will pause at each quiz section to allow you to use your computer mouse to select your answer. There is only one correct answer. Selecting the “submit” button will record your answer and the “clear” button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice. Please help us make even more improvements to our training modules by completing the post-course feedback form.

Announcer-Nicola Tavares: Your instructor, James Frazer, within the Intelligent Transportation System domain continues to play a pivotal role in the development of the U.S. Department of Transportation ITS Adaptive Lighting Standards, the U.S. Department of Energy Smart Grid Standards being developed by the National Institute of Standards and Technology as well as Roadway Lighting Control Standards being developed by Illuminating [sic] Society of North America. Jim currently chairs the U.S. Department of Transportation ITS NTCIP 1213 Electrical and Lighting Management Systems Working Group as well as the Illuminating Engineering Society Roadway Lighting Energy Management Committee.

James Frazer: The target audience for today’s presentation is engineering staff; engineers who plan, perform studies and design transportation systems; street and roadway lighting maintenance staff; personnel who troubleshoot and maintain systems; traffic management center and operations staff; those that work in transportation management centers; technicians and others that perform the day-to-day tasks of operating and supporting a transportation system; system developers; those that implement and integrate transportation systems; and private and public sector users. Users include people from private companies and public agencies.

James Frazer: The prerequisites for this course are I101, which provides an overview in the use of ITS Standards; A101, which provides information on procurement strategies for standards compliance systems; A102, which introduces how to identify user needs for standards regardless of whether the standard has SEP information; A201, for selecting the appropriate standard for acquiring standards-based systems; C201, which explains the NTCIP framework use of SNMP and STMP underlying NTCIP protocols; and C201, which explains the use of SNMP for transportation applications.

James Frazer: There are two possible paths a user can follow in implementing systems based on ITS Standards. The path to be taken depends on the standards needed to implement the system. The identified standard could have been developed using a Systems Engineering Process (SEP) of well-defined needs, requirements and design, or it could have been developed without use of SEP. In addition, there are curriculum paths that can be followed based on whether the module is SE or non-SE, prerequisites and sequential modules.

James Frazer: The two-part prerequisites C101 and C201 are shown in relation to the logical curriculum path for module A306a. The next module in the sequence is A306b.

James Frazer: Value of an ELMS Module Sequence. A306a, “Understanding User Needs for Electrical and Lighting Management Systems”, focuses on identifying, selecting and understanding user needs as defined by NTCIP 1213. A306b, “Specifying Requirements for Electrical and Lighting Management Systems” concentrates upon identifying, specifying and understanding requirements as defined by NTCIP 1213. T306, “Applying your Test Plan for Electrical and Lighting Systems” concentrates upon developing a test plan in order to test conformance as defined by NTCIP 1213.

James Frazer: Learning objective number one. A review of the structure of the NTCIP 1213 v02 standard: what is the purpose of the standard; what is the standard used for; components and structure; what actually is in the standard; and, lastly, how the standard fits into the Systems Engineering Process life cycle. We’ll examine the Systems Engineering Process V-diagram in detail.

James Frazer: Definition and purpose of an ELMS. An ELMS is defined as any system or device capable of sensing and communicating near real-time traffic parameters using NTCIP. The purpose of the NTCIP 1213 Standard is to provide users with a method to specify the detailed communication requirements and specifications for an electrical and lighting management system using NTCIP and support the deployment of interoperable systems. As far as the standard is concerned, to be an ELMS, they need to be able to communicate using NTCIP and must support the mandatory ELMS attributes. Near real-time is defined as data that depicts an event as it existed at the current time less the processing time. This data varies from real-time data because it is dependent on the type and speed of transmission. This data is usable for identifying the changes in traffic flows and related parameters.

James Frazer: What defines a system as an ELMS? In order to be an ELMS the system or device must do the following: it must communicate using the NTCIP protocol, it must support mandatory ELMS attributes, and it must communicate that near real-time data.
James Frazer: In the next few slides we’ll be looking at a case study.

James Frazer: As the public works manager in a small city, you’re responsible for traffic signals, roadway lighting and related infrastructure. It’s a demanding job of many needs voiced by many users. As an example, your finance director keeps asking you to reduce energy usage; your field maintenance staff wants instant notification of power outages; and you’d like to deploy dimmable LED street lighting to beautify parks in the city and to prepare for the adaptive dynamic roadway lighting systems of the future. More practically you’ve heard stories of older or poorly maintained electrical equipment leading to injuries and even deaths caused by electrical leakage. You’d like to do what you can to prevent those occurrences, too.

James Frazer: From these conversations you create a list of the needs listed by your users. These include energy use be controllable, power outages must be communicated in near real-time, dimmable LED lighting must be deployed, adaptive control of lighting based on vehicular pedestrian traffic must be deployed, and ground fault conditions must be communicated in near real-time.

James Frazer: You have reviewed the ELMS standard-based solutions. You’ve considered ELMS solutions very promising. So you then ask yourself, “Can an ELMS system satisfy these five wide-ranging user needs?” The answer is “Yes” and this course will provide the domain knowledge to achieve these goals.

James Frazer: An ELMS, once again, is defined as any system or device capable of sensing and communicating real-time traffic parameters using NTCIP. ELMS is a very broad standard that supports adaptive roadway lighting, revenue-grade power metering, ground fault detection and much more. The student supplement includes links to various white papers and application stories for further review.

James Frazer: The NTCIP Standard. User needs supported by the standard include Implement Roadway Lighting Plans based on a time schedule. Functional requirements supported by the standard include control roadway lighting levels based on a time of day. The standard supports interoperability with other NTCIP systems, other intelligent transportation systems and other Smart Grid systems.

James Frazer: The structure of the ELMS NTCIP Standard. This slide shows the table of contents for NTCIP 1213 so that the user can gain a familiarity with the overall flow of the standard. Communication between ITS management center or portable computer and an electrical and lighting management system is accomplished by using the NTCIP Application Layer services to convey requests to access or modify values of ELMS data elements resident in the device via the NTCIP network. An NTCIP message could consists of a specific application layer service and a set of data elements. An NTCIP message may be conveyed using any NTCIP-defined class of service that has been specified to be compatible with the Simple Transportation Management Framework (STMF). The concept of the general section, Section 1, is an overview of the document. Section 2, “Concept of Operation”, provides a description of user needs, needs for features and needs related to the operational environment applicable to ELMS devices. Section 3, “Requirements”, defines the functional requirements that address the user needs identified in the concept of operations. It includes a Protocol Requirements List (PRL) that defines conformance requirements thereby allowing users to select the desired options for a particular project. Section 4, “Dialog Specifications”, describes how each functional requirement is fulfilled. The dialogs define standardized procedure for a traffic management center to exchange with an ELMS device. Section 5, “ELMS Object Definitions”, to find the data exchange during communications some of the definitions are included via reference to other standards. Annex A, “The Requirements Traceability Matrix” (RTM) provides a table that associates each requirement to a dialog and its associated list of data. Annex B, the Object Tree, provides a graphical representation of the branch and tree structure for objects and the organization of the data defined in NTCIP 1213 v02. Annex C, “Astronomical Clock Support”, includes object definition modifications needed to support astronomical clock features.

James Frazer: Benefits of the ELMS NTCIP 1213 Standard are: Ease of use. It allows you to formulate or articulate user needs. We had to agree on the scope of our needs in developing the standard. We captured our thinking. This then became the driver for the interface requirements and the data elements.

James Frazer: Easy of specification. Many times there are different names used for the same features across technologies, agencies and vendors. Also, there may be specific features of a particular ELMS technology that are not widely used. We started with the sectional information for most transportation applications.

James Frazer: The benefit also includes drop-in user needs that can be cut and pasted into a project specification.

James Frazer: A review of the ELMS Standard NTCIP 1213. It provides 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, electric vehicle supply equipment and integration into the Smart Grid. It’s important to remember that objects represent language vocabulary while protocols are language rules.

James Frazer: The NTCIP Family of ITS Standards. Information profile standards contain “objects”. Objects are aggregated in a data table known as a Management Information Base (MIB). Underlying communications standards are called “protocols”. And NTCIP 1213 is an information content standard. It is a data dictionary standard. It is one of a series of data dictionaries standards in the NTCIP 1200 series of standards. Other NTCIP 1200 Standards include dynamic message signs, traffic signals and transportation sensor systems. You can visit NTCIP.org for more information.

James Frazer: ELMS is a data dictionary standard. It only addresses the highest level, the communications information level of the ISO-defined interoperability stack. ELMS is one of a number of informational level standards developed by the NTCIP organization. These, again, include the NTCIP 1200 series standards as well as NTCIP 2306.

James Frazer: The National Transportation Communications for ITS Protocol (NTCIP) family of standards created jointly by AASHTO, ITE and NEMA addresses the interfaces between a transportation management center, the ITS field devices it manages, and other centers. They provide both the rules for communicating (again, called protocols) and the vocabulary (called objects, data elements, and messages) necessary to exchange information between ITS systems. The NTCIP Center-to-Field group of standards addresses the communications protocols between a center and the ITS field devices it manages. The family includes the communications profiles that cover the interfaces between a traffic management center and the ELMS systems, dynamic message signs, ramp meters, environmental sensors, CCTV, and other field equipment under its control. These protocols are common across all center-to-field interfaces in the National ITS Architecture, and rather than repeat the entire list for each architecture flow, we have created this summary entry – the NTCIP C2C group of communications standards. The vocabulary (objects) is specific to the actual architecture flow in the National ITS Architecture and is therefore mapped to the corresponding Data Object standard.

James Frazer: So a review of the ELMS NTCIP Standard. This slide describes a physical architecture. It standardizes the communications interface. It specified the interface between the ELMS systems in the field and the host system. As you can see in the upper portion under “ELMS Management Station” communicates to the ELMS device via NTCIP, and the ELMS device speaks to or communicates with branch circuits, ground fault sensors, power quality monitors, electrical services, roadway lighting, power metering. That is non-NTCIP. An ELMS Management Station is one or more host computing platforms that control the field devices. It’s important to note that management stations may be installed in local Transportation Management Centers or they can be field-based. An ELMS device, again, is defined as a device, module, or piece of equipment that contains an SNMP agent and is the interface between a component of illumination system, an energy management system, an electric vehicle charging system and the NTCIP communications system. The device may be integral to a component of the system or it may be located remotely.

James Frazer: In the early 1990s the Illuminating Engineering Society of North America led by Karl Burkett of the Texas Department of Transportation embarked on an effort to create interoperable communication standards for the monitoring and control of roadway electrical infrastructure including street and roadway lighting. In September 1996 an agreement was executed among AASHTO, ITE and NEMA to jointly develop, approve and maintain the NTCIP Standards. In 2002 the Joint Committee on the NTCIP accepted the invitation from Karl Burkett of TexDOT to transfer the initial work of a committee of the Illuminating Engineering Society to form the NTCIP ELMS Working Group to further develop the control objects based on NTCIP.

James Frazer: Development on NTCIP 1213 v02 was started in 2002. In February 2004 it was accepted as a user comment draft by the Joint Committee of NTCIP. In March 2004 a standards bulletin was distributed for user comment. In June 2010 the publication began editing, and in February 2011 editing was completed and the final standard was published.

James Frazer: We’re now ready for our first pop-up quiz. Please use your computer mouse to select your answer on the screen and select “submit”. There is only one answer.

James Frazer: Which of the following statements is true? 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.

James Frazer: I hope you’ve recorded your answers. Now we’ll review. A) NTCIP 1213 is an information content standard. Choice “A” is correct because NTCIP 1213 addresses the information level interoperability. This level contains standards for the data elements, objects and messages to be transmitted. For example, TCIP and NTCIP 1200 series standards, etcetera.

James Frazer: B) NTCIP 1213 is an application level standard. Choice “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, FTP, CORBA, etcetera.

James Frazer: C) NTCIP 1213 is a transport level standard. Choice “C” is incorrect because NTCIP 1213 does not address the transport level. This level contains standards for data packets sub-division, packet re-assembly and routing when needed. For example, TCP, UDP, IP.

James Frazer: “D) NTCIP 1213 is a plant level standard” is incorrect because NTCIP 1213 does not address the plant level. The plant level consists of the physical transmission media used for communication. 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 sub-network level selection to which it must interface.

James Frazer: Major benefits of ELMS NTCIP 1213. The example, user need monitor the status of the ELMS Luminaire Switch Status Message is one of many user needs supported by the standard. The example functional requirement, monitor the ELMS Luminaire Current Status Message is one of a number of functional requirements supported by the standard. Notice the interrelationship of the user need and the functional requirements and remember that a single design exists for each requirement.

Nicola Tavares: Advantages of ELMS NTCIP 1213. IT enables solutions that are easier to use as agencies and specifications writers can easily determine what ELMS user needs and requirements the standard does support. It’s easier to specify. Agencies and specifications writers can easily specify their ELMS requirements for the proposed implementation by selecting user needs and dependent requirements. And it’s easier to test. 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.

James Frazer: Advantages of the Systems Engineering Process and NTCIP 1213. It supports off-the-shelf interoperability. Based on the requirements, the standard specifies the design, ensuring consistency between implementations. And it provides standardized user needs, requirements, and design content to fully support project engineering activities using the Systems Engineering Process.

James Frazer: The Systems Engineering Process is an interdisciplinary approach and a means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle by 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 types of systems. Systems Engineering Processes are related to the stages in a system life cycle. The Systems Engineering Process usually begins at a very early stage of the system life cycle and at the very beginning of a project. These standardized user needs and requirements allow creation of project-specific design content that allows specifiers to drop in these requirements into a project specification. Note again the interrelation of user needs and requirements in the Systems Engineering Process.

James Frazer: This graphic represents the Systems Engineering Life Cycle. The left side of the “V” represents the conceptual development and decomposition of requirements into function and physical entities that can be architected, designed and developed. The right side of the “V” represents integration of these entities, including appropriate testing to verify that they satisfy their requirements and their ultimate transition into the field where they are operated and maintained.

James Frazer: An obvious place to start developing system requirements is with the user requirements, high-level expressions of user need that the system’s expected to satisfy. Subsequently, system technical requirements are developed after the user requirements are defined. System requirements should be tracked or traced to the user requirements. Tracing a requirement means cross-referencing the source, in this case user requirements on which a system level requirement is based. And also to reverse reference which system requirements implement the source requirement or source user needs in this case. Tracing user to system level requirements helps ensure that all requirements have some user basis and that all user requirements are included in the system requirements for development.

James Frazer: And it’s time for our next pop-up quiz. Which of the following is not an advantage of using the Systems Engineering Process for the ELMS NTCIP 1213 Standard? Answer choices are: A) supports interoperability, B) it allows multiple designs for each requirement, C) it allows clear development of test procedures based on the requirements selected, or D) determines what user needs are supported. Please select your answer.

James Frazer: Let’s review our answers. “B” is false. This statement is not an advantage. NTCIP 1213 does define a unique design for each requirement. This unique design allows interoperability between the management center and the ELMS device as well as with external systems such as vehicle-to-infrastructure communications equipment and intelligent electrical distribution networks known as the Smart Grid.

James Frazer: “A” is an advantage. NTCIP 1213 SEP process supports the information level interoperability. It addresses the communications interface.

James Frazer: “C” is true. This statement is an advantage. It allows clear development of test procedures based on the requirement selected. Test procedures will be described in future presentations.

James Frazer: And “D) determines what user needs are supported.” This statement is also true and an advantage. NTCIP 1213 determines the user needs to be supported. These user needs are the foundation for the functional requirements.

James Frazer: Let’s summarize learning objective one. We reviewed the purpose and selection of the standard. We identified components of the standard, the concept of operations, the requirements, the dialogs, the management information base, the protocol requirement lists, the RTM. And we located user needs and standards on a V-diagram life cycle process.

James Frazer: Learning objective two. We’ll be identifying specific ELMS user needs, including: we’ll start with the architecture of an ELMS, we’ll define important terms and concepts, and then we will examine user needs in more depth.

James Frazer: As we proceed we’ll look at a few case studies.

James Frazer: The following slides describe three application examples from around the United States. During downtown reconstruction project in Minneapolis 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 non-peak periods. The results: a twenty-six city-block area was the focus. A comprehensive evaluation of all electrical infrastructure including traffic signals, roadway lighting, dynamic message signs and cameras was performed. And NTCIP-compliant system was designed and NTCIP-compliant equipment was installed. The results include roadway lighting system attributes are monitored, ground fault conditions are communicated in near real-time, and selected lighting fixtures are turned off during non-peak periods. A white paper describing this application is included in the student supplement.

James Frazer: In Florida, a nine-year old boy was electrocuted at a city bus stop powered by the roadway lighting system. Substandard electrical work was determined to be the cause of his death. Subsequently, also in the same county a man was injured and the horse he was riding upon died after it stepped on an electrical junction box. Based on this, a number of user needs were developed. Due to the severe and fatal injuries of people and animals, ground fall conditions were determined that they were needed to be communicated in near real-time, this data must be logged, and reports of alarms must be generated.

James Frazer: The result is that an ELMS system was deployed that wirelessly communicated near real-time attributes to the management center. County workers can monitor electrical leakage levels by circuit and can respond promptly when anomalies occur. Ground fault conditions are communicated near real-time, data is logged, reports and alarms are generated. Articles referencing this application are also included in the student supplement.

James Frazer: The 1963 SR520 Bridge is the longest floating bridge on Earth at seventy-five hundred and eighty feet. It carries State Road 520 across Lake Washington from Seattle to Medina in the U.S. State of Washington. The bridge’s total length is approximately fifteen thousand five hundred feet. On its eastern end it also includes a number of tunnels. It is currently being replaced. The new design features NTCIP compliance for many systems, including the electrical and lighting management system. During this project these user needs were identified: energy use must be controlled, power outages must be communicated in near real-time, and adaptive control of lighting based on ambient light levels must be deployed.

James Frazer: This NTCIP 1213-compliant solution supports circuit-based controls. Ambient light sensors collect light-level attributes at each tunnel opening. These light levels drive the switching of the circuit-based contactors. The status of each contactor’s switch state and current flow is also monitored. Thus the user needs are satisfied. Energy use is controlled, power outages are communicated in near real-time, and adaptive control of lighting based on ambient light levels is deployed.

James Frazer: What is the concept of operations? Here we get into the details of the concept of operations. We will define ELMS terms and concepts. We will then discuss user needs for the NTCIP 1213 standard. The user needs in this standard are expressed as features of a system. The concept of operation focuses on the system and its users. The timeframe is a full life cycle of the system and it provides an operational context for the system.

James Frazer: Primary uses of the ELMS NTCIP 1213 system. ELMS Version 2.0 uses comprise three distinct application areas internal to the field installed electrical infrastructure. These include monitoring and control of roadway lighting infrastructure including control of dimming, monitoring junction temperature of LED fixtures, grouping luminaires into logical zones, and applying schedules-- time-based schedules-- to those zones, monitoring and control of dangerous electrical faults, including ground fault leakage detection and arc fault issues, and monitoring and control of billable energy usage as well as power anomalies such as low-, high-voltage and electrical leakage.

James Frazer: What is a user need? A user need describes the major capability provided by a system to satisfy an operational need. These ELMS needs include roadway lighting, safety, revenue-grade power metering and power quality data, integration with other systems, vehicle-to-grid infrastructure integration for adaptive lighting, integration to the Smart Grid and integration with electric vehicle charging infrastructure, traffic signal power usage, and DMS power usage. User needs describe the needs of the user, which the systems intend it to need. They’re one of the main design inputs for the system requirements. Sometimes the two get confused or merged into one, and it’s very useful to distinguish between them. User needs are the basis of agreement from amongst your team on what the thing you are building is supposed to do. A project team with no user needs to document most probably also lacks agreement on what the exact purpose of the product or project is. And this is a major reason why projects and products fail.

James Frazer: Who and what can generate user needs? In order to develop user needs you should go beyond internal and external experts to get information from users. Focus groups of current and potential users can provide useful insight and feedback about system attributes. Reach out to other groups that represent current or potential users. A needs assessment engages users in the target audience not only in developing and testing a project’s specification but also in becoming faithful users of the deployed solution. A variety of techniques such as surveys, focus groups, and feedback from advisory and interested community groups can provide useful information from determining user needs. People have user needs: travelers, TMC operators, maintenance personnel. And, in addition, in some contexts, the system may itself generate a user need as in the management station may need to modify an operational parameter.

James Frazer: The ELMS problem statement. Generic information, a device ID for example. It needs to detect and sense device information from sensors in the field. It needs to control those field sensor attributes and it needs to integrate with other ELMS systems and other communication platforms, including the Smart Grid and vehicle-to-infrastructure systems. An ELMS is defined as any system that is able to manage roadside electrical and lighting devices using NTCIP. In general, an ELMS is composed of a set of field devices; luminaires, electrical circuits, etcetera-- that are controlled by one or more management stations. Some of the key concerns and user needs for transportation agencies that may be addressed by implementing an ELMS are citizen and maintenance personnel safety; reducing the potential for electrical shock hazards to citizens through automated detection of electrical lighting equipment faults; light pollution and trespass regulatory compliance by conforming to national, state and local laws and regulations; and voluntary programs on light pollution, light trespass can be reduced to improve citizens’ quality of life.

James Frazer: User needs can come from operations and maintenance by reducing resources used to monitor roadside electrical lighting devices through remote communication and detection of equipment failures, and also to allow the ability to improve re-lamping schedules. Other user needs come from energy utilization by optimizing energy consumption of electrical and lighting devices through automated monitoring and control. Homeland Security incident and event management drives a number of user needs. By providing flexible and timely control of roadside electrical and lighting equipment to assist law enforcement professionals in Homeland Security and/or specific incident or event management operations. Other user needs come from vehicle-to-infrastructure communications from that community, from communication to the Smart Grid and from electric vehicle charging stations and their users.

James Frazer: What is the scope of the ELMS NTCIP 1213 Standard? This graphic describes an ELMS that supports only proprietary terminal devices. Notice that the luminaire electrical service and branch circuit do not communicate using NTCIP. In this case the ELMS device translates proprietary protocols into standardized ELMS objects. Notice that the management stations connected to the data aggregator ELMS device. This connection is the subject of NTCIP standards. And once again the ELMS itself communicates with multiple terminal components including lighting controllers, ground fault interrupters, revenue-grade meters and branch circuits in this example.

James Frazer: Here’s an alternate architecture of the ELMS NTCIP Standard. This graphic of an alternate architecture depicts connections between various ELMS components.

James Frazer: Management station is connected to the data aggregator ELMS device and this connection is the subject of NTCIP standards. The ELMS itself communicates with multiple terminal components which may include various sensors including lighting, ground fault interrupters and revenue grade meters. Notice in this graphic that the ELMS device is resident in the roadway luminaire. Alternately, this ELMS device could be resident in an electric vehicle charging station for example or in an electricity meter. This graphic describes the logical zones resident within an ELMS device. Zones and/or hierarchies of zones may be defined; these are logical groupings of field devices. Individual ELMS devices may be assigned to one or more electrical zones. Definition and management of relative priorities of these zone-based operations can be configured. Reporting of summarized device status can be configured and each of the above is expected to be performed on the management station and not through the ELMS device interface.

James Frazer: ELMS NTCIP 1213 User Needs in Detail. Section 2, in general, and section 2.4, in particular, describes how user needs are encapsulated in the definition of the ELMS software interface. It also describes how user needs are the underlying basis for the detailed functional requirements. User needs are the deliverable that drives use of functional requirements. A requirement is a description of a condition or a capability to which a system is obligated to perform either derived directly from user needs or stated in a contract standard specification or other document. It’s a desired feature, property or behavior of a system.

James Frazer: User Needs in Detail. User needs are organized in two groups. Operational defines the basic modes of operation for communication between the management station and the field devices. Provide Live Data and Provide Off-line Logged Data are two such operational needs; this includes support of get data and set data logical operations. Features describe essential data communication and functions and message elements to be supported by the interface; it is defined as a behavior of an ELMS device.

James Frazer: Operational User Needs. One operational environment allows the management system to monitor and control the device by issuing requests; requests to access information, alter information or to control the device. In this environment, the devise responds to requests from the management station immediately through the provision of live data, success or failure notice of information or success and failure of the command itself. Live data is defined as a specific operational network configuration between the management station and the ELMS device where the information exchange can be performed without the need for initiating and terminating a physical network connection between the management station and the ELMS device. From a network perspective, this configuration is an always-on connection where the management station has access to the current information available in the ELMS device. This provision of live data is important to a user because it provides the most basic means 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: Another important operational user need for NTCIP 1213 is provide off-line logged data. Some operational environments do not always 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 or retrieved 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. This slot explains that the standard allows data to be collected over time and stored in a log for later retrieval. This data can include sensor data as well as any data managed by the system such as a timing plan change. This user need is mandatory. Logged data is defined as a specific operational network configuration between the management station and the ELMS device where the management station is required to execute a procedure for establishing a physical connection between the management station and the ELMS device prior to being able to exchange data with the ELMS device. In this configuration, information generated by the ELMS, which is expected to be retrieved by the management station, is stored externally to the management station until such time as the management station initiates the network connection to access the stored or logged data from the ELMS device. ELMS NTCIP 1213 Features. These relate directly to the informational needs of the users. They’re divided into three major functional categories. Control, monitoring and management of roadway lighting including attributes for power, current, voltage, dim level, runtime, LED junction temperature and alarms. Number two; control, monitor and management of electrical power including voltage, current, power usage, frequency, runtime and alarms. And number three; control, monitoring and management of electrical safety, ground fault detection and interruption and arc fault detection and interruption. More information and definitions can be found in the student supplement, in particular the glossary, the PRL table and the included white papers.

James Frazer: ELMS NTCIP 1213 Features: Managing Roadway Lighting. Managing Roadway Lighting includes sever sub-needs; implementing lighting based on ambient light level or time schedule; creating and configuring zones. Implementing a lighting plan based on ambient light level is also used for off-road lighting trespass applications. Full moon or new moon can impact ambient light levels and all the ELMS to alter lighting levels. Implementing a lighting plan based on a time-based schedule. Business districts may choose to alter lighting levels when businesses are open. A schedule is a mechanism by which the operator can define times in the future at which the luminaire performs actions. Zones are logical groupings of luminaires and/or circuits and are electrical services used for control and reporting purposes. Creating a zone allows inclusion of lighting fixtures to be groups into zones for sections of the highway or downtown business districts. Configuring a zone is where individual lighting fixtures are placed into a particular zone.

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

James Frazer: Continuing with managing roadway lighting sub-needs, there are a number of logging features: Configuration of Luminaire Switch State Logging; Configuration of Luminaire Lamp Condition Logging; of Luminaire Burn Condition Logging and Luminaire Pole Condition Logging. Logging is the process of recording that ELMS data into 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 on a 24 hour basis; pole knock down status may be reported on a shorter time basis and could be interrupted. Junction temperature of an LED roadway luminaire can be logged hourly or upon change of command and stay. Adaptive lighting actuations can also be logged.

James Frazer: There are a number of luminaire sub-needs within NTCIP1213. Luminaires are configured for various modes of operation including definition of identity, a light activated operation or scheduled operation. Configuration of a luminaire switch state, again, can be light activated or scheduled. You can change the unique ID of a luminaire. You can configure the luminaire dim level either as a fixed setting of 70 percent, for example, or dynamically as part of an integrated adaptive lighting system. And the luminaire can be controlled; it can be turned on or off. It can be dimmed by zone, by schedule, by ambient light.

James Frazer: Managing Electrical Power sub-needs. As you can see, the power meter possesses multiple configuration options including switch state, on or off, as well as monitoring a power meter attributes logging. This allows answering questions such as “Is the meter on or off? Do you want the log when the meter switch is on or off? Do you want to log the condition of the meter?” Or “How often do you want to record or log energy usage information?”

James Frazer: Managing Electrical Safety includes a number of sub-needs. Similarly to power configuration, the ground fault attributes can be configured, controlled and monitored. Ground fault alarm levels can be configured, monitored and logged. Ground fault levels can be monitored in near realtime. Electrical services can be configured, monitored and controlled. Circuit breakers, circuits and arc fault sensors can be configured, monitored and controlled; alarms can be enabled; attributes can be logged and realtime values can be reported. Examples include “Has the breaker tripped? What is the current draw through the breaker? Has a breaker alarm been activated?” We’re now ready for our next pop-up quiz. Please use your computer mouse to select your answer on the screen and select submit. There is only one correct answer. Which of the following user needs cannot be satisfied by an ELMS system? Answer choices are A, need to inform the Traffic Management Center of electrical leakage; B, need to control traffic flow at an intersection; C, need to inform the Traffic Management Center of energy usage or D, need to control lighting level by dimming.

James Frazer: Let’s review our answers. Choice B is false; NTCIP does not support traffic flow. Choice A is incorrect; NTCIP supports the communications of electrical leakage information. Choice C is incorrect; NTCIP does support the communications of energy usage information. And D is incorrect because NTCIP does support communications of dimming information.

James Frazer: Summarizing Learning Objective 2; we identified specific ELMS user needs; we discussed the problem definition of what are we trying to do as an ELMS; and we introduced three generic architecture models.

James Frazer: Next we will begin examining the PRL, the Protocol Requirements List. The PRL is a table that is a tool included in the standard for use by the system developers, agencies, specifiers and producers of ELMS equipment. It’s found in section 3, the requirements of the standard. We will step through the structure and parts of the PRL. We’ll begin discussing tailoring the PRL for use and specifications. And we’ll discuss reducing risk by having interoperable/interchangeable ELMS equipment in our system.

James Frazer: Section 3 of the ELMS standard defines the requirements based on the user needs identified in section 2 and the interrelationship of user needs and functional requirements. We’ll discuss the PRL and the three types of requirements that are resident within the PRL. Remember that user needs drive all requirements whether operational, functional or supplemental. In the next few slides we’ll examine the operational environment requirements, the functional requirements and the supplemental requirements in detail.

James Frazer: The purpose of the ELMS Protocol Requirements List. The purpose is to be a table that maps the user needs to the requirements, to be a part of the agency specification, to reference the standard to define the communications interface, to help define what you want the interface to do and to identify what requirements will be selected to address a specific set of user needs. Additionally, the PRL table should be used as part of an agency specification by determining user needs and tracing them through requirements, specification is developed. PRL defines the communications interface; it defines the protocol and logical object. Objects, as we discussed, are defined as mandatory or optional. The PRL helps to define what the interface is required to do in your particular project. Your user needs drive the definition of the interface through the selection of dependent objects.

James Frazer: This is an image of the ELMS Protocol Requirements list. The ELMS PRL is comprised of seven vertical columns. As you develop your project, you will work with the columns from left to right. The first two are user needs related. Columns three and four describe functional requirements. Column five describes conformance while six and seven describe project requirements. The complete PRL is listed in the student supplement.

James Frazer: This slide begins to explain the layout of the PRL table by locating the user needs ID and textual description. The first line contains the headings of the PRL table. The second line contains a user need. The first column shows the user need section number and the second column shows the user need textural title.

James Frazer: As we’ve already examined the user needs of Provide Live Data and Provide Off-line Logged Data we’ll be focusing, for this example, on the user needs 2.4.1.2.1, provide luminaire switch state logging; 2.4.1.2.2, provide luminaire lamp condition logging; and 2.4.1.2.3, provide luminaire burn condition logging.

James Frazer: The third column shows the functional requirement section number. The fourth shows the functional requirement title. Notice the requirement under and related to the particular user needs in our demonstration of 2.4.1.2.1, luminaire switch state log is under provide luminaire switch state logging, user need 2.4.1.2.1. Similarly, luminaire lamp condition log 3.3.2.10.3 is under the user need 2.4.1.2.2, provide luminaire lamp condition logging and 3.3.2.10.4, luminaire burn condition log is under the user need 2.4.1.2.3, provide luminaire burn condition logging.

James Frazer: Column five defines conformance indicating which of the items user needs and requirements are mandatory, conditional or optional. Taking a look at conformance in column five, note the choices of M, mandatory or O, optional in this column. And continue with our example notice that the user need provide luminaire switch state logging possesses an O in the conformance column; so does provide luminaire lamp condition logging and provide luminaire burn condition logging. These requirements are conditional upon the conformance of the user need. Thus if user need 2.4.1.2.1 is chose to be required for a particular project the dependent functional requirements must also be supported in the project.

James Frazer: Column six, project requirements, defines whether these features and user needs are requirements for the projects. Note that choices of yes or now for requirements that are defined as optional in the conformance column. Continuing with our examples of user need provide luminaire switch state logging, provide luminaire lamp condition logging and provide luminaire burn condition logging; notice they all possess a yes or no entry in the project requirements column. These requirements are conditional upon the conformance of the user need. Thus if user need 2.4.1.2.1 is chose to be required for a particular project the dependent functional requirements must also be supported in the project column.

James Frazer: Supplemental requirements are additional requirements derived from the concept of operations that do not fall into other categories, i.e. requirements related to the data contained in an inventory report, for example. Let’s identify each of the columns. The supplement requirement ID is the numerical reference of the requirement. The supplement requirement, column two, is the textual definition of the requirement. Conformance. Notice that mandatory and optional comments are included. Project requirement; we’ve reviewed the yes and no entries.

James Frazer: Let’s focus on column five and look at 3.5.1.1, support a number of actions. Notice it is mandatory but that in the additional project requirements we can define support of 1 to 255 actions. Let’s now look at 3.5.3.1, define dim levels as a percentage of maximum brightness. Notice is it optional and a project requirement choice of yes or no needs to be performed.

James Frazer: Other user needs not in the PRL. The standard, like the entire suite of NTCIP protocols, allows for extensions. Proprietary extensions are not desired; it causes interoperability problems but sometimes they are necessary. Extensions can become part of a future version of the standard. And the standard supports interoperability for all the included features.

James Frazer: So let’s summarize the PRL. The relationship between user needs and requirements, in particular, the relationship between user needs columns one and two and the functional requirements three or four is an important basis of using the PRL. User needs in columns one and two are defined in section 2; the PRL is based on those user needs. Requirements column three and four are defined in section 3 and the PRL traces the user needs to those requirements. These user needs and functional requirements are bi-directionally traceable to each other. The conformance column five defines project requirements as mandatory or optional. And projects requirements column six defines requirements for a particular project. Remember again that the entire PRL table is published in the student supplement.

James Frazer: Agency Use of the PRL. The ELMS PRL can be used by a user or an agency specification writer to indicate which requirements are to be implemented in a project specific implementation. It can also be used by the protocol implementer as a checklist to reduce the risk of failure to conform to NTCIP 1213.

James Frazer: The Supplier and User Use of the PRL. Users and suppliers can both check the capabilities of an ELMS implementation through use of the PRL. It could also be used to check interoperability with another ELMS installation as well as with Smart Grid and vehicle to infrastructure communication system implementations.

James Frazer: We are now ready for a pop-up quiz. Please use your mouse to select your answer on the screen and select submit. There is only one correct answer. 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 answer.

James Frazer: Let’s review our answers. D, the PRL promotes interoperability. It’s correct because the PRL does promote interoperability. A is incorrect because ELMS user needs do describe features the device needs to support and why. B is incorrect because ELMS functional requirements are not specifications. And C is incorrect because within the ELMS PRL the relationships between user needs and functional requirements are standardized.

James Frazer: The next three slides describe the process used to select user needs so that the desired operations are supported. We’ll be examining 2.4.2.2.2, configure electrical service and its related functional requirements. Note that 2.4.2.2.2 has a conformance classification of optional because the requirements on this particular project will impact a yes or no in column six.

James Frazer: Selecting User Needs through the PRL. ELMS user need 2.4.2.2.2, Control Electrical Service, is defined on page 14 of the ELMS standard as a management station may need to control an electrical service directly or by enabling or disabling the stagger mode for branch circuits served by the electrical service. A management station may need to control the electrical service to allow or disallow the scheduled control of one of these three states: continuous control, transitory control or timed control.

James Frazer: Based on a definition we shall choose if this user need is required for our project and if so, which of the relating functional requirements will need to be supported?

James Frazer: The ELMS PRL and Conformance. Let’s examine the conformance setting of this example. Conformance, again, identifies if the user need or requirement is mandatory or optional. Note, if user need 2.4.2.2.2, Control Electrical Service, is required functional requirement 3.4.2.2.1 is mandatory while subsequent requirements are optional.

James Frazer: Mandatory versus Optional Conformance. Conformance identifies if the user need or requirement is mandatory or optional. Some user needs, remember, are basic needs related to an ELMS as in retrieve ELMS attributes and configure the ELMS manager; these user needs are considered mandatory but many others are optional. Remember that there was a basic set of user needs that are essential for a device to be an ELMS.

James Frazer: We are now ready for a quiz. Please use your computer mouse to select your answer on the screen and select submit. There is only one correct answer. 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 false statement.

James Frazer: Let’s review our answers. D is false. D is the correct answer as it is a false statement. Selection of project requirements does drive the inclusion and exclusion of optional functional requirements. Choice A is true. The only valid entries for conformance are mandatory and optional. Choice B is also a true statement. The only valid entry for a project requirement is yes or no. C is true. The selection of project requirements does drive the inclusion/exclusion of optional user needs. The ELMS User Need Hierarchical Relationship. If a user need such as 2.4.1.2 provide off-line logged data, has a project requirement defined as yes, then the dependent functional requirements listed below in the figure become mandatory. Notice that 2.4.1.2 provide off-line logged data is optional. Thus if the project definition requires this user need the functional requirements of 3.3.2.1, Retrieve Configuration of Logging Service; 3.3.2.2, Configure Logging Service; and 3.3.2.4, Clear Log are termed mandatory and are required. Please note the relationship that exists between the higher level parent user need and these lower level user needs. The ELMS PRL User Need Project Requirements Relationship. To select the project requirement circle yes or no in the appropriate cell in the table. In this example, for functional requirement 3.4.1.10.2.1, Configure Branch Circuit Location, select yes or no in the project requirement column. Similarly, for Configured Branch Pole Identifier, similarly select yes or no in the appropriate area.

James Frazer: The Importance of the ELMS PRL User Needs and Functional Requirements Relationship. User needs describe required features. Functional requirements refine the user needs into detailed specifications. Within the PRL, relationships between user needs and functional requirements are standardized. And use of the PRL’s user needs and dependent functional requirements promotes interoperability.

James Frazer: The functional requirement ID is a numerical reference to each functional requirement and is located in column three. In this example, these are listed as 3.4.1.3.1, 3.4.3.3.2, 3.4.1.2.3 and 3.4.1.3.4. the functional requirement description is a textual reference to each functional requirement and is located in column four. In this example these are listed as configure luminaire for light activated operation; this allows individual fixtures to be actuated by ambient light levels. Configure electrical service for light activated operation; this allows individual electrical services to be actuated by ambient light levels. Configure branch circuit for light activated operation; this allows individual branch circuits to be actuated by ambient light levels. And configure devices in a zone for the light activated operation; this allows the aggregated devices collected in zones to be actuated by ambient light levels. The additional project requirements column also deals with performance requirements specific to unique project requirements.

James Frazer: The ELMS PRL User Needs/Functional Requirements Relationship in Detail. Requirements associated with a user need are found under that user need. Each user need will have at least one requirement associated with it. Each requirement in the standard is associated with at least one user need. The result is that the standard has no unnecessary requirements and that all user needs are satisfied by at least one requirement.

James Frazer: Mandatory versus Optional User Needs and Functional Requirements. 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 are required by another user needs selection. The example we used was 3.4.1.3.4, Configure Devices in the Zone for Light Activated Operation.

James Frazer: The ELMS PRL User Need Additional Project Requirements column is used to enter additional notes and requirements; is used to provide further details about the implementation such as a range of actions.

James Frazer: We are now ready for another quiz. Please use your mouse to select your answer on the screen and select submit. There is only one correct answer. Which of the following is a false statement? User needs describe what features the device needs to support, A; 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 false statement.

James Frazer: Let’s review our answers. D, the PRL does not promote interoperability. This is false because the PRL does promote interoperability. A is true. User needs do describe what features are required. B is a true statement. Functional requirements do refine user needs into detailed measureable specifications. And C is a true statement. The PRL does define standardized relationships.

James Frazer: Using the ELMS PRL to Check Interoperability. Off the shelf interoperability is achieved due to the successful completion of several activities. A standard that supports deployment at interoperable systems is only one of those items. In what application areas can interoperability be checked? Interoperability can be checked with the ITS Management Center; other ELMS systems both local and remote; the electrical and utility distribution network, the Smart Grid, as defined by the US Department of Energy and The NIST Smart Grid Interoperability Panel; and vehicle at the infrastructure communication systems both for police, fire, EMS applications as well as for generic vehicles on the system in the future. These will be used to drive adaptive roadway lighting applications.

James Frazer: Summarizing Learning Objective 3. We indicated how to select user needs that can be traced to requirements implemented in a project specific environment. We discussed how to reduce the risk of failure to conform to NTCIP 1213. We discussed providing detailed indication of the capabilities of the implementation. And we discussed using the standard to check interoperability with other ELMS systems as part of the vehicle to infrastructure communication system or as part of the interoperable Smart Grid.

James Frazer: Integrating the ELMS PRL into an ELMS Specification. From a vendor’s perspective, even if a user need and resulting requirements is not mandatory a vendor may optionally fulfill the user need and provide the feature. Vendors can provide a PRL for their standard products to show what user needs they support. Vendors can offer optional features as included features in their product such as the astronomical clock. Vendors can also provide a completed PRL to demonstrate the features their products do support.

James Frazer: Integrating the ELMS PRL into an ELMS Specification from an agency’s perspective. A completed PRL must become part of the overall specification. The completed PRL indicates the requirements for the communications interface and, by extension, the user needs and functional requirements that the ELMS must support. If the agency desires to utilize commercial off the shelf devices then the agency should compare their list of selected needs and requirements with commercially available equipment to ensure that they are not specifying something that does not exist.

James Frazer: Integrating the ELMS PRL into ELMS Contract Documents. The PRL and resulting specification includes a comprehensive communications interface specification. This includes the specification of ELMS functional requirements, performance requirements and protocol requirements. The ELMS communication specification, when combined with a software and hardware specification, becomes the product or project specification. This product specification then becomes part of the contract documents. It’s important to note that the completed PRL must be consistent with the hardware specification and a completed PRL shows the intent. Interested vendors can view this PRL and understand the intent of the requirements.

James Frazer: Conformance and Compliance in the Specification. Conformance is used to meet a specific standard. It’s used-- to claim conformance to ELMS NTCIP 1213 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. Vendors that replace conformant features with proprietary features are not conformant. Conformance differs from compliance. Compliance means meeting a specification for a specific project.

James Frazer: We are now ready for a quiz. Please use your mouse to select your answer and select submit. There is only one correct answer. 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 false statement.

James Frazer: Let’s review our answers. D is false. A completed ELMS PRL describes the entire project specification. False. It only describes the communications interface. A, vendors can provide an ELMS PRL for their standard products to show what user needs they support is true. Products can be evaluated for standardization. B, a completed ELMS PRL must become part of the overall specification is also true. Product specifications include communications, hardware and software specifications. C, a completed ELMS PRL indicates the requirements for the communications interface is true. The PRL does define the communications interface.

James Frazer: Let’s summarize Learning Objective 4. We explained how the PRL table of NTCIP 1213 fits into the ELMS specification. And we emphasized the user needs and requirements linkage.

James Frazer: So what have we learned today? NTCIP 1213 defines the concept of operations and user needs for electrical and lighting management systems. Number two, NTCIP 1213 follows the SEP approach. Number 3, ELMS has three major categories of functionalities: control roadway lighting, monitoring ground fault conditions, and monitoring electrical power usage. Number four, a Protocol Requirements List is used to link user needs to functional requirements. Number five, the PRL table of the ELMS standard fits into an ELMS project specification. We’ve identified specific ELMS user needs. We’ve identified what you’re trying to do with an ELMS. We’ve identified and introduced various ELMS architecture models and when to use them. We’ve used the Protocol Requirements List to select user needs and to link them to requirements including how to select user needs that can be traced through requirements implemented in a project. We’ve discussed using NTCIP 1213 and the PRL as a checklist to increase conformance to NTCIP 1213. We’ve discussed and provided detailed indication of the capabilities of implementing NTCIP 1213. And we discussed potential interoperability with other implementations of ELMS in the field as well as vehicle to infrastructure communication systems and as part of the Smart Grid.

James Frazer: There are a variety of resources that are listed additionally in the student supplement that you can review for further information. And it’s time for questions. We received a number of questions. Let’s start with “Where has ELMS been deployed?” Since the publication of the standard in 2011 many entities have begun designing ELMS into highway, roadway and downtown construction projects. States, counties and local governments from Miami Dade County through the upper Midwest including Minneapolis, Minnesota, St. Cloud, Minnesota, are enjoying the benefit of ELMS. Recently a variety of states including the state of Washington specified ELMS for all new and reconstructed electrical and lighting projects. “What other standards development organizations are supporting ELMS standards?” There are a number of these. Recently, number one, the US Department of Commerce, through the National Institutes of Standards and Technology, NIST, has referenced ELMS NTCIP 1213 as a Smart Grid standard. Two, the illuminating Engineering Society’s Roadway Lighting Energy Management Committee has included ELMS in its draft “Guide for Selection, Installation and Maintenance of Roadway Lighting Controls.” Three, the Department of Energy’s Municipal Solid State Lighting Consortium is supporting ELMS standards. Number four, IMSA, the International Municipal Signal Association, has begun integrating ELMS content into their roadway lighting technician and roadway lighting specialist’s continuing education programs. Number five, the IEEE, their Guide for Electric Sourced Transportation Infrastructure P2030.1 has begun inclusion of ELMS standards. And the United Nations International Telecommunications Union, ITU, supports ELMS in its global ITS communications requirements document. The ITU is also progressing in a similar fashion by including ELMS standards into its global Smart Grid standardization initiatives. And another question. “What’s next for the ELMS version 2.0 standard?” In the coming year the ELMS 3.0 standard initiative will commence. This will include support for electric vehicle charging, specifically vehicle support for electric vehicle supply equipment known by the abbr of EVSE for payments, for electrical loans, from loan shedding <ph?>. Number two, ELMS 3.0’s initiative will include vehicle to infrastructure communications. In the mid part of this decade vehicles will broadcast a multitude of attributes to the roadside for better traffic signal operation as well as for support of a comprehensive adaptive roadway lighting program. Adaptive roadway lighting is driven by this presence and absence of vehicles as well as by the vehicle broadcast of their own speed, direction, road friction and ambient light levels. ELMS 3.0 will also include integration to the Smart Grid. An Energy Services Interface will be created, an ESI, that informs the electrical utility exactly what power the system requires to buy and sell at what time, at particular price points. This ESI is equivalent to the ESI already present in many home and light commercial smart electric meters. It’s very similar to the ESI developed by the American Society of Heating, Refrigerating and Air Conditioning Engineers, ASHRAE for industrial building sites, college campuses, large office complexes and shopping malls.

James Frazer: Our next course module is A306b, Specifying Requirements for Electrical and Lighting Management Systems, ELMS, based on the NTCIP 1213 standard. This course reviews the structure of NTCIP 1213. It uses the requirements traceability matrix, the RTM, and the Protocol Requirements List to specify the standardized structure requirements. It discusses how to include the requirements from the PRL and RTM in your specification. It discusses how dialogs and messages in the PRL are communicated to the field device. It addresses specifier requirements that are not covered by the standard. It assists in specifying clear requirements from the list of requirements within the standards and meeting those identified user needs. It continues to provide participants with information on how to identify the appropriate use of the standard and describes how to acquire an ELMS system based on what the user is seeking to accomplish. Thank you for attending today.

#### End of 2013-01-23 14.18 A306a FinalRecording.wmv ####