Module 27 - A306b

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

HTML of the PowerPoint Presentation

(Note: This document has been converted from a PowerPoint presentation to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)

Slide 1:

(Extended Text Description: Author's relevant description: Welcome - Graphic image of introductory slide. A large dark blue rectangle with a wide, light grid pattern at the top half and bands of dark and lighter blue bands below. There is a white square ITS logo box with words "Standards ITS Training - Transit" in green and blue on the middle left side. The word "Welcome" in white is to the right of the logo. Under the logo box is the logo for the U.S. Department of Transpotation, Office of the Assistant Secretary for Research and Technology.)

Slide 2:

(Extended Text Description: Author's relevant description: This slide, entitled "Welcome" has a photo of Ken Leonard, Director, ITS Joint Program Office, on the left hand side, with his email address, Ken.Leonard@dot.gov. A screen capture snapshot of the home webpage is found on the right hand side - for illustration only - from August 2014. Below this image is a link to the current website: www.its.dot.gov/pcb - this screen capture snapshot shows an example from the Office of the Assistant Secretary for Research and Development - Intelligent Transportation Systems Joint Program Office - ITS Professional Capacity Building Program/Advanced ITS Education. Below the main site banner, it shows the main navigation menu with the following items: About, ITS Training, Knowledge Exchange, Technology Transfer, ITS in Academics, and Media Library. Below the main navigation menu, the page shows various content of the website, including a graphic image of professionals seated in a room during a training program. A text overlay has the text Welcome to ITS Professional Capacity Building. Additional content on the page includes a box entitled What's New and a section labeled Free Training. Again, this image serves for illustration only. The current website link is: https://www.its.dot.gov/pcb.)

Slide 3:

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

Slide 4:

Instructor

James J. Frazer

President

Gridaptive Technologies

Pompano Beach, FL, USA

Slide 5:

Learning Objectives

• Review the structure of the NTCIP 1213 v03 Standard
• Use the Protocol Requirements List (PRL) and then the Requirements Traceability Matrix (RTM) to specify the standardized structure of requirements
• Include the requirements from the PRL and RTM in the ELMS Communications Interface specification
• Explain conditions and context for extending the standard

Slide 6:

Learning Objective 1

• Review the structure of the NTCIP 1213 v03 Standard

Slide 7:

Components of the Standard:

ConOps, Requirements, Dialogs, MIB, PRL, RTM

Structure of NTCIP 1213 v03

• Section 1: General
• Section 2: Concept of Operations
• Section 3: Functional Requirements
• Section 4: Dialog
• Section 5: Management Information Base
• Annex A: Requirements Traceability Matrix (RTM)
• Annex B: Object Tree
• Annex C: Test Procedures

Slide 8:

Components of the Standard:

ConOps, Requirements, Dialogs, MIB, PRL, RTM

Capabilities of NTCIP 1213 Systems

Control and monitoring of terminal devices for:

• Roadway lighting
• Ground fault safety
• Revenue grade power metering
• Vehicle to Grid Infrastructure
• Vehicle to Infrastructure (V2I) communications
• Electrical distribution network (the Smart Grid)
• Electric vehicle charging infrastructure

Slide 9:

Components of the Standard:

ConOps, Requirements, Dialogs, MIB, PRL, RTM

Capabilities of NTCIP 1213 Systems - System Configurations

(Extended Text Description: Author's relevant description: This slide has a graphic of a Traffic management center on the left, field devices represented by streetlight images on the right and a gateway / embedded computer image in the center. Two arrows show that NTCIP 1213 communications can occur between the TMC and the gateway as well as between the TMC and the streetlights themselves.)

© 2017 Jim Frazer

Slide 10:

Components of the Standard:

ConOps, Requirements, Dialogs, MIB, PRL, RTM

Capabilities of NTCIP 1213 Systems - US DOT Framework

(Extended Text Description: Author's relevant description: This slide has a graphic of vehicles and streetlights on the bottom and a traffic management center on the upper left. Arrows describe NTCIP 1213 communications from the TMC to the streetlights as well as communications from the connected vehicles to the streetlights.)

Slide 11:

Components of the Standard:

ConOps, Requirements, Dialogs, MIB, PRL, RTM

Capabilities of NTCIP 1213 Systems - U.S. Smart Grid Framework

(Extended Text Description: Author's relevant description: This slide has a graphic of the NIST Smart Grid Framework, multiple arrows show NTCIP 1213 communications between customers, service providers, operation personnel, energy markets and managers of the distribution system.)

Slide 12:

Components of the Standard:

ConOps, Requirements, Dialogs, MIB, PRL, RTM

Structure of the NTCIP 1213 Standard -Missing Components of the Standard

• Does not include Test Cases for Compliance Testing
• Need to be produced for each project
• For more on testing, please examine:
  • T101: Introduction to ITS Standards Testing
  • T201: How to Write a Test Plan
  • T202: Overview of Test Design Specifications, Test Cases, and Test Procedures
  • T306: Applying Your Test Plan to the Electrical and Lighting Management Systems Based on NTCIP 1213 ELMS Standard v03

Slide 13:

Focus on Requirements

From User Needs to Functional Requirements

• Focus on Requirements:
  • Functional
  • Architectural
  • Data Exchange

Slide 14:

Relationship to the Previous Step (User Requirements)

User Needs and Functional Requirements

• Measurable Functional Requirements are derived from the Stakeholder's User Needs
• Each Functional Requirement must have an underlying User Need
• Each User Need must have a dependent Functional Requirement

Slide 15:

Review the User Requirements Step, As Needed

User Needs: A Review

• User Needs are compiled from all stakeholders
• They are the textual representation of "what needs to be accomplished"

Slide 16:

Slide 17:

Question

Which choice is not a capability of the NTCIP 1213 standard?

Answer Choices

1. Roadway lighting, including scheduling and zoning
2. Safety: electrical leakage anomalies, including power quality and ground fault issues
3. Revenue grade power metering
4. The physical size of electrical cabinets

Slide 18:

Review of Answers

a) Roadway lighting, including scheduling and zoning
Incorrect. This is a core capability of NTCIP 1213.

b) Safety: electrical leakage anomalies, including power quality and ground fault issues
Incorrect. This is a core capability of NTCIP 1213.

c) Revenue grade power metering
Incorrect. This is a core capability of NTCIP 1213.

d) The physical size of electrical cabinets
Correct! NTCIP 1213 does not support sizing of electrical cabinets.

Slide 19:

Learning Objectives

• Review the structure of the NTCIP 1213 v03 Standard
• Use the Protocol Requirements List (PRL) and then the Requirements Traceability Matrix (RTM) to specify the standardized structure of requirements

Slide 20:

Learning Objective 2

• Use the Protocol Requirements List (PRL) and then the Requirements Traceability Matrix (RTM) to specify the standardized structure of requirements

Slide 21:

How You Get Off-the-Shelf Interoperability

Use the PRL

• The PRL is a table that is a tool included in the standard for use by the system developers, agency specifiers, and producers of ELMS equipment
• Properly traces user needs to requirements
• Within a PRL, select a given range of a requirement
• Implement the design as specified in the standard (RTM)

Slide 22:

How You Get Off-the-Shelf Interoperability

Use the PRL to Ensure Interoperability

A Section of the PRL Table

Protocol Requirements List (PRL) Table
User Need ID	User Need	FR ID	Functional Requirement	Conformance	Support	Additional Specifications
2.5.2.1.21	Configure ELMS Device for Adaptive Operation			0	Yes / No
		3.5.4.23	Configure ELMS Device for Adaptive Operation	0	Yes / No
		3.5.4.23.1	Configure Connected Vehicle Speed Setpoint	0	Yes / No
		3.5.4.23.2	Configure Connected Vehicle Direction Setpoint	0	Yes / No
		3.5.4.23.3	Configure Connected Vehicle Location Setpoint	0	Yes / No
		3.5.4.23.4	Configure Connected Vehicle Ambient Light Level Setpoint	0	Yes / No
		3.5.4.23.5	Configure Connected Vehicle Headlight Status Setpoint	0	Yes / No
		3.5.4.23.6	Configure Connected Vehicle Road Friction Setpoint	0	Yes / No

Slide 23:

How You Get Off-the-Shelf Interoperability

User Needs in the PRL Table

(Extended Text Description: This slide contains the table shown on Slide 22, with the following column highlighted in red: User Need ID.)

Slide 24:

How You Get Off-the-Shelf Interoperability

User Needs in the PRL Table

(Extended Text Description: This slide contains the table shown on Slide 22, with the following column highlighted in red: User Need.)

Slide 25:

How You Get Off-the-Shelf Interoperability

User Need - Retrieve Luminaire Information

2.5.2.1.21

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.

Slide 26:

How You Get Off-the-Shelf Interoperability

Use the PRL to Trace User Needs to Requirements

Functional Requirement Identifier

(Extended Text Description: This slide contains the table shown on Slide 22, with the following column highlighted in red: FR ID.)

Slide 27:

How You Get Off-the-Shelf Interoperability

Use the PRL to Trace User Needs to Requirements

Functional Requirements Column

(Extended Text Description: This slide contains the table shown on Slide 22, with the following column highlighted in red: Functional Requirement.)

Slide 28:

How You Get Off-the-Shelf Interoperability

Requirements for Retrieve Luminaire Information

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.

Slide 29:

Within a PRL, Selecting a Given Range of a Performance Requirement (Collecting Information)

Examining the PRL's Project Criteria

Supplemental Requirement ID	Supplemental Requirement	Conformance	Project Requirement	Additional Project Requirements
3.5.5	Supplemental Requirements for Live Data	M	Yes
3.5.5.1	Live Data Response Time	M	Yes	The device shall initiate the transmission of the appropriate response (assuming that the device has permission to transmit) within 125 milliseconds of receiving the last byte of the request, plus 1 millisecond for each byte in the response variable-bindings field

Slide 30:

Supporting Project Requirements

Completing the PRL

By compiling your project-specific User Needs and examining the dependent functional requirements, you can select which optional features are to be required in your project-specific implementation.

Slide 31:

Conformance to the Standard

Conformance Column in the PRL

(Extended Text Description: This slide contains the following table, with the bottom four rows of the Conformance column highlighted in red:

User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
2.4.2.1.4	Configure for Scheduled Operation			0	Yes/No
		3.4.1.4.1.	Configure Luminaire for Scheduled Operations	0.1 (1..*)	Yes/No
		3.4.1.4.2	Configure Electrical Service for Scheduled Operations	0.2 (1..*)	Yes/No
		3.4.1.4.3.	Configure Branch Circuit for Scheduled Operations	0.3 (1..*)	Yes/No
		3.4.1.4.4.	Configure Devices in Zone for Scheduled Operations	0.4 (1..*)	Yes/No

)

Slide 32:

Slide 33:

Question

Which of the below is not a reason to use the PRL?

Answer Choices

1. To identify User Needs
2. To perform a test for compliance
3. To identify Functional Requirements
4. To develop a project-specific specification

Slide 34:

Review of Answers

a) To identify User Needs
Incorrect. The PRL does include User Needs.

