Module 14 - A311b

A311b: Specifying Requirements for DMS Systems Based on NTCIP 1203 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:

Welcome - Graphic image of introductory slide. Please see the Extended Text Description below.

(Extended Text 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:

Welcome slide with Ken Leonard and screen capture of home webpage. Please see the Extended Text Description below.

(Extended Text 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.pcb.its.dot.gov - 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: http://www.pcb.its.dot.gov.)

 

Slide 3:

A311b: Specifying Requirements for DMS Systems Based on NTCIP 1203 Standard v03

Specifying Requirements for DMS Systems Based on NTCIP 1203 Standard v03. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: Title slide: Specifying Requirements for DMS Systems Based on NTCIP 1203 Standard v03 - The slide graphic includes an image of a Traffic Management Center from NYC DOT on the left side-an operator is looking at work station with DMS images. Another image is shown at top right corner that actually shows DMS messages with travel times in minutes. An image at right side bottom shows a DMS controller installed in the field with door open. A software screenshot is shown below TMC image on left to indicate a message is confirmed. The entire slide graphics together conveys the meaning and purpose of this module and what is expected from DMS deployments. )

 

Slide 4:

Instructor

Headshot photo of Raman K. Patel

Raman K. Patel, Ph.D., P.E.

President

RK Patel Associates, Inc. New York City, NY, USA

 

Slide 5:

Learning Objectives

 

Slide 6:

Learning Objective 1

 

Slide 7:

What Is NTCIP 1203 v03?

DMS Communications Interface Standard

DMS Communications Interface Standard. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: DMS Communications Interface Standard - At bottom of the slide, a TMC management station is communicating with a connected line to a sign controller, which is connected to a DMS sign. The slide contains the following bullet items:

)

 

Slide 8:

What Is NTCIP 1203 v03?

Recap of Updated Module A311a

Image of NTCIP 1203 book page.

 

Slide 9:

Structure of Standard

Information Needed to Prepare a DMS Specification. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: Information Needed to Prepare a DMS Specification - On the left side, a slanted text box shows CoOps, Requirements and Design sections, each is then connecting to right side text boxes with Section 2 User Needs, 3 Functional Requirements, 4 Dialogs, and 5 Management Information Base Objects, respectively with arrows coming from left side. This means that NTCIP 1203 v03 Part 1 offers information needed in three sections.)

 

Slide 10:

Structure of Standard

Specific Guidance from the NTCIP 1203 v03 Standard

Part 1: Provides Template for Selecting User Needs Called Project Requirements List (PRL)

Part 1: Annex A: Provides template for Design Dialogs, and Objects Called Requirements Traceability Matrix (RTM)

Part 2: Annex C: Outlines Test Procedures for a DMS Test Plan

Background information icon indicates general knowledge that is available elsewhere and is outside the module being presented.

 

Slide 11:

What Is a Requirement?

"A statement that identifies a system, product, or process' characteristic or constraint, which is unambiguous, clear, unique, consistent, stand-alone (not grouped), and verifiable and is deemed necessary for stakeholder acceptability."

- INCOSE Systems Engineering Handbook

An image of a source title page from INCOSE is shown at right bottom corner.

 

Slide 12:

What Is a Requirement?

Definition of a Requirement

"A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document. A desired feature, property, or behavior of a system." NTCIP 1203 v03

Example of a DMS Requirement

3.5.2.3.3.3 Define a Message

The DMS shall allow a management station to download a message for storage in the sign controller's message library.

 

Slide 13:

Standard Structure

Types of DMS Requirements

3.4 Architectural Requirements

3.5 Data Exchange Requirements

3.6 Supplemental Non-Communications Requirements

Background information icon indicates general knowledge that is available elsewhere and is outside the module being presented.

 

Slide 14:

Review Standard Structure

Architectural Requirements

Define the required behavior of the system in exchanging data across the communications interface

3.4 Architectural Requirements

An image of a Management Station is shown connected to DMS sign controller. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: 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 Subject of NTCIP.)

 

Slide 15:

Standard Structure

Architectural Requirements (Section 3.4)

