Module 10 - A311a

A311a: Understanding User Needs for DMS Systems based on NTCIP 1203 Standard v03 - Student Supplement

HTML of the Student Supplement

(Note: This document has been converted from the Student Supplement 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.)

A311a: Understanding User Needs for DMS Systems based on NTCIP 1203 Standard v03

Table of Contents

Module Description - 2

Introduction/Purpose - 2

DMS Characteristics - 3

Reference to Other Standards - 3

Case Studies - 4

Protocol Requirements List (PRL) - 6

Glossary - 13

References for Additional Information - 14

Study Questions - 15

Icon Guide - 16

1. Module Description

Dynamic Message Signs (DMSs) are widely used field devices deployed as part of a central Freeway Management System's information dissemination purposes, and remotely monitored and controlled. The NTCIP 1203 standard v03 was developed using Systems Engineering Process (SEP) and was published in two companion volumes: Part 1 Main Standard contains user needs, requirements and design content, including PRL, and Part 2 contains Annex C Test Procedures (previous versions did not contain test procedures). Agencies prepare their DMS project specification based on the information provided by the standard to acquire standard-based interoperable signs. Participants will learn how to prepare a project level Protocol Requirement List (PRL) necessary for DMS procurement specification.

DMS Training Modules

Agencies preparing a DMS project specification for Dynamic Message signs (DMS) based on NTCIP 1203 v03 are advised to consult the following three updated sequential modules to complete the DMS related training:

1. A311a: Understanding User Needs for DMS Systems based on NTCIP 1203 standard v03
2. A311b: Specifying Requirements for DMS Systems based on NTCIP 1203 standard v03
3. T311: Applying Your Test Plan to the DMS Systems based on NTCIP 1203 standard v03

2. Introduction/Purpose

The purpose of this updated module is to incorporate necessary changes made by the updated NTCIP standard v03 (from v02), and assists technical staff in writing unambiguous, complete, and well-written user needs based on NTCIP 1213 Standard v03. This module provides participants with information on how to identify the appropriate use of the NTCIP 1213 Standard v03 and acquire a DMS system based on what the user is seeking to accomplish; and also provides participants with information on how to identify user needs that can be traced to requirements, which will be discussed in A306b: Specifying Requirements for DMS Systems based on NTCIP 1213 Standard v03, with support from tools and resources such as Requirements Traceability Matrix (RTM) and Protocol Requirements List (PRL) in following a Systems Engineering (SE) Process. An updated final module, T311, will deal with the preparing and applying of testing documentation for DMS based on NTCIP 1203 Standard v03.

The module focuses on the DMS communications interface aspects—how to configure, monitor, and control DMSs remotely from a Transportation Management Center (TMC)-Management Station- or locally at the front-panel of a DMS controller—using data objects provided by the NTCIP 1203 v03 standard Management Information Base (MIB).

3. DMS Characteristics

3.1 DMS Types

There are many types of DMS and they can be characterized in many ways. One way is by the DMS' capabilities for handling messages. This characterization places a DMS into one of three major categories:

• Blank-out Sign (BOS) - this type of DMS can only show one fixed message or nothing.
• Changeable Message Sign (CMS) - this type of DMS can display one of two or more predefined messages or be blank.
• Variable Message Sign (VMS) - this type of DMS is one in which the message to be displayed can be created after the sign is installed in the field. It can also have predefined messages in its library of stored messages. By policy and/or system design, the management system may restrict the rights of selected operators to ensure that only authorized personnel can modify.

3.2 DMS Technologies

DMS can also be characterized by the technology that is used in the sign. The technologies used include any combination of the following technologies:

• Fiber optic
• Light emitting diode (LED)
• Flip disk or shutter
• Lamp matrix
• Drum (rotating, multifaceted cylinder) 3.3 DMS Display Matrix Configuration

Finally, DMS can be characterized by the type of display layout employed by the sign, as follows:

• No matrix (i.e., it is not a pixel matrix sign)
• Matrix sign
• Full matrix
• Line matrix
• Character matrix

