Module 42 - A315b Part 2 of 2

A315b Part 2 of 2: Understanding Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 Standard Part 2 of 2

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" 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:

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

 

Slide 4:

Module A315b Part 2 of 2:

Understanding Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 Standard

Part 2 of 2

 

Slide 5:

Instructor

Headshot photo of Dave Miller

Dave Miller, Chair: NEMA / AASHTO / ITE

Joint Committee on ATC Chair: 3TS Technical Committee Principal Systems Engineer Siemens Industry, Inc.

RC-US MO MM-ITS R&D

Austin, Texas, USA

 

Slide 6:

Target Audience

  • Traffic management and engineering staff
  • Traffic Management Center / operations staff
  • Traffic signal maintenance staff
  • System developers
  • Software developers
  • Private and public sector users including manufacturers
  • Procurement personnel

 

Slide 7:

Recommended Prerequisite(s)

  • I101: Using ITS Standards: An Overview
  • A101: Introduction to Acquiring Standards-Based ITS Systems
  • A102: Introduction to User Needs Identification
  • A201: Details On Acquiring Standards-based ITS Systems
  • A202: Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content
  • A103: Introduction to ITS Standards Requirements Development
  • A203: Writing Requirements When ITS Standards Do Not Have SEP Content
  • C101: Introduction to the Communications Protocols and Their Uses in ITS Applications

 

Slide 8:

Recommended Prerequisite(s), continued

  • A315a: Understanding User Needs for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 Standard
  • A315b: Specifying Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 Standard Part 1of 2

 

Slide 9:

Curriculum Path

Curriculum Path: A graphical illustration indicating the sequence of training modules that lead up to this course. Please see the Extended Text Description below.

(Extended Text Description: Curriculum Path: A graphical illustration indicating the sequence of training modules that lead up to this course. Each module is represented by a box with the name of the module in it and an arrow showing the logical flow between the modules. There are 11 boxes total, two rows of 4 boxes and one row of 3. The sequence goes from left to right with the fourth box on the first and second rows having arrows which connect to the first box on the second and third rows respectively. The module titles are as follows:

  • I101 Using ITS Standards: An Overview
  • A101 Introduction to Acquiring Standards-based ITS Systems
  • A102 Introduction to User Needs Identification
  • A201 Details on Acquiring Standards-based ITS Systems
  • A202 Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content
  • A103 Introduction to ITS Standards Requirements Development
  • A203 Writing Requirements When ITS Standards Do Not Have SEP Content
  • C101 Intro. to Comm. Protocols and Their Uses in ITS Applications
  • A315a Understanding User Needs for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 Standard
  • A315b Understanding Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 Standard Part 1 of 2
  • A315b Understanding Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 Standard, Part 2 of 2

)

 

Slide 10:

Learning Objectives

Part 1 of 2 covered:

  1. Learn how to develop requirements using the NTCIP 1202 v02 Standard
  2. Achieve interoperability and interchangeability
  3. Understand traceability
  4. Developing the specification

Part 2 of 2 will cover:

  1. Manage special issues specific to ASC
  2. Incorporate requirements not supported by standardized objects

 

Slide 11:

Part 1 Covered: Requirements, Dialogs, and Traceability (RTM for Conformance)

  1. Requirements can be identified from user needs , SEP-based standards , conformance groups and the three (3) perspectives.
  2. Dialogs define rules on how to exchange information while objects define the meaning of the information; both must be defined to achieve interoperability .
  3. Traceability table allows a user to quickly determine why a design feature is included.
  4. An interface specification should reference standards whenever possible rather than copying their content.

 

Slide 12:

Part 1 Provided: Checklist for Interface Specification

See Student Supplement for Part 1*

  • Example Text Included:
    • Boilerplate
    • User needs
    • Requirements (Who generates requirements)
    • Dialogs
    • Any custom objects
    • User needs to requirements traceability table (Who verifies conformance)
    • Requirements traceability matrix (RTM)
    • Communication stack specifications