b) To perform a test for compliance
Correct! Testing is not part of the NTCIP 1213 Standard v03, but must be designed and documented during the project.

c) To identify Functional Requirements
Incorrect. The PRL does include Functional Requirements.

d) To develop a project-specific specification
Incorrect. The PRL is used to develop a project-specific specification.

Slide 35:

Learning Objectives

• Review the structure of the NTCIP 1213 v03 Standard
• Use the Protocol Requirements List (PRL) and then the Requirements Traceability Matrix (RTM) to specify the standardized structure of requirements
• Include the requirements from the PRL and RTM in the ELMS Communications Interface specification

Slide 36:

Learning Objective 3

• Include the requirements from the PRL and RTM in the ELMS Communications Interface specification

Slide 37:

Properly Tracing User Needs to Requirements

User Need/Functional Requirement Relationship

• 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 PRL, you will decide whether these are required in your project-specific implementation
• You will document this by circling "Yes" or "No" in the appropriate row of the PRL
• Next we will examine a real-world example

Slide 38:

Slide 39:

Completing the Project-Level PRL

Using the PRL to Build a Specification: Washington State DOT Case Study

In preparing the communications interface specification for a large bridge and tunnel project, many user needs were identified.

Slide 40:

Completing the Project-Level PRL

Using the PRL to Build a Specification: Washington State DOT Case Study