4. Reference to Other Standards

• NTCIP Joint Committee: NTCIP 1203 v3.03, Object Definitions for Dynamic Message Signs -(Part 1 and Part 2); April 2011; www.ntcip.org
• NTCIP Joint Committee: NTCIP 1201 Version v03.13a, National Transportation Communications for ITS Protocol, Global Object Definitions (www.ntcip.org)
• NTCIP Joint Committee, NTCIP 9001 NTCIP Guide Version 04. NTCIP Joint Committee, July 2009. https://www.ntcip.org/file/2018/11/NTCIP9001v0406r.pdf
• IEEE 1362 - IEEE Guide for Information Technology and System Definition Concept of Operations (ConOps) Document; https://standards.ieee.org/findstds/standard/1362-1998.html

5. Case Studies: Summary of DMS USER NEEDS

DMS User Needs / Features Classification

Section 2.5 of volume 1 of the standard identifies and describes the various standardized user needs addressed by and features that may be offered by a DMS. Section 3 uses these features in the analysis of the system to define the various functional requirements of a DMS.

The operation of a DMS can be categorized into three major areas:

• Manage the DMS configuration
• Control the DMS
• Monitor the status of the DMS

Section 2.5.1 Manage the DMS Configuration

The various sub-features for managing the DMS configuration include:

1. Determine the DMS Identity
2. Determine Sign Display Capabilities
3. Manage Fonts
4. Manage Graphics
5. Manage Brightness
6. Address Backwards Compatibility

2.5.2 Control the DMS

The various sub-features for controlling the DMS include:

1. Control a DMS from More than One Location
2. Remotely Reset the Sign Controller
3. Control the Sign Face
4. Control External Devices
5. Control the Brightness Outputs
6. Perform Preventative Maintenance

2.5.3 Monitor the Status of the DMS

The various sub-features for monitoring the status of the DMS include:

1. Perform Diagnostics
2. Monitor the Current Message

2.5.4 Provide for Backwards Compatibility of DMS to NTCIP 1203 v1

The following sub-features were modified within NTCIP 1203 v2 and need to be specifically spelled out to achieve backwards compatibility for certain features within a DMS conforming to NTCIP 1203 v2.

1. Allow a DMS to obtain the number of fan failures using the method defined in NTCIP 1203v1
2. Allow a DMS to initiate the fan test using the method defined in NTCIP 1203 v1
3. Allow a DMS to utilize a control mode of 'simulation' as defined in NTCIP 1203 v1

Understanding Key DMS Terminology that Impacts DMS Deployments

• PRL: The Protocol Requirements List - A Functional Requirement is a requirement of a given function and therefore is only required to be implemented if the associated functionality (e.g., user need) is selected through the use of the Protocol Requirements List (PRL). The PRL also indicates which of the items are mandatory, conditional, or optional. The PRL can be used by procurement personnel to specify the desired features of a DMS or can be used by a manufacturer to document the features supported by their implementation.
• Fundamental Needs Driving DMS Deployment
  The provision of timely and reliable information to the traveling public improves public safety and convenience by providing advance notification of items that may be of interest (e.g., downstream road conditions or the arrival of a transit vehicle). DMS are typically dispersed along interstate highways, arterial roadways, and at transit stops.
• Operational Environment
  NTCIP 1203 v03 addresses the interface between a DMS and a management station (e.g., a central computer). To enable communications between these components, the transportation system manager needs to establish a communication system that links the DMS with a management station. For some systems, the cost of communications may be minimal and as such, the system may be designed for constant polling; other systems may encounter significant costs for communicating with the DMS and as such, the system may be designed to minimize data exchanges.
• Conformance Definition
  To claim "Conformance" to NTCIP 1203 v03, the vendor must minimally satisfy the mandatory requirements as identified in the three (3) tables that compose this PRL. In addition, a conformant device may offer additional (optional) features, as long as they are conformant with the requirements of NTCIP 1203 v03 and the standards it references.
