Module 6 - A201

A201: Details On Acquiring Standards-Based ITS Systems

HTML of the PowerPoint Presentation

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

Slide 1:

(Extended Text Description: Slide 1: 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” 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 are the words “RITA Intelligent Transportation Systems Joint Program Office.”)

Slide 2:

Welcome

Shelley Row, P.E., PTOE

Director

ITS Joint Program Office

Shelley.Row@dot.gov

(Extended Text Description: Slide 2: Screen capture snapshot of RITA website - for illustration only. Below this image is a link to the current website: https://www.its.dot.gov/pcb - this screen capture snapshot shows an example from the RITA website from June 3, 2011. At the top of the page it shows the RITA logo with the text Research and Innovative Technology Administration - Intelligent Transportation Systems. Below the main site banner, it shows the main navigation menu with the following items: About RITA, Communities of Interest, Contact Us, Press Room, RITA Offices, Site Map, and a Search button. Below the main navigation menu, it shows a sub-navigation menu with the following items: About Us, T3 Webinars, ITS Peer-to-Peer, Resources, Local ITS PCB and Testimonials. Beneath the sub-navigation menu, the page is sub-titled "ITS Professional Capacity Building Program" and is divided into sub-sections such as "Welcome to ITS Professional Building", "News", "ITS Technical Assistance" and "Scheduled T3 Webinars". Again, this image serves for illustration only. The current website link is: https://www.its.dot.gov/pcb)

ITS PCB Home

(Note: There is additional text attached to this slide that includes the following introductory information from Shelley Row):

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

I am Shelley Row the director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly redesigned ITS standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines web based modules with instructor interaction to bring the latest in ITS learning to busy professionals like you.

This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the webinars.

ITS Standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program we prepare professionals to adopt proven and emerging  ITS technologies that will make surface transportation safer, smarter and greener which improves livability for us all. You can find information on additional modules and training programs on our web site ITS PCB Home.

Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you for participating and we hope you find this module helpful."

Slide 3:

A201: Details On Acquiring Standards-Based ITS Systems

Slide 4:

Target Audience

• Project managers
• Engineering staff
• Public and private consultants

Slide 5:

Instructor

Robert Rausch, P.E.

Vice President
TransCore ITS, LLC
Norcross, GA, USA

Slide 6:

Recommended Prerequisites

I101 Using ITS Standards: An Overview
A101 Introduction to Acquiring Standards-based ITS Systems
A102 Introduction to User Needs Identification

• Basic knowledge of the following is helpful
  • Intelligent Transportation Systems (ITS)
  • Managing ITS deployment projects
  • Government procurement processes
  • Systems Engineering Process (SEP)

Slide 7:

Curriculum Path (SEP)

(Extended Text Description: This is a chart showing the curriculum path for implementing a system that uses standards that are based on the systems engineering process. A linear box chart starting with I101 – Using Standards: An Overview with an arrow leading to A101 – Introduction to Acquiring Standards-based ITS Systems with an arrow leading to A102 – Introduction to User Needs Identification with an arrow leading to A201 – Details on Acquiring Standards-based ITS Systems (highlighted in purple) with an arrow leading to A311a-A321a– Understanding User Needs with an arrow leading to A311b-A321b – Specifying Requirements for NTCIP.)

Slide 8:

Curriculum Path (Non-SEP)

(Extended Text Description: A chart showing the curriculum path for implementing a system that uses standards that are not based on the systems engineering process. A linear box chart starting with I101 – Using Standards: An Overview with an arrow leading to A101 – Introduction to Acquiring Standards-based ITS Systems with an arrow leading to A102 – Introduction to User Needs Identification with an arrow leading to A201 – Details on Acquiring Standards-based ITS Systems (highlighted in purple) with an arrow leading to A202 – How to Identify and Write Standards-based ITS User Needs with an arrow leading to A103 – Introduction to ITS Standards Requirements Development with an arrow leading to A203 – Writing Standards-based ITS System Requirements with an arrow leading to A3xxa – Understanding User Needs Based on NTCIP 12xx vxx with an arrow leading to A3xxb – Specifying Requirements based on NTCIP 12xx vxx. The last two boxes are denoted with an asterisk that indicates these two modules are expected in year 2 of the training program.)

Slide 9:

Learning Objectives

1. Identify how to use the standards to achieve your Procurement Goals
2. Identify the process to be used to procure standards-based ITS systems and devices
3. Identify the standards that are likely to apply to your system or device procurement
4. Understand the general content of the SEP and non-SEP standards
5. Learn to incorporate the standards into your procurement documents

Slide 10:

Slide 11:

Poll Questions

1. Has your agency purchased NTCIP "conformant" traffic controllers?
2. Did you specify any special features or functions that were not part of a standard?
3. Did the vendor provide any special features unique for your operation?
4. Were they interchangeable with the previous traffic controllers (without changes to your cabinets or systems)?

Slide 12:

Slide 13:

Poll Questions

5. Has your agency purchased NTCIP "conformant" dynamic message signs?
6. Did you specify any special features or functions that were not part of a standard?
7. Did the vendor provide any special features unique for your operation?
8. Were they interchangeable with the previous DMS deployed (without changes to your cabinets or systems)?
   

Slide 14:

Slide 15:

Discussion

1. What proved to be the greatest challenge with multi-vendor procurement?

Type answers in the chat pod

Slide 16:

Discussion

2. How could you have prevented this problem or mitigated the risks associated with your procurement?

Type answers in the chat pod

Slide 17:

Learning Objective # 1

How Standards Fit into Overall ITS System Procurement

• ConOps identifies the operational role of the systems and devices that you plan to deploy
• Standards support two aspects of the specification process:
  • The communications interface requirements among the systems and ITS devices
  • The construction requirements for the ITS devices
• Goal: to support incremental deployment of interoperable systems and devices

Slide 18:

Learning Objective # 1

Application of the Standards

(Extended Text Description: This graphic indicates the progressive application of the standards. The first line is concept-of-operations – what you want the systems/devices to do. An arrow points diagonally downward to the right where there is a second line of text – Requirements (Select the requirements from the PRL/NRTM). Additional text at this level indicates that the job is to identify the value ranges or specific values were necessary such as the number of messages supported, number of fonts, etc.). These first two ideas are on a background highlighted in yellow. From the requirements, a diagonal line pointing downward to the right points to the dialogs (select the dialogs to be supported). Then, there is another diagonal line pointing downward to the right to the line of text: messages and data elements. Finally, there is a line of copy below this labeled “test procedures” and there is a curved line pointing from the Requirements as noted above to the test procedures indicating that the requirements drive the development of the test procedures. These last three lines of text are not highlighted with a yellow background. )