*Presentation material for Part 1 Module (#32) is available at USDOT PCB website: http://www.pcb.its.dot.gov/stds training.aspx

 

Slide 13:

Part 2 Learning Objectives 6 and 7 Answer Two Questions

Question 1

What are the specific ASC requirements related issues and how to manage them in a project specification?

Question 2

What if certain project requirements are NOT supported by the NTCIP 1202 v02 Standard?

How to properly use Manufacturer-Specific Objects (MSO) and recognize their improper use to avoid conflicts.

 

Slide 14:

Learning Objective #5: Manage Special Issues Specific to ASC

  • Managing requirements: What does it mean?
  • ASC Types vs. Performance Requirements
  • Understand control, parameter, and status objects
  • Understand database transaction sets (i.e. dbcreate, etc.)
  • Understand NTCIP consistency checks and rules
  • Understand block objects
  • Simple Network Management Protocol (SNMP)
  • Simple Transportation Management Protocol (STMP)

 

Slide 15:

Learning Objective #5

1. Managing Requirements: What Does It Mean?

Authorized, Correctly Stated and Testable to Conformance Groups (CGs)

  • Managing requirements means:
    • Associating each requirement to the correct conformance group
    • Correct implementation of objects within the conformance group
    • Correct dialog to meet requirements
  • Requirements gatekeeper:
    • Manages requirements on behalf of authorized stakeholders
    • Enforces the quality of the requirements management process

 

Slide 16:

Learning Objective #5

1. Managing Requirements:

What Does It Mean? (cont.)

Requirements Must be Testable to Conformance Groups

  • Requirements gatekeeper is assigned and is responsible for:
    • Rejecting requirements that are not testable
    • Identifying requirements that cannot be fulfilled by CGs
  • Requirements that cannot be fulfilled by CGs:
    • Manufacturer-Specific Object (later slide)
    • Becomes part of project special terms, conditions, and deliverables

 

Slide 17:

Learning Objective #5

2. ASC Types and Performance Requirements

Legacy: ASC Types in Service for Ten Years

  • Communications: Private line, 1,200 bits per second
  • Performance: Less than 1 million instructions per second (MIPS)
  • Examples: Type 170, NEMA and Electromechanical

Performance is not specified and No Ethernet IP communications

 

Slide 18:

Learning Objective #5

2. ASC Types and Performance Requirements

Modern: Performance of Most ASCs in Service Today

  • Communications: Ethernet Internet Protocol (IP), 10 M bps
  • Performance: Greater than 4 MIPS
  • Examples: ATC 5202 Standard (Model 2070L, 2070E), NEMA TS2
    Performance typically > 4 MIPS and Single 10 Mbps Ethernet port

ATC: Performance of ATC5201 Standard Controllers

  • Communications: (4) Ethernet Internet Protocol (IP), 10 M bps
  • Performance: 60 MIPs minimum, typically > 400 MIPS
  • Examples: ATC5201 (Model 2070LX and Shelf Mount ATC) Performance: 60 MIPS minimum, > 400 MIPS typical Separate internal 10/100 Mbps hubs for Central and Roadside

 

Slide 19:

Learning Objective #5

How Types Affect Performance Requirements (cont.)

Legacy ASC Requirements Constrained by Network Performance:

  • Data traffic is constrained within the available bandwidth
  • Requires additional manufacturer information for testing

Modern ASC Requirements Constrained by Processor Performance:

  • Use of standardized objects eliminates special testing
  • Ethernet IP communications can overwhelm the processor

ATC 5201 Requirements Have the Fewest Constraints:

  • Standardized objects without special testing or documentation
  • Superior computational performance for communications

 

Slide 20:

Learning Objective #5

How Types Affect Performance Requirements (cont.)

Communications Volume Affects Requirements

Requirement to GET status of a ASC continually:

  • Legacy ASCs may be constrained by communications
  • Modern ASCs may be constrained by computational speed
  • Requirement for a Dialog:
    • Legacy ASCs require small dialogs of compact, complex objects that must be documented and tested for each ASC
    • Modern ASCs can use long dialogs of standardized objects but may be constrained to computational speed
    • ATC5201 ASCs can use long dialogs of standardized objects without being constrained by computational speed

 

Slide 21:

Learning Objective #5

Examples: Large Data Download to ASC

  • A single NTCIP central (channel) may be connected to a mixture of:
    • Legacy ASCs communicating via private lines at 1200 bps
    • Modern ASCs communicating via Ethernet IP at 10 Mbps
    • ATC 5201 ASCs communicating via Ethernet IP at 100 Mbps
  • Identical ASC functions may require different NTCIP objects
    • Legacy ASC: SET many objects may overwhelm communications
    • Modern ASC: SET many objects may overwhelm processor
    • ATC 5201 : SET many objects are handled within time constraints

 

Slide 22:

Learning Objective #5

Bandwidth Analysis: Center-to-Field

NTCIP 9001 v04.06 Guide, Annex E

  • Typical SNMP Message Size
    • 26 header bytes of header
    • 23 bytes per data element
  • Typical STMP Message Size
    • 1 byte of header
    • 1 byte per data element
  • STMP is defined within devices
    • Maintain each unique device
    • Test each unique message

Bandwidth Analysis: Center to Field. Please see the Extended Text Description below.

(Extended Text Description: Bandwidth Analysis: Center to Field: A graphic illustration from standard NTCIP 9001 v04.04 Guide, Annex E illustrating the data elements of a typical message. The black text "Information Content" is represented to the right by two adjacent yellow text boxes, the left box text is "Data Element 1", and the right box text is "Data Element 2". Below the "Information Content" boxes, black text "SNMP Packet" is represented to the right by two adjacent yellow text boxes, the left box text is "SNMP Header", and the right box text is "Information Content". A black line connects the lower left corner of "Data Element 1" box to the upper right corner of "Information Content box". A black line connects the lower right corner of the "Data Element 2" box to the upper right corner of the "Information Content" box. Below the "SNMP Packet" boxes, black text "IP Packet" is represented to the right by two adjacent yellow text boxes, the left box text is "Internet Protocol (TCP / IP)", and the right box text is "SNMP Packet". A black line connects the lower left corner of "SNMP Header" box to the upper right corner of "SNMP Packet" box. A black line connects the lower right corner of the "Information Content" box to the upper right corner of the "SNMP Packet" box.)

SNMP requires more bandwidth, but is identical among manufacturers.

 

Slide 23:

Learning Objective #5

3. Understand Control, Parameter, & Status Objects

  • Control objects (C) are sent to an ASC to alter an operation
    • Central monitoring system is required to alter the ASC
    • For example, to SET the ASC time of day on the ASC
  • Parameter objects (P) indicate a range
    • Central system is required to know the ASC capabilities
    • For example, the number of phases serviced by the ASC
  • Status objects (S) are received from an ASC, indicating operation
    • Central monitoring system is required to display ASC data
    • For example, to GET the time of day from an ASC

 

Slide 24:

Learning Objective #5

4. Understand Database Transaction Sets

Transaction Set Effects and Advantages

  • Database transaction sets:
    • Changes the ASC operation, just as a Control Object SET
    • Forces the buffering of multiple objects
    • All of the objects are modified within the ASC at one time
    • Used when required to alter multiple ASC parameters that could have a detrimental effect if not all done at the same time

 

Slide 25:

Learning Objective #5

4. Understand Database Transaction Sets (cont.)

Example: dbcreate

  • Example of Transaction Set:
    • Requirement to change multiple phases at a time of day.
    • If communications is interrupted, none of the phases are altered.
  • Example of dbcreate:
    • Normal mode: SETs are stored in ASC immediately
    • Transaction mode: SETs are buffered until verified with consistency check
    • Used when required to initialize ASCs for safe operation
    • The entire database is configured, sent to ASC, and verified for consistency before the ASC can operate

 

Slide 26:

Learning Objective #5

5. Understand NTCIP Consistency Checks and Rules

  • Consistency Checks:
    • Checks on data received by the ASC
    • Compares the data against expected values
    • Operation is not completed if consistency check fails
    • For example, an error message would occur if one or more defined concurrent phases have the same ring assignment as the new phase or when defining a phase in a ring with that phase number already defined

 

Slide 27:

Learning Objective #5

5. Understand the NTCIP Consistency Checks and Rules (cont.)

  • NTCIP Rules Insure ASC Interoperability:
    • The NTCIP Protocol defines the structure
    • Rules define what is required for interoperability
    • Interoperability requires that both sides of the interface have the same interpretation of the data
    • Interoperability requires that both sides of the interfaces have the same interpretation of the order of the data received

 

Slide 28:

Learning Objective #5

6. Understand the Block Objects

Block Objects are Pre-Defined Sets of Objects

  • Block objects:
    • Provide an efficient method of uploading and downloading
    • Entire ASC database can be uploaded with one block object
    • More efficient than multiple GET objects

 

Slide 29:

Learning Objective #5

6. Understand the Block Objects (cont.)

  • When block object may be needed to meet requirements
    • Block objects fulfill a requirement to GET a snapshot of multiple objects at the same point in time, while multiple GETs result in the status of blocks at different times
    • Block objects are often used to remain within the bandwidth requirements of the communications channel

 

Slide 30:

Learning Objective #5

6. Understand the Block Objects (cont.)

Example: High Resolution Performance Measures

Requirements: The Central shall:

  • Log all ASC vehicle actuations
  • Correlate all logged vehicle actuation to a phase
  • Further correlate to signal color
  • Report correlated data each second

Realization:

  • Phase blocks to GET all phases and colors with timestamp
  • Detector blocks to GET the status of all detectors with timestamp
  • Multiple GETs would not meet 1 second latency requirement

 

Slide 31:

Learning Objective #5

7. Simple Network Management Protocol (SNMP)

SNMP is a Widely Used Communication Protocol Used by Computer Networks

  • Typical SNMP Message Size
    • 26 header bytes of header
    • 23 bytes per data element

Simple Network Management Protocol (SNMP). Please see the Extended Text Description below.

(Extended Text Description: Simple Network Management Protocol (SNMP): A graphic illustration from standard NTCIP 9001 v04.04 Guide, Annex E illustrating the data elements of a typical message. The black text "Information Content" is represented to the right by two adjacent yellow text boxes, the left box text is "Data Element 1", and the right box text is "Data Element 2". Below the "Information Content" boxes, black text "SNMP Packet" is represented to the right by two adjacent yellow text boxes, the left box text is "SNMP Header", and the right box text is "Information Content". A black line connects the lower left corner of "Data Element 1" box to the upper right corner of "Information Content box". A black line connects the lower right corner of the "Data Element 2" box to the upper right corner of the "Information Content" box. Below the "SNMP Packet" boxes, black text "IP Packet" is represented to the right by two adjacent yellow text boxes, the left box text is "Internet Protocol (TCP / IP)", and the right box text is "SNMP Packet". A black line connects the lower left corner of "SNMP Header" box to the upper right corner of "SNMP Packet" box. A black line connects the lower right corner of the "Information Content" box to the upper right corner of the "SNMP Packet" box.)

SNMP requires more bandwidth, but is identical among manufacturers.

 

Slide 32:

Learning Objective #5

8. Simple Transportation Management Protocol

(STMP)

STMP is an Extension of SNMP Developed Specifically for the Transportation Industry

  • Typical STMP message size
    • 1 byte of header
    • 1 byte per data element
  • Messages can be unique
    • Dynamic messages
    • Established when connected
    • Sets of ASC data elements
    • Each end must know how to establish and interpret data

Simple Transportation Management Protocol (STMP). Please see the Extended Text Description below.

(Extended Text Description: Simple Transportation Management Protocol (STMP): Two adjacent orange text boxes, the left box text is "Header", and the right box text is "Composite Data".)

STMP requires little bandwidth, but varies among manufacturers.

 

Slide 33:

Learning Objective #5

STMP Pros: Reduced Bandwidth

Advantages

  • Significantly reduces the number of bytes on the communications channel
  • Data traffic reductions of 25:1 are typical
  • Allows operation via low-speed modems
  • Allows operation on existing twisted pair private phone lines
  • Allows continued use of legacy controllers via a software update that replaces proprietary protocols

 

Slide 34:

Learning Objective #5

STMP Cons: Complexity, Maintenance, Testing

Disadvantages

  • Object identifiers are removed
  • Increases software complexity, STMP objects are unique
  • Increases testing complexity, requires unique test plan per STMP object
  • Data content is not defined by the NTCIP standards, need to know the manufacturer's data structure
  • Because objects are dynamically composed, typically at power-up, each ASC must know how to compose and interpret the composite objects

 

Slide 35:

Learning Objective #5

STMP Related to Requirements

  • What to consider when developing requirements:
    • As Legacy ASCs are replaced, STMP advantages are negated
    • Suggest that STMP only be used to meet requirements to operate ASCs on a low-speed communications channel
    • Absent of bandwidth restrictions, consider the project cost and milestone requirements, as well as the total cost of ownership using SNMP vs. STMP
    • System expansion via competitive bids would need each manufacturer to develop similar dynamic objects
    • Configuration management costs to archive and maintain the configuration of each ASC, vs. identical SNMP objects
    • Regression testing costs of each dynamic object

 

Slide 36:

Additional Information Provided in the Student Supplement

  • Background on ASC Types in Service
  • Managing ASC Specific Requirements
    • Communications loading
    • Clock coordination

Additional Information Provided in the Student Supplement: A graphic of the A315b Student Supplement cover appears on the slide.

 

Slide 37:

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

 

Slide 38:

Learning Objective #5

Which of the following is NOT part of managing requirements correctly?

Answer Choices

  1. Associating each requirement to the correct conformance group
  2. Correct implementation of objects within conformance group
  3. Correct dialog to meet requirements
  4. Adding a new requirement received via email

 

Slide 39:

Learning Objective #5

Review of Answers

A small graphical red and yellow X representing incorrect.a) Associating each requirement to the correct conformance group
Incorrect. Each requirement is fulfilled by a conformance group.