These User Needs include the ability to:

• Control lighting system lumen output by current ambient light level (adaptive lighting)
• Control lighting fixtures by zones of branch circuits
• Configure branch circuits into alternate zones
• Configure, control, and monitor branch circuits
• Configure schedules for branch circuit zones
• Report exceptional conditions in a near real-time basis
• Override schedules as required
• Provide Live Data as well as Logged Data

Slide 41:

Completing the Project-Level PRL

Using the PRL to Build a Specification:

Washington State DOT Case Study

These User Needs do not include the ability to:

• Configure, control, or monitor
  • Luminaires
  • Electrical services
  • Ground fault equipment
  • Arc fault equipment
• Provide Smart Grid information to the local electric utility

Photo: Gridaptive Technologies

Slide 42:

Completing the Project-Level PRL

Using the PRL to Build a Specification:

Washington State DOT Case Study

Provide Live Data

User Need ID	User Need	FR ID	Functional Requirement	Conformance	Project Requirement	Additional Project Requirements
24.1	Operational User Needs			M	Yes
2.4.1.1	Provide Live Data			M	Yes
		3.3.1.1	Retrieve Data	M	Yes
		3.3.1.2	Deliver Data	M	Yes
		3.3.1.3	Data Retrieval and Data Delivery Action Performance	M	Yes
		3.5.5.1	Live Data Response Time	M	Yes