3.4.2.3 Retrieve Logged Data

The DMS shall allow a management station to retrieve data from the event log.

3.4.2.4 Clear Log

The DMS shall allow the management station to clear log entries of a given event class that are less than or equal to a given time.

3.4.4.1 Determine Current Access Settings

The DMS shall allow the administrator at the management station to determine the current access settings.

Same as above slide 14. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: Example - Same as above slide 14, showing the connection between a Management Station and DMS sign controller.)

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

 

Slide 16:

Standard Structure

Data Exchange Requirements (Section 3.5)

Define the required behavior of the system in exchanging data across the communications for three major areas:

3.5.1 Manage the DMS Configuration

3.5.2 Control the DMS

3.5.3 Monitor the Status of the DMS

Same as above slide 14

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

 

Slide 17:

Standard Structure

Data Exchange Requirements (Section 3.5)

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

 

Slide 18:

Standard Structure

Examples of Data Exchange Requirement (Section 3.5)

A screen shot of a TMC software is shown at right-bottom corner. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: Example - A screen shot of a TMC software is shown at right-bottom corner. Additional text on the slide shows a box of text at the bottom left connected to the bullet item "Maximum number of pages", then connected to the screen shot. The box at the bottom contains the text: "3.5.1.2.3.2 Determine Maximum Message Length The DMS shall allow a management station to determine the maximum length for a downloadable message." The bulleted list is as follows:

3.5.1 Manage Configuration

)

 

Slide 19:

Standard Structure

Data Exchange Requirements (Section 3.5)

3.5.1 Manage Configuration

Authors relevant description: Example: A DMS is shown at right side with a message. WET ROADS AHEAD EXPECT DELAYS.

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

 

Slide 20:

Standard Structure

Examples of Data Exchange Requirements (Section 3.5)

3.5.2 Control the DMS

3.5.2.1 Manage Control Source

A DMS shall allow the user to switch between the local and central control modes.

Authors relevant description: Example - Same as above slide 14, different message, with a local computer in local control mode.

 

Slide 21:

Standard Structure

Example of a Requirement for Scheduling a Message

3.5.2.3.4.1 Retrieve a Schedule: The DMS shall allow a Management station to retrieve the schedule as stored within the sign controller.

Authors relevant description: Example - Image of management station computer software on left.

Management Station

If an event is known in advance, a message can be scheduled to run between a set time and date.

Authors relevant description: Example - Backside of a sign controller.

Sign Controller

Source: WSDOT

 

Slide 22:

Standard Structure

Examples of Data Exchange Requirements (Section 3.5)

3.5.3 Monitor the Status of the DMS

Authors relevant description: Example - An image of a circuit board-subsystem is shown at RIGHT upper corner.

 

Slide 23:

Standard Structure

Monitor the Status of the Current Message

Same set of images appears as shown in Title slide 3 images

 

Slide 24:

Standard Structure

Support for Maintenance Requirements

Example: A screenshot shows maintenance requirements.. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: Example: A screenshot shows maintenance requirements. Diagnostics and Troubleshooting can be performed with central system that contains numerous maintenance tools used for troubleshooting sign failures. Pop-up Examples are shown in the text box, such as Light Sensor readings, Temp Sensor readings, Power Supply Pass/Fail readings, etc.)

Source: WSDOT

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

 

Slide 25:

Standard Structure

Supplemental Requirements (Section 3.6)

Supplemental Requirements are additional requirements not covered by the other two categories (Architectural/Data exchange).

Example: Include range capabilities of the DMS:

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

 

Slide 26:

Standard Structure

Types of DMS Requirements Supported (Section 3.6)

3.6 Supplemental non-communications Requirements. Please see the Extended Text Description below.