A small graphical red and yellow X representing incorrect.b) Correct implementation of objects within conformance group
Incorrect. Content of each object must be correct.

A small graphical red and yellow X representing incorrect.c) Correct dialog to meet requirements
Incorrect. Objects must transact in the correct sequence.

A small graphical green and yellow check mark representing correct.d) Adding a new requirement received via email
Correct! Gatekeeper insures that the requirement came from an authorized source is well-stated and includes an incremental estimate of cost and schedule impact before review and approval by stakeholders.

 

Slide 40:

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

 

Slide 41:

Learning Objective #5

How do ASC types affect requirements?

Answer Choices

  1. Different objects and dialogs needed to meet identical requirements
  2. Legacy ASCs require the use of compact, complex objects
  3. ATC 5201 ASCs handle long dialogs of standardized objects
  4. Legacy ASCs are being replaced within existing budgets and have standardized objects
  5. All of the above

 

Slide 42:

Learning Objective #5

Review of Answers

A small graphical green and yellow check mark representing correct.a) Different objects and dialogs needed to meet identical requirements
Correct. Legacy ASCs are constrained to short dialogs.

A small graphical green and yellow check mark representing correct.b) Legacy ASCs require the use of compact, complex objects
Correct. Legacy ASCs are constrained to low speeds.

