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:
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
220.127.116.11. 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
18.104.22.168. 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
22.214.171.124. 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
126.96.36.199. Legacy ASC: Low MIPS, low- speed communications
188.8.131.52. Modern ASC: Limited MIPS, network interface controller
184.108.40.206. ATC5201 ASC: High speed, (2) network interface controllers
2.3.3. Control, Parameter and Status Objects
220.127.116.11. Control: C2F messages that alter the ASC operation
18.104.22.168. Parameter: F2C messages that request ASC capabilities
22.214.171.124. Status: F2C messages that indicate ASC operation
2.3.4. Database Transaction Sets
126.96.36.199. Used to buffer of multiple Set objects
188.8.131.52. Avoids detrimental effects of individual Sets at different times
2.3.5. NTCIP Consistency Checks and Rules
184.108.40.206. Compares C2F data to expected ranges
220.127.116.11. Returns error message if data is unexpected, "sanity check"
2.3.6. Block Objects
18.104.22.168. Efficient, compressed C2F and F2C communications
22.214.171.124. Commonly used for Legacy ASCs with slow communications
126.96.36.199. Vary among manufacturers, adds design and testing costs
2.3.7. Simple Network Management Protocol (SNMP)
188.8.131.52. Widely used by computer networks
184.108.40.206. Objects are identical among manufacturers, no unique testing
2.3.8. Simple Transportation Management Protocol (STMP)
220.127.116.11. Extension of SNMP developed for the Transportation Industry
18.104.22.168. Compact messages, but differ among manufacturers
22.214.171.124. Each end requires special software to interpret STMP messages
2.3.9. Proper Use of Manufacturer Specific Objects
126.96.36.199. MSOs are defined by ASC manufacturers, not by the standards
188.8.131.52. Allowed by standards for functions beyond TS-2 Standard
184.108.40.206. MSOs differ from Optional Objects, MSO are not interoperable
220.127.116.11. MSOs must be carefully documented and archived
2.3.10. Improper Use of Manufacturer Specific Objects
18.104.22.168. MSOs are not a substitute for mandatory or optional objects
22.214.171.124. MSOs should not be a disguise for proprietary protocols
2.3.11. Adaptive Control Example of MSO
126.96.36.199. MSO1 to assign Phases to Stages
188.8.131.52. M SO2 to set Stage that moves the most traffic
184.108.40.206. Deliverable: MSO1 and MSO2 documentation
2.3.12. Suggested Contract Deliverables- Manufacturer shall provide:
220.127.116.11. All mandatory ASC objects
18.104.22.168. All Optional objects needed for ASC operation
22.214.171.124. MSOs for only special requirements listed in the contract, if any
2.3.13. Exception Based Reporting
126.96.36.199. Included n NTCIP 1103 v03, referenced by NTCIP 1202 v02
188.8.131.52. Defined events are reported by ASC immediately (F2C)
184.108.40.206. Eliminates need for central to poll each ASC
2.3.14. Verify NTCIP Conformance
220.127.116.11. Conformance: Verification, not enforcement
18.104.22.168. Include RTM and Test Scripts in contract terms in the beginning
22.214.171.124. Verification by all stakeholders throughout the life of the project
126.96.36.199. 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|
|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|
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.
(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:
(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
|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.|
|DSL||Digital Subscriber Line|
|F2C||Field to Center|
|GPS||Global Positioning System|
|MIPS||Millions of instructions per second|
|Modem||Modulator / Demodulator|
|NHTAS||National Highway Traffic Safety Administration|
|SPAT||Signal Phase and Timing|
7. Study Questions
1. Which of the following is NOT part of managing requirements correctly?
2. How do ASC types affect requirements?
3. Why should dialogs be defined in a procurement specification?