(Extended Text Description: Types of DMS Requirements Supported (Section 3.6) are shown below, with the words "non-communications" highlighted in red:

3.6 Supplemental non-communications Requirements.....

3.6.1 Supplemental Requirements for Fonts.
3.6.2 Supplemental Requirements for General Illumination Brightness.
3.6.3 Supplemental Requirements for Automatic Brightness Control....
3.6.4 Supplemental Requirements for Control Modes...........................
3.6.5 Supplemental Requirements for Message Activation Request.....
3.6.6 Supplemental Requirements for Message Definition....................
3.6.7 Supplemental Requirements for Locally Stored Messages..........
3.6.8 Supplemental Requirements for Color Scheme............................
3.6.9 Supplemental Requirements for Monitoring Subsystems.............
3.6.10 Supplemental Requirements for Scheduling.................................
3.6.11 Supplemental Requirements for Graphics....................................
3.6.12 Supplemental Requirements for Page Justification......................
3.6.13 Supplemental Requirements for Line Justification........................

)

Background information icon indicates general knowledge that is available elsewhere and is outside the module being presented.

 

Slide 27:

Standard Structure

This slide highlights supplemental requirements with familiar types for signs used in photos, both are font issues. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: This slide highlights supplemental requirements with familiar types for signs used in photos, both are font issues. An arrow points from the text "the number of fonts" to the table below, "The DMS shall support at least ____ fonts":

Illustration of a Supplemental Requirement

3.6.1.1 Support for a Number of Fonts

The DMS shall support the number of fonts as defined by the specification. If the specification does not define the number of fonts, the DMS shall support at least one font.

3.3.4 Protocol Requirements List - Supplemental Table

Req ID Requirement Req ID Requirement Conformance Support Additional Specifications
  Supplemental Requirements      
3.6.1 Supplemental Requirements for Fonts      
  3.6.1.1 Support for a Number of Fonts M Yes The DMS shall support at least ____ fonts (1..255). NOTE: The specification may optionally specify the fonts to be stored in the sign controller upon initial delivery by using an additional attached sheet to define the desired pixel-by-pixel bitmaps of each character of each font,

)

 

Slide 28:

Standard Structure

Types of Standardized Dialogs Used to Manage DMSs (Section 4)

Dialogs are sequence of data exchanges that fulfill various requirements to communicate to a DMS system:

G.1 Generic SNMP GET Interface to retrieve data from DMS

G.2 Generic SNMP GET-NEXT Interface defines a process by which a management station can explore data within a device to fulfill the requirements

G.3 Generic SNMP SET Interface defines a generic process by which a management station can send data to a device

 

Slide 29:

Standard Structure

Illustration of a Generic SET Dialog

G.3 GENERIC SNMP SET INTERFACE

SNMP defines a generic process by which a management station can send data to a device. This process consists of a Set request and a GetResponse (sic) as depicted in Figure 14. Both the Set request and the GetResponse messages contain a list of objects as defined by the varBindingList structure (see Annex G.4).

Authors relevant description: Example of G.3 SET Interface is shown. Illustration: G.3 message is shown from a TMC to DMS controller and sign.

Figure 14 SNMP Set Interface

 

Slide 30:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 31:

Question

Which of the following is a FALSE statement

related to the DMS Standard?

Answer Choices

  1. Supports configuration, control, and monitoring of DMS functions
  2. Supplemental requirements directly involve communications between the management station and the DMS
  3. Supports remote communications to the DMS Controller
  4. Standardized dialogs carry messages between two ends

 

Slide 32:

Review of Answers

A small graphical green and yellow check mark representing correct.b) Supplemental requirements directly involve communications between the management station and the DMS
False statement. Supplemental requirements cover range values such as message line justification shown below.

3.6.13.2 Support Center Line Justification

The DMS shall support center line justification.

This DMS shows the message SPEED MONITORED BY LASER AND RADAR and is center justified.

3.6.13.1 Support Left Line Justification

The DMS shall support left line justification.

This DMS shows the message RIGHT LANE CLOSED MERGE LEFT and is left justified.

 

Slide 33:

Review of Answers

A small graphical red and yellow X representing incorrect.a) Supports configuration, control and monitoring of DMS functions
Correct statement. These are core functions of the DMS standard.

A small graphical red and yellow X representing incorrect.c) Supports remote communications to DMS Controller
Correct statement. This statement is true. The standard supports the DMS communications interface.