• Backwards Compatibility and Support of Different Versions of NTCIP 1203
  In NTCIP 1203 v02, the enhancement of certain functions caused corresponding objects to be replaced. A device conformant with NTCIP 1203 v03 shall by default support functions (and resulting objects) from all existing versions, if said device is required to support that particular functionality. In order to provide maximum backwards compatibility, a field device that is required to support the auxiliary input/output (auxIO) functionality and that wants to claim conformance to NTCIP 1203 v03 is required to support the objects defined in both, version 01 and version 02. However, a specification writer might determine that support of (an) older version(s) is not required and may state this within the following PRL table (the table contains within the 'additional specifications requirements' column statements where a user can de-select the support of any existing version).

6. Protocol Requirements List (PRL) and Fill-In PRL Examples

The PRL, provided in tables defined under Sections 3.3.8, and 3.3.9, map the user needs defined in Section 2 to the requirements defined in Section 3. The table can be used by:

1. A user or specification writer to indicate which requirements are to be implemented in a project-specific implementation.
2. The protocol implementer, as a checklist to reduce the risk of failure to conform to NTCIP 1203 v03 through oversight.
3. The supplier and user, as a detailed indication of the capabilities of the implementation.
4. The user, as a basis for initially checking the potential interoperability with another implementation.

User Needs Column

The user needs are defined within Section 2 and the PRL is based upon the user need sections within that Section. The section number and user need name are indicated within these columns.

Requirements Column

The requirements are defined within Section 3 and the PRL references the traces from user needs to these requirements. The section number and functional requirements name are indicated within these columns.

Conformance Column

The following notations and symbols are used to indicate status and conditional status in the PRL within all NTCIP standards. Not all of these notations and symbols may be used within NTCIP 1203 v03.

Support / Project Requirements Column

The support column can be used by a procurement specification to identify the required features for the given procurement or by an implementer to identify which features have been implemented. In either case, the user circles the appropriate answer (Yes, No, or N/A) in the support column.

Fill-in PRL with User Needs/Requirements Examples

Fill-in PRL with User Needs/Require merits

(Extended Text Description: This slide contains the following table with the Support/Project Requirement column highlighted and the word Yes circled in red on the first row:

USER NEED SECTION NUMBER	USER NEED	FR SECTION NUMBER	FUNCTIONAL REQUIREMENT	CONFORMANCE	SUPPORT/ PROJECT REQUIREMENT	ADDITIONAL PROJECT REQUIREMENTS
2.5.3.1.5 (Environment)	Monitor Sign Environment			0	Yes/No
		3.5.3.1.4.7	Monitor Sign Housing Temperatures	M	Yes
		3.5.3.1.4.3	Monitor Sign Housing Humidity	0	Yes/No
		3.5.3.1.4.9	Monitor Control Cabinet Temperatures	0	Yes/No
		3.5.3.1.4.10	Monitor Control Cabinet Humidity	0	Yes/No
		3.5.3.1.7	Monitor Ambient Environment	Temp:M	Yes/NA

)

• Use the Support/Project Requirement column to indicate if the user need is required for the implementation;
• If the; YES is selected;, the requirements associated with that user need are also selected;

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

USER NEED SECTION NUMBER	USER NEED	FR SECTION NUMBER	FUNCTIONAL REQUIREMENT	CONFORMANCE	SUPPORT/ PROJECT REQUIREMENT	ADDITIONAL PROJECT REQUIREMENTS
2.4.2	Operational Environment M				Yes
2.4.2.1	Live Data Exchange			M	Yes
		3.4.1.1	Retrieve Data	M	Yes
		3.4.1.2	Deliver Data	M	Yes
		3.4.1.3	Explore Data	M	Yes
		3.4.4.1	Determine Current Access Settings	M	Yes
		3.4.4.2	Configure Access	M	Yes	The DMS shall support at least access levels in addition to the administrator.

)