Slide 19:

Learning Objective # 1

Application of the Standards

(Extended Text Description: This is a repeat of the previous graphic on Slide 18, but instead of highlighting the concept-of-operations and requirements, the lines with text dialogs, messages and data elements, and test procedures are highlighted with a yellow background. The point of these two slides is that the sequence is actually divided into 2 phases: the first phase is the definition of the concept of operations and requirements as identified by the end user, while the second phase is the detailed design of the dialogs, messages, and data elements which has been developed by the standards working group. For SEP standards, the user can stop at the identification of the requirements and leave the details to the standard and the vendor. For the non SEP standards, the end user is responsible to specify the dialogs, messages, and data elements.)

Slide 20:

Learning Objective # 2

Recall the Systems Engineering Process

(Extended Text Description: This image contains the “V” diagram from the systems engineering process. The main graphic of the SEP is the V with some additional horizontal “wings” on the left and right side of the top of the V. Starting from the left “wing” the steps are regional architecture, needs assessment, concept selection, and systems engineering management planning. At this point the steps begin to descend the left side of the V with concept of operations, system requirements, high-level design subsystem requirements, detailed design, and software coding and hardware fabrication. At this point the steps begin to ascend the right side of the V with unit testing, subsystem integration, subsystem verification, system integration system verification, initial deployment, system validation, and operations and maintenance. At this point the steps are on the right “wing” of the V with changes and upgrades and retirement/replacement. These SEP steps can also be described as parts of phases which are listed across the top of the graphic: Phase -1 (Interfacing with Planning and the Regional Architecture), Phase 0 (Concept Exploration and Benefits Analysis), Phase 1 (Project Planning and Concept of Operations Development), Phase 2 (System Definition and Design), Phase 3 (System Development and Implementation), Phase 4 (Validation, Operations and Maintenance, Changes and Upgrades), Phase 5 (System retirement/replacement). Numerous cross-cutting activities are listed vertically to the left of the V diagram: Stakeholder involvement, Elicitation, Project Management Practices, Risk Management, Program Metrics, Configuration Management, Process Improvement, Decision Gates, Trade Studies, Technical Reviews, and Traceability. The ascending side of the “V” is highlighted and the word “testing” referring to it. The space between the descending and ascending sides of the “V” is highlighted with the word “traceability” referring to it.)

Slide 21:

Learning Objective # 2

Understanding your ConOps

(Extended Text Description: This image also contains the “V” diagram from the systems engineering process as described in Slide 20. In this slide, a diagonal arrow points from the words “it is important to understand what the system is intended to do” to the concept-of-operations which is highlighted with a transparent yellow oval.)

Slide 22:

Learning Objective # 2

Developing the ConOps

• Generate some examples or concepts of operation that you think might be important for the development and deployment of an ITS system in your region or city
  • What do you want to do using the system?
  • What ITS devices do you need to deploy to support your system?
  • What do you need these devices to do to satisfy your need for the system?

• Be as explicit as possible: It will drive detailed requirements and hence the use of the ITS standards.

Slide 23:

Learning Objective # 2

Read and Understand Your Regional Architecture

• Provides stakeholder perspective
• Identifies likely centers within the region
• Identifies roles and responsibilities of the stakeholders that operate the centers
• Identifies the interconnections between centers

Slide 24:

Learning Objective # 2

Developing the ConOps

Examples:

• Provide Traveler Information
  • What level of detail, for what purpose?
• Incident Detection
  • What type of incidents are you trying to detect?
  • How quickly do you want to detect?
• Regional Incident Management
  • Exchanges with other systems
  • Traveler information dissemination
  • Share ITS devices (fixed and portable DMS)
  • Detour and alternate route management
• Multimodal Interactions
  • What is your operational purpose?
  • Improved reliability, shorter travel times?

Slide 25:

Learning Objective # 2

Developing the ConOps

More examples:

Off-hours Operations and Maintenance Improved Freeway Capacity

• Active Traffic Management
  • Dynamic lane control
  • Dynamic/variable speed limits
  • Ramp metering
  • Diversion/detour management
• Increased Roadway Capacity
  • Reversible lane operation
    • Lane control signals
    • Gates
  • HOV lane management
  • HOT price management

Slide 26:

Learning Objective # 2

Developing the ConOps

More examples:

• Traffic/Roadway Monitoring
  • Level of accuracy
  • Length of segments, purpose of data, etc.