Slide 43:

Completing the Project-Level PRL

Using the PRL to Build a Specification:

Washington State DOT Case Study

Provide Off-Line Log Data

(Extended Text Description: This slide contains the following table with the word Yes circled in red on the first row:

2.4.1.2	Provide Off-line Log Data			0	Yes / No
		3.3.2.1	Retrieve Configuration of Logging service	M	Yes
		3.3.2.2	Configure Logging Service	M	Yes
		3.3.2.4	Clear Log	M	Yes
		3.3.2.5	Retrieve Capabilities of Event Logging Services	M	Yes
		3.3.2.6	Retrieve Number of Events Currently Logged	M	Yes
		3.3.2.7	Set Time	M	Yes
		3.3.2.8	Retrieve Current Time	M	Yes
		3.3.2.9	Set Daylight Saving Time Mode	M	Yes
		3.3.2.10	ELMS Pre-defined Event Configurations	M	Yes
		3.3.2.10.1	Supported Event Classes	M	Yes
		3.5.4	Supplemental Requirements for Event Logs	M	Yes

)

Slide 44:

Completing the Project-Level PRL

Using the PRL to Build a Specification:

Washington State DOT Case Study

Provide Luminaire Switch State Logging

(Extended Text Description: This slide contains the following table with the word No circled in red on the first row:

2.4.1.2.1	Provide Luminaire Switch State Logging			0	Yes / No
		3.3.2.10.2	Luminaire Switch State Log	0	Yes / No

)

Slide 45:

Completing the Project-Level PRL

Using the PRL to Build a Specification:

Washington State DOT Case Study

Provide Luminaire Lamp Condition Logging

(Extended Text Description: This slide contains the following table with the word No circled in red on the first row:

2.4.1.2.2	Provide Luminaire Lamp Condition Logging			0	Yes/No
		3.3.2.10.3	Luminaire Lamp Condition Log	0	Yes/No

)

Slide 46:

Completing the Project-Level PRL

Using the PRL to Build a Specification:

Washington State DOT Case Study

Provide Luminaire Burn Condition Logging

(Extended Text Description: This slide contains the following table with the word No circled in red on the first row:

2.4.1.2.3	Provide Luminaire Burn Condition Logging			0	Yes/No
		3.3.2.10.4	Luminaire Burn Condition Log	0	Yes /No

)