A small graphical green and yellow check mark representing correct.c) ATC 5201 ASCs handle long dialogs of standardized objects
Correct. Each object can be standardized with ID.

A small graphical green and yellow check mark representing correct.d) Legacy ASCs are being replaced within existing budgets and have standardized objects
Correct. Suppliers build only Modern, ATC 5201, ATC 5202.

A small graphical green and yellow check mark representing correct.e) All of the above
Correct! All of the above are true.

 

Slide 43:

Summary of Learning Objective #5

Manage Requirements Specific to ASC

We discussed each of the following issues:

  • Managing requirements: What does it mean?
  • ASC Types vs. Performance Requirements
  • Understand control, parameter and status objects
  • Understand database transaction sets (i.e. dbcreate, etc.)
  • Understand NTCIP consistency checks and rules
  • Understand block objects
  • Simple Network Management Protocol (SNMP)
  • Simple Transportation Management Protocol (STMP)

 

Slide 44:

Learning Objective #6: Incorporate Requirements Not Supported by Standardized Objects

  • Proper use of manufacturer-specific objects to support advanced functions beyond TS-2
  • Improper use of manufacturer-specific objects that creates conflicts with standards
  • Example of manufacturer-specific object for advance function
  • Example of contract wording to avoid improper use of manufacturer-specific objects
  • Adaptive control and architectures
  • Exception-based reporting
  • Verify NTCIP conformance

 

