Module 27 - A306b

A306b: Specifying Requirements for Electrical and Lighting Management Systems (ELMS) Based on NTCIP 1213 Standard v03

HTML of the Course Transcript

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

Ken Leonard:
ITS standards can make your life easier. Your procurements will go more smoothly and you'll encourage competition, but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems.

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

James Frazer:
Welcome to A306b, Specifying Requirements for Electrical and Lighting Management Systems (ELMS) Based on the NTCIP 1213 standard Version 03. The purpose of this updated module is to incorporate necessary changes resulting from new user needs and capabilities—such as connected vehicles, the Smart Grid, and others included in the updated NTCIP 1213 standard Version 03, updated from Version 02—and to also assist technical staff in specifying clear requirements from the list of requirements that exists in the NTCIP 1213 Version 3 standard, and to meet identified project-specific user needs.

James Frazer:
I'm Jim Frazer. I'm your instructor today. I'm deeply involved in the convergence of energy, lighting, and transportation. Within the ITS domain, I play a significant role in the development of U.S. DOT adaptive lighting standards, as well as Smart Grid standards being developed by the National Institute of Standards and Technology and the Illumination Engineering Society. I've held a variety of positions at development and consulting firms, as well as startup organizations in high technology, and I've been involved in, proposed, engineered, and managed large commercial and governmental projects in the U.S. and Europe. I'm currently the Vice Chair of the Illuminating Engineering Society's Roadway Lighting Committee.

James Frazer:
Our learning objectives for today include reviewing the structure of the NTCIP 1213 Version 03 standard, using the Protocol Requirements List and then the Requirements Traceability Matrix to specify the standardized structure of requirements. We will examine how to include the requirements from the PRL and the RTM in an ELMS Communications Interface specification. And, lastly, we'll explain conditions and the context for extending the standard beyond Version 03.

James Frazer:
Learning Objective 1: reviewing the structure of the NTCIP 1213 Version 03 standard.

James Frazer:
We will begin by identifying components of the standard—the Concept of Operations, requirements, dialogs, and the Management Information Base, the Protocol Requirements List, and the Requirements Traceability Matrix. We will focus on requirements—functional, architectural, and data exchange requirements. We'll discuss the relationships to user needs from A306a, and we'll take a brief review of the user requirements step. The structure of NTCIP 1213 Version 03. Section 1 is termed “General.” It's the introduction. Section 2, the Concept of Operations, includes all the textual descriptions of the user needs. Section 3 describes the functional requirements. These are the measurable, unambiguous requirements that you will include in your project. Section 4 describes in detail, unambiguously, the dialogs—the actual code and syntax—that's within the Management Information Base. Section 5 describes that Management Information Base in detail. Annex A includes the Requirements Traceability Matrix—which we'll get into in a short while—Annex B is the Object Tree, and Annex C is Test Procedures.

James Frazer:
The capabilities of NTCIP 1213 Systems. They control and monitor terminal devices on the roadway for roadway lighting, ground fault safety and arc fault safety, and revenue grade power metering. Those first three were resident in Version 02. The following are resident in the new Version 03. That's vehicle-to-grid infrastructure, vehicle-to-infrastructure (V2I) communications, support for the electrical distribution network known as the Smart Grid, and support for electric vehicle charging infrastructure.

James Frazer:
This slide is a graphic of basically the three physical components of a system. There's a Management Center with the workers. It could be located at a public works department or a state DOT. There's an optional gateway that may or may not host the NTCIP 1213 Version 03 interface. Or that NTCIP 1213 Version 03 interface could also reside directly in the field devices. Thus, those communications—the NTCIP 1213 communications—can be between the Management Center and the gateway, or directly to the field devices as shown by the two yellow arrows. This slide describes the larger transportation ecosystem in which the NTCIP 1213 Version 03 ELMS operates and shows which interfaces are addressed by the standard. Notice that NTCIP 1213 is a center-to-field communication standard and it is part of the larger ITS ecosystem.

