Module 27 - A306b

A306b: Specifying Requirements 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.)

 

Nicola Tavares: Welcome to the ITS Standards Training.

Ken Leonard: ITS standards can make your life easier. Your procurements will go more smoothly and you will 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 am 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 are 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 will 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.pcb.its.dot.gov. 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.

Nicola Tavares: 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 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. This module is A306b, Specifying Requirements for Electrical and Lighting Management Systems Based on NTCIP 1213 Standard. Your instructor, Jim Frazer is President of Gridaptive Technologies. Jim Frazer poses in-depth knowledge of the commercial and industrial sales and marketing process as well as that of control system integration networks and protocols. He has proposed, engineered, and managed large commercial and governmental automation projects in the United States and Europe. He possesses an undergraduate degree in Mechanical Engineering and a Master's Degree in Business Administration.

James Frazer: The target audience for today's presentation is engineering staff, street lighting maintenance staff, Traffic Management Center and Operations personnel, Systems developers, and private and public sector users including manufacturers.

James Frazer: The recommended prerequisites for this course are I101: Using ITS. Standards An Overview, A101: Introduction to Acquiring Standards-based ITS. Systems, A102: Introduction to User Needs Identification, A201: Details on Acquiring Standards-based ITS. Systems, C101: An Introduction to the Communication Protocols and Their Uses in ITS. Applications, and A306a: Understanding User needs for Electrical and Lighting Management Systems based on the NTCIP 1213 Standard.

James Frazer: This particular slide places the current course in the context of the overall curriculum path for NTCIP 1213. The user is recommended to take as a prerequisite A306a: Understanding User Needs for ELMS based systems, based on the NTCIP 1213 Standard before taking this module A306b. This slide represents the graphical flow chart of seven courses that are to be taken in sequential order.

James Frazer: Our learning objectives for today. Number one we will review the structure of the NTCIP 1213 v02 Standard. Number two, we will use the Protocol Requirements List, the PRL, to specify the standardized structure of requirements. Number three, we will include the requirements from the PRL in a project-specific specification. Number four, we'll explain how interoperability is achieved through the Requirements Traceability Matrix known as the RTM Number five, we will examine the benefits of the systems engineering process approach regarding verification and validation in the ELMS testing process. And number six, we'll explain the conditions and context for extending the standard including specifying requirements that are not included in the current version of the standard.

James Frazer: Learning objective one, reviewing the structure of the NTCIP 1213 Standard. In this learning objective we will summarize the capabilities of NTCIP 1213. We will identify the components of the standard, the concept of operations, the requirements, dialogs, the Management Information Base abbreviated as MIB, the Protocol Requirements List, the PRL, and the Requirements Traceability Matrix, the RTM. In this particular course we'll focus on the requirements and we will state what this standard does not have. The primary focus of this first learning objective centers around the ability to understand how user needs can be used to trace the requirements by using the PRL. Prior to discussing this, we will also review the outline of the 1213 Standard as discussed in the previous course A306a. We will also provide a high-level overview of how the requirements are arranged in the document, but we'll have to wait to discuss the detailed user need to requirement traceability until we also complete learning objective two so that we will only have to step through the PRL once. This section of the presentation reviews high level information containing A306a in order to provide an overall context to the participant in case you do not take the previous courses. It describes the typical components of an ELMS architecture and highlights the interface that NTCIP 1213 standardizes. It also describes the status of the standard and summarizes its contents by presenting an outline.

James Frazer: The capabilities of NTCIP 1213 Systems include the control and monitoring of terminal devices for roadway lighting including scheduling and zoning of those roadway lighting fixtures, safety for electrical leakage anomalies including power quality, ground fault issues, as well as revenue grade power metering.

James Frazer: NTCIP 1213 systems also include the capability of integrating with other systems including vehicle to grid infrastructure for true adaptive lighting applications. Integration with the electrical distribution network, the smart grid for reporting past energy usage as well as reporting a future forecasting energy requirements, and integration with electric vehicle charging infrastructure for management of dynamic electrical loads including electric vehicle chargers, photovoltaic power, and wind power. This slide defines the environment in which the ELMS operates and where the interfaces are addressed by the standard. Field devices on the right side of the screen include meters, roadway lights, and safety equipment such as ground fault sensors. Notice that the NTCIP 1213 interface could be located at a Gateway data collector or at the terminal device. On the left hand side of the screen we have representation of the management center, on the right the field devices, and optionally NTCIP 1213 architectures include a Gateway.

James Frazer: This next slide describes the larger transportation ecosystem in which the ELMS operates and where the interfaces are that are addressed by the standard. Note that NTCIP 1213 is a center-to-field communications standard and that it is part of the larger ITS. ecosystem. Notice that NTCIP from the traffic management center speaks to the electrical infrastructure represented by the red line. It's also more in communicating to the vehicle to infrastructure communications.

James Frazer: This next slide describes the larger electrical distribution ecosystem in which the ELMS operates and where the interfaces are that are addressed by the standard. The National Institute of Standards and Technology, NIST. Smart Grid conceptual model provides a high level framework for the smart grid that defines seven important domains. Volt generation, transmission, distribution, customers, operations, markets, and service providers. It shows all the communications in energy electricity flows connecting each domain and how they are interrelated. Each individual domain is itself comprised of important smart grid elements that are connected to each other through two-way communications and the energy and electricity pass. These connections are the basis of the future, intelligent and dynamic electricity grid. The NIST. smart grid model helps stakeholders understand the building blocks of an end-to-end smart grid system. From generation to and from customers and explores the interrelation between these smart grid elements. By examining this Department of Commerce image we can see that NTCIP 1213 interfaces to a number of the components of this model: distribution, markets, operations, and service provider.

James Frazer: This next slide describes the first part of the table of contents for the NTCIP 1213 standard so that the user can gain the familiarity of the overall flow of the standard. Notice that the PRL, the Protocol Requirements List is contained in the functional requirement section. Notice also that the objects represent individual pieces of data that are referenced by the dialogs. Major components are number one through five, section one is the general introduction, Section 2: describes the concept of operations, section three the function requirements, Section 4: the specific dialog specifications, and Section 5: the master object definitions that are included within the standard.

James Frazer: This next slide shows the appendices of the table of contents for NTCIP 1213 so that the user can gain a familiarity with the overall flow of the appendices. The RTM, the Requirements Traceability Matrix is the tool used to show the relationship with objects and dialogs within the standard. The RTM maps each requirement for specific design consisting of a dialog and a list of required objects.

