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 Student Supplement

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

 

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

Table of Contents

Introduction/Purpose - 2

Basic Overview - 2

Samples/Examples - 2

Reference to Other Standards - 11

Case Studies - 12

Glossary - 13

References - 14

Study Questions - 14

 

Module Description

This module is part of the non-SE path, thus students must learn how to specify requirements based on well-written user needs specific to the ASC Standard in A315a: Understanding User Needs for Actuated Traffic Signal Controllers Based on NTCIP1202 Standard. A315b, Part 1: Understanding Requirements for Actuated Signal Controllers Based on NTCIP 1202 Standard addressed the next step of the systems life cycle, to develop well-formed requirements specific to the ASC. This module addresses learning how to manage special issues specific to ASC and how to incorporate requirements that are not supported by standardized objects.

 

1. Introduction/Purpose

The purpose of this module is to provide the student with a short review of identification and development of well-formed requirements specific to the NTCIP 1202 v02 ASC Standard, which was covered in A315b, Part 1. Following the review of Part 1, the focus of this module is to assist technical staff in identifying and managing special issues specific to ASCs, plus how to fulfill requirements that are not supported by standardized objects of NTCIP 1202.

This module assumes that the participant, having taken A315a and A315b Part 1, understands how to develop well-formed requirements based on the identified needs to meet ASC controller functions.

This module picks up with a short review of A315b, Part 1, and then continues forward with student instructions to manage special issues specific to ASC. Finally, the module focuses upon fulfilling requirements that are not supported by standardized objects of the NTCIP 1202 standard, while preserving interoperability through contract terms and conditions.

 

2. Samples/Examples

The following text provides example topics discussed in the presentation, plus related topics that were not included in the presentation due to time constraints. These topics cover four areas:

2.1. Review of A315b, Part 1 module content

2.1.1. Developed requirements to fulfill User Needs using NTCIP 1202 v02

2.1.2. Achieved interoperability and interchangeability using a "bottom up" approach starting from Conformance Groups of the NTCIP 1202 v02 standard

2.1.3. Created a traceability link from each requirement back to the original user need to insure complete coverage of stakeholder expectations

2.1.4. Created a requirements specification for stakeholder acceptance

2.2. Transitioning to A315b, Part 2 module content

2.2.1. Manage special issues specific to Actuated Signal Control that are not found within other roadside devices: What are the specific ASC requirements-related issues and how do we manage them in a project specification?

2.2.2. Successfully incorporate requirements that are not supported by the standardized objects to meet unique User Needs: What is the proper use of MSOs and how is their improper use recognized and eliminated to avoid conflicts?

2.3. A315b, Part 2 module content

2.3.1. Requirements Management

2.3.1.1. Requirements Management means:

Associating each requirement to the correct Conformance Group Correctly implementing each object within Conformance Group Designing correct dialogs of objects to meet requirements

2.3.1.2. Requirements Gatekeeper:

Manages the requirements on behalf of the authorized stakeholders in the project

Enforces the quality of the requirements management process Rejects requirements that are not testable or are unauthorized

2.3.1.3. Managing "leftover" requirements not fulfilled by Conformance Groups, while remaining within the NTCIP 1202 framework

Proper use of Manufacturer Specific Objects

Project contract Terms and Conditions

2.3.2. ASC Types and Performance Requirements for each

2.3.2.1. Legacy ASC: Low MIPS, low- speed communications

2.3.2.2. Modern ASC: Limited MIPS, network interface controller

2.3.2.3. ATC5201 ASC: High speed, (2) network interface controllers

2.3.3. Control, Parameter and Status Objects

2.3.3.1. Control: C2F messages that alter the ASC operation

2.3.3.2. Parameter: F2C messages that request ASC capabilities

2.3.3.3. Status: F2C messages that indicate ASC operation

2.3.4. Database Transaction Sets

2.3.4.1. Used to buffer of multiple Set objects

2.3.4.2. Avoids detrimental effects of individual Sets at different times

2.3.5. NTCIP Consistency Checks and Rules

2.3.5.1. Compares C2F data to expected ranges

2.3.5.2. Returns error message if data is unexpected, "sanity check"

2.3.6. Block Objects

2.3.6.1. Efficient, compressed C2F and F2C communications

2.3.6.2. Commonly used for Legacy ASCs with slow communications

2.3.6.3. Vary among manufacturers, adds design and testing costs

2.3.7. Simple Network Management Protocol (SNMP)

2.3.7.1. Widely used by computer networks

2.3.7.2. Objects are identical among manufacturers, no unique testing

2.3.8. Simple Transportation Management Protocol (STMP)

2.3.8.1. Extension of SNMP developed for the Transportation Industry

2.3.8.2. Compact messages, but differ among manufacturers