James Frazer:
This slide graphically represents a Management Center and a number of field devices. A bi-directional arrow representing NTCIP communications connects the Management Center to the field devices. Notice that a vehicle-to-infrastructure block is also represented in the graphic. Thus, NTCIP communications can be between a connected vehicle to the field devices, as well as from the Traffic Management Center to the field devices.

James Frazer:
This next slide describes the larger electrical distribution ecosystem in which the ELMS operates, and shows which interfaces are addressed by that standard. This is a U.S. Smart Grid Standards Framework diagram. This National Institute of Standards and Technology Smart Grid conceptual model provides a high-level framework for the Smart Grid that defines seven important domains: bulk generation, transmission, distribution, customers, operations, markets, and service providers. It shows all the communications and energy electricity flows connecting each domain and how they are interrelated. Each individual domain is itself composed of important Smart Grid elements that are connected to each other through two-way communications and energy electricity paths. These connections are the basis of the intelligent and dynamic power electricity grid known as the Smart Grid. This conceptual 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 segments. Notice that NTCIP 1213 facilitates development of this network because it is a connection from the customer—the State DOT, the city, the county—and the distribution network—as well as to markets by providing financial information, to operations, and also to the service provider.

James Frazer:
The structure of the NTCIP 1213 standard. There are missing components of the standard. Most notably, it does not include test cases for compliance testing. These tests and test cases need to be produced for each project. For more on testing, please examine the testing series of courses. It begins with T101: Introduction to ITS Standards Testing; T201: How to Write a Test Plan; T202: An Overview of Test Design Specifications, Test Cases, and Test Procedures; and it concludes with the application-specific T306: Applying your Test Plan to the Electrical and Lighting Management Systems Based on NTCIP 1213 ELMS Standard Version 03.

James Frazer:
This course focuses on functional, architectural, and data exchange requirements. We'll be examining the relationship of user needs for functional requirements.

James Frazer:
User Needs and Functional Requirements. Measurable functional requirements are derived directly from the stakeholder's project-specific user needs. Each of these functional requirements must have an underlying user need and, similarly, each user need must have a dependent functional requirement. These are very important foundational issues that are not only resident in the NTCIP 1213 Version 03 standard, but across all of the center-to-field NTCIP 1200 series standards.

James Frazer:
Let's take a brief review of user needs. User needs are compiled from all stakeholders. It's requested that you query exhaustively all the varying stakeholder communities to compile your list of user needs. These are vehicle drivers, pedestrians, bicyclists, maintenance people, engineers, designers, financial managers. They are the textual representation of what actually needs to be accomplished.

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

James Frazer:
Please read and answer the next question. Which choice is not a capability of the NTCIP 1213 Version 03 standard? Your answer choices are: A) 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) The physical size of electrical cabinets. Please select the correct answer.

James Frazer:
The correct answer is D, the physical size of electrical cabinets. NTCIP does not support sizing of electrical cabinets. A is incorrect because roadway lighting—including scheduling and zoning—is a core capability of NTCIP 1213 Version 03. B is incorrect because safety issues, electrical leakage anomalies—including power quality—and ground fault issues are also a core capability of NTCIP 1213 Version 03. C is incorrect because revenue grade power metering is also a core capability of NTCIP 1213.

James Frazer:
With that, we have concluded the discussion of Learning Objective 1, and we will proceed to Learning Objective 2— using the Protocol Requirements List and then the Requirements Traceability Matrix to specify the standardized structure of requirements.

James Frazer:
Using the Protocol Requirements List and then the RTM to specify the standardized structure of requirements. This allows you to define how you get off-the-shelf interoperability.

James Frazer:
We'll discuss that, within the PRL, selecting a given range of our performance requirements. We'll discuss supporting project requirements, and also conformance to the standard. So how do you get off-the-shelf interoperability by using the PRL?

James Frazer:
The PRL's a table that's a tool included in the standard for use by system developers, agency specifiers, and manufacturers/producers of ELMS equipment. It properly and unambiguously traces user needs to measureable functional requirements. Within the PRL, users select a given range of a requirement, and then the design is implemented—as specified in the standard—in the Requirements Traceability Matrix.