Slide 45:

Learning Objective #6

1. Proper use of Manufacturer-Specific Objects

What are MSOs ?

Manufacturer-specific objects(MSO) are:

  • Objects defined by ASC manufacturers and developers
  • Allowed by the NTCIP Standards
  • Implemented to support advanced functions beyond TS-2 Standard

 

Slide 46:

Learning Objective #6

1. Proper Use of Manufacturer-Specific Objects

MSOs Versus Optional Objects

  • Optional objects are defined by the NTCIP Standard
  • MSOs are defined by ASC manufacturers
  • Optional objects are interoperable
  • MSOs are not interoperable

 

Slide 47:

Learning Objective #6

1. Proper Use of Manufacturer-Specific Objects (cont.)

To Support Advanced Functions Beyond TS-2

  • Proper use of MSOs:
    • Allows innovation and new features beyond TS-2 functionality
    • Provides a migration path to optional if widely used
    • Example of MSO migration:
    • Purdue University Indiana Performance Measures began as a private NTCIP node for interoperability
    • Adopted by three manufacturers to date
    • Appearing in contract specifications beyond Indiana

 

Slide 48:

Learning Objective #6

2. Improper Use of Manufacturer-Specific Objects

Creates Conflicts with Standards

  • Manufacturer-specific objects (MSOs) are:
    • Never a substitute for standardized NTCIP objects that perform similar functions
    • Not to be used as a disguise for proprietary protocols

 