A small graphical red and yellow X representing incorrect.d) Standardized dialogs carry messages between two ends
Correct statement. This statement is true. DMS has three dialogs: G. 1, G.2, and G.3 to facilitate remote conversations.

 

Slide 34:

Learning Objectives

 

Slide 35:

Learning Objective 2

 

Slide 36:

What Is an RTM?

Revisiting Protocol Requirements List (PRL): Module A311a

PRL table traces User Needs to Requirements

USER NEED SECTION NUMBER USER NEED FR SECTION NUMBER FUNCTIONAL REQUIREMENT CONFORMANCE SUPPORT / PROJECT REQUIREMENT ADDITIONAL PROJECT REQUIREMENTS
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  
    H.2.1 Determine Device Component Information M Yes  
    H.2.4 Determine Supported Standards M Yes  
2.5.1.2 Determine Sign Display Capabilities 0 Yes/ No  
    3.5.1.2.1.1 Determine the Size of the Sign Face M Yes  

Standardized DMS user needs are provided in Section 2 and requirements in Section 3 of v03 standard.

Tools/Applications icon. An industry-specific item a person would use to accomplish a specific task, and applying that tool to fit your need.

 

Slide 37:

What Is an RTM?

Terminology

FR Section Number Functional Requirement Dialog ID Object Section Number Object Additional Specifications
3.5.1.1 Identify DMS  

NTCIP 1203 v03 Annex A, Page 233

Background information icon indicates general knowledge that is available elsewhere and is outside the module being presented.

 

Slide 38:

What Is an RTM?

Example of a DMS Requirement

"Determine Sign Type and Technology" is traced to dialog G.1 and associated design objects - 5.2.2 and 5.2.3

The example of a requirement with associated design elements is shown and the traceability aspect is stressed.. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: The example of a requirement with associated design elements is shown and the traceability aspect is stressed. Example: RTM is shown with Traceability pointing to FR, G1 and Objects with individual arrows.

Traceability

FR Section Number Functional Requirement Dialog ID Object Section Number Object Additional Specifications
3.5,1.1 Identify DMS  
3.5.1.1.1 Determine Sign Type and Technology G.1  
     
      5.2.2 dmsSignType  
      5.2.9 dmsSignTechnology  

)

Tools/Applications icon. An industry-specific item a person would use to accomplish a specific task, and applying that tool to fit your need.

 

Slide 39:

What Is an RTM?

Value of Design Content Provided by the RTM

This slide makes key points on value-added content of an RTM. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: This slide makes key points on value-added content of an RTM. Use of an RTM leads to conformant Interface. Image is shown same as one in slide 14 with the following bullet items. The word Interface from the first bullet points to the image:

)

Checklist icon used to indicate a process that is being laid out sequentially.

 

Slide 40:

Parts of RTM with DMS Examples

Parts of RTM Table

Parts of RTM: An RTM table is shown with a text box pointing to first row which shows columns of RTM. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: Parts of RTM: An RTM table is shown with a text box pointing to first row which shows columns of RTM.

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 dmsSignType  
      5.2.9 dmsSignTechnology  

The text box contains the following bulleted items:

)

 

Slide 41:

Parts of RTM with DMS Examples

Parts of RTM Table

A text box with bulleted items points to the Object ID column of the same table as Slide 40. Please see the Extended Text Description below.

(Extended Text Description: A text box with bulleted items points to the Object ID column of the same table as Slide 40:

)

 

Slide 42:

Parts of RTM with DMS Examples

Single Message is referenced with Generic G.1, G.2 and G.3 Dialogs. Please see the Extended Text Description below.

(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 same table as Slide 40.)

 

Slide 43:

Parts of RTM with DMS Examples

More Complicated Data Exchange Requires Specified Dialogs (Section 4)

Example: Activate a Message

SPECIFIED DIALOGS-This section provides the standardized data exchange sequences that can be used by management stations. Please see the Extended Text Description below.

(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.)

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

 

Slide 44:

Parts of an RTM with DMS Examples

Special Note on Importance of Dialogs Order

If you are a system developer, these issues are bound to come up in your work.

 