James Frazer: NTCIP is missing test cases. This slide explains that standard test cases are not yet included with NTCIP 1213  version two but they will be included in future versions. These test cases should be developed for any deployment. Those deploying the standards should investigate the latest development to see if other projects have already developed the standardized test procedures that can be reused. For more information, students are urged to examine the testing courses T101, T201, and T202.

James Frazer: Next it's time for our first quiz.

James Frazer: Which choice is not a capability of the NTCIP 1213 Standard? Answer A, is roadway lighting including scheduling and zoning, B, safety: electrical leakage anomalies including power quality and ground fault issues, C, revenue grade power metering, or D, wiring specifics. Please review the question and the answers and make the appropriate selection.

James Frazer: Let's review our answers. D is correct, wiring specifics. Because NTCIP does not support wiring specifics. A is incorrect because roadway lighting including scheduling and zoning is a core capability of NTCIP 1213. Similarly B is incorrect because safety electrical leakage issues, power quality ground fault concerns are also all core capabilities of NTCIP 1213. And lastly C is also incorrect because revenue grade power metering was also included in the core capabilities of NTCIP 1213.

James Frazer: Okay let's summarize learning objective one. We did in learning objective one summarize the capabilities of NTCIP 1213. We identified the components of a standard, we focused on the requirements, and we stated what this standard does not have, test cases.

James Frazer: Learning objective two. Using the protocol requirements list, the PRL to specify the standardized structure of requirements. The PRL is the table that is a tool included in the standard for use by system developers, agency specifiers, and producers of ELMS equipment. It properly traces user needs to requirements. Within the PRL select a given range of a performance requirement to properly complete a project-specific specification.

James Frazer: This slide is a small portion of the NTCIP 1213 PRL table. In module 306a we discussed how to use the table to select user needs for a project. We will now discuss how you use the table to select requirements. Note that the full PRL shows additional requirements traced to this need that are not shown on this slide. The full PRL is included in the student supplement along with a completed PRL for the project-specific application which we will discuss a little later in our presentation. The first column in the PRL presents the user need identifier which is the number of the clause within the standard where the user need is formally defined. The second column indicates the name of the user need that is being referenced. Notice the dependencies between this column: 2.4.2 is the top level user need entitled Features. 2.4.2.1 is dependent upon 2.4.2 and is entitled Configure ELMS Device. Notice that this is one of multiple features. 2.4.2.1.1 is dependent upon 2.4.2.1 and is entitled Configure Luminaire Device. Notice that a luminaire is one of multiple types of ELMS devices. And lastly, 2.4.2.1.1.1 is dependent upon 2.4.2.1.1 and is entitled Retrieve Luminaire Information Device. Notice that the retrieve luminaire information is one of multiple functions related to a luminaire.

James Frazer: This slide shows the user need reference in the PRL has a formal definition in the standard that can easily be looked up. Notice that the text typically identifies the need as in this example, retrieve luminaire information, but it does not include measurable requirements.

James Frazer: The third column of the PRL presents the requirement identifier which is the number of the clause within the standard where the requirement is formally defined. Traceability is shown by listing requirements underneath the user needs to which they trace. A user need that traces to multiple requirements will have multiple requirements listed beneath it as shown here. A requirement that traces the multiple user needs will appear multiple times in the table, one time under each user need to which it traces. The fourth column describes the textual name of the requirement that's being referenced.

James Frazer: This slide shows that the requirements referenced in the PRL have formal definitions in the standard that can easily be looked up. Notice that the definitions provide precise and measurable requirements without defining precisely how they will be achieved.

James Frazer: As an example let's look at requirements for retrieve luminaire information. It has three sub-requirements. Retrieve luminaire location definition is stated as a management station shall be able to retrieve the location of the luminaire from the ELMS device. The location information shall be in one of the following forms. Specify location in latitude longitude states a management station shall be able to configure location information of an ELMS device using longitude and latitude. The coordinate information shall be specified in accordance with the location reference message specification geometry or geographic profiles. Or it can be defined as specified location information using textual description of a road, street, block name or number. This location information shall be specified in accordance with the location reference message specification address profile. Or lastly it can be specified in a local reference coordination grid. This coordinate information shall be using the location reference message specification grid profile.

James Frazer: This next slide shows that the requirements reference the PRL are formal definitions in the standard that can be looked up. Notice that the formal definitions provide precise and measurable requirements. So for retrieve luminaire information a management station shall be able to retrieve the current operating mode of the luminaire from the ELMS device. Retrieving luminaire zone, a management station shall be able to retrieve the zone identifiers for a luminaire from the ELMS device. And retrieve luminaire vendor information, a management station shall be able to retrieve the information on the version, make, and model of the luminaire from the ELMS device.

James Frazer: This next slide reviews the very important principles discussed in previous courses and describes the structured use for requirements. This structure is designed to minimize ambiguities. While ELMS requirements are well formed the actor is what identifies who or what does the action. The action identifies what is to happen. The target identifies who or what receives the action. The constraint identifies how to measure success or failure of that requirement. And localization identifies the circumstances under which the requirement applies. Localization and restraint portions are important but not all requirements will have both.

James Frazer: The next set of slides provides an overview of requirements included in the standard. We'll start by reminding the participants that the requirements are well-formed based on I.T. industry standards. And then we'll proceed to discuss the requirements covered by the standard within the context of each user need. We only give a high level overview of the requirements organization by discussing the outlines of the requirements section. The discussion of specifics will occur at the end of learning objective two after we have explained the additional specification column. So this slide provides an analysis of one of the requirements that we previously discussed. The NTCIP 1213 requirements are written as device requirements because it's not the intent of the standard to define when or why the ELMS might choose to call on a requirement. It does define how. So in our example the actor is the management station, the action is to be able to retrieve data, the target is the ELMS device, and the constraint is the location of the luminaire.

James Frazer: Next we will examine section three of the standard functional requirements. This slide provides an overview of the functional requirements. These are high level requirements that define basic characteristics of exchanging information both on and offline. We will examine operational, functional, and supplemental requirements in the following series of slides. Operational environment requirements. These are general requirements that define basic characteristics of exchanging information both on and offline. 3.3.1 provide live data. Contains requirements for specifying capabilities of an ELMS device to provide live data to an ELMS management station. Live data describes a permanently odd communications connection. 3.3.2 provide offline log data. Describes the case when the ELMS device is not sharing a live data connection with the management station but is instead storing data offline for periodic retrieval by the management station. 3.3.3 monitor exceptional conditions, describes the ability and capability of the ELMS device to communicate exceptional conditions to an ELMS management station.