Slide 49:

Learning Objective #6

2. Improper Use of Manufacturer-Specific Objects (cont.)

Examples of Improper Uses

  • Replace mandatory object
  • Replace optional object
  • Wrapper for proprietary protocols

 

Slide 50:

Learning Objective #6

Example of Manufacturer-Specific Objects

For Advanced Function

Proper MSO Use for Adaptive Control:

  • User Need: ASC signal timing needs to automatically adjust based on vehicles departing nearby ASCs
  • Requirements:
    • ASC shall detect vehicles departing intersection
    • ASC shall transmit detection of departing vehicles to central
    • Transmission of departures shall occur once per second
    • Central shall adjust signal timing on all ASCs once every three seconds
  • Analysis:
    • No standard mandatory object meets the requirement
    • No standard optional object meets the requirements

 

Slide 51:

Learning Objective #6

3. Example of Manufacturer-Specific Objects

Adaptive Control

Proper MSO Use for Adaptive Control (continued):

  • Create the following MSOs to meet requirements:
    • PhasesToStage MSO to configure each combination of non-conflicting Phases as Stage ID
    • StageNext MSO to force ASC to a stage of non-conflicting phases that best handles arrivals from all directions
  • Deliverables:
    • Documentation for two MSOs for interoperability
    • List of mandatory objects provided
    • List optional object required for ASC interoperability

 