2.3.8.3. Each end requires special software to interpret STMP messages

2.3.9. Proper Use of Manufacturer Specific Objects

2.3.9.1. MSOs are defined by ASC manufacturers, not by the standards

2.3.9.2. Allowed by standards for functions beyond TS-2 Standard

2.3.9.3. MSOs differ from Optional Objects, MSO are not interoperable

2.3.9.4. MSOs must be carefully documented and archived

2.3.10. Improper Use of Manufacturer Specific Objects

2.3.10.1. MSOs are not a substitute for mandatory or optional objects

2.3.10.2. MSOs should not be a disguise for proprietary protocols

2.3.11. Adaptive Control Example of MSO

2.3.11.1. MSO1 to assign Phases to Stages

2.3.11.2. M SO2 to set Stage that moves the most traffic

2.3.11.3. Deliverable: MSO1 and MSO2 documentation

2.3.12. Suggested Contract Deliverables- Manufacturer shall provide:

2.3.12.1. All mandatory ASC objects

2.3.12.2. All Optional objects needed for ASC operation

2.3.12.3. MSOs for only special requirements listed in the contract, if any

2.3.13. Exception Based Reporting

2.3.13.1. Included n NTCIP 1103 v03, referenced by NTCIP 1202 v02

2.3.13.2. Defined events are reported by ASC immediately (F2C)

2.3.13.3. Eliminates need for central to poll each ASC

2.3.14. Verify NTCIP Conformance

2.3.14.1. Conformance: Verification, not enforcement

2.3.14.2. Include RTM and Test Scripts in contract terms in the beginning

2.3.14.3. Verification by all stakeholders throughout the life of the project

2.3.14.4. Success: (Design Dialogs = Test Dialogs) as part of deliverables 2.4. Additional Information beyond A315b, Part 2 module content

This section is included to provide a deeper dive into additional topics beyond those included within the limited time constraints of the module. These topics are identified to avoid adverse effects on project delivery and system performance if not handled properly by ASC Requirements.

2.4.1. Background on ASC Types in Service The module content discusses "Types" of ASCs and their related performance requirements. Lacking an industry-wide definition of ASC "Type", this training module references the "Controllers in Service" section of publication FHWA-JPO-11-090 cited in the References below. From a survey of ASC manufacturers, the number of ASCs in service was analyzed for their readiness for Connected Vehicle applications in terms of performance, without regard to manufacturer, owner/operator or age of equipment. The 307,000 controllers estimated to be in service in 2011 were split into the nine "Types", based on four performance factors:

  Controller Type Speed Comm OS API In Service
1 ATC 5.2b Yes Yes Yes Yes 8,000
2 Model 2070LX Yes Yes Yes Yes 0
3 Model 2070E Yes Yes Yes No 0
4 Model 2070L Yes Yes Yes No 52,000
5 NEMA. Modern Yes Yes 33% No 36,000
6 NEMA, Legacy No Adaptor Yes No 91,000
7 Type 170, Modern Yes Yes No No 12,000
8 Type 170, Legacy No Adaptor No No 102,000
9 Electromechanical & Other No No No No 6.000
          Total: 307,000

Table 7: Types of Controller in Service in the U.S.

As can be seen in Table 7, only three differences exist among "Types". For the purpose of this training module, the "Types" refer to:

Importance of ASC types and the effect on requirements:

Future trends that affect ASC requirements:

The survey of Table 7 was conducted in 2011. When writing requirements, be sure to anticipate the situation at the future point in time the ASC will be installed. The installed base is a moving target as shown in the graph below. All major manufacturers produce ATC 5201 ASCs; no major manufacturer produces Legacy ASCs. Assuming a 10-year service life, Legacy ASCs are being naturally replaced within existing budgets, avoiding the testing cost and risk of using non-standardized objects.

Future Trends graphic is a line chart. Please see the Extended Text Description below.