James Frazer: Section 3.4 functional requirements. This slide provides the top level outline for the functional requirements. As with many NTCIP standards, most of the requirements have been divided into three groups representing system configuration, system control as in for an ELMS time-based schedule and plans, and system monitoring. It should be noted that the actual organization is not very important. What is important is the traceability to use needs and we will go through these presentations later in the presentation. 3.4.1 configure ELMS device is a functional requirement. It specifies the information exchanges between a management station and an ELMS device to support the configuration of that ELMS device. 3.4.2 control device specifies the information exchanged between the management station and an ELMS device for the purposes of controlling the ELMS device. 3.4.3 monitor device status, specifies the information exchanged between the management station and the ELMS device for purposes of monitoring the ELMS device.

James Frazer: The next section is 3.5. supplemental requirements. This slide provides the top level outline for the supplemental requirements. 3.5.1 includes dependent requirements, 3.5.1.1. support a number of actions, 3.5.1.2 support a number of day plans, and 3.5.1.3 perform an action at a scheduled time. 3.5.2 supplemental requirements for zones includes the dependent requirements of 3.5.2.1 define the number of zones supported by ELMS device. 3.5.2.2, define the number of ELMS devices included in a zone. 3.5.3 requirement supplemental requirements for dim levels includes dependent requirements for defining a dim level as a percentage of maximum brightness. 3.5.4 supplemental requirements for event logs includes the dependent requirements for configuring the number of events in an event log, configuring a number of event classes and configuring the number of event types. 3.5.5 includes a number of dependent requirements for managing live data response times.

James Frazer: With that it's time for the next quiz. Which of the following is not a major group of requirements in NTCIP 1213. The answer choices are A, configure an ELMS device, B, control a device, C, monitor device status, or D, backwards compatibility requirements. Please read the question, read the answers and select the appropriate answer…

James Frazer: Let's review our answers. D is the correct answer. As the first published version of the NTCIP 1213 standard, this version does not have any backwards compatibility issues with which to deal. Configuring an ELMS device A is incorrect. These requirements provide for configuring ELMS devices. Similarly B is incorrect because these requirements do provide for controlling an ELMS device. And C is incorrect because these requirements do provide for monitoring alarms and device statuses.

James Frazer: Now we shall examine the fifth column of the PRL The fifth column defines the conformance for the user need or requirement referenced by the row. The "M" in this column stands for mandatory. The "O" stands for optional. Mandatory means that the item must be supported by any implementation that claims conformance to the next higher hierarchical item. Optional alternately means that the item does not have to be supported to claim conformance to the next higher hierarchical item. For example if an implementation claims conformance to retrieve luminaire information, it must support the retrieve luminaire location, retrieve luminaire mode, and retrieve vendor information requirements. But it does not have to support the retrieve luminaire poll identifier or retrieve luminaire zone. The retrieve luminaire information user need is a top level user need. In essence there are no higher level needs with this conformance statement. Therefore its higher level item is the standard itself. Conformance also has an "O" an optional entry with numbers following it. You'll notice that in this example. In addition to the basic "M" and "O" options the conformance column may indicate an option group by indicating an "O" followed by a decimal point and then the option group number, then followed by a parenthetical phrase that defines the rules for the option group. The parenthetical phrase indicates the minimum and maximum number of items that must be selected from the group.

James Frazer: For example this slide shows four user needs with the conformance of "O.X" with a "1" in parenthesis. This means that one or more items from this option group must be selected in order to claim conformance. Please note that there is an error in this standard and this representation on this slide. Following the "O" in each of the functional requirements columns there should be a "1". A "1" in that location means that only one of the four function requirements needs to be selected. This will be corrected in the next version of the standard. The sixth column allows a user to indicate what an implementation supports or what a project requires. For example, a manufacturer can use the table on a project specification sheet to indicate exactly which items are supported by their standard product. Similarly an agency can use the table to indicate the items that they want included for the project. The support column only allows a selection of "Yes" for mandatory items, while optional items allow for a selection of "Yes" or "No".

James Frazer: The final column allows the user to indicate additional project requirements and or notes. Standardized PRLs contain text in this column when the developers of a standard believe in the specification of a requirement is important but it cannot necessarily be standardized across all projects. This is also the case of performance requirements. Let's examine additional projects requirements in terms of performance criteria. Notice that in this example the user can enter a response time into the field pictured in the slide. This requirement is described by 3.5.5.1 which states live data response time the ELMS device shall process the data request in accordance with all of the rules of the NTCIP 1103 version two which stipulates that if the SNMP agent does not specify the maximum response time, the maximum response time shall be 100 milliseconds plus one millisecond for each byte in the response variable bonding list. The project provides the requirement for a more stringent maximum response time for the device, and supersedes this requirement if it is less than the maximum response time stipulated by NTCIP 1103. So in this example we would enter our maximum response time in the red box. And here we have selected "125" milliseconds.

James Frazer: Let's summarize learning objective two. In learning objective two we used the PRL to specify the standardized structure requirements. We properly traced user needs to requirements and within the PRL we selected a given range of performance.

James Frazer: Learning objective three, how to include the requirements for the PRL in the specification. The PRL facilitates inclusion of ELMS technology into the larger big picture control networks. This big picture includes the positive impacts of the SEP process over the entire life cycle of the system. It can be thought of as the life-cycle benefits that includes vehicle-to-infrastructure communications, and smart grid functionalities such as dynamic response for control of electrical loads on the grid. These loads not only include lighting, traffic signals, D.M.S. signs, but are beginning to include electrical vehicle charging stations. So as we work through objective three, we'll examine how to compare and contrast the vendor PRLs for an off-the-shelf interoperability analysis. We'll delve into the big picture in explaining how ELMS fits in with the smart grid and vehicle to infrastructure communications, we'll take a detailed look at smart grid infrastructure, we'll properly trace user needs to requirements, and we will create a project-specific specification. We'll examine overview, contents and other considerations.

James Frazer: We have now gone over all the rules for traceability conformance. Our next task is to go through the entire PRL for a sample project and see what the end result might look like. We'll use the same case studies that we used in the prerequisite module A306a. As we go through this example, it's important to remember that as we look at the mandatory and optional objects and circle the "Yes"s and "No"s that a completed PRL is included in the student supplement so I urge all viewers of this presentation to take a look at that after you've completed this course.