Slide 47:

Completing the Project-Level PRL

Using the PRL to Build a Specification: Washington State DOT Case Study

Provide Periodic Luminaire Burn Time Logging

(Extended Text Description: This slide contains the following table with the word No circled in red on the first row:

2.4.1.2.4	Provide Periodic Luminaire Burn Time Logging			0	Yes / No
		3.3.2.10.5	Periodic Luminaire Burn Time Log	0	Yes / No

)

Slide 48:

Completing the Project-Level PRL

Using the PRL to Build a Specification:

Washington State DOT Case Study

Provide Periodic Luminaire Temperature Logging

(Extended Text Description: This slide contains the following table with the word No circled in red on the first row:

2.4.1.2.5	Provide Luminaire Temperature Logging			0	Yes / No
		3.3.2.10.6	Luminaire Temperature Log	0	Yes / No

)

Slide 49:

Completing the Project-Level PRL

Using the PRL to Build a Specification:

Washington State DOT Case Study

Provide Periodic Luminaire Pole Condition Logging

(Extended Text Description: This slide contains the following table with the word No circled in red on the first row:

2.4.1.2.6	Provide Luminaire Pole Condition Logging			0	Yes / No
		3.3.2.10.7	Luminaire Pole Condition Log	0	Yes / No

)

Slide 50:

Completing the Project-Level PRL

Using the PRL to Build a Specification:

Washington State DOT Case Study

Provide Relay Switch State Logging

(Extended Text Description: This slide contains the following table with the word No circled in red on the first row:

2.4.1.27	Provide Relay Switch State Logging			0	Yes / No
		3.3.2.10.8	Relay Switch State Log	0	Yes / No

)

Slide 51:

Completing the Project-Level PRL

Using the PRL to Build a Specification:

Washington State DOT Case Study

Provide Power Meter Switch State Logging

(Extended Text Description: This slide contains the following table with the word No circled in red on the first row:

2.4.1.2.8	Provide Power Meter Switch State Logging			0	Yes/No
		3.3.2.10.9	Power Meter Switch State Log	0	Yes/No

)

Slide 52:

Completing the Project-Level PRL

Washington State DOT Case Study - Summary

• In this section, we have examined a short example of objects to be excluded or included in your project-specific specification when completing the PRL.
• 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 in the Student Study Guide.

Slide 53:

Use of PRL to Communicate Dialogs and Messages with SNMP

Using the Requirements Traceability Matrix (RTM)

• How the RTM traces to a single design
• The RTM maps requirements to a specific design
• Annex A contains the RTM

Slide 54:

Use of PRL to Communicate Dialogs and Messages With SNMP

Using the Requirements Traceability Matrix (RTM)

Requirement ID Column

(Extended Text Description: This slide contains the following table with the Requirement ID column highlighted in red:

Requirement ID	Requirement	Dialog ID	Dialog	Object ID	Object
3.3	Operational Environment Requirements
3.3.1	Provide Live Data
3.3.1.1	Retrieve Data
		4.2.1	Generic SNMP Get Interface
3.3.1.2	Deliver Data
		4.2.3	Generic SNMP Set Interface
3.3.1.3	Data Retrieval and Data Delivery Action Performance
		4.2.1	Generic SNMP Get Interface
		4.2.2	Generic SNMP Get-Next Interface
		4.2.3	Generic SNMP Set Interface
3.3.2	Provide Off-line Log Data
3.3.2.1	Retrieve Configuration of Logging service
	4.2.1 Generic SNMP Get Interface

)

Slide 55:

Use of PRL to Communicate Dialogs and Messages with SNMP

Using the Requirements Traceability Matrix (RTM)

Requirement Column