Slide 45:

Benefits of RTM to Shareholders

DMS stakeholders are many, and each has a stake in a successful DMS implementation. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: DMS stakeholders are many, and each has a stake in a successful DMS implementation. Image shown in slide 14 is shown here at bottom, indicating What between Management station and DMS controller-means What is being communicated.

Beneficiary of RTM Uses

  1. Procuring Agency-DMS Specification is connected to Are we missing something?
  2. Traffic Management Center-Operations is connected to Will the interface support operations?
  3. System Developers-Implementers is connected to Do I have to do it all over again?
  4. DMS Manufacturers/Vendors is connected to How do I know what their requirements are?
  5. Conformance Testers is connected to What do I test for conformance and why?

)

 

Slide 46:

Benefits of RTM to Shareholders

Benefits of RTM to Agency Procurement-Specification Preparation

An image of a group of engineers working at a Table is shown at the right bottom corner.

Source: NYCDOT-Patel

 

Slide 47:

Benefits of RTM to Shareholders

Benefits of RTM to System Developers/Implementers

Checklist icon used to indicate a process that is being laid out sequentially.

 

Slide 48:

Benefits of RTM to Shareholders

Benefits of RTM to DMS Vendors

 

Slide 49:

Benefits of RTM to Shareholders

The Market Place

The Market Place is shown with two maps. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: The Market Place is shown with two maps: this first one shows a region with multiple DMS sign manufacturers such as Daktronics, Telnet etc.; Bullet items include:

)

The Market Place is shown with two maps. Please see the Extended Text Description below.

(Extended Text Description:Author's relevant description: The Market Place is shown with two maps: this second one shows a US map with locations where DMSs are deployed; Bullet items include:

)

 

Slide 50:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 51:

Question

Which of the following is a FALSE statement as it is applied to DMS?

Answer Choices

  1. RTM provides the standardized design content
  2. Generic Dialogs are used for single message to and from a DMS Controller
  3. Testing process uses RTM to verify each DMS requirement
  4. RTM does not reference dialog

 

Slide 52:

Review of Answers

A small graphical red and yellow X representing incorrect.a) RTM provides the standardized design content
Correct statement. It reflects what RTM is about. For each requirement, a full design is provided.

A small graphical red and yellow X representing incorrect.b) Generic Dialogs are used for single message to and from a DMS Controller
Correct statement. G. 1, G.2 and G.3 generic dialogs are meant for simple-single conversations between two ends.

A small graphical red and yellow X representing incorrect.c) Testing process uses RTM to verify each DMS requirement
Correct statement. RTM is used in preparing Test Cases during testing process to test a requirement.

A small graphical green and yellow check mark representing correct.d) RTM does not reference dialog
False statement. RTM specifies the order in which dialogs must be implemented in order to make error-free communications possible and to achieve interoperability.

 

Slide 53:

Learning Objectives

 

Slide 54:

Learning Objective 3

 

Slide 55:

Review a Step to Continue with Requirements from PRL

A PRL table with a box highlighting Requirements is shown. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: Refer to PRL: A PRL table with a box highlighting Requirements is shown and Support column-means these requirements are Mandatory M and must be selected YES in the support column. The table is shown below with requirements highlighted in red:

Refer to a Project-Level PRL for Supported Requirements

USER MEED SECTION NUMBER USER NEED FR SECTION NUMBER FUNCTIONAL REQUIREMENT CONFORMANCE SUPPORT/ PROJECT REQUIREMENT ADDITIONAL PROJECT REQUIREMENTS
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  
    H.2.1 Determine Device Component Information M Yes  
    H.2.4 Determine Supported Standards M Yes  
2.5.1.2 Determine Sign Display Capabilities 0 Yes /No  
    3.5.1 2 1 1 Determine the Size of the Sign Face M Yes  

)

See Student Supplement for Module A311a for a Project PRL Example

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

 

Slide 56:

Complete Project RTM with Entries (Populating Table) for Dialogs/Design Concepts

RTM Provides the Design for Each Supported Requirement