James Frazer: In our example today we'll be using a Washington State Department of Transportation case study. The user needs identified by the state D.O.T. included the ability to control lighting system lumen output by current ambient light level essentially adaptive lighting. The user needs include: controlling lighting fixtures by zones and branch circuits, configuring branch circuits into alternate zones, configuring, controlling, and monitoring these branch circuits, configuring and reconfiguring schedules for branch circuit zones, reporting exceptional and dangerous conditions in a near real-time basis., and overriding schedules as required. These are some of the basic major user needs for this case study and we'll be examining many of these in detail moving forward.

James Frazer: Just as importantly these user needs did not include the ability to configure, control, or monitor luminaires, electrical services, ground fault equipment, arc fault equipment, or provide smart grid information to the local electrical utility. We have now gone over the rules for traceability and conformance. Next we'll go through the entire PRL for this sample project and we'll see in the student supplement what the end result will look like. We'll first examine the operational user needs commencing a 2.4.1 of the PRL. Many of these user needs were derived from the examples we first presented in course A306a.

James Frazer: Using the project's specific needs for our Washington State D.O.T. example, let's examine the rows of the PRL In 2.4.1.1 provide live data, this allows the management system to monitor and control the device by issuing requests. Requests to access information, alter information, or control the device. In this environment the device responds to requests from the management station immediately through the provision of live data, through success or failure notice of information, or success and failure of the command. So the first user need we encounter is the mandatory need to provide live data. All the requirements that trace to this user need are marked mandatory so these are required for our project.

James Frazer: The next row in the PRL is provide offline log data, 2.4.1.2. Some operational environments do not always have on connections. They might have dial-up links. In such environments a transportation system operator may wish to define conditions under which the data is placed in a log which they can then be uploaded at a later time. For example, the operator may wish to manage the ELMS device so that it autonomously maintains a log whenever a specific luminaire is turned on or off. Our Washington State example project requires offline log data, so we shall circle "Yes".

James Frazer: The second user need that we encounter in a PRL is the optional need to provide offline log data. All of the 11 requirements that trace this user need are marked mandatory. So we will select all of these.

James Frazer: Provide luminaire switch state logging, 2.4.1.2.1. The management station may need to configure the ELMS device to keep a local log of an occurrence when the switch state for luminaire changes. This is an optional need. It's optional and it's not required for our project so we shall circle "No".

James Frazer: 2.4.1.2.2, provide luminaire lamp condition logging. The management station may need to configure the ELMS device to keep a local log of an occurrence when a lamp condition changes, when it becomes cycling or inoperable. This is optional, it is not required for our project so we shall select "No".

James Frazer: Provide luminaire burn condition logging, 2.4.1.2.3. The management station may need to configure the ELMS device to keep a local log of an occurrence when the burn condition changes i.e. when the lamp turns on or off. Again this is optional and not required for our project so we shall select "No".

James Frazer: Provide periodic luminaire burn time logging, 2.4.1.2.4. This is needed to configure the ELMS device to keep a local log of periodic measurements of the monthly burn time and the monthly expected burn time. It's optional and is not required for our Washington State Project so we shall select "No".

James Frazer: Provides Luminaire temperature logging, this allows the ELMS device to keep a local log of an occurrence when the measurement of a luminaire temperature is above or below specified values. This need is very important for newer L.E.D. street lighting fixtures whose life and light output is directly related to the amount of time spent running at a certain temperature. The higher the run time temperature, the faster the degradation. For our project this is not required. It is optional so we shall select "No".

James Frazer: Provide periodic luminaire pole condition logging. This allows the ELMS device to keep a local log of an occurrence when the pole condition changes, i.e. when the pole is knocked down. This user need is optional. It's not required for our project so we shall select "No".

James Frazer: Provide relay switch state logging. This allows the ELMS device to keep a local log of an occurrence when the switch state for a relay changes. This user need is optional. It's not required for our Washington State project so we shall select "No".

James Frazer: Provide power meters for state logging. This allows the management station to configure the ELMS device to keep a local log of an occurrence when the power meter switch state changes. This information can be used by the local utility as part of a standardized smart grid communications platform. This user need is optional. It's not required for our project so we shall select "No".

James Frazer: Provide periodic power meter measurement logging. The management station may need to configure the ELMS device to keep a local log of periodic measurements of the voltage, current, power, and energy. This information can be used by the local utility for smart grid implementation. This user need is optional. It's not required for our project in Washington State so we shall select "No".

James Frazer: Provide power meter condition logging. The management station may need to configure the ELMS device to keep a local log of an occurrence when the power meter condition changes. This information can also be used by the local utility for a smart grid implementation. It's optional, it's not required for our Washington project so we shall select "No".

James Frazer: Provide ground fault switch state logging. The management station may need to configure the ELMS device to keep a local log of an occurrence when the switch state for a ground fault detector changes. This can be used as part of a smart grid implementation and is very important for safety issues. It's an optional user need, it's not required for our project, so we shall select "No".

James Frazer: Provide periodic ground fault measurement logging. This allows the management station to configure the ELMS device to keep a local log of measurements of ground fault leakage occurring. This user need is optional. Is not required for our project, so we shall select "No".

James Frazer: Retrieving log data, 2.4.1.2.13. The management station may need to retrieve log data from the ELMS device. This user need is mandatory, thus it is required for our project.

James Frazer: 2.4.1.3 Monitor exceptional conditions. In some operational environments it may be desirable to have the device automatically transmit data to the management station when certain conditions occur. Under this scenario the transportation system operator can define conditions under which notification occurs. And the ELMS device will automatically notify the management station when that condition does in fact happen. This user need is optional but is required for our project. Notice that by selecting "Yes" dependent requirements then become mandatory for our project.

James Frazer: Next we'll examine the features section of the PRL commencing at user need 2.4.2. Section 2.4.2 describes the essential data communication functions and message elements to be supported by the interface. 2.4.2 starts the features section and again we'll continue using the project specific needs for our Washington State D.O.T. example project as we move through the PRL

James Frazer: Configuring an ELMS device, 2.4.2.1. A management station that is monitoring or controlling the ELMS may need to retrieve information about the configuration to properly communicate with the device. The management station may also need to alter the configuration of the device to produce expected operations. This user need is mandatory, thus it is required for our project.

