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
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.
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.
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:
- Review of requirements developed in A315b Part 1 as a refresher leading in to A315b Part 2
- Preview of Part 2 Learning Objectives: What will be covered in this presentation?
- Presentation content: What special ASC issues arise when writing a procurement specification that affects the project requirements?
- Additional information beyond the presentation: Additional issues and detailed information.
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
22.214.171.124. 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
126.96.36.199. 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
188.8.131.52. 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
184.108.40.206. Legacy ASC: Low MIPS, low- speed communications
220.127.116.11. Modern ASC: Limited MIPS, network interface controller
18.104.22.168. ATC5201 ASC: High speed, (2) network interface controllers
2.3.3. Control, Parameter and Status Objects
22.214.171.124. Control: C2F messages that alter the ASC operation
126.96.36.199. Parameter: F2C messages that request ASC capabilities
188.8.131.52. Status: F2C messages that indicate ASC operation
2.3.4. Database Transaction Sets
184.108.40.206. Used to buffer of multiple Set objects
220.127.116.11. Avoids detrimental effects of individual Sets at different times
2.3.5. NTCIP Consistency Checks and Rules
18.104.22.168. Compares C2F data to expected ranges
22.214.171.124. Returns error message if data is unexpected, "sanity check"
2.3.6. Block Objects
126.96.36.199. Efficient, compressed C2F and F2C communications
188.8.131.52. Commonly used for Legacy ASCs with slow communications
184.108.40.206. Vary among manufacturers, adds design and testing costs
2.3.7. Simple Network Management Protocol (SNMP)
220.127.116.11. Widely used by computer networks
18.104.22.168. Objects are identical among manufacturers, no unique testing
2.3.8. Simple Transportation Management Protocol (STMP)
22.214.171.124. Extension of SNMP developed for the Transportation Industry
126.96.36.199. Compact messages, but differ among manufacturers
188.8.131.52. Each end requires special software to interpret STMP messages
2.3.9. Proper Use of Manufacturer Specific Objects
184.108.40.206. MSOs are defined by ASC manufacturers, not by the standards
220.127.116.11. Allowed by standards for functions beyond TS-2 Standard
18.104.22.168. MSOs differ from Optional Objects, MSO are not interoperable
22.214.171.124. MSOs must be carefully documented and archived
2.3.10. Improper Use of Manufacturer Specific Objects
126.96.36.199. MSOs are not a substitute for mandatory or optional objects
188.8.131.52. MSOs should not be a disguise for proprietary protocols
2.3.11. Adaptive Control Example of MSO
184.108.40.206. MSO1 to assign Phases to Stages
220.127.116.11. M SO2 to set Stage that moves the most traffic
18.104.22.168. Deliverable: MSO1 and MSO2 documentation
2.3.12. Suggested Contract Deliverables- Manufacturer shall provide:
22.214.171.124. All mandatory ASC objects
126.96.36.199. All Optional objects needed for ASC operation
188.8.131.52. MSOs for only special requirements listed in the contract, if any
2.3.13. Exception Based Reporting
184.108.40.206. Included n NTCIP 1103 v03, referenced by NTCIP 1202 v02
220.127.116.11. Defined events are reported by ASC immediately (F2C)
18.104.22.168. Eliminates need for central to poll each ASC
2.3.14. Verify NTCIP Conformance
22.214.171.124. Conformance: Verification, not enforcement
126.96.36.199. Include RTM and Test Scripts in contract terms in the beginning
188.8.131.52. Verification by all stakeholders throughout the life of the project
184.108.40.206. 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:
- Computational speed needed for signal control and Connected Vehicle software applications
- Communications from ASC to Central Station and from ASC to roadside equipment
- Software Operating System required for 3rd party Connected Vehicle software application
- Compatibility with API standard used to share ASC resources among software applications
||Type 170, Modern
||Type 170, Legacy
||Electromechanical & Other
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:
ATC5201 Standard ASCs: > 60 MIPS, Linux OS, API compatibility and separate networks for Central and Roadside Equipment,
- ATC 5.2b, which is the current version of ATC5201 at this writing
- Model 2070 LX, which references ATC5201 v5.2b, plus special provisions
Modern ASCs: 4 MIPS, OS, no API compatibility, network for Central and Roadside Equipment
- Model 2070E compliant to ATC5202 at this writing o Model 2070L
- NEMA TS-2 ASCs that include Ethernet o Type 170 ASCs that include Ethernet
Legacy ASCs: < 4 MIPS, no standard OS, no API compatibility and no network communications,
- NEMA TS-2 and NEMA TS-1 ASCs without Ethernet
- Type 170 ASCs without Ethernet
- Electromechanical and other non-standard ASC types
Importance of ASC types and the effect on requirements:
- ASC 5201 ASCs have the computational speed and the network communications performance necessary to send, receive, interpret and store long dialogs of 100% standardized objects. Because the standardized objects are identical among manufacturers, no special testing or software is required for interoperability. Each object has the same format and identification so that ASCs can be replaced or added in the future with little or no recurring cost of testing and software development. When writing requirements, this total cost of ownership should contrast the cost of upgrading to ASC 5201, compared to moving the older ASCs to non-NTCIP locations, such as solo intersections in order to use standardized objects.
- Modern ASCs have the network communications necessary to send and receive long dialogs of 100% standardized objects, but may not have the computational speed to interpret and store those objects while running signal control. When writing requirements, be aware that network traffic can exceed the computational speed of Modern ASCs with adverse effects. Incidences of Modern ASC being overwhelmed by network communications are known. Dialogs of non-standardized objects may be used as a remedy, but creates additional cost for development and testing. Again, the total cost of ownership should be considered when writing requirements.
- Legacy ASCs have neither the network communications necessary to send and receive long dialogs of standardized objects, nor the computational speed to interpret and store those objects along with signal control. Dialogs of non-standardized objects such as STMP and Block Objects are typically used to overcome the Legacy ASC limitations, which creates additional cost for development and testing. Again, the total cost of ownership should be considered when writing requirements. The cost to replace or relocate Legacy ASCs may be less expensive.
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.
(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.
Traditional deterministic dedicated circuits, such as modems
- 1200 to 9600 bits per second communications speed, START/STOP bit
- Typically via dedicated private phone lines
- 10 Mbps to 1000 Mbps, Internet Protocol (IP)
- Ethernet interface on ASC
Relationship to performance requirements
- User may face a requirement to retain the existing communications infrastructure
Bandwidth requirement must be reconciled with ASC functional requirements
- What is the required update rate from each ASC to Central?
- What is the required Control and Status for each ASC for each update?
- How many bits are exchanged using defined NTCIP blocks?
- If blocks fit within the channel bandwidth, no special blocks are needed
- If data exceeds channel bandwidth, block objects are required
Total Cost of Ownership to remain within bandwidth capacity of private lines
Use of non-standardized objects to compress data using legacy modems
- Cost to test and verify non-standardized objects unique to manufacturer
- Recurring cost to test and verify when other ASCs are added in the future
Use of standardized objects compressed using modern communications, i.e. DSL
- Cost to replace legacy modems with modern communications equipment
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.
ASC Clock Accuracy
- Absolute accuracy of the ASC clock is less important than clock drift between ASCs
- Coordinated "Green Wave" requires that all ASCs drift identically to maintain a fixed offset time between intersections
ATC 5201 Standard supports three clock coordination methods at this writing:
- Power line service frequency: 60 cycles = 1 second. The service frequency will drift above or below 60 Hz over the short term, but each ASC senses the same Linesync frequency, which is used by the control application to maintain the time.
- Crystal oscillator: Each ASC has slightly different time drift over temperature. The crystal oscillator frequency is very accurate over the short term, but the slight inaccuracy accumulates continuously. After years of continuous operation, the clock may drift by minutes or hours among ASCs.
- GPS: ASC is attached to a GPS receiver that includes a very accurate timestamp with no drift, but with a slight latency delay through the receiver.
- NTCIP includes a method to broadcast identical time to each ASC from Central Station
Clock coordination method will vary depending upon control strategy requirements:
- Time Base Coordination (Green Wave): Constrains the clock source to service frequency, GPS or broadcast so that each ASC on the corridor retains the same inaccuracy. Each ASC may vary slightly from actual time, but the same variance in each ASC will maintain the green wave progression timing.
- DC service: Constrains the clock to GPS, crystal, or broadcast. Portable intersections, work zones, and solar-powered applications are typically powered by DC and lack the 60 Hz service frequency used for the ASC time base.
- Solo intersections: Constrains the clock to GPS, crystal, or service frequency. Intersections lacking backhaul communications to a central station will not be synchronized by a time broadcast from the central station.
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:
User Needs example:
- An identified arterial corridor needs to move 33,000 vehicles on normal weekdays
- On football Saturdays, the corridor needs to automatically accommodate the abnormal traffic flow that arrives in unpredictable volumes
- Police cannot be reassigned to direct traffic
Requirements traceable to Needs:
- Existing ASCs shall be retained due to cost and budget constraints
- Existing communications backhaul shall be retained for cost and budget constraints
- Signal timing shall automatically adjust, based on arriving vehicles
Proper use of Manufacturer-Specific Objects
- No standard Mandatory object meets the requirements
- No standard Optional object meets the requirements
- Create MSO1 PhasesToStage: Each non-conflicting Phase combination to a Stage ID
- Create MSO2 StageNext: Force ASC to a Stage, based on arriving vehicles
- Create MSO3 ForceOff: Prepare for next StageNext object
- All MSOs are documented for interoperability when ASCs are added to the system later
Design dialogs traceable to Requirements
- During installation and commissioning, the Engineer will identify each combination of non-conflicting stages with a Stage ID using PhasesToStage for each ASC
- The Central Station sends PhasesToStage MSO to each ASC that configures Stage ID with non-conflicting Phases for that intersection
- ASC constantly detects departing vehicles using standardized Objects
- Central sends StageNext for optimal phases before cars arrive
- Central sends ForceOff at the end of optimal phase time for next StageNext
3. Reference to Other Standards
- Institute of Transportation Engineers, ATC5201 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
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:
(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
||A document that has been prepared by an agency to define requirements for a subject item or process when procured by the agency.
||Application Program Interface
||Center to Field
||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.
||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.
||Digital Subscriber Line
||Field to Center
||Global Positioning System
||Millions of instructions per second
||Modulator / Demodulator
||National Highway Traffic Safety Administration
||Signal Phase and Timing
- Federal Highway Administration, AASHTO Connected Vehicle Infrastructure Deployment Analysis, FHWA-JPO-11-090, June 17, 2011
- California Department of Transportation, Transportation Electrical Equipment Specification. Caltrans, March 12, 2009
- US Department of Transportation, Systems Engineering for Intelligent Transportation Systems, USDOT, January 2007
7. Study Questions
1. Which of the following is NOT part of managing requirements correctly?
- Associating each requirement to the correct conformance group
- Correct implementation of objects within conformance group
- Correct dialog to meet requirements
- Adding a new requirement received via email
2. How do ASC types affect requirements?
- Different objects and dialogs needed to meet identical requirements
- Legacy ASCs require the use of compact, complex objects
- ATC 5201 ASCs handle long dialogs of standardized objects
- Legacy ASCs are being replaced within existing budgets and have standardized objects
- All of the above
3. Why should dialogs be defined in a procurement specification?
- Devices are more likely to conform to the standards
- Devices are more likely to interoperate and interchange
- Increases the total cost of ownership
- Devices are likely to be less expensive