James Frazer:
So let's examine a section of the PRL table. The user needs in the PRL table are in the first column. The first column presents the User Need Identifier, which is the number of the clause within the standard that formally defines the user need. In this example, 2.5.2.1.21 is the user need ID. In Section 2, you can refer using that number and get the textual description of this particular user need.

James Frazer:
In column 2, the second column indicates the name of the user need that is being referenced. Notice the dependencies within this column. 2.5.2.1.21 is the top-level user need entitled “Configure ELMS Device for Adaptive Operation.” 3.5.4.23 is dependent upon that user need, and is entitled “Configure ELMS Device for Adaptive Operation.” Notice that this is one of multiple features. Notice that there are successive dependent features that are related to 2.5.2.1.21.

James Frazer:
So let's examine that user need in a little bit more detail. In Section 2, looking up that user need entitled “Configure ELMS Device for Adaptive Operation.” “A Management Station may need to configure the ELMS device for adaptive operation. Adaptive operation includes adjusting light levels based on ambient light levels, as well as connected vehicle sensor and status information.” That is directly from Section 2.

James Frazer:
Continuing on in the PRL, 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 to multiple user needs will appear multiple times in the table—one time under each user need to which it traces.

James Frazer:
The fourth column indicates the title—the name of the requirement that is being referenced. Let's examine one of those requirements. 3.5.4.23.3: Configure Connected Vehicle Location Setpoint. “The ELMS device shall allow a Management Station to configure the connected vehicle location setpoint from within the ELMS device.”

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 this formal definition provides precise and measurable requirements without defining precisely how they will be achieved. This happens to be an important requirement for it, as you can see, defines support of connected vehicle functions within the NTCIP 1213 Version 03 standard for adaptive roadway lighting applications.

James Frazer:
Project Criteria. Notice that the user can enter a response time into the field pictured in the slide. This requirement is described by 3.5.5.1: Live Data Response Time. So reading from its textual description in Section 3, the ELMS device shall process the data request in accordance with all of the rules of NTCIP 1103 Version 02, which stipulates in Section 3.2.4 that if the SNMP agent does not specify the maximum response time, the maximum response time shall be 100 milliseconds, plus 1 millisecond for each byte in the response variable binding list. This project column 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 Version 02 Section 3.2.4. In this case, we will enter 125 milliseconds into the additional project requirements box.

James Frazer:
Completing the PRL—by compiling your project-specific user needs and examining the dependent measurable functional requirements—you can then select which optional features ought to be required in your particular project-specific implementation.

James Frazer:
Conformance. In addition to the basic mandatory and optional options in the Conformance column, the Conformance column may also indicate an option group by indicating an “O” followed by a decimal point and the option group number, and then be followed by a parenthetical phrase that defines the rules for that option group. This parenthetical phrase indicates the minimum and maximum number of items that must be selected from the group. For example, this slide shows four user needs with the conformance of O.x(1.*). This means that one or more items from each option group must be selected in order to claim conformance.

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

James Frazer:
Which of the below is not a reason to use the Protocol Requirements List—the PRL? Your answer choices are: A) To identify user needs; B) To perform a test for compliance; C) To identify functional requirements; or D) To develop a project-specific specification. Please select the correct answer.

James Frazer:
Let's review our answers. The correct answer is B. Testing is not part of the NTCIP 1213 standard Version 03, but it must be designed and documented for each project. A is incorrect because the PRL does include user needs. C is incorrect because the PRL includes functional requirements. And D is incorrect because the PRL is used to develop a project-specific specification.

James Frazer:
With that, we have concluded Learning Objective 1 and Learning Objective 2. Our next learning objective is including the requirements from the Protocol Requirements List and the Requirements Traceability Matrix in the ELMS Communications Interface Specification.

James Frazer:
Learning Objective 3—including the requirements from the PRL and the RTM in the ELMS Communications Interface Specification. We'll be examining properly tracing user needs to requirements, completing the PRL, and use of the PRL to communicate dialogs and messages with SNMP.