James Frazer: Configuring luminaire. A management station that is controlling the ELMS device may need to manage the configuration of the connected luminaires, the lighting fixtures. The following subsections describe the luminaire configuration features needed.

James Frazer: Retrieve luminaire information, 2.4.2.1.1.1. A management station may need to retrieve basic information about the luminaire such as its pole identifier, location, mode of operation, zone, and vendor information. This user need is mandatory and is required. Notice that while this user need is mandatory, it is not applicable to our project. This is an error in the standard. In future versions 2.4.2.1.1.1 retrieve luminaire information will be optional with the choice of yes or no. Using the current version of the standard, we shall select "No" for the optional user needs that are not required for our project.

James Frazer: Configure luminaire identification information. Using the project-specific needs for our Washington State D.O.T. project, let's examine configure luminaire identification information. 3.4.1.1.2.1 specify location in latitude and longitude is not required for our project so we shall select "No". Specify location information using textual description of a road street block is mandatory. Additionally we need to define the length of the text field for this descriptor, thus we shall enter "255" in the appropriate area. Specify location in the local reference coordinate grid as well as configure luminaire pole identifier are not required for our project so we shall circle "No" for both of these.

James Frazer: Configure luminaire mode. A management station may need to configure the mode in terms of on, off, schedule, or light activated operation for luminaire. This user need is mandatory thus it is required for our project.

James Frazer: Configure electrical service. A management station that is controlling an ELMS device may need to manage the configuration of the electrical service. The following sections describe the electrical service configuration features needed. This information can be used by local utilities for smart grid implementations. This user need is optional, but it is required for our project so we shall enter "Yes" in the project requirements column.

James Frazer: Retrieving electrical service information. A management station may need to retrieve basic information about the electrical service such as its location and pole identifier. This information can also be used by the local utility for smart grid projects. This user need is optional, is not required for our project, so we shall enter "No" in the project requirements column.

James Frazer: Configure for light-activated operation. A management station controlling an ELMS may need to configure a luminaire or a service, branch circuit or zone for operation based on ambient light levels. This user need is optional but is required for our project so we shall enter "Yes" in the project requirements column. We do not require in our project control by electrical service, so we shall enter "No" there. Notice as our project involves controlling lighting by branch circuits and branch circuit zones, we do enter "Yes" in those areas. Configuring for scheduled operation. A management station controlling an ELMS may need to configure a luminaire, electrical service, branch circular zone to operate on a schedule to turn on, off, or dim. This user need is optional. It is required for our Washington State project, so we shall enter "Yes" in the project requirements column. 3.4.1.4.1, configure luminaire for scheduled operations is required for our project. We shall enter the appropriate response in that field. 3.4.1.4.2 configure electrical service for scheduled operations is required so we shall enter "No". Configure branch circuit for scheduled operations is required so we shall enter "Yes". 3.4.1.4.4 configure devices in zone for scheduled operations is required so we shall enter "Yes".  So notice in this example 2.4.2.1.4 configure for schedule operation is optional. Scheduled operation is required for our project so we selected "Yes". The first two options configure luminaire for schedule operations and configure electrical service are not required for our project so we selected "No" for both of those. We do require configuring branch circuits for scheduled operations and configuring devices for scheduled operations so both of those are "Yes". The remaining three are mandatory so they are included in our project.

James Frazer: Configuring zones. A management station controlling an ELMS devices may need to configure the zones which the luminaire branch circuit or electrical service belongs. This user need is optional but it is required for our project so we shall answer "Yes" in the project requirements column. 3.4.1.5.2, configure electrical service zone is not required for our project so we shall enter "No" there. Additionally since 3.4.1.4.3 configure branch circuit zones is required we will enter "Yes" in that area.

James Frazer: Configuring for manual operation. The management station controlling an ELMS may need to configure the device to support manual operations. Examples are configuring an ELMS device to support manual operation of luminaire, electrical service, branch circuit or zone. This user need is mandatory, it is required for our project. 3.4.1.8.2 is not required for our project so there we shall enter a "No". However 3.4.1.8.3 and 3.4.1.8.4 configure branch circuit for manual operation and configure devices in zone for manual operation are both required for our project so there we shall enter a "Yes" in both areas.

James Frazer: Configuring a stagger interval. A management station controlling an ELMS may need to alter the interval at which luminaires, circuits, services, are staggered in operation. This is used to minimize in rush occuring. This user need is optional, not required for our Washington State project so we shall enter "No".

James Frazer: Configuring dim levels. A management station controlling an ELMS may need to configure a luminaire to set dim levels or a management station may need to adjust light output levels of all luminaires on a circuit or assigned to a zone by adjusting power levels supplied to the circuit. This user need is optional, is not required for our project, so we shall enter "No" in the project requirements column.

James Frazer: Configuring electrical service monitoring meter and equipment. Again using the project specific needs for our Washington State D.O.T. example project, let's examine configuring sensors and meters. A management station may need to calibrate sensors and meters associated with the service. This information can also be used by the utility for a smart grid implementation. It's optional, not required for our project, so we shall enter "No".

James Frazer: Configuring branch circuits. The management station controlling the ELMS device may need to manage the configuration to branch circuit. It's optional but is required for our project so we shall enter "Yes" in the project requirements column. This parent user need and the child user need 2.4.2.1.10.1 is addressed in the next slide.

James Frazer: Retrieving branch circuit information. The management station may need to retrieve basic information about the branch circuit such as location, pole identifier and zone. This user need is optional but it is required for our project so we shall enter "Yes" in the project requirements column. Similarly dependencies are all required. Retrieve branch circuit zone, retrieve branch circuit location, and retrieve branch circuit pole identifier. So we shall place "Yes" in all of those rows.

James Frazer: Configure the branch circuit. The management station we need to configure a branch circuit for location pulse status. It's optional in the standard but is required for our project so we shall enter "Yes" in the project requirements column. The dependent requirements configure branch circuit location and configure branch circuit pole identifier are both required for our project. So we shall circle "Yes" for both needs.

James Frazer: Controlling a device. Section 2.4.2.2 describes the major categories of services the management station may need to use to control ELMS device. This user need is mandatory. It is required for our project. It is a parent user need. The dependent child user needs are described in the following slides. 2.4.2.2.1 control luminaire, the management station may need to control a luminaire by turning it on or off either directly, individually, or in a staggered mode. It may also need to control the luminaire to allow or disallow a schedule control by one of three states: continuous control, transitory control, or time control. Well the user needs 3.4.2.1.2, 3.4.2.1.3, and 3.4.2.1.4 are all optional and are not required for our project. So we shall enter "No" for these.