(Extended Text Description: This slide contains the following table with the Requirement column highlighted in red:

Requirement ID	Requirement	Dialog ID	Dialog	Object ID	Object
3.4.1.3.1	Configure Luminaire for Light Activated Operations
		4.2.3	Genenc SNMP Set Interface
				5.4.1.3	luminaireMode
				5.4.1.15	luminaireLightThreshold
				5.4.1.16	lurninaireHoldInterval
				5.4.1.17	luminaireLightHysteresis
				5.4.1.18	luminaireDelayInterval
3.4.1.3.2	Configure Electrical Service for Light Activated Operations
		4.2.3	Generic SNMP Set Interface
				5.5.1.6	electncalserviceMode
				5.5.1.9	electricalserviceLightThreshold
				5.5.1.20	electricalserviceHoldInterval
				5.5.1.21	electricaberviceLightHysieresis
				5.5.1.22	electricalserviceDelayInterval

)

Slide 56:

Use of PRL to Communicate Dialogs and Messages with SNMP

Using the Requirements Traceability Matrix (RTM)

Dialog ID Column

(Extended Text Description: This slide contains the same table as Slide 55 with the Dialog ID column highlighted in red.)

Slide 57:

Use of PRL to Communicate Dialogs and Messages with SNMP

Using the Requirements Traceability Matrix (RTM)

Dialog Column

(Extended Text Description: This slide contains the same table as Slide 55 with the Dialog column highlighted in red.)

Slide 58:

Use of PRL to Communicate Dialogs and Messages with SNMP

Using the Requirements Traceability Matrix (RTM)

Object ID Column

(Extended Text Description: This slide contains the same table as Slide 55 with the Object ID column highlighted in red.)

Slide 59:

Use of PRL to Communicate Dialogs and Messages with SNMP

Using the Requirements Traceability Matrix (RTM)

Object Column

(Extended Text Description: This slide contains the same table as Slide 55 with the Object ID column highlighted in red.)

Slide 60:

Use of PRL to Communicate Dialogs and Messages with SNMP

Using the Requirements Traceability Matrix (RTM)

Summarizing the RTM:

The RTM

• Maps each requirement to one specific design
• Is a precise dialog
• Is a precise list of objects
• All of the objects must be supported if the requirement is supported

Slide 61:

Use of PRL to Communicate Dialogs and Messages with

SNMP

Using the Requirements Traceability Matrix (RTM)

How to Compare for Interoperability:

• The RTM provides interoperability of requirements
• The PRL indicates which requirements are supported
• Comparison of PRLs allows quick determination of interoperability

Slide 62:

Use of PRL to Communicate Dialogs and Messages with

SNMP

Using the Requirements Traceability Matrix (RTM)

Comparison of PRLs for Interoperability and Interchangeability:

(Extended Text Description: Author's relevant description: This slide includes an image of a data object at the traffic management center and a data object at the field device. An arrow labeled "NTCIP" denotes NTCIP communications between the two objects.)

Slide 63:

Use of PRL to Communicate Dialogs and Messages with

SNMP

Using the Requirements Traceability Matrix (RTM)

Comparison of PRLs for Interoperability:

• If both the Traffic Management System (TMS) and the ELMS support a feature
  • Interoperability is provided
• If the TMS supports, but ELMS does not
  • TMS can still use other features (typically)
  • TMS can still interoperate with feature with other devices
• If ELMS supports, but TMS does not
  • Feature could be used by other/future TMSs
  • Feature can potentially be used manually
• In order to ensure interoperability, both sides of the interface must implement the same dialog and objects as specified in the standard. This will give off-the-shelf interoperability.

Slide 64:

Use of PRL to Communicate Dialogs and Messages with

SNMP

Using the Requirements Traceability Matrix (RTM)

Comparison of PRLs for Interchangeability

• Both support a feature
  • Equipment is interchangeable for feature
• New equipment supports; old one does not
  • New equipment is interchangeable (meets or exceeds)
• Old equipment supports; new ones do not
  • Feature will not be supported
  • Is feature needed?

Slide 65:

Slide 66:

Question

What does the following table mean?

(Extended Text Description: This slide contains the following table:

Requirement ID	Requirement	Dialog ID	Dialog	Object ID	Object
3.4.1.3.1	Configure Luminaire for Light Activated Operations
		4.2.3	Generic SNMP Set Interface
				5.4.1.3	luminaireMode
				5.4.1.15	luminaireLightThreshold
				5.4.1.16	luminaireHoldlnterval
				5.4.1.17	luminaireLightHysteresis
				5.4.1.18	luminaireDelaylnterval

)

1. All of the objects must be supported
2. All of the objects must be supported if the requirement is supported
3. At least one of the objects must be supported
4. At least one of the objects must be supported if the requirement is supported

Slide 67:

Review of Answers

a) All of the objects must be supported
Incorrect. They only need to be supported if the requirement has been selected in the PRL.