James Frazer:
Properly Tracing User Needs to Requirements. There's a relationship between user needs and functional requirements that we've previously discussed. In order to build a project-specific specification, you will trace the connections between your project-specific user needs. As you encounter optional requirements in the Protocol Requirements List, you will decide whether these are required in your particular project-specific implementation. You will document this by circling “Yes” or “No” in the appropriate row of the Protocol Requirements List.

James Frazer:
Next, we will examine a real-world example. This is our case study.

James Frazer:
Here, we'll be examining using the PRL to build a specification, and this case we're using is the Washington State Department of Transportation Route 520 case. It's the world's longest floating bridge, and it's a lighting tunnel energy project. In preparing the communications interface specification for the Route 520 Bridge and Tunnel Project, many user needs were identified. Now as we move on, we have now gone over all of the rules for traceability and conformance. Our next task is to go through the entire PRL for this sample project and see what the end result looks like. We'll use the same case study here that we used in the prerequisite module A306a: Understanding User Needs for Electrical and Lighting Management Systems Based on NTCIP 1213 ELMS Standard Version 03.

James Frazer:
Using the PRL to build a Specification. The user needs for this particular project are as follows: we need to control the lighting system lumen output by examining the current ambient light level; we need to control lighting fixtures by zones of branch circuits; we need to configure these branch circuits into alternate zones; we need to configure, control, and monitor each of these branch circuits; we need to configure schedules for those branch circuit zones; we need to report exceptional conditions in a near real-time basis; we need to override schedules as required; and we need to provide live data as well as logged data. These are needs that are required in our project-specific implementation.

James Frazer:
There are some user needs we do not need, and this is the configuring, controlling, or monitoring of individual luminaires; individual electrical services; ground fault equipment; or arc fault equipment. Nor do we need to provide Smart Grid information to the local electrical utility. With this documentation of our user needs, we'll move on to the PRL.

James Frazer:
Using the project-specific needs for our Washington State DOT example, let's examine the PRL. 2.4.1.1: Provide Live Data. One operational environment allows the management system to monitor and control the device by issuing requests—requests to access information, alter information, or control a device. In this environment, the device responds to requests from the Management Station immediately—through the provision of live data, or success/failure notice of information alteration, or simple success or failure of the command. The first user need we encounter in this PRL is the mandatory need to provide live data. All of the requirements that trace to this user need are marked mandatory with an “M” in the Conformance column. These are required in our project.

James Frazer:
In our example, you might remember from our user need discussion, we also do need offline log data for project-specific implementation. We circle “Yes” in this column. Notice, upon circling “Yes,” that all of the requirements from 3.3.2.1 down to 3.5.4 are all now Mandatory and are required for our project.

James Frazer:
Next, we'll examine some of these user needs and requirements in detail. Using the project-specific needs for example, let's examine 2.4.1.2.1: Providing Luminaire Switch State Logging. As stated in Section 2, the Management Station may need to configure the ELMS device to keep a local log of an occurrence when the switch state for a luminaire changes. This is not required, as we discussed in our user need discussion, so we circle a “No.”

James Frazer:
Our next user need requirements pair is to 2.4.1.2.2: Provide Luminaire Lamp Condition Logging. In Section 2, it reads as follows, “The Management Station may need to configure the ELMS device to keep a local log of an occurrence, when the lamp condition changes, if it's cycling or inoperable.” We'll circle a “No” here because when we discussed our user needs, it was deemed to be not required.

James Frazer:
Similarly, 2.4.1.2.3: Provide Luminaire Burn Condition Logging, is not required, so we circle a “No.”

James Frazer:
2.4.1.2.4: Provide Periodic Luminaire Burn Time Logging. The Management Station may need to configure the ELMS devices to keep a local log of periodic measurements of the monthly burn time and monthly expected burn time. It's optional—not required—for our project, so we shall circle a “No.”

James Frazer:
2.4.1.2.5: Provide Periodic Luminaire Temperature Logging. From Section 2: “The Management Station may need to configure the ELMS device to keep a local log of an occurrence when the measurement of the luminaire temperature is above or below specified values.” This need is very important for new LED street lighting fixtures whose life and light output is directly related to the amount of time spent running at certain temperatures. The higher the runtime temperature, the faster the degradation in the light output. This user need is optional and is not required for our project, so we shall circle a “No.”