James Frazer: Controlling electrical service. A management station controlling electrical service may need to control it directly by enabling or disabling the stagger mode for branch circuits served by the electrical service. It may also control the electrical service by allowing or disallowing a variety of control states: continuous control, transitory control, and time control. This user need is optional. It's not required for our Washington State project, so we shall enter "No" in the project requirements column.

James Frazer: Control your branch circuit. The management station may need to control the branch circuit directly or in a staggered mode of operation. Again three states are of control are optional, continuous control, transitory control, or time control. It is required in our project, thus we shall select "Yes" for control branch circuit, "Yes" for control branch circuit by transitory override, "Yes" for control brand circuit by timed to override, but we do not need stagger mode in our implementation. So we shall select "No" there.

James Frazer: Controlling devices by zone. A management station may need control multiple ELMS devices by a zone by minimizing data exchanges. Instead of controlling ten luminaires and five brand circuits, the management station can control one zone in which those ten luminaires and five branch circuits belong. This management station may need to control the ELMS devices configured in the zone to allow or disallow scheduled control by one of the three states we reviewed previously. In our example, zone control is required so we shall select "Yes". Controlling devices in a zone by transitory override is required so we shall select "Yes." And controlling devices in a zone by timed override is required so we shall also circle "Yes" there.

James Frazer: Monitoring device status. A management station needed to monitor the ELMS device for status at various subsystems. This user need is mandatory, it is required, so "Yes" is in the project requirements column. This is a parent need, the dependent child needs are examined in the next few slides.

James Frazer: Monitoring a luminaire. A management station may need to monitor the luminaire for status of various features of a luminaire. This user need as well as 3.4.3.1.1 is mandatory, thus it is required for our project. "Yes" is already in the project requirements column. The other user needs are all optional and are not required for our project so we shall enter a "No" in each one of them.

James Frazer: Monitoring the electrical service. A management station may need to monitor the electrical service for a status of various features including a status on branch circuits. This user need is optional, it is not required for our Washington State project so we shall enter "No" in the project requirements column.

James Frazer: Monitoring the branch circuit. A management station may need to monitor the branch circuit status for various features. This user need it optional but is required for our project so we shall enter "Yes" in the project requirements column. Retrieve branch circuit breaker status, retrieve branch circuit operational status, retrieve branch circuit hours, are all required for our project so we shall also enter "Yes" in those fields as well. Notice that retrieve branch circuit power ratings are at fault status and ground fault status are not required for our project so in those fields we entered "No".

James Frazer: Supplemental requirements are additional requirements derived from the concept of operations and do not fall into categories. The requirements as in requirements related to the data contained in an inventory report. We'll be examining them, the supplemental requirements in detail in the next few slides.

James Frazer: Supplemental requirements for scheduled operations include supporting a number of actions. The ELMS device shall support a number of actions as defined in the additional project requirements column in the PRL If the additional project requirements column in the PRL does not define the number of actions, the ELMS device shall support at least two actions. Note: if an action is defined as a unique command that might be called on by a day plan event. For example, turning on a luminaire is an action. Turning off a luminaire is a second action. In our example where we require the maximum is 255 actions so we've entered that in the field. 3.5.1.2, supporting a number of day plans. A management station shall be able to define the number of day plans in the ELMS device to be used to control scheduled operation of the device defined in the additional project requirement in the PRL If the number of day plans is not defined in the PRL the ELMS device shall be able to support at least one day plan. In our project we require 255 day plans so we've entered "255" into the appropriate column. 3.5.1.3 perform action the scheduled time. The ELMS device shall perform the actions configured in the events of the day plan schedule at the times identified. That's mandatory and will be included in our project.

James Frazer: Supplemental requirements for zones include defining the number of zones supported by an ELMS device. It's optional, it is required in our projects so we shall select "Yes". And additionally we are required to choose a number of zones for our project specific implementation. So in this case we've chosen "999" for our example project. 3.5.2.2, defining the number of ELMS devices allowed to be included in the zone is also required in our project specific implementation so we circled "Yes" and we require at least 100 ELMS devices shall be able to be assigned to a single zone so we entered "100" into the appropriate field.

James Frazer: Supplemental requirements for dim levels. 3.5.3.1, defines dim level as a percentage of maximum brightness. This is measured in lux. It is not required for our project so we select a "No". Supplemental requirements for event logs, 3.5.4.1. Configure the number of events in the event log. A management station shall be able to configure in the ELMS device the maximum number of events that can be stored in a log. That is required for our projects, and we entered "255" events. Configure number of event classes. A management station shall be able to configure a maximum number of event classes to be used in an event logging service for the ELMS device. That's required so we circled "Yes". And we entered "255" because our project requires 255 classes. 3.5.4.3 configure number of event types. The management station shall be able to configure the maximum number of event types logged for the ELMS device. This is required for our project, and our project requires 255 event types so that's what we've entered in the field in the right column.

James Frazer: Live data response time. The ELMS device shall process the data request in accordance with all the rules of the NTCIP 1103 which stipulates that if the maximum response time is not specified it shall be 100 milliseconds plus one millisecond for each byte in response variable-bindings list. The project column here provides a requirement for a more stringent maximum response time for the device. And supersedes the requirement if it is less than a maximum response time stipulated by NTCIP 1103. So here we enter "152" milliseconds.

James Frazer: Using the PRL in a specification. A completed PRL defines the requirement for the NTCIP interface. A deployment may need multiple interface specifications, management systems that support multiple devices, each ELMS device may have differing sets of optional objects. And it also may need support for legacy protocol for systems that are not NTCIP compliant. The completed PRL defines the requirements for the NTCIP interface.

James Frazer: Comparing and contrasting vendor PRLs for off-the-shelf for interoperability analysis. Once your project-specific PRL is complete, you can use it to determine if off-the-shelf solutions from vendors are available, which vendor products fit your application best, whether custom development if any is required, and which vendor products are interoperable and exactly which features are interoperable.

James Frazer: Consistency. The interface specification must be consistent with the remainder of the specification. The ELMS standard NTCIP 1213 is the interface specification. A full project specification including the hardware specification and the software specification.

James Frazer: Using the PRL specification. The PRL should be properly introduced within the specification, the copyright disclaimer should appear with the PRL, and I would urge all students to refer to the student supplement for guidance on wording used to introduce the PRL as well as the completed PRL from our example project in the earlier section.