DMS Specification MUST Select YES these User Needs and associated Requirements

(Extended Text Description: This slide contains the following tables with the Conformance column highlighted and the word Yes circled in red on the first row:

2.5	Features			M	Yes
2.5.1	Manage the DMS Configuration			M	Yes
2.5.1.1	Determine the DMS Identity			M	Yes
		3.5.1.1.1	Determine Sign Type and Technology	M	Yes

)

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

USER NEED SECTION NUMBER	USER NEED	FR SECTION NUMBER	FUNCTIONAL REQUIREMENT	CONFORMANCE	SUPPORT/ PROJECT REQUIREMENT	ADDITIONAL PROJECT REQUIREMENTS
2.5.2.3	Control the Sign Face			M	Yes
2.5.2.3.1	Activate and Display a Message			M	Yes
		3.5.2.3.1	Activate a Message	M	Yes
		3.5.2.3.3.5	Retrieve Message	M	Yes

)

Specification Must selects YES

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

2.5 3.1.8 (Door)	Monitor Door Status			0	Yes /No
		3.5 3 1 3.10	Monitor Door Status	M	Yes

)

Specification selects YES, if Door status is monitored

(Extended Text Description: This slide contains the following table with the Conformance column highlighted and the word Yes circled in red on the first row, then with an arrow pointing down the text below:

USER NEED SECTION NUMBER	USER NEED	FR SECTION NUMBER	FUNCTIONAL REQUIREMENT	CONFORMANCE	SUPPORT/ PROJECT REQUIREMENT	ADDITIONAL PROJECT REQUIREMENTS
2.5.2	Control the DMS			M	Yes
2.5.2.1	Control a DMS from More than One Location			M	Yes
		3.5.2.1	Manage Control Source	M	Yes
		3.6.4 t	Supplemental Requirements for Control Modes	M	Yes

)

2.5.2.1 Control a DMS from More than One Location

This feature addresses the need for DMS to be controlled both remotely (e.g., from one or more central computers) and locally (c.c., from the controller directly or from a laptop computer connected to the controller).

Instructions for Completing the PRL (Page 17, Volume 1)

In the 'project requirements' column, each response shall be selected either from the indicated set of responses (for example: Yes / No / NA), or it shall reference additional items that are to be attached (for example, list of Permanent DMS Messages to be supported by an implementation).

If a conditional requirement is inapplicable, use the Not Applicable (NA) choice. If a mandatory requirement is not satisfied, exception information must be supplied by entering a reference Xi, where i is a unique identifier, to an accompanying rationale for the non-conformance.

3.3.4 Protocol Requirements List - Supplemental Table: The reason that the PRL provides two tables is because the supplemental requirements may relate to multiple architectural and/or data exchange requirements (contained in the first table). This split reduces the amount of repetition that would otherwise increase the size of the first table.

PARTIALLY FILLED_IN Sample Protocol Requirements List (PRL)

Table Based on NTCIP 1203 v03

PRL does NOT allow you change COLUMNS, but Rows can be tailored to map project user needs and their associated Requirements as per the standard. To reduce the table size, the following PRL shows ONLY key user needs with minimal information in the last column. Local projects may add additional project requirements as needed in the last column and populate OPTIONAL user needs marked as SELECTED YES. All Mandatory user needs are shown as M are to be supported YES and a box highlights all M user needs. (Note: table below is shown as example-not a full list of user needs.)