RTM Provides the Design: RTM table is shown with box over Dialog-Object columns. . Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: RTM Provides the Design: RTM table is shown with box over Dialog-Object columns. A text box points I am a Blank Out Sign, another point to I am LED Technology. Both are related to objects shown with arrows. The table is shown below:

FR Section Number Functional Requirement Dialog ID Object Section Number Object Additional Specifications
3.5,1.1 Identify DMS  
3.5.1.1.1 Determine Sign Type and Technology G.1  
       
      5.2.2 dmsSignType  
      5.2.9 dmsSignTechnology  

)

 

Slide 57:

Examples of RTM

Example: same as above RTM tables is shown with box covering requirement column and objects column. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: Example: same as above RTM tables is shown with box covering requirement column and objects column. The table is shown below:

Message Display Capabilities-Manage Configuration (3.5.1)

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  

)

 

Slide 58:

Examples of RTM

Display Capabilities Requirements Are Fulfilled

Same as above slide 57, shown with a sample screenshot with DMS message-ODOT System Under Test.

 

Slide 59:

Examples of RTM

Reset the Sign Controller-Manage Control (3.5.2)

FR Section Number Functional Requirement Dialog ID Object Section Number Object Additional Specifications
3.5.2.2 Reset the Sign Controller G.3  
       
      5.7.2 dmsSWReset  

3.5.2.2 Reset the Sign Controller

The DMS shall allow a management station to reset the sign controller.

RTM table is shown, with an image under 3.5.2.2 Reset the Sign Controller requirement. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: RTM table is shown, with an image under 3.5.2.2 Reset the Sign Controller requirement. The image shows a TMC talking to a DMS sign controller with two-headed red arrow in between.)

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

 

Slide 60:

Examples of RTM

Requirements Traceability Matrix (RTM)
FR ID Functional Requirement Dialog ID Object ID Object Name Additional Specifications
3.5.3 Monitor the Status of the DMS        
3.5.3.1 Perform Diagnostics  
3.5.3.1.1 Test Operational Status of DMS Components  
3.5.3.1.1 1 Execute Lamp Testing 4.2.4.1  
      5.11.2.5.3 lampTestActivation  
3.5.3.1.1.2 Activate Pixel Testing 4.2.4.2  
      5.11.2.4.3 pixelTestActivation  

Authors relevant description: Same as above, the image is BAD Weather Conditions and on right side a broken pixel board is shown.

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

 

Slide 61:

Examples of RTM

Monitor Status-Manage Control (3.5.3)

Requirements Traceability Matrix (RTM)
FR ID Functional Requirement Dialog ID Object ID Object Name Additional Specifications
      5.11.2.6.2 clmsDrumNumRows  
3.5.3.1.3.1 0 Monitor Door Status G.1  
      5.11.1.6 dmsStatDoorOpen  

3.5.3.1.3.10 (Monitor Door Status

The DMS shall allow a management system to determine which doors of the DMS are open or closed.

Authors relevant description: Example: RTM is shown with a TMC talking to a DMS controller.

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

 

Slide 62:

Examples of RTM

Monitor Current Status of a Message-Manage Control

FR Section Number Functional Requirement Dialog ID Object Section Number Object Additional Specifications
3.5.3.2 Monitor the Current Message  
3.5.3.2.1 Monitor Information about the Currently Displayed Message 4.2.4.14  
       
      5.8.5 dmslllumBrightLevelStatus  
      5.8.9 dmslllumLightOutputStatus  
       
      5.6.8.1 dmsMessageMemoryType Value of '5' only
      5.6.8.2 dmsMessageNumber Value of '1' only

Monitoring the Status of the DMS. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: Monitoring the Status of the DMS - This slide brings up how we monitor a sign status and perform diagnostics. Four phots are used. A TMC on upper left corner is shown communicate with a DMS controller in the field that is connected to a DMS sign at left bottom with a message: travel time to... This message is confirmed at TMC software driven-display on workstation at TMC. This shows how a message is monitored at TMC with conformation.)

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

 

Slide 63:

Examples of RTM

Architectural Requirements (3.4.2)