(Extended Text Description: Author's relevant notes: Future Trends graphic is a line chart, with controllers in service on the Y axis and calendar year on the X axis. A red line indicates In Need of Replacement, a blue line indicates Technology- Ready and a green line indicates Total Installed Base. This graphic was created new for this Supplement.)

 

Red: Legacy ASCs requiring non-standardized objects, being replaced within existing budgets Blue: Replacement ASCs that handle longer dialogs of standardized objects Green: Total installed base of ASCs

2.4.2. Calculating Communications Loading Historically, ASCs communicated via private phone lines using dedicated circuits, such as modems. Beginning in the mid-1990s, modern network ports such as Ethernet began to appear on ASCs. Although ASCs are manufactured with network ports, replacement of the private phone lines with faster communications media such as fiber is costly. Engineers faced with the requirement to retain the copper phone lines are encouraged to calculate the expected communications loading over the expected life of the system. Next, compute the total cost of ownership to contrast the test and maintenance expense of compressed but non-standard objects, versus the long-term cost of simply replacing the older modems with modern communications equipment, such as DSL that can handle the higher network traffic of standardized objects without replacing the existing phone lines.

2.4.3. ASC Clock Coordination When writing ASC requirements, be sure to analyze the control strategy used and how the selected control strategy affects the ASC clock coordination. Be aware that absolute accuracy may not be an important requirement, while precise clock accuracy can be detrimental when allowed to accumulate over long periods of time.

2.4.4. Adaptive Control Adaptive control is an advanced function beyond the TS2 standard that automatically adjusts signal timing based on approaching traffic in real-time. For example, vehicles leaving an intersection might be reported to a central system that calculates new timings for all ASCs based on arrivals from nearby intersections. The results would be sent to each intersection every second to allocate the most efficient use of GREEN times. Refer to the USDOT website for a list of Adaptive Control systems such as ASC Lite, funded by USDOT and others. Adaptive control is not described by the NEMA TS-2 standard and is neither a Mandatory nor an Optional Object in NTCIP 1202. Adaptive control can be properly implemented as MSOs to meet requirements for efficient traffic flow in response to changing conditions such as sporting events.

Hypothetical example of proper MSO use for Adaptive Control:

 

3. Reference to Other Standards

 

4. Case Study: Connected Vehicle Safety Pilot, Ann Arbor MI

Although most vehicles and mobile devices know their GPS location, over 30,000 highway fatalities occur because mobile devices are unaware of others that are on a collision trajectory. USDOT partnered with two ASC manufacturers to broadcast interoperable Signal Phase and Timing (SPAT) messages to nearby vehicles for red light violation warnings to drivers. Although the driver may see a Green signal or be distracted, the vehicle will warn that the signal will be Red at arrival, based on the vehicle location, heading and speed. The SPAT object definitions that were developed closely follow the NTCIP framework. Two proof-of-concept corridors were installed in Ann Arbor MI. The Geddes Road corridor operates as a time-base coordinated green wave with dynamic yield points that changes signal timing. The Plymouth Road corridor operates as an adaptive control strategy that automatically adjusts the signal timing every three seconds ahead of approaching vehicles. Each corridor broadcasts SPAT messages to 3,000 vehicles equipped to receive the messages, which are used to warn drivers of red light violations before they occur for collision avoidance.

This Safety Pilot Model Deployment demonstrates the value of the ITS standards. In this deployment, the Central Station from one manufacturer communicates to ASCs from a second manufacturer using the NTCIP 1202 objects. The ASCs from each manufacturer were of the Modern Type, meaning that the Connected Vehicle messages were added by simply updating the software in the ASCs without hardware update or replacement.

The new SPAT objects were level-tested before system integration by a third party, using an automated simulation tool running on a personal computer. The simulation tool was supplied to project stakeholders to verify conformance throughout the design of the objects and dialogs. The collected data was used by NHTSA for the February, 2014, NHTSA decision to begin legislation requiring the technology on future new vehicles. The system map is shown in Figure 1:

Figure 1 is an area map of the USDOT Safety Pilot Model Deployment. Please see the Extended Text Description below.

(Extended Text Description: For illustration only: Figure 1 is an area map of the USDOT Safety Pilot Model Deployment depicting Ann Arbor MI and the location of Connected Vehicle installed equipment. This graphic was reproduced from the USDOT Model Deployment website.)

Figure 1: Safety Pilot Model Deployment, USDOT

 

5. Glossary

Term Definition
Agency Specification A document that has been prepared by an agency to define requirements for a subject item or process when procured by the agency.
API Application Program Interface
C2F Center to Field
Compliance A condition that exists when an item meets all of the requirements of an agency specification.
Concept of Operations A document that describes the purpose for a system project, including a description of the current and proposed system, as well as key user needs that the new system is required to address.
Conformance A condition that exists when an item meets all of the mandatory requirements as defined by a standard. It can be measured on the standard as a whole, which means that it meets all mandatory (and applicable conditional) requirements of the standard or on a feature level (i.e., it conforms to feature X as defined in section X.X.X), which means that it meets all mandatory (and applicable conditional) requirements of the feature.
DC Direct Current
DSL Digital Subscriber Line
F2C Field to Center
GPS Global Positioning System
Hz Hertz
IP Internet Protocol
MIPS Millions of instructions per second
Modem Modulator / Demodulator
MSO Manufacturer-specific object
NHTAS National Highway Traffic Safety Administration
SPAT Signal Phase and Timing

 

6. References

 

7. Study Questions

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

  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

2. How do ASC types affect requirements?

  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

3. Why should dialogs be defined in a procurement specification?

  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. Devices are likely to be less expensive