James Frazer: It's now time for our next quiz. Which choice is not a functional requirement contained in the NTCIP 1213 PRL? A, retrieve luminaire location, B, configure luminaire mode, C, configure branch circuit zone, or D, retrieve wiring particulars? Please choose the correct answer

James Frazer: Let's review our answers. The correct answer is D. NTCIP does not support retrieval of wiring particulars. A is incorrect because retrieve luminaire location is a functional requirement of NTCIP 1213. B is incorrect because configure luminaire mode is also a functional requirement of NTCIP 1213. And C is incorrect because configure branch circuit zone is also a functional requirement of NTCIP 1213.

James Frazer: Summarizing learning objective three, how to include requirements from the PRL and specification. We demonstrated how to compare and contrast vendor PRLs for off-the-shelf interoperability analysis. We explained how ELMS fits in the smart grid infrastructure architecture. We properly traced user needs to requirements. And most importantly we created a project-specific specification. We examined the overview, contents and considerations and that completed PRL is included in the student supplement for your review.

James Frazer: Learning objective four. Explaining how interoperability is achieved through the requirements traceability matrix. We'll be examining the source requirement and how it is selected in the RTM We'll be explaining the link to dialogs objects and block objects. We'll learn how dialogs and messages in the RTM are communicated to the field device using Simple Network Management Protocol, SNMP We will be providing a complete description of how a specification needs to be created to support and a complete end-to-end example. And we'll provide an in-depth example of how monitoring of ELMS systems work.

James Frazer: Using the Requirements Traceability Matrix. How the RTM traces to a single design. Annex A contains the RTM, you should examine that after the course is complete. The RTM maps requirements to a specific design. And the next few slides will be examining how to compare for interoperability and for interchangeability.

James Frazer: The first column of the RTM is the requirement I.D. It's the numerical representation of the I.D. The second column is the textural definition. In this example we are using configure luminaire for light activated operations and configure electrical service for light activated operations. The third column is the dialog I.D. The fourth column is the textual definition of the dialog. The fifth column is the object I.D. Some of these dialogs will refer to multiple objects. In these cases every object shown must be supported to claim support for the dialog unless otherwise indicated.

James Frazer: Column six is the object column. Some of these dialogs again will refer to multiple objects. Every object must be supported to claim support for the dialog again unless otherwise indicated.

James Frazer: Summarizing the Requirements Traceability Matrix. It maps each requirement to one specific design. It is a concise unambiguous dialog. It is a precise unambiguous list of objects. All of the objects must be supported if the requirement is supported.

James Frazer: How to use the RTM to compare for interoperability? The RTM provides interoperability requirements whereas the PRL indicates which requirements are to be supported. Comparison of PRLs allow for quick determination of interoperability. Thus by comparing and contrasting supported requirements, this slide describes how a user could compare two PRLs to see if an ELMS could be interoperable with the central management system.

James Frazer: This slide introduces interoperability and interchangeability. Notice that NTCIP as we discussed previously is a communications interface between data objects in the management center and data objects in field devices. For interoperability, a user can compare two PRLs to determine if the new piece of equipment is interoperable with the management center. If both the transportation management center and the ELMS supports a feature, interoperability is provided. If the T.M.S. supports that feature but the ELMS does not, the T.M.S. can still use other features. The T.M.S. can also still interoperate with that feature with other devices. If the ELMS supports the feature but the T.M.S. does not the feature could be used by an upgraded or future T.M.S. or the feature can potentially be used manually.

James Frazer: For interchangeability if PRLs both support a feature the equipment is interchangeable feature for feature. If the new equipment supports but the old one does not, the new equipment is interchangeable because it meets or exceeds the older equipment. If the old equipment supports but new ones do not, the feature would not be supported. In an instance such as this, the system designer, the users need to question whether the future is required.

James Frazer: It's time for our next quiz. What does the following table mean? Answer A, is all of the objects must be supported. B, at least one of the objects must be supported. C, all of the objects must be supported if the requirement is supported. Or D, at least one of the objects must be supported if the requirement is supported.

James Frazer: Let's review our answers. C is correct. All of the objects must be supported if the requirement is supported. A is incorrect because the objects must be supported only if the requirement has been selected in the PRL B is incorrect because if the requirement is selected, all of the objects must be supported. And D is incorrect similar to B because if the requirement is supported, all of the objects must be supported. NTCIP 1213 dialogs. The image shown in this slide is a basic dialog between the Traffic Management Center and the Electrical and Lighting Management System. The image describes a simple get request. Many dialogs are a simple get or set command coupled with a response. Notice that in this example the management station is getting a variable binding list. Request and response.

James Frazer: This slide describes the set commands using configuring a schedule. To configure a schedule, schedule actions, schedule day plans, and time-based schedules need to be defined in the ELMS device. This is accomplished through use of the set command that writes data to the ELMS device from the management station. In the first example of the three the management station is configuring scheduled items through the set command. In the second example the management station is configuring day plans to a set command. And in the final example, the management station is configuring a time-based schedule through the set command. NTCIP 1213 dialogs, all dialog objects are listed in the RTM

James Frazer: Summarizing learning objective four. We explained source requirements and how they are selected in the RTM. We examined links to dialogs, objects, and block objects. We described how a specification is created to support the complete end-to-end example from a user need to the dialog on the wire. And we discussed how monitoring of ELMS is accomplished.

James Frazer: Learning objective five. Examining the benefits of the systems engineering approach. We'll be looking at benefits in developing test plan. Benefits of testing using SEP as well as the benefits to agencies and vendors.

James Frazer: The benefits in developing a test plan are that it verifies that requirements are fulfilled. It reduces the risk of misinterpretation between the agency manufacturers, reduces the risk of financial mismanagement, reduces the risk of a perceived lack of oversight, and ensures interoperability to allow system expansion.

James Frazer: Validation is making sure a system when placed in operation will support agency needs. Verification is making sure a design complies with requirements and that the systems as both proposed and delivered comply with both the design and the requirements. Traceability is a tool to help determine if the agencies requirements are fulfilled by the design and that the implementation was done correctly. Testing is used in the hierarchical format for unit, subsystem, and complete system testing.

James Frazer: Unit device testing focuses on comparing and implementation against standards and the specified options. It may be performed by inspecting the code to using proven software to send test messages to the device. Subsystem testing is an assemblage of unit and devices. It consists of connecting two or more devices together and exchanging data. It assumes that devices and components have passed a design unit test plan as descried above.