Requirements Traceability Matrix (RTM)
FRID Functional Requirement Dialog ID Object ID Object Name Additional Specifications
3.4.2.3 Retrieve Logged Data H.3.1.3  
      1103 v02 A.7.3.5 eventClassNumRowslnLog  
      1103 v02 A.7.3.6 eventClassNumEvents  
      1103 v02 A.7.7.1 eventLogClass  
      1103 v02 A.7.7.2 eventLogNumber  
      1103 v02 A.7.7.3 eventLoglD  
      1103 v02 A.7.7.4 eventLogTime  
      1103 v02 A.7.7.5 eventLogValue  
3.4.2.4 Clear Log G.3  
      1103 v02 A.7.3.3 eventClassClearTime  

This slide provides an example of architectural requirement. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: This slide provides an example of architectural requirement, Retrieve Logged Data using Dialog H.3.1.3, which is derived from NTCIP 1103 v02 standard. Support Operational Environment with Logged Data exchange - Same as above except communication is to the DMS controller for logged data inquiry. Additional text on this slide: When Connection is Broken or Using Dial-UP Connection: Logged-Data is retrieved at latertime when a broken connection is restored.)

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

 

Slide 64:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 65:

Question

Which of the following statements does NOT apply to RTM?

Answer Choices

  1. RTM includes Architectural Requirements to communicate with sign controller
  2. Includes DMS user needs
  3. Includes dialogs and objects
  4. RTM lists requirements for retrieving data from a remote DMS

 

Slide 66:

Review of Answers

A small graphical red and yellow X representing incorrect.a) RTM includes Architectural requirements to communicate with sign controller
Incorrect answer. The statement is valid. Architectural requirements make interface operational.

A small graphical green and yellow check mark representing correct.b) Includes DMS user needs
Correct! This statement does not apply to RTM since user needs are part of only PRL.

A small graphical red and yellow X representing incorrect.c) Includes dialogs and objects
Incorrect answer. Dialogs and objects for each requirement are provided in RTM.

A small graphical red and yellow X representing incorrect.d) RTM lists requirements for retrieving data from a remote DMS
Incorrect answer. Retrieving data from a DMS is a data exchange function which is included in the RTM.

 

Slide 67:

Learning Objectives

 

Slide 68:

Learning Objective 4

 

Slide 69:

DMS Specification Communications Interface Specification (NTCIP)

Procurement Contract Specifications. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: Procurement Contract Specifications - At bottom right a DMS is shown pointing to sign controller and a TMC Talking to DMS controller. An arrow points to a text box on upper right side. Procurement Contract Specifications text:

1 - Hardware Specifications

Functional Req.
Performance Req.
Structural Req.
Mechanical Req.
Electrical Req.
Environmental Req.

2 - Software Specifications

Functional Req.
Performance Req.

Contractual requirements during:

3 - Communications Interface Specifications

User Needs
Functional Req.
Project PRL, RTM
Testing Documentation

)

 

Slide 70:

DMS Specification Communications Interface Specification (NTCIP)

Building Communications Interface Specifications

Two text boxes with bulleted text on left are shown connected with arrows into a text box on right middle. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: Two text boxes with bulleted text on left are shown connected with arrows into a text box on right middle: Communications Interface Specifications, text below:

What the Standard Provides

What the User Provides

Communications Interface Specifications

User Needs Functional Req.
Project PRL, RTM Testing Documentation

)

 

Slide 71:

Integrate PRL and RTM into a Specification: Interoperability-Coordination Needs

Checklist of Key Elements That Must Be Present

  1. Address Interoperability
  2. Integrate Project PRL and RTM in the Specification
  3. Maintain consistency with DMS product specification
  4. Specific Performance Requirements
  5. Coordination Requirements

Checklist icon used to indicate a process that is being laid out sequentially.

 

Slide 72:

Integrate PRL and RTM into a Specification: Interoperability-Coordination Needs

1. Address Interoperability

Why

How

Checklist icon used to indicate a process that is being laid out sequentially.

 

Slide 73:

Integrate PRL and RTM into a Specification: Interoperability-Coordination Needs