(Extended Text Description: This figure contains the following table with items highlighted in red, represented in BOLD in the table below:

USER NEED SECTION NUMBER	USER NEED	FR SECTION NUMBER	FUNCTIONAL REQUIREMENT	CONFORMANCE	SUPPORT/ PROJECT REQUIREMENT	ADDITIONAL PROJECT REQUIREMENTS
2.3.2	DMS Characteristics			M	Yes
	DMS Type			M	Yes
2.3.2.1.1 (BOS)	BOS			O.1 (1)	Yes / No
2.3.2.1.2 (CMS)	CMS			O.1 (1)	Yes / No
2.3.2.1.3 (VMS)	VMS			O.1 (1)	Yes / No
2.3.2.2	DMS Technology			M	Yes
2.3.2.2.1 (Fiber)	Fiber			O	Yes / No
2.3.2.2.2 (LED)	LED			O	Yes / No
2.3.2.2.3 (Flip/Shutter)	Flip/Shutter			O	Yes / No
2.3.2.2.4 (Lamp)	Lamp			O	Yes / No
2.3.2.2.5 (Drum)	Drum			O	Yes / No
2.3.2.3	DMS Display Matrix Configuration			M	Yes	The DMS shall be _millimeters wide (0..65535) and_ millimeters high (0..65535), inclusive of borders.
2.3.2.3.1	Non-Matrix			O.2 (1)	Yes / No
2.3.2.3.2 (Matrix)	Matrix			O.2 (1)	Yes / No
2.3.2.3.2.1	Full Matrix			O.3 (1)	Yes / No	The sign shall be pixels wide (0..65535) and pixels high (0..65535).
2.3.2.3.2.2	Line Matrix			O.3 (1)	Yes / No
2.3.2.3.2.3	Character Matrix			O.3 (1)	Yes / No

)

(Extended Text Description: This figure contains the following table with items highlighted in red, represented in BOLD in the table below:

USER NEED SECTION NUMBER	USER NEED	FR SECTION NUMBER	FUNCTIONAL REQUIREMENT	CONFORMANCE	SUPPORT/ PROJECT REQUIREMENT	ADDITIONAL PROJECT REQUIREMENTS
2.3.2.4 (Beacons)	DMS Display Support of Beacons			O	Yes / No
2.4.2	Operational Environment			M	Yes
2.4.2.1	Live Data Exchange			M	Yes
		3.4.1.1 Retrieve Data		M	Yes
		3.4.1.2 Deliver Data		M	Yes
		3.4.1.3 Explore Data		M	Yes
2.4.2.2	Logged Data Exchange			O	Yes / No
		H.2.2.1	Set Time	M	Yes
		H.2.2.4	Verify Current Time	M	Yes
2.5	Features			M	Yes
2.5.1	Manage the DMS Configuration			M	Yes
2.5.1.1	Determine the DMS Identity			M	Yes
		3.5.1.1.1	Determine Sign Type and Technology	M	Yes
2.5.1.2	Determine Sign Display Capabilities			O	Yes / No
		3.5.1.2.1.1	Determine the Size of the Sign Face	M	Yes
		3.5.1.2.3.1	Determine Maximum Number of Pages	VMS:M	Yes / NA	The DMS shall support at least ____ (1..255) pages for a single message.
2.5.1.3	Manage Fonts			VMS:O	Yes / No / NA
		3.5.1.3.1	Determine Maximum Number of Fonts Supported	M	Yes
2.5.1.4	Manage Graphics			VMS:O	Yes / No / NA
		3.5.1.4.1	Determine Maximum Number of Graphics	M	Yes	The DMS shall support at least graphics.
		3.5.1.4.2	Determine Maximum Graphic Size	M	Yes
2.5.2	Control the DMS			M	Yes
2.5.2.1	Control a DMS from More than One Location			M	Yes
		3.5.2.1	Manage Control Source	M	Yes

)