James Frazer:
2.4.1.2.7: Provide Relay Switch State Logging. The Management Station may need to configure the ELMS device to keep a local log on occurrence when the switch state changes. Again, this is optional. It's not required for our project, so we shall circle a “No.”

James Frazer:
2.4.1.2.8: Provide Power Meter Switch State Logging. The ELMS device may need to keep a local log of when the power meter switch state changes. This information can also be used by the local utility as part of a standardized Smart Grid communications platform. This is optional. It is not required for our project, so we shall circle a “No.”

James Frazer:
That concludes our brief look at mandatory and optional selection in creating a project-specific communications interface definition for your project. In this section, we have examined a short example of objects to be excluded or included in your project-specific specification when completing the Protocol Requirements List. For your project, you will examine each requirement in the PRL. A full version of the PRL is located within the standard, as well as within the Student Study Guide.

James Frazer:
Next, we'll examine use of the PRL to communicate dialogs and messages with SNMP. We'll examine how the Requirements Traceability Matrix traces to a single ambiguous design, how the RTM maps requirements to that design, and we'll examine the location of the RTM, which is in Annex A. This section of the presentation further explains how the RTM works to ensure that requirements selected in the PRL are implemented in a way that will ensure interoperability of all supported features.

James Frazer:
Using the Requirements Traceability Matrix. This is an image—a subset—of the RTM. The first column is a numerical Requirement ID.

James Frazer:
The second column is the textual description of the Requirement and, in this case, we have two: “Configure Luminaire for Light-Activated Operations,” and “Configure Electrical Service for Light-Activated Operations.”

James Frazer:
The third column is the numerical Dialog ID and, in this case, 4.2.3 is the generic SNMP set interface.

James Frazer:
The fourth column is the textual description of the Dialog, as stated previously.

James Frazer:
The next column—column 5—is the Object ID. 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 6 of the RTM is the textual description of each Object.

James Frazer:
Let's summarize the RTM. It maps each requirement to one specific design; it is a precise dialog, as well as a precise list of objects; and it's very important to remember that all of the objects must be supported if the requirement is to be supported. How do we use the PRL and the RTM to compare for interoperability? The RTM provides interoperability of requirements. The PRL indicates which particular requirements are to be supported in your project-specific implementation.

James Frazer:
Comparison of PRLs allows for a very quick determination of interoperability. Thus, by comparing and contrasting supported requirements, a user could compare two PRLs to see if an ELMS implementation would be interoperable with a Central Management System.

James Frazer:
Continuing on and using the Requirements Traceability Matrix. This slide introduces interoperability and interchangeability. Two boxes are pictured. The first represents the data object within the Management Center. The second represents the data object within the NTCIP 1213 device. The bi-directional arrow—representing NTCIP communications—connects those two boxes. How do we compare PRLs for interoperability?

James Frazer:
Well, if both the Traffic Management System—the TMS—and the ELMS support a feature, interoperability is provided. If the Traffic Management System supports a feature, but the ELMS does not, the TMS can still use other features. Also, the TMS can still interoperate with that feature with other devices. If the ELMS supports that feature, but the TMS does not, that feature could be used by other TMSs or TMSs that are planned for the future. That feature could also potentially be used manually. It's important to remember that in order to ensure interoperability, both sides of the interface must implement the same dialog and objects as specified in the standard. This provides off-the-shelf interoperability.

James Frazer:
Next, we'll examine interchangeability. If both the TMS and the ELMS implementation support a feature, the equipment is interchangeable for that feature. If new equipment supports but the old one does not, the new equipment is interchangeable because it meets or exceeds the previous implementation. However, if the old equipment supports but the new one does not, the feature will not be supported. That then requires you to answer the question “Is that feature actually needed?”

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

James Frazer:
What does the following table mean? A) All of the objects must be supported; B) All of the objects must be supported if the requirement is supported; C) At least one of the objects must be supported; or D) At least one of the objects must be supported if the requirement is supported. Please select the correct answer.