Slide 52:

Learning Objective #6

4. Example of Contract Wording

Learn to Avoid Improper Use of MSOs

  • Example contract wording:
    • All mandatory objects shall be provided
    • All optional objects required for ASC functions shall be listed
    • No MSOs are allowed except as listed in the procurement contract for advanced functions not contained in NTCIP Standards

 

Slide 53:

Learning Objective #6

5. Exception-Based Reporting

What is Exception Reporting ?

  • NTCIP 1103 v03 contains common transportation management protocols and is referenced by NTCIP 1202 v02
  • Defined events are reported by ASC when they occur
  • Eliminates the need to poll each ASC to avoid missing an event
  • Significantly reduces communications loading to many ASCs
  • Use of exception-based reporting to meet requirements
    • Required number of bits to GET required status from all ASCs
    • Required additional communications bits, SETs, etc.
    • Required update rate
    • If the required data exceeds the available bandwidth, exception-based reporting may be used to meet requirements

 

Slide 54:

Learning Objective #6

5. Exception-Based Reporting (cont.)

Example

  • User needs to:
    • Maintain the status of 12,000 ASCs
    • Use existing communications infrastructure
  • Requirements:
    • Central data shall update within 1 second
    • Central shall monitor 12,000 ASCs
  • Design:
    • Existing communications infrastructure bandwidth constrains polling of each ASC to 76 ASCs per second
    • Central sets each database for initialization
    • ASCs push exceptions to central that identify data changes

 

Slide 55:

Learning Objective #6

6. Verify NTCIP Conformance

Conformance to Requirements

  • Include NTCIP conformance in contract terms and conditions
  • Require lists of mandatory and optional objects for each ASC as a deliverable
  • For interoperability, dialogs for each function must be included
  • Conformance for 1202 v3 will be different than 1202 v2
  • MSOs should be contractually forbidden except for features not defined by NTCIP
  • Acceptance terms should be included in the contract
  • Develop RTM to insure conformance and reinforce conformance

 

Slide 56:

Learning Objective #6

6. Verify NTCIP Conformance (cont.)

Use of Test Scripts

  • Test scripts should be required to test interfaces before equipment is installed using off-the-shelf testers
  • Test scripts are a record of dialogs that are installed on an off-the-shelf tester that simulates the connected device
  • Test scripts are provided by the systems engineer
  • Test scripts define the interfaces of the high-level design

 

Slide 57:

Learning Objective #6

6. Verify NTCIP Conformance (cont.)

Verify, Not Enforce

  • Use the Requirements Traceability Matrix (RTM)
  • Verify each requirement ID using the test scripts
  • Ideally, the test scripts are available to the manufacturers

Verify NTCIP Conformance (cont.). Please see the Extended Text Description below.

(Extended Text Description: Verify NTCIP Conformance (cont.): Six adjacent green text boxes, the left box contains the white text "RID", the next box to the right contains the white text "Requirement", the next box to the right contains the white text "Dialog (Design), the next box to the right contains the white text "Object ID", the next box to the right contains the white text "Object", the next box to the right contains the white text "Dialog (Test)".)

 

Slide 58:

Additional Information Provided in the Student Supplement

  • Adaptive Systems
    • List of available Adaptive Systems
    • Requirements for Adaptive Systems
    • MOS example for Adaptive Control

Additional Information Provided in the Student Supplement: A graphic of the A315b Student Supplement cover appears on the slide.

 

Slide 59:

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

 

Slide 60:

Learning Objective #6

Why should dialogs be defined in a procurement specification?

Answer Choices

  1. Devices are more likely to conform to the standards
  2. Devices are more likely to interoperate and interchange
  3. Increases the total cost of ownership
  4. Device costs are likely to be less expensive

 

Slide 61:

Learning Objective #6

Review of Answers

 

A small graphical red and yellow X representing incorrect.a) Devices are more likely to conform to the standard
Incorrect. Dialogs are not part of the standards. Dialogs are part of the design used to meet project requirements.