James Frazer: System testing is the highest level of testing. It's performed after all lower level testing is successfully completed, it's performed in an operational environment, and it includes final acceptance testing. This is the V model and explains the benefits of testing using systems engineering. Notice the relation between user needs, traceability, and testing in the V model. For more information you can reference the course T101 and the subsequent courses.

James Frazer: Examining the benefits of the SEP approach. It provides the framework and process to verify that the system meets the user needs, improves stakeholder participation, results in more adaptable resilient systems, verifies functionality with fewer defects, it results in a higher level of reuse for future projects, and results in better documentation.

James Frazer: The benefits to agencies using the SEP approach are that users, transportation users, electric utilities, specification developers, can all use testing results to confirm which requirements have been delivered in a project-specific implementation. The protocol implementer can use testing results to confirm conformance.

James Frazer: The benefits to vendors. The suppliers can supply testing data as a detailed indication of the capabilities of their NTCIP 1213 implementation. The user can use his vendor supply and test data as a basis for checking interoperability with other implementations and for seeing which features are available in a vendor-standard product.

James Frazer: Summarizing learning objective five. The benefits of the SEP approach. We discussed the importance of the SEP. We examined the benefits in developing a test plan. We reviewed the benefits to agencies including transportation and electricity specification developers. We reviewed the benefits to vendors.

James Frazer: Learning objective six, extending the standard. We'll examine conditions and context for extending the standard, and how to specify requirements not covered by the standard, by adding missing requirements through best practices, all the while emphasizing user needs and requirements link.

James Frazer: Extending the standard complicates interoperability and interchangeability. It's not achievable unless all design details are known. Extensions are relatively custom solutions. They often result in increased specification costs, increased development costs, increased testing costs, increased integration costs, a longer deployment timeframe, and increased maintenance costs.

James Frazer: Extensions should only be considered when NTCIP features are inadequate to meet the need and the benefits of the extension outweigh the added costs.

James Frazer: Extended equipment should be designed to appropriately integrate with NTCIP only deployments and they should be designed to minimize added complexity.

James Frazer: Next we'll examine an example of how to extend using a custom user need. This example actually is Annex C within NTCIP 1213 version two. Custom needs. A T.M.S. operator needs the ELMS to switch luminaires, circuits and electrical services based on the sunrise and sunset time as calculated by day of year and latitude, longitude. This feature allows ELMS to ensure these conditions are managed daily.

James Frazer: Thus the ELMS X.2.1 Configure Astronomical Control is created as well as X.2.2 Monitor Astronomical Control. This slide identifies the two different requirements that we trace to this custom user need whose traceability will be shown in the table. The requirements typically include configure, control, and monitoring as we've seen previously. In this example we've determined that we did not have any control requirements for the interface.

James Frazer: It's time for our next quiz question. Which of the following is the best reason to extend the NTCIP 1213 Standard? A, there is an unmet need that justifies the item cost. B, the existing system uses a nonstandard method, C, you want to use your specification to favor a specific vendor, or D, when the standardized solution is overly complex for your simple needs. Please select the correct answer…

James Frazer: Let's review our answer. A is correct. There is an unmet need that justifies the added cost. Sometimes you just have to accept the added cost when you're extending a standard. B is incorrect. If the existing system uses a nonstandard method doing this will prolong the expensive customized approach for another generation or products and solutions. C is incorrect because this can trap you to into a proprietary solution. D is incorrect because some NTCIP features are complex to allow flexibility but the cost of custom solutions far outweigh any cost due to the complexity of NTCIP 1213.

James Frazer: Summarizing learning objective six. We discussed specifying requirements that are not included in the standard. By adding missing requirements identified through best practices and by emphasizing the user need requirements link.

James Frazer: What we have learned today. The components of the standards include user needs requirements, dialogs, the Protocol Requirements List, and the RTM, the Requirements Traceability Matrix. Number two, dialogs and messages in the RTM are communicated to the field device using SNMP, Simple Network Management Protocol. Number three, the protocol implementer can use testing results to confirm conformance to NTCIP 1213 as a benefit to agencies. Number four, the RTM traces a requirement to a single design solution thereby providing unambiguous interoperability.

James Frazer: For more information I would urge viewers of this presentation to consider these resources, the Systems Engineering Handbook, the Systems Engineering Guidebook, the NTCIP Guide, version 2.0 of the NTCIP 1213 Standard, and the A306b participant student supplement that has a completed PRL for the example project we discussed.

James Frazer: Questions. A few questions have come in during the presentation. The first is "Can you describe adaptive roadway lighting?" Adaptive roadway lighting is a design concept that has come into fruition in the United States and many other areas. It involves the input of road-based users: pedestrians, bicyclists, and motor vehicles as well as environmental inputs such as ambient lighting levels and road conditions to dynamically alter light levels. It includes support for vehicle-to-infrastructure communication as well as the larger, bigger picture smart grid. Question two, "How does NTCIP 1213 integrate with V2I, vehicle-to-infrastructure communications?" In the near future vehicles will broadcast a wide range of information to other vehicles and to equipment located on the roadside such as traffic signalization equipment, and roadway lighting systems. This data will be used to control traffic signals, roadway lighting levels and other parameters of the roadway using NTCIP Intelligent Transportation System Communication Protocols. Question number three, "Can you expand on smart grid support?" The U.S. Department of Commerce and the National Institute of Standards in Technology refer to NTCIP 1213 in their standards documents. Support can range from simple on-off load control to the support of an energy services interface which provides the electrical utility with detailed information regarding the forecast of future electrical and other energy use. "Where have NTCIP systems been installed?" Many states, counties and cities have installed NTCIP 1213 compliance systems. These include the Departments of Transportation in Minnesota and Washington State, Miami-Dade, and Sterns County, as well as smaller cities such as Saint Cloud, Minnesota. "What other resources are available to learn about roadway electrical and lighting technology?" In addition to the range of ITS. PCB. courses the Illuminating Engineering Society of North America publishes the Design Guide for Roadway Lighting Control Systems. Furthermore the International Municipal Signal Association offers two sixteen-hour courses on the specifics of roadway lighting system selection, installation and maintenance.

James Frazer: That concludes our presentation today. And I would like to thank everyone for coming and viewing and I hope this was a very productive session. I urge you to view the prerequisites, and also to examine the student supplement that accompanies this course. Thank you very much for attending.

#### End of A306b_Edited.mp4 ####