b) All of the objects must be supported if the requirement is supported
Correct!

c) At least one of the objects must be supported
Incorrect. If the requirement is selected, all of the objects must be supported.

d) At least one of the objects must be supported if the requirement is supported
Incorrect. If the requirement is supported, all of the objects must be supported.

Slide 68:

Learning Objectives

• Review the structure of the NTCIP 1213 v03 Standard
• Use the Protocol Requirements List (PRL) and then the Requirements Traceability Matrix (RTM) to specify the standardized structure of requirements
• Include the requirements from the PRL and RTM in the ELMS Communications Interface specification
• Explain conditions and context for extending the standard

Slide 69:

Learning Objective 4

• Explain conditions and context for extending the standard

Slide 70:

User Needs-Requirements Link

Extending the Standard

• Conditions and context for extending the standard
• Specify requirements not covered by the standard
• Adding missing requirements identified through best practices

Slide 71:

Using Requirements Not Covered by the ELMS Standard

Extending the Standard Complicates Interoperability and Interchangeability

• Not achievable unless all design details are known
• Extensions are relatively custom solutions, resulting in:
  • Increased specification costs
  • Increased development costs
  • Increased testing costs
  • Increased integration costs
  • Longer deployment timeframe
  • Increased maintenance costs

Slide 72:

Using Requirements Not Covered by the ELMS Standard

Extending the Standard Complicates Interoperability and Interchangeability

Extensions should only be considered when:

• NTCIP features are inadequate to meet need
• Benefits of extension outweigh added costs

Slide 73:

Using Requirements Not Covered by the ELMS Standard

Extending the Standard Complicates Interoperability and Interchangeability

Extended equipment should be designed to:

• Appropriately integrate with NTCIP-only deployments
• Minimize added complexity

Slide 74:

Slide 75:

Question

Which of the choices below is a reason to extend an ELMS system specification?

Answer Choices

1. The existing system uses a nonstandard method
2. There is an unmet need that justifies the added cost
3. You want to use your specification to favor a specific vendor
4. The standardized solution is overly complex

Slide 76:

Review of Answers

a) The existing system uses a nonstandard method
Incorrect. Doing this will prolong the expensive customized approach for another generation.

b) There is an unmet need that justifies the added cost
Correct! Sometimes you just have to accept the added cost.

c) You want to use your specification to favor a specific vendor
Incorrect. This can trap you into a proprietary solution.

d) The standardized solution is overly complex
Incorrect. Some NTCIP features are complex to allow flexibility, but costs of custom solutions far outweigh any costs due to added complexity.

Slide 77:

Module Summary

• Review the structure of the NTCIP 1213 v03 Standard
• Use the Protocol Requirements List (PRL) and then the Requirements Traceability Matrix (RTM) to specify the standardized structure of requirements
• Include the requirements from the PRL and RTM in the ELMS Communications Interface specification
• Explain conditions and context for extending the standard

Slide 78:

We Have Now Completed A306a and A306b in the ELMS Curriculum

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

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

Module T306:
Applying Your Test Plan for Electrical and Lighting Management Systems Based on NTCIP 1213 ELMS Standard v03

Slide 79:

Next Course Module

Module T306: Applying Your Test Plan for Electrical and Lighting Management Systems Based on NTCIP 1213 v03 Standard

Concepts taught in next module (Learning Objectives):

1. Describe ELMS Testing
2. Describe ELMS Test Plan Application
3. Identify Relevant Elements of an ELMS Test Plan
4. Describe Adaptation of a Test Plan

Slide 80:

Thank you for completing this module.

Feedback

Please use the Feedback link below to provide us with your thoughts and comments about the value of the training.

Thank you!