(Extended Text Description: This figure contains the following table with items highlighted in red, represented in BOLD in the table below:

USER NEED SECTION NUMBER	USER NEED	FR SECTION NUMBER	FUNCTIONAL REQUIREMENT	CONFORMANCE	SUPPORT/ PROJECT REQUIREMENT	ADDITIONAL PROJECT REQUIREMENTS
		3.6.4 t	Supplemental Requirements for Control Modes	M	Yes
2.5.2.2	Remotely Reset the Sign Controller			O	Yes / No
		3.5.2.2	Reset the Sign Controller	M	Yes
2.5.2.3	Control the Sign Face			M	Yes
2.5.2.3.1	Activate and Display a Message			M	Yes
		3.5.2.3.1	Activate a Message	M	Yes
		3.5.2.3.3.5	Retrieve Message	M	Yes
2.5.2.3.2	Prioritize Messages			M	Yes
		3.5.2.3.1	Activate a Message	M	Yes
		3.5.2.3.3.3	Define a Message	VMS:M	Yes / NA
2.5.2.3.3	Define a Message			VMS:M	Yes / NA
		3.5.1.2.1.3	Determine Beacon Type	M	Yes
		3.5.2.3.2.2	Configure Default Background and Foreground Color	O	Yes / No
2.5.2.3.4	Blank a Sign			M	Yes
			Activate a Message	M	Yes
2.5.2.3.5	Schedule Messages for Display			O	Yes / No
		3.5.2.3.1	Activate a Message	M	Yes
2.5.2.6	Perform Preventative Maintenance			Fiber OR Flip/Shutter:O	Yes / No / NA
		3.4.2.6	Manage the Exercise of Pixels	M	Yes
		H.2.2.1	Set Time	O	Yes / No
		3.6.6.6 t	Pixel Service Flag	M	Yes
2.5.3	Monitor the Status of the DMS			M	Yes
2.5.3.1	Perform Diagnostics			M	Yes

)

(Extended Text Description: This figure contains the following table with the first five column headers outlined in red in the table below:

USER NEED SECTION NUMBER	USER NEED	FR SECTION NUMBER	FUNCTIONAL REQUIREMENT	CONFORMANCE	SUPPORT/ PROJECT REQUIREMENT	ADDITIONAL PROJECT REQUIREMENTS
2.5.3.1.1	Determine Sign Error Conditions -High-Level Diagnostics			M	Yes
		3.5.3.1.1.1 (LampTest)	Execute Lamp Testing	Lamp OR Fiber:M	Yes / NA
		3.5.3.1.1.2 (PixelTest)	Activate Pixel Testing	Matrix:M	Yes / NA
2.5.3.1.5 (Environment)	Monitor Sign Environment			O	Yes / No
2.5.3.1.13	Monitor the Current Message			M	Yes
		3.5.3.2.1	Monitor Information about the Currently Displayed Message	O	Yes / No

)

7. Glossary

Term	Definition
BOS	Blank Out Sign
CMS	Changeable Message Sign
DMS	Dynamic Message Signs
FMS	Freeway Management System
NTCIP	National Transportation Communications for ITS Protocols
PRL	Protocol Requirements List
RTM	Requirement Traceability Matrix
SNMP	Simple Network Management Protocol
MULTI	Mark Up Language for Transportation Information
TMC	Traffic Management Center
VMS	Variable Message Sign
Agency Specification	A document that has been prepared by an agency to define requirements for a subject item or process when procured by the agency.
Beacon	A device that directs light in one direction and flashes (Similar to one-section traffic intersection signal head). The device is intended to increase a driver's attention to a message. The color is undefined (see also Strobe Lights).
Compliance	A condition that exists when an item meets all of the requirements of an agency specification.
Concept of Operations	A document that describes the purpose for a system project, including a description of the current and proposed system, as well as key user needs that the new system is required to address.
Conformance	A condition that exists when an item meets all of the mandatory requirements as defined by a standard. It can be measured on the standard as a whole, which means that it meets all mandatory (and applicable conditional) requirements of the standard or on a feature level (i.e., it conforms to feature X as defined in section X.X.X), which means that it meets all mandatory (and applicable conditional) requirements of the feature.
Dialogs	A sequence of information or message exchanges.
Dynamic Message Sign (DMS)	Any sign system that can change the message presented to the viewer, such as VMS, CMS, and BOS. It includes the following major components: sign face, sign housing, controller, and, if present, the controller cabinet.
Feature	A service provided by / behavior of the device.
Interchangeability	A condition which exists when two or more items possess such functional and physical characteristics as to be equivalent in performance and durability, and are capable of being exchanged one for the other without alteration of the items themselves, or adjoining items, except for adjustment, and without selection for fit and performance.
Interoperable	The ability of two or more systems or components to exchange information and use the information that has been exchanged (IEEE Std. 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology).
Protocol Requirements List (PRL)	A table mapping user needs with its associated requirements. This table allows procurement personnel to specify the desired features of a DMS or can be used by a manufacturer to document the features supported by their implementation. Requirement A condition or capability needed by a user to solve a problem or achieve an objective.
Specification	The project-specific detailed requirements for a DMS to be purchased by an agency or a statement by a manufacturer defining the detailed features provided by the DMS. Within NTCIP 1203 v03, 'specification' often refers to the text contained in the 'Additional Project Requirements' column of the PRL.
User Need	The business or operational problem (opportunity) that must be fulfilled to justify purchase or use. While this is termed a 'user need' within the NTCIP community, it reflects needs of all stakeholders.
Requirements Traceability Matrix (RTM)	A table that links the requirements to the corresponding dialogs and objects.