• Improved Traffic Flow (capacity of surface streets)
  • Traffic signal coordination
  • Synchronize timing plans
  • Regional Integration
  • Exchanges with other systems
• Special event management
• Highway assistance dispatch
• Links to SCADA or other devices
  • Tunnels, underpasses
  • Highway lighting

Slide 27:

Learning Objective # 2

Developing the ConOps

More examples:

• Safety Applications
  • Curve speed warning
  • Roadway speed warning
• Parking Information Enforcement
  • Exclusive Bus Lane
  • Speed limits
  • Red light
• Towing Management Integration of RWIS
  • High winds
  • Fog warning
  • Freeze warnings
  • High water
• Construction Zone Management
• Evacuation Route Management

Slide 28:

Learning Objective # 2

Refining the ConOps

Developing a deployment plan

• As you review and develop your ConOps
  • Identify what your systems are to do operationally
  • Identify the devices you plan to deploy
    • Identify how the devices will meet your ConOps
  • Refine your interactions with other systems

Slide 29:

Learning Objective # 2

Include Performance Requirements

• Your operational requirements will impact your performance requirements
• Identify the performance requirements for your applications and exchanges
  • Second-by-second
  • Once-per-minute updates
  • 20-second data collection
  • Event-driven notification

Slide 30:

Learning Objective # 2

Develop an Implementation Architecture

• Based on the ConOps:
  • Develop a physical architecture that identifies what devices will be used, their role, and locations
  • Develop a systems architecture that identifies the systems and the interconnection of systems that will be used, their role, and locations

Reminder - regional architecture should provide guidance

Slide 31:

Learning Objective # 2

Document Your Communications Requirements

• As part of your deployment plan, it is essential to quantify the communications system requirements
  • How frequently do you need to communicate to the device - and why?
  • What is the nature of the communications requirements for each device?

Slide 32:

Learning Objective # 2

Recap

Before we employ the standards as part of the procurement process:

• Document what you want to do (ConOps)
• Identify what you want the systems and devices to do to support your ConOps
  • Functional Requirements for the devices and information exchanges
  • Performance Requirements for the actions and exchanges

Slide 33:

Learning Objective # 2

Recap continued

Before we employ the standards as part of the procurement process:

• Develop a high level physical architecture for your system
  • Decision making systems (central systems)
  • ITS field devices - CCTV, DMS, traffic controllers, lane control signs, ramp meters, data collection, lighting control, etc.
  • e.g. what equipment and systems you plan to deploy to support your ConOps
• Document what you want these devices and systems to do for you
  • What are the specific functions for the various devices

The standards used will be determined by the interfaces, and devices you have identified

Slide 34:

Slide 35:

Learning Objective # 2

(Extended Text Description: This is a graphic depicting a street network. There is a major interstate connecting the upper right corner to the lower left corner labeled I-1. There are intersecting streets labeled S1 and S2 perpendicular to the interstate indicating major surface streets that commuters use to access the freeway. There is a circular interstate or ring road which covers the City proper and is labeled I-201 which is typical for ring interstate highways. Outside the ring road on the south west side, there are 2 additional major surface streets labeled S3 and S4 which connect commuters locate on the southwest side of the city to the interstate I-1. There is an additional interstate roadway which connects the center of the city I-1 to the eastern side of the perimeter highway. There is a star and a stadium shown in the south eastern quadrant of the area inside the ring road, to the east of the NE to SW interstate I-1 and south of the major highway connecting I1 to the I201 ring road on the east side. The center of the circle bears the text “city center arterial network”.)

Slide 36:

Learning Objective # 2

Exercise

• Let's walk through a specific freeway management system example
• Suggested goals for the system
  • To provide travel times for route options
  • To provide alerts regarding traffic conditions and alternate routes around incidents
  • To distribute incoming traffic to available event parking
  • To mitigate freeway traffic breakdown occurring at peak hours where possible

Slide 37:

Exercise (Continued)

Let's assume you will be constructing a single central system (or adding to an existing one)

• What ITS devices would you deploy and for what purpose? Provide several examples.
• What other systems would you likely need to communicate with?

Enter your suggestions in the chat pod

Slide 38:

(Extended Text Description: This graphic contains the same base diagram as Slide 35: Our Roadway Network, but now shows the addition of ITS devices including ramp meters at the intersection of the surface streets S1,S2,S3 and S4 as they “meter” traffic onto the Interstate I1 in the direction of the central city. The slide also shows the placement of variable message signs for the inbound direction of I1 just before the intersection with S1 and S2 and on the inbound direction from the southwest quadrant as they enter onto I1 heading northbound toward the City. There are a few message signs around the east side perimeter largely used to direct event parking for the stadium in the SW quadrant of the inner city. There are additional signs on the Interstate to assist in directing people to the appropriate parking spaces as they approach the stadium on I1.)

Slide 39:

Learning Objective # 2

Document the ConOps and Device Requirements

• Identify concepts of operation and ITS system and device requirements based on the preceding discussions.

Enter your suggestions in the chat pod

Slide 40:

Learning Objective # 3

Where Standards Come Into Play

This next section will describe the standards role in the typical ITS deployment and hence their role in the procurement process.

• Look at what standards are likely to be applicable from a high-level physical architecture.

Slide 41:

Learning Objective # 3

What is Covered by the Standards