James Frazer:
Let's review our answers. B is correct. All of the objects must be supported if the requirement is supported. A is incorrect because objects only need to be supported if the requirement has been selected in the PRL. C is incorrect because if the requirement is selected, all of the objects must be supported. And D is incorrect because if a requirement is supported, all objects dependent upon that requirement must be supported.

James Frazer:
With that, we have concluded Learning Objective 3. We have reviewed the structure of the NTCIP 1213 Version 03 standard; we've examined using the PRL and the RTM to specify a standardized structure of requirements for the communications interface; and we've discussed how to include the requirements from the PRL and the RTM in a project-specific ELMS communications interface specification. Next, we will proceed to explaining the conditions and context for extending the standard.

James Frazer:
Explaining the conditions and context for extending the standard.

James Frazer:
Our three components to this learning objective: we'll discuss conditions and context for extending that standard, how to specify requirements not covered by the standard, and adding missing requirements that are identified through best practices.

James Frazer:
It's important to remember that extending the standard complicates both interoperability and interchangeability. It's not achievable unless all design details are known.

James Frazer:
Extensions are relatively custom solutions often resulting in some negative impacts to your project, including increased specification costs, increased development costs, increased testing costs, and increased integration costs. It often increases and results in a longer deployment timeframe, and can lead to increased maintenance costs. Extensions to NTCIP 1213 Version 03 and all of the NTCIP 1200 Series standards should only be considered when current NTCIP 1213 features are inadequate to meet the user need, and when the benefits of extending the standard outweigh the added costs that we discussed in a previous slide.

James Frazer:
Extending the equipment should be designed to appropriately integrate with NTCIP-compliant deployments, and care should be taken so that added complexity is minimized.

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

James Frazer:
Which of the choices below is a reason to extend an ELMS system specification? A) The existing system uses a non-standard method; B) There is an unmet need that justifies the added cost; C) You want to use your specification to favor a specific vendor; or D) The standardized solution is overly complex. Please select the correct answer.

James Frazer:
Let's review our answers. B is the correct answer. Sometimes, you just have to accept the added cost of extending the standard to support an unmet need that's within the standard. A is incorrect because using a nonstandard method will prolong the expensive customized approach for another generation of field-installed hardware and software. C is incorrect because it can trap you into a proprietary solution from a single vendor. And D is incorrect. Some NTCIP features are complex to allow flexibility, but the costs of custom solutions far outweigh any costs due to added complexity within the standard.

James Frazer:
So far, we have reviewed the structure of the NTCIP 1213 Version 03 standard. We have examined using the Protocol Requirements List and the Requirements Traceability Matrix to specify a standardized structure of requirements. We have examined including the requirements from the PRL and the RTM in a project-specific ELMS communications interface specification. And we have examined and explained conditions and the context for extending the standard. Additionally, we have learned the components of the standard—including user needs, requirements, dialogs, the PRL, and the RTM. We have learned that dialogs and messages in the RTM are communicated through the field device using SNMP. We've learned how an implementer can use testing results to confirm conformance to NTCIP 1213 Version 03 as a benefit to agencies. And we've learned how the RTM traces requirements to a single design solution, thereby providing interoperability.

James Frazer:
We have now completed A306a and A306b in the ELMS NTCIP 1213 Version 03 curriculum. We have discussed Module A306a, “Understanding User Needs for Electrical and Lighting Management Systems Based on the NTCIP 1213 Standard Version 03.” Today, we have concluded Module A306b, “Specifying Requirements for Electrical and Lighting Management Systems Based on the NTCIP 1213 Standard Version 03.”

James Frazer:
Our next course is Module T306, “Applying Your Test Plan for Electrical and Lighting Management Systems Based on NTCIP 1213 Standard Version 03.” Within module T306, concepts taught in this module are a description and the examination of ELMS testing and a description of an ELMS test plan application. We will identify relevant elements of an ELMS test plan, and we will describe adaptation of a test plan for your project-specific implementation.

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