8. References for Additional Information

• NJ Department of Transportation; VARIABLE MESSAGE SIGN OPERATIONS MANUAL-final report, Dudek, Conrad L, ntl.bts.gov/lib/24000/24800/24856/VMS Manual.pdf.
• USDOT; Freeway Management and Operations Handbook, 2006
• Washington State, Department of Transportation, Introduction to VMS, Student Handbook, December 2010. http://www.wsdot.wa.gov/
• NEMA Standards Publication TS 4-2005, Hardware Standards for Dynamic Message Signs (DMS) With NTCIP Requirements, NEMA, 2005.
• DMS Procurement Workshop, U.S. Department of Transportation, Federal Highway Administration, December 28, 2006. Available online at:
• http://ops.fhwa.dot.gov/int its deployment/standards imp/dmswkshp.htm Accessed April 31, 2016.
• USDOT; Systems Engineering Guidebook for Intelligent Transportation Systems Version 3.0., November 2009. https://www.fhwa.dot.gov/cadiv/segb/
• IEEE Std 1362-1998, IEEE Guide for Information Technology - System Definition -Concept of Operations (ConOps) Document, IEEE, 1998.

9. Study Questions

1. Which of the following is a FALSE statement related to NTCIP 1203 v03 DMS Standard?

1. Contains SNMP Interface
2. Lacks Conformance Testing Documentation
3. Includes Protocol Requirements List (PRL)
4. Includes Requirements Traceability Matrix (RTM)

2. Which of the following is NOT a DMS operational need?

1. Management station remotely configures a DMS sign
2. Management station monitors and controls a DMS sign
3. Management station activates the beacon during an incident
4. Management requests current traffic flow data from the DMS controller

3. Which of the following is NOT a correct statement?

1. PRL is used to ensure conformance to the standard
2. PRL only identifies mandatory user needs/requirements
3. PRL is necessary for acquiring just a "few" DMSs
4. NTCIP 1203 v03 supports all types of DMSs and technologies

4. Which of the following is a FALSE statement related to a DMS specification?

1. DMS specification includes a PRL
2. Conformance requires only meeting mandatory user needs
3. Compliance requires only mandatory user needs
4. Vendor must use the project PRL

Icon Guide

The following icons are used throughout the module to visually indicate the corresponding learning concept listed below, and/or to highlight a specific point in the training material.

1) Background information: General knowledge that is available elsewhere and is outside the module being presented. This will be used primarily in the beginning of the slide set when reviewing information readers are expected to already know.

2) Tools/Applications: An industry-specific item a person would use to accomplish a specific task, and application of that tool to fit the need.

3) Remember: Used when referencing something already discussed in the module that is necessary to recount.

4) Refer to Student Supplement: Items or information that are further explained/detailed in the Student Supplement.

5) Example: Can be real-world (case study), hypothetical, a sample of a table, etc.

6) Checklist: Used to indicate a process that is being laid out sequentially.