A small graphical green and yellow check mark representing correct.b) Devices are more likely to interoperate and interchange
Correct! Dialogs promote a common expectation on how objects are to be exchanged among devices.

A small graphical red and yellow X representing incorrect.c) Increases the total cost of ownership
Incorrect. Interoperability results in lower integration and testing costs. Interchangeability allows competitive bids of standard equipment throughout the service life of the system.

A small graphical red and yellow X representing incorrect.d) Device costs are likely to be less expensive
Incorrect. Specifying longer dialogs of standardized objects might require upgrading or relocating legacy ASCs.

 

Slide 62:

Summary of Learning Objective #6

Incorporate Requirements Not Supported by Standardized Objects

  • MSOs are used only for ASC functions not defined by NEMA TS-2
  • Using MSOs to replace standardized objects:
    • Creates conflicts with the NTCIP Standards
    • Breaks interoperability with other manufacturers
  • Adaptive control is an example of an MSO properly used to automatically adjust signal timing, which is not defined by TS-2
  • Procurement contracts should contain wording that prohibits the use of MSOs to replace standardized functions defined by NEMA TS-2

 

Slide 63:

Summary of Learning Objective #6

Incorporate Requirements Not Supported by Standardized Objects (cont.)

  • Adaptive control algorithms are used to automatically adapt signal timing to approaching vehicles
    • "Per-second" automatic adjustments before vehicle arrivals
    • Not based on traditional timing plans or actuations of vehicles that have already arrived
    • Immediate response to incidences and events
  • Exception-based reporting can be used to meet requirements for large ASC deployments lacking bandwidth to poll each ASC
  • Verification should be a contract term, not an afterthought, including the expected results of test scripts using off-the-shelf test equipment

 

Slide 64:

What We Have Learned

  1. The same functionality may lead to different requirements for ASC performance types.
  2. Depending upon requirements, parameter, control and status can be realized as individual objects, block objects, transaction sets.
  3. STNP should be avoided to use standardized objects when communicating on modern networks.
  4. ASC clock coordination is constrained by service power, communications, and coordination type.

 

Slide 65:

What We Have Learned

  • Manufacturer-specific objects are properly used for functions not defined by optional and mandatory objects.
  • Except for their proper use, manufacturer specific objects should be banned by contract terms and conditions.
  • Adaptive control is an example of a manufacture-specific object used to meet requirements not possible by using standard objects.
  • Exception-based reporting can be used to receive status changes without repeatedly polling all ASCs on the communications network.
  • Contract terms should include requirements traceability matrix and test scripts for standard 3rd party test equipment.

 

Slide 66:

Resources

  • Institute of Transportation Engineers, ATC 5201 Advanced Transportation Controller (ATC) Standard Version 06. ATC Joint Committee, 30 July 2012.
  • Institute of Transportation Engineers, ATC 5202 Model 2070 Controller Standard Version 03. ATC Joint Committee, 28 December 2012.
  • Institute of Transportation Engineers, Intelligent Transportation System (ITS) Standard Specification for Roadside Cabinets v01.02.17b. ATC Joint Committee, 16 November 2006.
  • National Electrical Manufacturers Association, NEMA Standards Publication TS 2-2003 v02.06 Traffic Controller Assemblies with NTCIP Requirements. NEMA, 2003.
  • California Department of Transportation, Transportation Electrical Equipment Specification. Caltrans, March 12, 2009
  • Federal Highway Administration, AASHTO Connected Vehicle Infrastructure Deployment Analysis, Publication FHWA-JPO-11-090, June 17, 2011
  • US Department of Transportation, Systems Engineering for Intelligent Transportation Systems, USDOT, January 2007
  • NTCIP 12xx, Device Data Dictionaries and NTCIP Guide (available at ntcip.org)

 

Slide 67:

Questions? A placeholder graphic image with word Questions? at the top, and an image of a lit light bulb on the lower right side.