(Extended Text Description: This image is a diagram with pictures of a Variable message sign on a cantilever structure, a CCTV camera, and two traffic signals. These devices are spread horizontally along the lower right hand quadrant of the slide and connect to a single horizontal line indicating a network connection to a picture of a personal computer. There are a total of three personal computers with double headed arrows indicating center-to-center communications with the first computer and the first computer indicates double headed arrows to all of the field devices. )

Slide 42:

Learning Objective # 3

ITS Communications Standards

(Extended Text Description: This is a block diagram showing three management centers along the top. The left one and the center one are labeled “traffic management center” and the third (right hand most) one is labeled “emergency management center”. There is a colored box on top of a double headed arrow between the center “traffic management center” and each of the other two centers. This box is labeled C2C indicating center-to-center, and is colored red indicating that there is a standard that has been through the SEP process to handled this connection. Below the middle box there is a vertical line with double headed arrow that connects to boxes labeled ACC, actuated signal controller, CCTV Cameras & Switches, Data Collection & Monitoring (DMC), Traffic Sensor Systems (TSS), Field Management Station (a.k.a. SSM – Signal Station Master (SSM), Environmental Sensor Stations , Dynamic Message Signs, Electrical Lighting Management Systems, Signal Control Priority, Ramp Meters (RMC), Cabinet Monitoring Unit – CMU (Under development). Of the boxes listed above, the CMU is green indicating it is under development, the ASC, CCTV, DCM, and RMC boxes are colored in light blue indicating there is not standards available (at the time this course was developed); the balance have the SEP content.)

Slide 43:

Learning Objective # 3

Communications Infrastructure

• Understand the actual requirements for each of the devices before selecting a specific solution
• Identify the bandwidth and latency requirements for devices
• The communications infrastructure
  • What is available, or
  • Broader communications planning for the area
• Services/technology commonly used
  • Leased hardwired services (DSL, T1, Cable, dial-up)
  • Wireless services (3G, WiMax)
  • Existing infrastructure (wireless or wired)
  • Custom: fiber, wireless, various technologies, microwave, etc.

Slide 44:

Learning Objective # 3

NTCIP Protocol Standards

Application Level Protocol

• Center-to-center
  • DATEX 2304 (not widely deployed)
  • Web Services - 2306
• Center-to-field
  • File Transfer Protocol - 2303
  • Trivial File Transfer Protocol - 2302
  • SNMP - 2301/1103
  • Traps (Exception Based Reporting) - 1103
  • STMP - 2301/1103

Lower Layers

• Transport Level
  • TCP/IP - 2202
  • UDP/IP - 2202
  • T2/NULL - 2201
• Sub-network Level
  • PPP - 2103
  • Ethernet - 2104
  • PMPP - 2101 & 2102

Slide 45:

Learning Objective # 3

Hardware Standards

• It is important to understand the requirements that the field hardware must meet to satisfy your ConOps
  • The ConOps should drive the requirements included in your RFP, not the "available hardware"

Slide 46:

Learning Objective # 3

Hardware Standards

• Examples of hardware standards include
  • NEMA TS4 (Dynamic message signs)
  • NEMA TS2-2003 (Traffic Signal Controllers)
  • Advanced Transportation Controller (ATC)
    • Includes 2070
    • API
    • ATC
    • ITS Cabinet
  • Some states have their own hardware standards

Slide 47:

Learning Objective # 3

Know Your Devices!

• WARNING: Not all devices support all of the protocols or capabilities described in the NTCIP standards!
  • DMS do not support STMP
  • Only the ASC is known to support the 1103 traps
  • Requiring 255 phases just because the standard allows this may limit or eliminate vendors unnecessarily.
• It is important to understand what features and functions are generally available rather than specify a custom collection of requirements
• Proprietary objects and features -> non-interoperable systems

Slide 48:

Learning Objective # 3

Application of the Standards

(Extended Text Description: This slide is identical to Slides 18 and 19 for the "Application of Standards". The only exception is that the dialogs line now says “select the dialogs to be supported").

Slide 49:

Learning Objective # 3

Developing the Requirements

(Extended Text Description: This slide contains the is identical to "V" diagram from the systems engineering process from Slide 21. Only in this slide, the phrase “The requirements emerge from the ConOps and drive the remainder of the project” now appears with a diagonal arrow pointing to a transparent oval that highlights System requirements. )

Slide 50:

Learning Objective # 3

Standards Provide Detailed Information

(Extended Text Description: This "V" diagram from the systems engineering process is identical to diagram on Slide 21. On this slide, however, the phrase “The RTM then points to the specifics for a conformant implementation.” now appears with a diagonal arrow pointing to a transparent oval that highlights “the high level design and detailed design”. )

Slide 51:

Definitions

• Conformance
  • A product conforms to the standard if it meets the specific conformance requirement stated in the standard.
• Compliance
  • A product complies to a specific procurement specification if it meets all of the requirements stated in the specification.

Slide 52:

Learning Objective # 4

Requirements Example

• Consider the requirements for each of the ITS devices and communications between the device and the TMC
  • Focus on DMS as a device example
    • Sign type, color, size, message content, etc.
    • There should be a why for each issue
    • Reference 1203 for examples

Slide 53:

Slide 54:

Learning Objective # 4

DMS Assumptions

For the Example:

• What aspects of the DMS do you feel were needed?

Enter your list in the chat pod

Slide 55:

Learning Objective # 4

DMS Assumptions

For the Example:

• Signs are full matrix - able to show graphics
• Signs are three color LED - yellow, green, red
• Sign Size - 27x120 -7 LED's create an 18 inch character
• Signs to use IP communications over fiber (or wireless)
• Signs will present up to three "phases"
• Minimum of 4 fonts
• All messages will be sent to the sign for display
  • No message library at the sign
• There is no scheduler at the sign

Slide 56:

Learning Objective # 4

Some other Considerations

• Will the signs be on the side of the road?
• Will the signs be over the road?
• How will one gain access for service?
• What is your preferred structure?
• Will it be walk-in design?

Slide 57:

Learning Objective # 4

Let's Use the SEP Content

Goal: show how the content of the standards with the SEP content can be an aid in the development of the ConOps

Slide 58:

Learning Objective # 4

Using The SEP Enhanced Standards

Example

• Introduce the content of the SEP enhanced standards
  • TMDD and DMS examples
• ConOps in the standards is an aid to understanding the types of functions available
  • Need to reference when developing ConOps (TMDD)
• Provide an overview of the structure of the standards
  • Protocol 2301,1103
  • Communications
  • Dialogs 12xx
  • Content 12xx

Slide 59:

Learning Objective # 4

The Content of NTCIP 1203

• Introductory Material
  • Introduction and Normative References
  • Glossary Terms
    • Relate to the specific operation of the device
• ConOps for the device
  • Description of the device functionality as it relates to the communications interface
• Functional Requirements
  • Describes the requirements based on the user needs from the ConOps.
  • Includes a PRL to be used by the specifier to identify the specific features/functions (requirements) for a specific implementation or procurement
• Dialogs and interface specification
  • This level of detail is used by the vendor and tester
• Object definitions

Slide 60:

Learning Objective # 4

1203 Details -1

• User Needs - Section 2
  • Fundamental Needs for what a DMS should do
    • Exchanging of data
    • Logging of data
    • Condition reporting
  • All of the functions of a DMS
    • Intensity, characters, message display, prioritize messages, control external devices, blank, Diagnostics, monitor sign conditions (temp, door, etc.)

Slide 61:

Example user need (2.5.2.5)

Control the Brightness Output

This feature enables the operator to control the sign brightness either directly or through an automated algorithm, depending on the capabilities of the DMS. At a minimum, the operator should be able to control brightness of the sign display manually for light emitting signs. In addition, the operator should be able to control the brightness level through the use of light sensors (photocells) on the DMS, if available, that can detect the ambient light levels and adjust brightness levels in an appropriate fashion. This brightness control is needed to compensate for the external environment's effect on the visibility of the message, such as when the sun is shining in the eyes of travelers.

Slide 62:

1203 Details - 2

Learning Objective # 4

Section 3 - DMS Functional Requirements

• Details for the functions of the sign are described
• Protocol Requirements List (PRL):

User Need Section Number	User Need	FR Section Number	Functional Requirement	Conformance	Support / Project Requirement	Additional Project Requirements
2.5.2.5	Control the Brightness Output			Lamp OR LED OR Fiber:M	Yes / NA
		3.5.2.5.1	Determine Number of Brightness Levels	V	Yes
		3.5.2.5.2	Determine Current Photocell Readings	AutoBright:M	Yes / NA
		3.5.2.5.3	Manually Direct-Control Brightness	0.6	Yes / No	This functionality is not applicable to Version 1. Select this or the next option (Manually Index-Control Brightness) depending on desired operation.
		3.5.2.5.4	Manually Index-Control Brightness	0.6	Yes / No	This functionality is not applicable to Version 1. Select this or the previous option (Manually Direct-Control Brightness) depending on desired operation.
		3.5.2.5.5	Manually Control Brightness	0	Yes / No	This functionality is only applicable to Version 1. Describe in detail how this operation is supposed to work in order to achieve backwards compatibly.

(Additional Notes from Author: In this table the headings are as follows from left to right: User need section number, user need description, FR Section number indicating functional requirements function number, a description of the functional requirement, a column indicating whether the item is supported or not, mandatory or not, and a column for additional comments.
In this instance the chart is developing the brightness concept for the dynamic message signs and the rows contain the various sections numbers from the standard. )

Slide 63:

Example Requirement - (3.5.2.5)

Control Sign Brightness

3.5.2.5 Control Sign Brightness
Requirements for controlling the brightness of the message on the sign face are provided in the following subsections.

3.5.2.5.1 Determine Number of Brightness Levels
The DMS shall allow a management station to determine the maximum number of (settable) brightness levels.

3.5.2.5.2 Determine Current Photocell Readings
The DMS shall allow a management station to determine the current photocell readings.

3.5.2.5.3 Manually Direct-Control Brightness (Version 2)
The DMS shall allow a management station to manually control the light output of the display by selecting any of the brightness levels supported by the DMS.

Slide 64:

Learning Objective # 4

1203 Details - 3

• Section 4 then identifies the specific dialog or sequence of operations required by the implementer to be conformant:

(Extended Text Description: Relevant descriptive information provided by author for this figure: This slide contains a UML sequence diagram; the user along the top is a stick-figured man labeled Management Station, the other box along the top is labeled DMS. The diagram is a time sequenced interaction between these 2 processes and descriptive information. The management station sends a SET operation for the brightness to the DMS. If everything is OK, a response is sent back to the management station indicating all status is OK. If not, it responds with a message shown as a horizontal line to the left indicating an error, then the management station then sends a get command, another horizontal line to the right to retrieve the error condition which ends this exchange. A box to the right indicates the same transaction in text form.)

Slide 65:

Learning Objective # 4

1203 Details - 4

Section 5 contains the Management Information Base (MIB)

• Object Definitions for configuring the device, controlling the device, and monitoring the device

5.8.5 Status of Illumination Brightness Level Parameter

dmsIllumBrigh-levelStatus OBJECT-TYPE
SYNTAX INTEGER (0. .255)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"<Definition> Indicates the current Brightness Level of the device, ranging from 0 (OF?) zo the maximum value given by the dmalllumNumBrigh-levela-object (Brightest).
<Object Identified 1.3.6.1.4.1.1206.4.2.3.7.5"
: := ( ilium 5 }

Slide 66:

Learning Objective # 4

1203 Details - 5

• The new standards which contain SEP content will include a Requirements Traceability Matrix (RTM)
  • Traces requirements to dialogs and specific objects
  • Note that 1203 also references specific objects in NTCIP 1201
  • To be conformant the system/device MUST implement the interface as contained in standard
  • Content will be discussed in subsequent courses

Slide 67:

Learning Objective # 4

TMDD Standard

• ConOps - Volume 1 Section 2
  • Explains the needs for the inter-system exchanges
• Requirements for the exchanges
• Needs to requirements matrix
  • Traces the needs to the requirements and allows the agency to identify what operational needs and requirements are included for their project
•  Volume II shows the dialogs and message contents used to satisfy the requirements and is typically used by the system integrator and tester to verify conformance to the standard.

Slide 68:

Learning Objective # 4

TMDD - Content - Examples

Volume 1, Section 2 identifies typical User Needs for center-to-center communications.

2.3.6.4 Need to Share DMS Status and Control

2.3.6.4.1 Need to Share DMS Inventory
2.3.6.4.2 Need to Share Updated DMS Inventory
2.3.6.4.3 Need to Share DMS Status
2.3.6.4.4 Need to Display a Message on a Remote DMS
2.3.6.4.5 Need to Verify DMS Control Status
2.3.6.4.6 Need to View DMS Message Queue
2.3.6.4.7 Need to Cancel DMS Message Requests
2.3.6.4.8 Need to Share DMS Message Appearance
2.3.6.4.9 Need to Share DMS Message Inventory
2.3.6.4.10 Need to Share DMS Font Table

Slide 69:

Example User Need from TMDD

2.3.6.4.1 Need to Share DMS Inventory

Centers need to exchange DMS inventory information so that DMSs operated by a center can become known to other centers. Centers need to exchange DMS device attributes so that the capabilities of the DMS devices operated by the owner center can become known to external centers. Inventory information includes static DMS device attributes such as:

• Location (including direction of traffic the DMS is facing);
• Size (physical dimensions, characters per line, number of lines); and
• Type (technology, permanent versus portable).

Slide 70:

Learning Objective # 4

TMDD - Content Examples (Continued)

Volume 1, Section 3 identifies typical User Requirements for center-to-center Communication.

3.3.6.5 Dynamic Message Signs

3.3.6.5.1 Share DMS Inventory Information
3.3.6.5.2 Share DMS Status Information
3.3.6.5.3 Control Requests for Remote DMS Devices
3.3.6.5.4 Request DMS Control Status
3.3.6.5.5 Cancel Control Requests for Remote DMSs
3.3.6.5.6 Share DMS Message Appearance
3.3.6.5.7 Share DMS Message Table
3.3.6.5.8 Share DMS Font Table
3.3.6.5.9 Share DMS Priority Queue Information

Slide 71:

Learning Objective # 4

Example Requirement from TMDD

The requirements device information request:

3.3.6.1.1.1 Contents of Device Information Request
The external center shall send a device information request to an owner center.

3.3.6.1.1.1.1 Required Device Information Request Content
The device information request sent from an external enter to an owner center shall include:

a. Unique identifier of the owner organization;
b. Device type (detector, CCTV camera, video switch, dynamic message sign, environmental sensor station, gate, highway advisory radio, lane control signal, ramp meter, ramp meter controller, signal controller and signal section);
c. Device information type (device inventory, device status, device schedule, device plan, device maintenance history, device data, device metadata, message appearance, device font table).

Slide 72:

Learning Objective # 4

TMDD-NRTM Example

UN ID	User Need	UN Selected	Requirement ID	Requirement	CFRM	Support
2.3.6.4.1	Need to Share DMS Inventory	Yes / No	3.3.6.1.1.1	Contents of Device Information Request	M	Yes
			3.3.6.1.1.1.1	Required Device Information Request Content	M	Yes
			3.3.6.1.1.1.2.1	Username of the Requesting Operator	O	Yes / No
			3.3.6.1.1.1.2.2	Password of the Requesting Operator	O	Yes / No
			3.3.6.1.1.1.2.3	Owner Organization	O	Yes / No
			3.3.6.1.1.1.2.4	Organization	O	Yes / No
			3.3.6.1.1.1.3	Content of Device Information Request Filter	O	Yes / No
			3.3.6.1.1.1.3.1	Device Identifier Filter	O	Yes / No
			3.3.6.1.1.1.3.5	Route Designator Filter	O	Yes / No
			3.3.6.1.1.1.3.6	Linear Reference Filter	O	Yes / No
			3.3.6.1.2.1	Contents of the Device Inventory Header	M	Yes
			3.3.6.1.2.1.1	Required Device Inventory Content	M	Yes

(Additional Notes from Author: This table shows a segment of the TMDD NRTM for the user need to share DMS inventory. The labels across the top are UN ID for user need ID, User need expressed in text, a column indicating whether the user need is selected, a requirement ID to trace back to the actual documented requirement, a brief description of the requirement, a column labeled CFRM indicating whether it is mandatory or optional, and a column for the specifyer or agency to indicate, for these features that are optional, which ones are selected by circling the word yes or no. In this case, the table is copied from the TMDD version 3.0.)

Slide 73:

Review

Standards with the SEP content include:

• Concept of Operations - User Needs
• Functional Requirements
• Protocol Requirements List (PRL)
  • User needs > Requirements
  • Agencies use the PRL and identify specifics
• Requirements Traceably Matrix
  • Requirements > Dialogs and Data elements

Agencies can use the PRL and simply mandate that the dialogs and data elements conform to the standards for all selected functions - leads to interoperability.

Slide 74:

Learning Objective # 4

Some Standards Do Not Include the SEP Content

• Examples:
  • C2F: Actuated Signal Controller (NTCIP 1202)
  • C2C: IEEE 1512 Family of messages
• Without the ConOps, it is up to the agency to identify the functions, dialogs, and "objects" needed
  • This is much more difficult

Slide 75:

Learning Objective # 4

Application of the Standards - Non SEP

(Extended Text Description: This diagram is similar to Slide 18: A graphic indicating the progressive application of the standards. The first line is concept-of-operations – what you want the systems/devices to do. An arrow points diagonally downward to the right where there is a second line of text – Document your Requirements. From the requirements, a diagonal line pointing downward to the right and phrase “select the functions from the conformance groups". There is additional text at this level: Identify the value ranges or specific values where necessary (number of phases, rings, etc.). Then there is another diagonal line pointing downward to the right to the line of text: Select Specific Objects and value ranges where necessary to meet requirements. Finally, there is a line of copy below this labeled “develop test procedures” and there is a curved line pointing from the Requirements as noted above to the test procedures indicating that the requirements drive the development of the test procedures. )

Slide 76:

Learning Objective # 4

Understanding Your Requirements

• Examples of features/functions that need to be addressed for actuated signal control
  • Phase based control
    • Number of phases, rings
  • Interval based control
    • Number of intervals
  • Support for TSP
    • Functionality to be provided, hardware interfaces
  • Special functions at the intersection
    • Flashing Yellow Arrow
  • Scheduler

Slide 77:

Learning Objective # 4

NTCIP 1202 - Based on NEMA TS2 Functional Description

Section 2 - Object Definitions
Section 3 - Block Definitions
Annex A - Information Profile
PRL for various conformance groups
Annex B - Rules for consistency check
Annex C - Concept-of-operations
>> Really only a description of generic dialogs <<

Slide 78:

Conformance Groups (1202) - Example

A.3 Phase Conformance Group
A.4 Detector Conformance Group
A.5 Volume Occupancy Report Conformance Group
A.6 Unit Conformance Group
A.7 Special Function Conformance Group
A.8 Coordination Conformance Group
A.9 Time Base Conformance Group
A.10 Preempt Conformance Group
A.11 Ring Conformance Group
A.12 Channel Conformance Group
A.13 Overlap Conformance Group
A.14 TS 2 Port 1 Conformance Group
A.15 Block Object Conformance Group ...

Slide 79:

Learning Objective # 4

Sample 1202 Conformance Group

CONFIGURATION CONFORMANCE GROUP
NTCIP 1201 Clause	Object Name	Object Type	Object Status	Object Support	Allowed Values	Supported Values
2.2	Global Config Conformance Group	—	M	Yes		----
2.2.1 2.2.2 2.2.3	globalSetIDParmeter globalMaxModules globalModuleTable	S S ---	2.2 : O 2.2 : M 2.2 : M	Yes / No Yes Yes	0-65535 1-255 ---	---
2.2.3.1 2.2.3.2	moduleTableEntry moduleNumber moduleDeviceNode	--- S S	2.2 : M 2.2 : M 2.2 : M	Yes Yes Yes	--- 1-255 OID	---
2.2.3.3 2.2.3.4 2.2.3.5	moduleMake moduleModel moduleVersion	S S S	2.2 : M 2.2 : M 2.2 : M	Yes Yes Yes	String String String
2.2.3.6	moduleType other(1) hardware(2)	S --- ---	2.2 : M --- ---	Yes Yes / No Yes / No	1-3 --- ---	--- ---
2.2.4	software(3) controller-baseStandards	--- S	--- 2.2 : O	Yes / No Yes / No	--- String	---

(Additional Notes from Author: This table contains columns labeled: NTCIP 1201 Clause, Object Name, Object Type, Object Status, Object Support, Allowed Values, and then Supported Values. The first column indicates a specific clause number such as 2.2.1 taken from the existing NTCIP 1201 standard, its actual name – in this case globalSetIDParameter which is a single word with various capitalizations imbedded to indicate its origin. The object status indicates if it is mandatory or optional, the column of object support is a place for the agency or manufacturer to circle yes or no, the values allowed are based on the object, and the supported values column allows the agency to specify minimums and maximums that must be supported. This example is the “Global config conformance group” and hence there are no supported values.)

Slide 80:

Learning Objective # 4

globalSetIDParameter

Global Set ID Parameter globalSetlDParameter OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"<Definition> Specifies a relatively unique ID (e.g., this could be a counter, a check-sum, etc.) for all user-changeable parameters of the particular device-type currently implemented in the device. Often this ID is calculated using a CRC algorithm.
This value shall be calculated when a change of any static database object has occurred. The value reported by this object shall not change unless there has been a change in the static data since the last request. If the actual objects, which are to be included to create this object value, are not defined in the actual device-level standard such as 1202 or 1203, then the general guidance is to include all configuration objects that are stored in a type of memory that survives power outages.
A management station can use this object to detect any change in the static database objects by monitoring this value after it has established a baseline.
<Object Identifier> 1.3.6.1.4.1.1206.4.2.6.1.1"
::= { globalConfiguration 1}

Slide 81:

Learning Objective # 4

Application of the Standards - Non-SEP

(Extended Text Description: This diagram is identical to Slide 75: A graphic indicating the progressive application of the standards. The first line is Concept-of-Operations – what you want the systems/devices to do. An arrow points diagonally downward to the right where there is a second line of text – Document your Requirements. From the requirements, a diagonal line pointing downward to the right and phrase “select the functions from the conformance groups). There is additional text at this level: Identify the value ranges or specific values where necessary (number of phases, rings, etc.). Then, there is another diagonal line pointing downward to the right to the line of text: Select Specific Objects and value ranges where necessary to meet requirements, Finally, there is a line of copy below this labeled “develop test procedures” and there is a curved line pointing from the Requirements as noted above to the test procedures indicating that the requirements drive the development of the test procedures. )

Slide 82:

Learning Objective # 5

Your Procurement Document

Your procurement documents should include the following:

• A discussion of your concept-of-operations
• A listing of the devices your expect to be supplied in your system
• A detailed listing of the requirements taken from the NRTM or PRL of the SEP standards that identify the functions to be supported, value ranges, and optional capabilities required

Slide 83:

Learning Objective # 5

Your Procurement Document

Your procurement documents should include (cont.):

• A detailed listing of the objects, conformance classes, and functions to be supported, value ranges, and optional capabilities for non SEP standards
• Include language that requires that the interface be implemented using the standardized dialogs and associated objects in order to be conformant (for SEP based Standards)
• An overview of the testing program that will be required to verify conformance to the standards and compliance to your procurement documents

Slide 84:

Learning Objective # 5

WARNING

• The standards are not perfect - and some may undergo changes as technology and new functions are "requested" - e.g. Flashing Yellow Arrow
• Extending the standard is acceptable but must be well documented and follow prescribed procedures; such extension will likely render an implementation non-interoperable.
• Vendors may claim "conformance to the NTCIP standards" but may not provide all features and value ranges allowed in the standards.
• Beware of "cherry picking" from manufacturers datasheets. Stick to the functions you really need to meet your ConOps.

Slide 85:

Learning Objective # 5

WARNING - Part 2

• Avoid specifying proprietary features
• Avoid specifying proprietary objects
• Both will result in non-standard, non-interoperable solutions
• If you must have a new or different "feature" document thoroughly for all to use.

Slide 86:

Summary

• We have looked at the development of a ConOps and what it should include
• We have discussed the content of several standards (SEP and NON-SEP)
• We have discussed many of the broader issues when procuring interoperable ITS systems and equipment
• Subsequent courses will walk through the process of using each of the standards more thoroughly

Slide 87:

Let's Review

• The first step in the procurement process is the development of the Concept of operation(ConOps)
• Using ConOps the next step in the procurement process is Document the functional requirements
• For Standards with proper SEP content, the following are used by the agency to select the elements of the standards:
  • NRTM - Needs to requirements matrix(TMDD)
  • PRL - Protocol requirements list

Slide 88:

Let's Review - Continued

• For Non SEP standard, the first two steps are the same:
  • Concept of operation (ConOps)
  • Document the functional requirements
• The burden for documenting the functionality to be supported, including dialogs and data elements rests with the agency. Non SEP standards typically include: ConformanceGroups
• But the description of the functions is shown on the contents of the Data Elements or references other standards such as TS2.

Slide 89:

Learning Objectives

1. Identify how to use the standards to achieve your Procurement Goals
2. Identify the process to be used to procure Standards-based ITS systems and devices
3. Identify the standards that are likely to apply to your system or device procurement
4. Understand the general content of the SEP and Non-SEP standards
5. Learn to incorporate the standards into your procurement documents

Slide 90:

Curriculum Path (SEP)

(Extended Text Description: This is a chart showing the curriculum path for implementing a system that uses standards that are based on the systems engineering process. A linear box chart starting with I101 – Using Standards: An Overview with an arrow leading to A101 – Introduction to Acquiring Standards-based ITS Systems with an arrow leading to A102 – Introduction to User Needs Identification with an arrow leading to A201 – Details on Acquiring Standards-based ITS Systems with an arrow leading to A311a-A321a– Understanding User Needs (highlighted in purple) with an arrow leading to A311b-A321b – Specifying Requirements for NTCIP.)

Slide 91:

Curriculum Path (Non-SEP)

(Extended Text Description: A chart showing the curriculum path for implementing a system that uses standards that are not based on the systems engineering process. A linear box chart starting with I101 – Using Standards: An Overview with an arrow leading to A101 – Introduction to Acquiring Standards-based ITS Systems with an arrow leading to A102 – Introduction to User Needs Identification with an arrow leading to A201 – Details on Acquiring Standards-based ITS Systems with an arrow leading to A202 – How to Identify and Write Standards-based ITS User Needs with an arrow leading to A103 – Introduction to ITS Standards Requirements Development with an arrow leading to A203 – Writing Standards-based ITS System Requirements with an arrow leading to A3xxa – Understanding User Needs Based NTCIP 12xx vxx with an arrow leading to A3xxb – Specifying Requirements Based on NTCIP 12xx vxx. The last two boxes are denoted with an asterisk that indicates these two modules are expected in year 2 of the training program. Box A202 is now highlighted.)

Slide 92: