Module 14 - A311b
A311b: Specifying Requirements for DMS Systems Based on NTCIP 1203 Standard v03
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.)
A311b: Specifying User Needs for DMS Systems Based on NTCIP 1203 Standard
Table of Contents
Module Description - 2
Introduction/Purpose - 2
About NTICP 1203 v03 - 3
DMS Functional Requirements - 4
Requirements Traceability Matrix (RTM) - 5
Reference to Standards - 9
Glossary - 9
References for Additional Information - 11
Study Questions - 12
Icon Guide - 13
1. Module Description
Dynamic Message Signs (DMSs) are 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 specify requirements and prepare a project level Requirements Traceability Matrix (RTM) 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:
- A311a: Understanding User Needs for DMS Systems based on NTCIP 1203 standard v03
- A311b: Specifying Requirements for DMS Systems based on NTCIP 1203 standard v03
- 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. About NTCIP 1203 v03
The NTCIP 1203 v2 specifies the logical interface between Dynamic Message Signs (DMS) and the host systems that control them (commonly referred to as central systems). NTCIP 1203 v03 describes the supported DMS interface functionality in terms of user needs and requirements.
As for limitations, NTCIP 1203 v03 defines the data that could be transmitted between a central system and a conformant DMS, but it does not define the functionalities and functions available within a DMS or a central system. Also, NTCIP 1203 v03 does not claim to address all potential capabilities of a DMS or a controlling/monitoring Central System; if NTCIP 1203 v03 would make this claim, no progress could be made (e.g., if NTCIP 1203 v03 would not allow for the possibility of defining extensions, no additional functionalities could be added, by either NTCIP 1203 v03 itself or by vendors or agencies).
It is also of utmost importance for the reader to understand that not all of the functionalities have to be supported by a DMS (or a Central System) to claim conformance. Instead, the project-specific specifications that do reference and incorporate desired applicable functionalities from NTCIP 1203 v03 (also sometimes represented as NTCIP 1203v3) are the guiding requirements that determine compliance.
How NTCIP 1203 v03 is Organized (Sections)
NTCIP 1203 v03 contains the following main sections, each building on the previous section(s):
Section 1 - Overview - This section provides the user with references, table of contents, glossary, and other information.
Section 2 - Concept of Operations - This section provides a description of user needs (needs for features and needs related to the operational environment) applicable to DMS systems.
Section 3 - Functional Requirements - This section defines the functional requirements that address the user needs identified in the Concept of Operations. It includes a Profiles Requirements List (PRL) Table that defines conformance requirements thereby allowing users to select the desired options for a particular project. An additional table identifies supplemental requirements that show requirements that are used more than once by different main functional requirements. A third table identifies the supplemental requirements for the MULTI tags and provides an indication of the functional requirement that a particular MULTI tag fulfills.
Section 4 - Dialogs and Interface Specifications - This section describes how each functional requirement is fulfilled. The dialogs define the standardized procedures for a central system to manage a sign. The interface specifications define the operations that are allowed by the sign and how data elements are inter-related.
Section 5 - Management Information Base - This section defines the data elements (object definitions) exchanged during communications (an update of NTCIP 1203:1997 Section 2).
Section 6 - Mark-Up Language for Transportation Information (MULTI) - This section defines the language used to communicate to the sign how a message is to be displayed. Similar to HTML, tags are included to specify the attributes of a message and how it is displayed on a sign (an update of NTCIP 1203:1997 Section 3).
Section 7 - Test Procedures - This section is currently left empty until guidance from another NTCIP working group has been received. This group, called the Technical Coordination Forum (TCF), defines the guidelines for the test procedures that are applicable to all technical WGs within the NTCIP community.
Annex A - Requirements Traceability Matrix - This annex provides two tables. The first table traces each requirement to a dialog, one or more interfaces, and its associated list of objects. The second table identifies supplemental traces for requirements that are used more than once for various requirements.
Guidance on Use of Sections
NTCIP 1203 v03 has been designed for different audiences.
- General Interest Users: Review Sections 1, 2, and the Frequently Asked Questions (FAQ) annex.
- Specifications Writers / Purchasers: Review Sections 1, 2, 3, and the FAQ annex.
- Submittal Reviewers: Review Sections 1, 2, 3, the FAQ annex, and the Requirements Traceability Matrix (RTM) annex.
- Firmware/Software Developers: Review all Sections and Annexes.
- Testers: Review all Sections and Annexes.
- Operators: Review Sections 1, 2, and the Frequently Asked Questions (FAQ) annex.
4. DMS Functional Requirements
The Protocol Requirements List (PRL) - 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.
Types of DMS Requirements
The functional requirements are presented in three broad categories as follows:
- Architectural Requirements - These requirements define the required behavior of the system in exchanging data across the communications interface, including any restrictions to general architectural requirements, based upon the architectural needs identified in the Concept of Operations.
- Data Exchange Requirements - These requirements define the required behavior of the system in exchanging data across the communications interface based upon the features identified in the Concept of Operations.
- Supplemental Requirements - These requirements define additional requirements of the system that are derived from the architectural and/or data exchange requirements, but are not themselves architectural or data exchange requirements. A given supplemental requirement may relate to multiple architectural and/or data exchange requirements. Supplemental requirements frequently include range capabilities of the equipment (e.g., how many messages a VMS is required to support or what the message shall be on a blank-out sign).
For example, they include requirements related to the content of the message to be displayed on a DMS, which may be a supplemental requirement to activating a message, defining a message, etc.
Requirements Traceability Matrix (RTM) Examples
What is RTM?
The RTM is a table that links the Functional Requirements as presented in Section 3 with the corresponding Dialogs (Section 4.2) on the same (gray) line. Each Functional Requirement/Dialog relates/uses one or more groups of Objects. The Objects (also known as Data Elements) are listed to the side; the formal definition of each object is contained within Section 5. Using this table, each Functional Requirement can thus be traced in a standardized way.
The audience for this table is implementers (vendors and central system developers) and conformance testers. Additionally, other interested parties might use this table to determine how particular functions are to be implemented using the standardized dialogs, interfaces, and object definitions. The following figure explains value of RTM.
(Extended Text Description: Author's relevant description: Value of Design Content Provided by the RTM. This figure makes key points on value-added content of an RTM. Use of an RTM leads to conformant Interface. An image of a Management Station is shown connected to DMS sign controller which in turn connects to a DMS sign. An arrow points to the connection with the text DMS Communications Interface, with the following bullet items. The word Interface from the first bullet points to the image:
- RTM presents the standardized Designcontent to build the DMS Communications Interface
-
Interface will be conformant to standard ONLY if:
- Each functional requirement is implemented with all Objects and Dialogs traced from that requirement given by the RTM.
- Management Station implements all Dialogs traced from the functional requirement.
)
To conform to a Functional Requirement, a DMS shall implement all Objects and Dialogs traced from that Functional Requirement; a Management Station shall implement all Dialogs traced fromthe Functional Requirement. In order to be consistent with a Functional Requirement, a Management Station shall be able to fulfill the Functional Requirement using only Objects and Dialogs that a conforming DMS is required to support.
Conformance: Meets a specified standard
- To claim "Conformance" to NTCIP 1203 v03, the vendor shall minimally satisfy the mandatory requirements selected
- Vendors that provide additional features beyond the completed PRL are still conformant as long as they conform with the requirements of NTCIP 1203 v03 and its normative references
Examples of Partially Completed RTM
Requirements Traceability Matrix (RTM)-Annex A
- RTM is a Table, with fixed columns and populated rows ;
- Functional Requirement is traced to design elements (dialogs; objects) in a standardized way :
Example entries in rows traces DMS requirement called Identify DMS,: Traces to Dialogs G.1 and objects 5.2.2 and 5.2.9.
Agency does: NOT try to figure out the design, RTM provides that.
(Extended Text Description: Author's relevant description: Single Message is referenced with Generic G.1, G.2 and G.3 Dialogs. The Requirements Traceability Matrix (RTM) presented in Annex A identifies the standardized dialog that can be used to achieve each of the data exchange requirements defined in Section 3.5. Simple data exchange requirements reference one of the generic SNMP dialogs along with a list of data elements. These equate to a single message being sent (e.g., a GET request) containing the referenced data elements followed the appropriate response per the generic dialog specification. Single message dialog is shown with arrow to G1 in RTM and objects from bottom text box, to the following table:
| Requirements Traceability Matrix (RTM) | |||||
| FR ID | Functional Requirement | Dialog ID | Object ID | Object Name | Additional Specifications |
|---|---|---|---|---|---|
| 3.5 | Data Exchange and Operational Environment Requirements | ||||
| 3.5.1 | Manage the DMS Configuration | ||||
| 3.5.1.1 | Identify DMS | ||||
| 3.5.1.1.1 | Determine Sign Type and Technology | G.1 | |||
| 5.2.2 | drnsSignType | ||||
| 5.2.9 | drnsSignTechnology | ||||
)
(Extended Text Description: Author's relevant description: SPECIFIED DIALOGS-This section provides the standardized data exchange sequences that can be used by management stations to ensure interoperable implementations for the various data exchange requirements identified in Section 3.4. Diagrams and graphical representations are included to supplement the text (i.e., not used as a replacement for the text). This section only includes dialogs that have special semantics or impose special restrictions on the operations that are allowed. Example: RTM is shown with Dialog 4.2.3.1 with an arrow pointing in RTM with associated objects in the following table:
| Requirements Traceability Matrix (RTM) | |||||
| FR ID | Functional Requirement | Dialog ID | Object ID | Object Name | Additional Specifications |
|---|---|---|---|---|---|
| 3.5.2.3 | Control the Sign Face | ||||
| 3.5.2.3.1 | Activate a Message | 4.2.3.1 | |||
| 5 7.3 | dmsActivateMessage | ||||
| 5.11.2.1.1 | shortErrorStatus | ||||
| 5.7.17 | dmsActivateMsgError | ||||
| 5.7.24 | dmsActivateErrorMsgCode | ||||
| 5.7.18 | dmsMultiSyntaxError | ||||
| 5.7.19 | dmsMultiSyntaxError Position | ||||
| 5.7.20 | dmsMultiOtherErrorDescription | ||||
Dialog 4.2.3.1 fulfils the requirement using these objects.)
- Example of a Populated RTM-VMS Message Display Capabilities
(Extended Text Description: Table shown with the Functional Requirement in the first two rows pointing to their corresponding Objects:
| FR Section Number | Functional Requirement | Dialog ID | Object Section Number | Object | Additional Specifications | |
|---|---|---|---|---|---|---|
| 3.5.1.2.3 | Determine VMS Message Display Capabilities | |||||
| 3.5.1.2.3.1 | Determine Maximum Number of Pages | G.1 | ||||
| 5.5.24 | dmsMaxNumberPages | |||||
| 3.5.1.2.3.2 | Determine Maximum Message Length | G.1 | ||||
| 5.5.25 | dmsMaxMultiStringLength | |||||
| 3.5.1.2.3.3 | Determine Supported Color Schemes | G.1 | ||||
| 5.5.22 | dmsColorScheme | |||||
| 5.3.7 | monochromeColor | |||||
| 3.5.1.2.3.4 | Determine Message Display Capabilities | G.1 | ||||
| 5.5.23 | dmsSupportedMultiTags | |||||
| 3.5.1.2.4 | Delete All Messages of a Message Type with One Command | G.3 | ||||
| 5.7.16 | dmsMemoryMgmt | |||||
)
The Requirements Traceability Matrix (RTM) presented in Annex A identifies the standardized dialog that can be used to achieve each of the data exchange requirements defined in Section 3.5. Simple data exchange requirements reference one of the generic SNMP dialogs along with a list of data elements (see Annex G). These equate to a single message being sent (e.g., a GET request) containing the referenced data elements followed the appropriate response per the generic dialog specification.
The dialogs may also be accompanied by an informative figure that provides a graphical depiction of the normative text. The figures conform to the Unified Modeling Language and depict the management station as an outside actor sending a series of messages to the device and the device returning responses. If there is any conflict between the figure and the text, the text takes precedence.
The following figure provides a detailed UML depiction of Activating a Message of DMS.
(Extended Text Description: Author's relevant description: Example of a detailed UML (Unified Modeling Language) depiction of Activating a Message of DMS, with the management station on the upper left and the DMS on the right. The precondition states: The management station shall ensure that the desired message is supported by the DMS. This may entail downloading the desired message contents to the DMS. The UML diagram describes the behavior between the objects in the system.)
5. Reference to Standards
- NTCIP Joint Committee: NTCIP 1203 v3.03, Object Definitions for Dynamic Message Signs -(Part 1 and Part 2); April 2011; https://www.ntcip.org/file/2018/11/NTCIP9001v0406r.pdf
- NTCIP Joint Committee: NTCIP 1201 Version v03.13a, National Transportation Communications for ITS Protocol, Global Object Definitions; https://www.ntcip.org/document-numbers-and-status/
- NTCIP Joint Committee, NTCIP 9001 NTCIP Guide Version 04. NTCIP Joint Committee, July 2009. https://www.ntcip.org/document-numbers-and-status/
- IEEE 1362 - IEEE Guide for Information Technology and System Definition Concept of Operations (ConOps) Document; https://standards.ieee.org/findstds/standard/1362-1998.html
6. Glossary
| Term | Definition |
|---|---|
| DMS | Dynamic Message Signs |
| FMS | Freeway Management System |
| MULTI | Mark Up Language for Transportation Information |
| NTCIP | National Transportation Communications for ITS Protocols |
| PRL | Protocol Requirements List |
| RTM | Requirement Traceability Matrix |
| SNMP | Simple Network Management Protocol |
| TMC | Traffic Management Center |
| 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 a 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. |
| Volatile Memory | A generic term for memory that allows a user to modify the content, however loses its content when power is turned off. See also Changeable Memory, Permanent Memory, and Non-Volatile Memory. |
| Volatile Messages | A library of messages stored in read-write memory devices that lose their data upon loss of power. See also Changeable Messages and Permanent Messages. |
| Requirements Traceability Matrix (RTM) | A table that links the requirements to the corresponding dialogs and objects. |
7. 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: https://ops.fhwa.dot.gov/int_its_deployment/standards_imp/dmswkshp.htm. Accessed April 31, 2016.
- ITS Standards Fact Sheets - NTCIP 1203 - Object Definitions for Dynamic Message Signs (DMS), Research and Innovative Technology Administration, U.S. DOT 2010. Available online at: https://www.standards.its.dot.gov/Factsheets/Factsheet/23. 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.
8. Study Questions
1. Which of the following is a FALSE statement related to the DMS Standard?
- Supports configuration, control, and monitoring of DMS functions
- Supplemental requirements directly involve communications between the management station and the DMS
- Supports remote communications to the DMS Controller
- Standardized dialogs carry messages between two ends
2. Which of the following is a FALSE statement as it is applied to DMS?
- RTM provides the standardized design content
- Generic Dialogs are used for single message to and from a DMS Controller
- Testing process uses RTM to verify each DMS requirement
- RTM does not reference dialog
3. Which of the following statements does NOT apply to RTM?
- RTM includes Architectural Requirements to communicate with sign controller
- Includes DMS user needs
- Includes dialogs and objects
- RTM lists requirements for retrieving data from a remote DMS
4. Which of the following is a False Statement related to a DMS specification?
- Specification includes PRL-identified user needs
- Project RTM provides project-based design content
- To achieve interoperability either PRL or RTM is required
- Extended standard is not conformant to the DMS standard
9. 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.