2. Integrate PRL and RTM in the Project Specification

"Give me everything you have" should be avoided. ONLY specify in the project PRL what you need.

Checklist icon used to indicate a process that is being laid out sequentially.

 

Slide 74:

Integrate PRL and RTM into a Specification: Interoperability-Coordination Needs

3. Maintain Consistency with DMS Product Specification

Checklist icon used to indicate a process that is being laid out sequentially.

 

Slide 75:

Integrate PRL and RTM into a Specification: Interoperability-Coordination Needs

4. Performance Requirements

G.5.5 Performance

The DMS shall process the Get, GetNext or Set request in accordance with all of the rules of NTCIP 1103 v02r including updating the value in the database and initiating the transmission of the appropriate response (assuming that the DMS has permission to transmit) within 1 second of receiving the last byte of the request.

Checklist icon used to indicate a process that is being laid out sequentially.

 

Slide 76:

Integrate PRL and RTM into a Specification: Interoperability-Coordination Needs

5. Coordination Requirements

Checklist icon used to indicate a process that is being laid out sequentially.

 

Slide 77:

Compliance and Conformance Requirements

Conformance Versus Compliance

 

Slide 78:

Backward Compatibility Issues

v03 has addressed known issues with backward compatibility. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant description: v03 has addressed known issues with backward compatibility with v01 and v02. 3.3.7.1 - 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. Additional text on the slide follows:

)

 

Slide 79:

Specifying Requirements Not Covered by the Standard (Extensions)

Support for Extensions

 

Slide 80:

Specifying Requirements Not Covered by the Standard (Extensions)

Drawbacks/Consequences

 

Slide 81:

Specifying Requirements Not Covered by the Standard (Extensions)

Rules for Extensions

  1. Dialog definitions and particularly object definitions must follow the same configuration as contained in the standard for those dialogs and object definitions contained in it
  2. Dialogs and object definitions are NOT allowed to be redefined or replaced
  3. All extended work must be published to other parties affected by the DMS operations

 

Slide 82:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 83:

Question

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

Answer Choices

  1. Specification includes PRL-identified user needs
  2. Project RTM provides project-based design content
  3. To achieve interoperability either PRL or RTM is required
  4. Extended standard is not conformant to the DMS standard

 

Slide 84:

Review of Answers

A small graphical red and yellow X representing incorrect.a) Specification includes PRL-identified user needs.
Incorrect answer. The statement is true. PRL must be in every DMS specification because it has user needs and requirements.

A small graphical red and yellow X representing incorrect.b) Project RTM provides project-based design content.
Incorrect answer. The statement is true. RTM is the complete source of DMS design content.

A small graphical green and yellow check mark representing correct.c) To achieve interoperability either PRL or RTM is required.
Correct! The statement is only False. To ensure interoperability, we need both PRL and RTM and SNMP in specification.

A small graphical red and yellow X representing incorrect.d) Extended standard is not conformant to the DMS standard.
Incorrect answer. The statement is true. Vendor-specific design will not be conformant to the standard, even with properly done extensions.

 

Slide 85:

Module Summary

 

Slide 86:

We Have Now Completed A311a and A311b in the DMS Curriculum

A small graphical green and yellow check mark representing correct.Module A311a: Understanding User Needs for DMS
Systems based on NTCIP 1203 Standard v03

A small graphical green and yellow check mark representing correct.Module A311b: Specifying Requirements for DMS
Systems based on NTCIP 1203 Standard v03

SpacerModule T311: Applying Your Test Plan to the NTCIP 1203 v03 DMS Standard

 

Slide 87:

Next Course Module

Module T311: Applying Your Test Plan to the NTCIP 1203 v03 DMS Standard

Concepts taught in next module (Learning Objectives):

  1. Describe within the context of a testing lifecycle the role of a test plan and the testing to be undertaken for DMS
  2. Identify the key elements of NTCIP 1203 v03 relevant to the test plan
  3. Describe the application of a good test plan to a DMS system being procured
  4. Describe a process of adapting a test plan based on the selected user needs and requirements

 

Slide 88:

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!