Module 42 - A315b Part 2
A315b Part 2: Specifying Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 v03 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:
![This slide contains a graphic with the word “Welcome” in large letters. ITS Training Standards “WELCOME” slide, with reference to the U.S. Department of Transportation Office of Assistant Secretary for Research and Technology](a315b2ppt1.jpg)
Slide 2:
![This slide contains a graphic with the word “Welcome” in large letters, photo of Kenneth Leonard, Director ITS Joint Program Office - Ken.Leonard@dot.gov - and on the bottom is a screeshot of the ITS JPO website - www.its.dot.gov/pcb](a315b2ppt2.jpg)
Slide 3:
Module A315b Part 2:
Specifying Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 v03 Standard
Part 2 of 2
![The title slide shows photo of a 2070 traffic signal controller and indicates the course was updated in July 2020.](a315b2ppt3.jpg)
Updated July 2020
Slide 4:
Instructor
![This slide, entitled “Instructor” has a photo of the instructor, Kenneth Vaughn, on the left-hand side.](a315b2ppt4.jpg)
Kenneth L. Vaughn
President
Trevilon LLC
Slide 5:
Learning Objectives
- Manage Special Considerations for NTCIP 1202: Infrastructure
- Manage Special Considerations for NTCIP 1202: Functionality
- Incorporate Requirements Not Supported by Standardized Objects
- Testing NTCIP 1202 v03 Conformance
Slide 6:
Learning Objective
- Manage Special Considerations for NTCIP 1202: Infrastructure
Slide 7:
Special Considerations: Infrastructure
Overview
- Origins of NTCIP
- Simple Network Management Protocol (SNMP)
- Simple Transportation Management Protocol (STMP)
- Exception-Based Reporting
- Block Objects
- Infrastructure Limitations
- Communications Loading
Slide 8:
Origins of NTCIP
Original NTCIP Constraints and Origins of Design
NTCIP effort originated in 1993 to support remote communication for traffic signal control
-
Intended to be the communication protocol for NEMA TS 2 (Traffic Controller Assemblies)
- Originally intended for signal control
- Quickly expanded to support other devices
-
Different architectures
- Central control
- Field masters
- Distributed control
-
Predominant 1200 bps environment
- Recognition that higher speeds would emerge
NEMA = National Electrical Manufacturers Association
Slide 9:
Origins of NTCIP
Practical Challenges
-
Different needs for:
- Frequency of command and monitoring messages
- Content of command and monitoring messages
- Number of devices sharing communications medium
Slide 10:
Origins of NTCIP
A Layered Solution
- Adopted layered protocol model to provide flexibility
![This slide contains three communication reference models. On the left is the Open Systems Interconnect (OSI) model, which is represented as a seven-layer stack. The seven layers, starting from the bottom, are Physical, Data Link, Network, Transport, Session, Presentation, and Application. In the middle is the NTCIP Model, which uses a four-layer stack. The four layers, starting from the bottom, are Subnet, Transport, Application, and Information. the layers of this model are mapped to the ones in the OSI model as follows: NTCIP Subnet equates to OSI Physical and Data Link; NTCIP Transport equates to OSI Network and Transport; NTCIP Application equates to OSI Session, Presentation, and Application. The NTCIP Information Layer resides outside of the OSI stack. On the right is the ITS station reference architecture, which defines 6 areas consisting of a 3-layer stack with additional entities on the left, right, and on top. Starting from the bottom, the three layers are Access, TransNet, and Facility – these are mapped to the Subnet, Transport, and Application Layers of the NTCIP model. On top of the stack and also spanning over the entities on the left and right is the Application Entity, which is mapped to the Information Layer of the NTCIP model. Finally, on the left is the Management Entity and on the Right is the Security Entity.](a315b2ppt5.jpg)
Slide 11:
Origins of NTCIP
Application Layer
-
Flexibility: Simple Network Management Protocol (SNMP)
- Major Internet standard
- Provides flexible message structure
- Manager decides when to send each message
![This slide includes the NTCIP model from the previous slide with the Application Layer highlighted.](a315b2ppt6.jpg)
Slide 12:
Simple Network Management Protocol (SNMP)
SNMP Packet Structure
![Author's relevant description: This slide depicts how an SNMP message gets put together across the different layers of the communications stack by showing three levels of analysis. The top layer, labeled Information Layer, depicts an object name of “phaseStatusGroupGreens.1” followed by a value of 32 (indicating a meaning of Phases 2 and 6) followed by the object name of “shortAlarmStatus.0”, which is followed by a value of 0 (indicating a meaning of no error). The Information Layer is shown being miniaturized into the Application Layer, which prepends the following fields as a header: the value of 1 (indicating SNMP version 1), the text “admin” (which represents a community name to control access for the request), the word “Response” (representing the type of message), the value 1 (representing the message ID), the value 0 (representing the error status), and the value 0 (indicating the error index). The Application Layer is then miniaturized into the layer called “Lower Layers” which adds a “Protocol Specific” header and a “Protocol Specific” footer.](a315b2ppt7.jpg)
Manager decides when to use each object
Slide 13:
Simple Network Management Protocol (SNMP)
Challenges with SNMP
-
SNMP is verbose
- Request and response are nearly same size
- Inefficient encoding
- Example message is ~75 bytes + lower layers
- One exchange every ~1.6 seconds @ 1200bps
-
SNMPv1 does not provide any cybersecurity protection
- Community name provides access control but not authentication
-
SNMPv3 coupled with (D)TLS provides necessary security
- See Module CSE203: Adding Security to NTCIP
-
NTCIP developed a configurable protocol
- Simple Transportation Management Protocol (STMP)
- Custom design for transportation industry
- Defined as optional enhancement to base NTCIP
(D)TLS = Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS)
Slide 14:
Simple Transportation Management Protocol (STMP)
STMP Packet Structure
![Author's relevant description: This slide depicts how an STMP message gets put together across the different layers of the communications stack by showing three levels of analysis, similar to Slide 12. The top layer, labeled Information Layer, depicts a value of 32 (indicating a meaning of Phases 2 and 6) followed by a value of 0 (indicating a meaning of no error). A note indicates that the object names have been removed as they have been pre-configured. The Information Layer is shown being miniaturized into the Application Layer, which prepends “Response1” as a header to indicate the type of message. A note indicates that there are 13 configurable dynamic objects. The Application Layer is then miniaturized into the layer called “Lower Layers” which adds a “Protocol Specific” header and a “Protocol Specific” footer.](a315b2ppt8.jpg)
Manager decides configuration of and when to use each "dynamic object"
Slide 15:
Simple Transportation Management Protocol (STMP)
Predominant 1200 bps Environment
-
Simple Transportation Management Protocol
- GET-Requests and SET-Responses omit data fields
- Example message is 3 bytes + lower layers
- Request is only 1 byte + lower layers
- One exchange every 0.16 seconds @ 1200 bps
-
Dynamic objects are configured through SNMP
- Configure once; use many
- Each system can configure dynamic objects to meet their needs
Slide 16:
Simple Transportation Management Protocol (STMP)
STMP vs SNMP
-
Reduced data communication demand
- Most integer parameters have a 25:1 reduction
-
Both provide flexibility
- STMP only allows 13 dynamic objects
- STMP requires full support for and use of SNMP
-
STMP increases processor/memory/code demands
- Translating dynamic object number into series of object requests
- Encoding using different rules
-
Niche market of a more complex protocol increases integration costs
- Custom testing for each configuration
Slide 17:
Exception-Based Reporting
A New Approach to Monitoring Equipment
-
Traditional Systems Polled Signals Once-per-Second
- 120-second cycle = 120 requests/replies
-
Exception Reporting Allows Signal to Report Changes
- E.g., send a message each time a signal phase green changes
- At most, 2 message exchanges per phase per cycle
- Delay settings can further reduce number of messages
- Acknowledgements can be suppressed
- Perhaps a 20:1 reduction in communications demand
Slide 18:
Exception-Based Reporting
Other Benefits of Approach
- Can be used to capture transient events
-
Based on event-logging logic
- Most of logic already implemented in many controllers
- Exceptions can also be stored in local logs
- Standard supports monitoring 65,535 conditions
Slide 19:
Exception-Based Reporting
Challenges with Exception-Based Reporting
- Current design (NTCIP 1103) based on SNMPv1
-
Upgrade to SNMPv3 required for proper cybersecurity
- Requires changes to the design
- ISO 15784-2 defines the use of SNMPv3 within ITS
- ISO 20684-3 and 20684-4 will define exception reporting within ITS
- Event detection increases processor requirements
Should consider as a part of cybersecurity migration plan
Slide 20:
Block Objects
Database Uploads and Downloads
-
An ASC configuration can be megabytes
-
NTCIP 1202 v03 Defines Standardized "Block Objects"
- An SNMP object containing a static structure of a set of other objects
- Similar to dynamic objects, but statically defined in standard
- Only standardized for upload/download of standardized configuration parameters
- Manufacturers may define their own block objects
- Reduces time to transfer an entire configuration
Slide 21:
Infrastructure Limitations
![Please see extended text description below.](a315b2ppt9.jpg)
(Extended Text Description: This slide includes three photographs accompanying a table. The table has three columns that describe the capabilities of legacy, mainstream, and emerging infrastructure (i.e., communications and controller equipment). Associated with each column is a photograph of a car. The legacy column depicts a 1930s roadster coupe. The mainstream column depicts a 1970s Ford Mustang. The emerging column depicts recent model Mercedes. The table information is included below:
Capability |
Legacy |
Mainstream |
Emerging |
Data Rate |
1200-9600 bps |
10Mbps |
>=50 Mbps |
Communications Technology Examples |
Multi-drop Copper Wire, Dial-up |
Ethernet, LTE |
Ethernet, WiFi, 5G |
Processor Speed |
0-4 MIPS |
4-60 MIPS |
>= 60 MIPS |
OS and API for CV Applications |
No |
Typically no |
Yes |
Controller Examples |
Type 170 NEMA TS 1 |
ATC 5202 (2070 L) NEMA TS 2 |
ATC 5201 |
)
![Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.](a315b2pptimsupplement.jpg)
Slide 22:
Infrastructure Limitations
Processor Capability Timeline
![Author's relevant description: Processor Capability Timeline: This slide shows a chart that compares millions of instructions per second (MIPS) for processors from ~1951 to ~2017 and shows a fairly steady increase on a logarithmic scale from roughly 0.002 MIPS in 1951 to 100,000 MIPS in 2017. The graph also shows the cost of processors in dollars per million floating point operations per second (MFLOPS) from 1960 to 2017, also on a logarithmic scale. This line starts at roughly $10 million in 1960 and drops to roughly $0.00005 in 2017. Across the chart are three stars that show the processor speed and year for the various controller types discussed in the report. The legacy controllers are represented as a star in 1978 with a processing power of 0.1 MIPS. The mainstream controllers are represented as a star at 1998 with a processing power of roughly 4 MIPS. Finally, the emerging controllers are represented by a star in 2018 and a speed of 400 MIPS](a315b2ppt11.jpg)
MIPS = Millions of instructions per second
MFLOPS = Millions of floating point operations per second
Source: https://en.wikipedia.org/wiki/FLOPS, https://en.wikipedia.org/wiki/Instructions_per_second#Millions_of_instructions_per_second_(MIPS)
Slide 23:
Infrastructure Limitations
Controller Costs
-
The cost of an ASC reflects
- Processor
- Other components
- Software
- Custom engineering
-
As with computers, price point tends to stabilize while
- Processor speeds increase
- Memory increases
- Ports improve speed
- Each version results in custom engineering
-
A 2020 survey indicated that "emerging" controllers cost between $2,000 and $5,500; prices vary based on
- Required features (processor speed, proprietary features, support)
- Type of software
- Purchase quantity
- Testing requirements
Slide 24:
Infrastructure Limitations
![Photo depicts a 1930's roadster coupe.](a315b2ppt12.jpg)
Limitations of Legacy Systems for Traffic Signal Control
-
Legacy Communication Networks Struggle to Support NTCIP
- 1200 bps requires STMP or exception reporting
- No support for any cybersecurity (insufficient bandwidth)
- Should never be used with connected vehicles
-
Legacy Controllers Struggle to Support NTCIP
- Original processors/memory too limited
- Limited support with later-model/upgraded legacy controllers
- No support for any cybersecurity (insufficient processing)
- Unable to support connected vehicle applications
-
Recommendations
- Upgrade to emerging controllers
- Consider mainstream/emerging communication alternatives
![Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.](a315b2pptimsupplement.jpg)
Slide 25:
Infrastructure
![Photo of a 1970s Ford Mustang.](a315b2ppt14.jpg)
Mainstream Systems
-
Mainstream Communication Networks Support NTCIP
- Supports all NTCIP features
- Network loading of SNMP generally not an issue
- Cybersecurity is critical (See Module CSE 203)
-
Mainstream Controllers Support Standard NTCIP
- Ethernet communications can overwhelm early mainstream processors
- Support possible for most NTCIP functionality
- Might bump against processing/memory limitations (e.g., complex event reporting, large logs)
- Cybersecurity will introduce additional processor loads
- Connected vehicle applications might stress systems
-
Recommendations
- Upgrade to emerging controllers as needed
- Initiate migration plan to provide cybersecurity
Slide 26:
Infrastructure
![Photo depitcs a recent model Mercedes nextg to the text Connected Vehicles](a315b2ppt15.jpg)
Emerging Systems for Traffic Signal Control
-
Emerging Communication Networks Support NTCIP
- Supports all NTCIP features
- Network loading of SNMP generally not an issue
- Cybersecurity is even more critical (See Module CSE 203)
-
Emerging Controllers Support NTCIP
- Can handle current requirements for connected vehicles
- Cybersecurity is critical
-
Recommendations
- Initiate migration plan to provide cybersecurity
- Buy more than enough processing power
Slide 27:
Infrastructure Limitations
Processor Capability Timeline
![Processor Capability Timeline: This chart shows a 2012 projection of the percentage of controller deployments from 2011 through 2020 that was developed as a part of the previous version of this course. In 2011, there were just over 300,000 signal controllers in the US and roughly 200,000 of these were in need of replacement to support connected vehicle applications (i.e., legacy controllers) while 100,000 of the controllers were technologically ready. The three lines (total, in need of replacement, and technologically-ready) continue across in a mostly linear fashion until 2018 when there are a total of roughly 340,000 controllers, all of which are shown as technologically-ready. The table is supplemented by text indicating that, at least in Minnesota, in 2019, that this projection has been largely validated as there are only 5% of legacy controllers remaining.](a315b2ppt16.jpg)
-
Actual Statistics - 2019 Minnesota
- Legacy: 5%
- Mainstream: 65%
- Emerging 35%
MNDOT data extrapolated from data in https://www.dot.state.mn.us/research/reports/2019/201935.pdf
![Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.](a315b2pptimsupplement.jpg)
Slide 28:
Communications Loading
Communications Demand Versus Capacity
-
System Design Should Consider Communications Loading
- Too little capacity limits capabilities
- Too much capacity opens security vulnerabilities and might increase costs
-
Determine how much data per second from all devices sharing the communications medium
- Double estimate for "collision detection" and peaks
-
Mainstream/Emerging Systems Often Incorporate Video
- Video requires 1,500-4,000 kbps* per feed
- SNMP requires 1.5-4 kbps per signal
- Mainstream communications support 1,000 SNMP signals/channel
- One video link per 100 signals will dominate design
*https://support.google.com/youtube/answer/2853702?hl=en for 720p resolution
Slide 29:
Communications Loading
Legacy Communications
-
Costs of Maintaining Legacy Communications
- No cybersecurity
- Increased equipment costs due to custom code
- Increased testing/integration costs
- Fading industry support in future
-
If you have a legacy communications system, consider:
- Upgrading (wireless solutions are often viable)
- Using exception-based reporting
- View STMP as a last-resort
![Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.](a315b2pptimsupplement.jpg)
Slide 30:
![Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.](a315b2ppt19.jpg)
Slide 31:
Question
Which of the below is a waning technology that is not recommended for most new deployments?
Answer Choices
- Exception reporting
- Block objects
- STMP
- None of the above
Slide 32:
Review of Answers
a) Exception reporting
Incorrect. Exception reporting is a fairly new feature that has been added to NTCIP to reduce overhead in communications.
b) Block objects
Incorrect. Block objects are used to speed the upload and download of large portions of an ASC database.
c) STMP
Correct! STMP is a protocol specific to the transportation industry that requires custom code, extra testing, and integration expenses.
d) None of the above
Incorrect. STMP is a waning technology that is no longer recommended due to its niche market and cost implications.
Slide 33:
Learning Objective
- Manage Special Considerations for NTCIP 1202: Functionality
Slide 34:
Special Considerations: Functionality
Overview
- Database Transaction Sets
- Consistency Checks and Rules
- Connected Vehicle Support
- Clock Coordination
- Managing Expectations for Off-The-Shelf Interoperability
Slide 35:
Database Transaction Sets
Need for Complex Transactions
- Traffic signals are safety-critical devices
- Many configuration parameters are inter-related
- Changing configuration of some parameters need to happen in single step
- Size of each SNMP message is limited
- Database transaction mode interprets multiple SNMP messages as one transaction
![This slide includes a standard 8-phase NEMA traffic signal timing diagram consisting of two rings and two concurrency groups. Ring 1, Concurrency Group A consists of Phases 1 and 2 where Phase 1 is a left turn phase from the left approach turning to the top of the diagram and Phase 2 is a right approach through movement. Ring 1, Concurrency Group B consists of Phases 3 and 4 where Phase 3 is a left turn phase from the top approach turning to the right of the diagram and Phase 4 is a bottom approach through movement. Ring 2, Concurrency Group A consists of Phases 5 and 6 where Phase 5 is a left turn phase from the right approach turning to the bottom of the diagram and Phase 6 is a left approach through movement. Ring 2, Concurrency Group B consists of Phases 7 and 8 where Phase 7 is a left turn phase from the bottom approach turning to the left of the diagram and Phase 8 is a top approach through movement. A barrier line separates the two concurrency groups to indicate that both rings have to cross the barrier at the same time.](a315b2ppt21.jpg)
Slide 36:
Database Transaction Sets
Impact on operations
-
When in transaction mode, some operations are buffered
- Get requests return "live" values (not buffered)
-
Set requests for control objects are implemented immediately
- E.g., setting force off or current timing pattern
-
Set requests for database parameters are buffered
- E.g., setting minimum green time
-
Some database parameters can only be set in transaction mode
-
Designation of parameter type was omitted from NTCIP 1202v03
- WG has been notified of ambiguity
- NTCIP 1202v02 provides designation for most objects
Slide 37:
Consistency Checks and Rules
Need for Consistency Checks
- Critical configuration parameters can only be changed using the transaction mode
-
17 standardized consistency checks are required
- Prevent implementation of controller settings with internal conflicts
- Require additional time
- Are performed at end of transaction mode process
- Manufacturer may impose additional restrictions
- Failure of any rule results in transaction set failing
Slide 38:
Consistency Checks and Rules
Example Consistency Check
-
Concurrent phases must be in different rings
- Example: Phase 1 must not be concurrent with Phases 2, 3, or 4
![This slide contains the same standard, 8-phase NEMA traffic signal timing diagram that was on Slide 35](a315b2ppt22.jpg)
Phase |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
Ring |
1 |
1 |
1 |
1 |
2 |
2 |
2 |
2 |
Concurrency |
5,6 |
5,6 |
7,8 |
7,8 |
1,2 |
1,2 |
3,4 |
3,4 |
Slide 39:
Connected Vehicle Support
![Blue label with the text "Connected Vehicles"](a315b2ppt23.jpg)
Signal Controllers and the Connected Vehicle Environment
![Author's relevant description: This slide depicts a diagram similar to that used to depict a service package Physical View in the Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT, http://arc-it.net). At the top is a teal colored box labeled “Traffic Management Center (TMC)”. It is connected to two gold colored boxes (representing field units) with bi-directional lines. One of these boxes is labeled “ITS Roadway Equipment (ASC)”; the line connecting it to the TMC is labeled “NTCIP 1202”. The other gold box is labeled “Connected Vehicle Roadside Equipment (RSE)” and its line connecting to the TMC is labeled “NTCIP 1202/1218”. The two gold boxes are connected with gold dashed lines with a note that these two boxes might be separate physical units or joined into a single unit. There is another bi-directional line between the two gold boxes labeled NTCIP 1202. The ASC includes a white box (showing functionality) within it labeled “Roadway Signal Control”. The RSE is shown with a white box in it labeled “RSE Intersection Management”. Finally, the RSE box is shown with a wireless antenna that is connecting to another wireless antenna hosted by a blue box that is labeled “Vehicle Onboard Equipment (OBE)”](a315b2ppt24.jpg)
Slide 40:
Connected Vehicle Support
![Blue label with the text "Connected Vehicles"](a315b2ppt25.jpg)
New Features for Connected Vehicles
-
TMC-ASC
- Manage data exchanged between the ASC and RSE
-
TMC-RSE
- Manage map information
- Manage transformation of ASC timing data to Signal Phase and Timing (SPaT) message
- Manage data collected from basic/personal safety messages (BSM/PSMs)
-
ASC-RSE
-
ASC provides
- Current/next movement information
- Expected start/end times of each phase
-
ASC selects
- Current geometry
- Current transformation of ASC timing data to SPaT message
- RSU reports presence of vehicles and vulnerable road users (VRUs)
Slide 41:
Connected Vehicle Support
![Blue label with the text "Connected Vehicles"](a315b2ppt26.jpg)
Challenges with Interface to RSE Intersection Management
-
Connected Vehicle environment is safety critical
- Integrity of data must be maintained
- Messages must be properly authenticated
- Access to data must be controlled
- Roadside Unit (RSU) Specification v4.1 only allows secure protocols
- NTCIP 1202 v03 designed for SNMPv1, which is not secure
- Required Security and Credentials Management System (SCMS) is still being established
-
Connected Vehicle features of NTCIP 1202 v03 should only be used in a fully secure environment
- Secure communications (e.g., SNMPv3 with TLS)
- Proper maintenance of SCMS certificates
TLS = Transport Layer Security
Slide 42:
Clock Coordination
Need for Clock Coordination
-
Traffic signals need to coordinate timing with
- Adjacent signals
- Connected vehicles
-
Inter-signal coordination requires:
- Precision ± 2 seconds (green waves approach when expected)
- Accuracy ± 5 minutes (morning timing pattern starts on time)
- Any synchronization technology (each system can be different)
![This slide includes a timeline at the bottom that starts at 7:59 am and goes until 8:01am. Above the line, there are four stacked gold points representing when four different ASCs might think it is 8:00 am. The four points are shown within a couple of seconds of each other at approximately 8:00:30 am. The distance between 8:00 am and the mean of the four points is labeled “accuracy”. The width of separation of the four points is labeled “precision”.](a315b2ppt27.jpg)
Slide 43:
Clock Coordination
![Blue label with the text "Connected Vehicles"](a315b2ppt28.jpg)
Need for Clock Coordination
-
Coordination with connected vehicles requires
- ±50 millisecond precision (consistency of signal displays)
- A single, reliable, national standard to synchronize
-
Selected synchronization technology is based on Global Navigation Satellite System (GNSS) time
- Assuming satellites are accurate, accuracy = precision
![This slide includes the same timeline as shown on Slide 42, but now shows one gold point (representing an ASC) and three blue points (representing vehicles). All four points are stacked at 8:00:00 with very little variance (indicating an accuracy and precision of +/- 50 milliseconds).](a315b2ppt29.jpg)
Slide 44:
Clock Coordination
![Blue label with the text "Connected Vehicles"](a315b2ppt30.jpg)
![Author's relevant description: This slide includes the same timeline as shown on Slide 43, with the same stacked gold and blue points, but the timeline is supplemented by a figure showing how the timing coordination works. At the top of the slide, there are three boxes. The left box is a white box with a gold boundary indicating a function performed by a field device; it is labeled “Roadway Signal Control”, one of the same functions identified in the Figure of Slide 39. A note indicates that this function can use any time source, which might be minutes off from the Global Navigation Satellite System (GNSS) time. The middle box is also a white box with a gold boundary and is labeled “RSE Intersection Management”, which was the other function included in the figure on Slide 39. Connecting these boxes is a green line labeled “intersection control status”, which is an information flow from ARC-IT. This flow includes a note that indicates that the Roadway Signal Control sends what it thinks the current time is in tenths of seconds from the top of the hour according to its unsynchronized clock (e.g., 0.0 seconds) and when it expects to change its phase indication, also in tenths of seconds from the top of the hour (e.g., 4.3 seconds). The RSE Intersection Management box indicates that it will convert the data to GNSS time. It receives GNSS time via a global navigation satellite. It then is connected to a blue “Vehicle OBE” box via a wireless link with a flow name of “intersection status”, which is also defined in ARC-IT. A note on this flow indicates that if the GNSS time reports a current time of 08:00:01.0 (rather than the 0.0 seconds from top of the hour that the ASC thinks it is), the RSE will convert the change time to a GNSS time of 08:00:05.3 (i.e., the current GNSS time of 08:00:01.0 plus the expected change time of 4.3 seconds minus the ASC current time of 0.0 seconds). Finally, the Vehicle OBE also receives the same GNSS signal with time so it can properly interpret the transmitted time from the RSE.](a315b2ppt31.jpg)
Slide 45:
Managing Expectations for Off-the-Shelf Interoperability
Signal Controllers Have Most Complex Interface
- Signal controllers have many more configurable parameters than other field devices
-
Many agencies continue to require specialized functionality
- Results in customized extensions
-
Some details are manufacturer-specific
-
Shortway, Add-only, and Subtract-only Coordination Correction:
- This operation is performed in a device specific manner
- NTCIP designed to improve interoperability and interchangeability
NTCIP 1202 v03 is a step in the right direction
Slide 46:
![Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.](a315b2ppt32.jpg)
Slide 47:
Question
Which of the following most accurately expresses the state of connected vehicle (CV) support in the standard?
Answer Choices
- Does not address any CV functionality
- Does not define sufficient security for ASCs in a CV environment
- Defines a secure solution for intersection maps
- Defines a secure solution for signal timing
Slide 48:
Review of Answers
a) Does not address any CV functionality
Incorrect. NTCIP 1202 v03 defines the data to support CV applications, including map and signal timing information
b) Does not define sufficient security for ASCs in a CV environment
Correct! NTCIP 1202 v03 assumes SNMPv1, which is not secure. For CV operation, NTCIP 1202 v03 must only be deployed over a secure protocol (e.g., SNMPv3 with TLS).
c) Defines a secure solution for intersection maps
Incorrect. SNMPv1 does not provide for secure communications.
d) Defines a secure solution for signal timing
Incorrect. SNMPv1 does not provide for secure communications.
Slide 49:
Learning Objective
- Incorporating Requirements Not Supported by Standardized Objects
Slide 50:
Incorporating Requirements Not Supported by Standardized Objects
Overview
-
Conditions and Context for Extending the Standard
- Example: Dilemma Zone Protection
- Specifying Requirements Not Covered by the Standard (Extensions)
Slide 51:
Conditions and Context for Extending the Standard
What is a Custom Extension
-
Standard defines
- Mandatory and optional user needs
- Mandatory, optional, and conditional requirements for each need
- Mandatory dialogs and objects for each requirement
-
Custom extensions define
- Objects (and dialogs) for user needs and requirements that are not addressed by the standard
- Extensions are allowed by NTCIP
Slide 52:
Conditions and Context for Extending the Standard
Reasons to Specify a Custom Extension
-
Standard does not define every traffic signal control feature
- Standard only addresses features in wide use
- Customization allows for market innovations
- Might eventually be incorporated into standard
-
Example:
- Purdue University developed a high-resolution data logger
- Implemented by multiple manufacturers
- Added to draft of NTCIP 1103v03 in 2015
- Approved in NTCIP 1103v03 in 2016
Slide 53:
Conditions and Context for Extending the Standard
Costs Associated with a Custom Extension
-
Custom features might be proprietary
- Documentation might be limited or cryptic
- Rights to distribute documentation might be limited
- Custom features might reduce bidders for device
- Custom features increase costs of management system
-
Custom features complicate testing
- Developing and implementing custom test procedures is expensive
- Documentation might not reflect as-built product if untested
-
Custom features complicate maintenance
- Potentially limited to one vendor/model/version
- A single product might be discontinued
Slide 54:
Example of Extending the Standard
![Orange label with the text "Connected Vehicles"](a315b2ppt34.jpg)
Connected Vehicle Dilemma Zone Protection: User Need
-
Minimize drivers being caught in dilemma zone
- Use Basic Safety Message (BSM) for advanced detection
- Provides ~19-second advanced detection at 35 mph
- Continuously track each vehicle's path on approach
- Identify individualized dilemma zones based on speed, acceleration, etc.
- Optimize when to gap out
Slide 55:
Extending the Standard
![Orange label with the text "Connected Vehicles"](a315b2ppt35.jpg)
Connected Vehicle Dilemma Zone Protection: Requirements
-
Within 0.1 second of its receipt, the RSU shall forward the following data to the signal controller for each BSM received that reports a vehicle on one of the approaches of the intersection:
- Temporary ID
- DSecond (i.e., the millisecond within the minute)
- Latitude
- Longitude
- Speed
- Heading
- Longitudinal Acceleration
- Vehicle Length
- Upon request from a manager, the RSU shall enable or disable its BSM reporting.
![Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.](a315b2pptimexample.jpg)
Slide 56:
Example of Extending the Standard
![Orange label with the text "Connected Vehicles"](a315b2ppt37.jpg)
Connected Vehicle Dilemma Zone Protection: Design
-
Some data already exists
- The RSU has a copy of the intersection map
-
Some data needs to be transformed
- Definitions of BSM data need to be mapped to SNMP
-
Some data is new
- Object to toggle the reporting of the BSM data
Slide 57:
Example of Extending the Standard
![Orange label with the text "Connected Vehicles"](a315b2ppt38.jpg)
Connected Vehicle Dilemma Zone Protection: Procurement
-
Option 1: (Potentially Closed) Proprietary Solution
- Explain the user need and define validation testing
- Validate operation of delivered product
-
Likely to result in vendor lock-in
- Requires manager and controller from same vendor
Slide 58:
Example of Extending the Standard
![Orange label with the text "Connected Vehicles"](a315b2ppt39.jpg)
Connected Vehicle Dilemma Zone Protection: Procurement
-
Option 2: Integrable Solution
- Explain the user need and define validation testing
- Require delivery of systems engineering documentation
- Obtain rights to distribute documentation to those with a need
- Obtain rights for others to develop products to implement design
- Verify that delivered product implements design
- Validate operation of delivered product
-
Might result in limited marketplace
- Distribution of documentation is based on need-to-know
Slide 59:
Example of Extending the Standard
![Orange label with the text "Connected Vehicles"](a315b2ppt40.jpg)
Connected Vehicle Dilemma Zone Protection: Procurement
-
Option 3: Open Solution
- Explain the user need and define validation testing
-
Produce/Reference systems engineering (SE) documentation in public domain
- Without patents
- Developed by agency, manufacturer, system developer, consultant, etc.
- Verify that delivered product implements design
- Validate operation of delivered product
-
Provides best competition
- Might increase initial costs
Slide 60:
![Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.](a315b2ppt41.jpg)
Slide 61:
Question
Which of the following is NOT true regarding an extension based on an open solution?
Answer Choices
- Documentation is made public
- Cost of initial deployment may be higher
- Delivered product needs to be tested against requirements
- Likely to result in vendor lock-in
Slide 62:
Review of Answers
a) Documentation is made public
Incorrect. The defining characteristic of an open solution is that the documentation is public.
b) Cost of initial deployment may be higher
Incorrect. Vendors are less able to recover costs in subsequent deployments thereby increasing costs for initial deployment.
c) Delivered product needs to be tested against requirements
Incorrect. To obtain the interoperability enabled by an open solution, the product should be tested against the requirements.
d) Likely to result in vendor lock-in
Correct! An open solution prevents true vendor lock-in by ensuring that the design is publicly available
Slide 63:
Learning Objective
- Testing NTCIP 1202 v03 Conformance
Slide 64:
Testing NTCIP 1202 v03 Conformance
Overview
- Systems Engineering Documentation and NTCIP
- Anaheim Case Study
- Interim Guidance
Slide 65:
Systems Engineering Documentation and NTCIP
Systems Engineering Vee-Diagram
![This slide displays the Systems Engineering “Vee” Diagram, which shows a V-shaped diagram in gradated blue with some additional horizontal extensions on the left and right side of the top of the V shape. Each section is separated with dark blue lines. There is a key at the lower right showing the blue separator lines, and designating them as “Document/Approval.” The left horizontal extension is labeled as “Lifecycle Processes” and include the sections “Regional Architecture” (separated by a white space) to the second section labeled “Feasibility Study / Concept Exploration.” At this point the sections begin to descend the left side of the V with “Concept of Operations,” “System Requirements,” “High-level Design,” “Detailed Design,” and “Software / Hardware Development Field Installation” at the bottom juncture of the V shape. Underneath the bottom point of the V shape are the words “Implementation” then “Development Processes” and a long thin arrow pointing to the right labeled “Time Line.” There is a long thin diagonal arrow pointing down along the left side of the V labeled “Decomposition and Definition.” From the bottom point of the V, the sections begin to ascend up the right side of the V with “Unit/Device Testing,” “Subsystem Verification,” “System Verification & Deployment,” “System Validation,” and “Operations and Maintenance.” There is a long thin arrow pointing up along the right side of the V shaped labeled “Integration and Recomposition.” At this point the sections on the right “wing” of the V are labeled with “Changes and Upgrades” and (white space) “Retirement/Replacement.” Between the V shape there are a series of black dashed arrows connecting the related sections on each left/right side of the V shape. The first arrow (top) is labeled “System Validation Plan” and connects “Concept of Operations” on the left and “System Validation” on the right. The second arrow is labeled “System Verification Plan (System Acceptance)” and connects “System Requirements” on the left and “System Verification & Deployment” on the right. The third arrow is labeled “Subsystem Verification Plan (Subsystem Acceptance)” and connects “High-Level Design” on the left and “Subsystem Verification” on the right. The last arrow (at the bottom) is labeled “Unit/Device Test Plan” and connects “Detailed Design” on the left and “Unit/Device Testing” on the right. The “Subsystem Verification Plan (Subsystem acceptance)” arrow in the middle of the diagram is circled to show that it is the focus of the current discussion.](a315b2ppt43.jpg)
Slide 66:
Systems Engineering Documentation and NTCIP
Standard Outline for NTCIP 1200 Series
1. General
2. Concept of Operations
3. Functional Requirements
4. Dialogs
5. Management Information Base (MIB)
6. <Other Design Elements>
A. Requirements Traceability Matrix
B. Object Tree
C. Test Procedures
D. Documentation of Revisions
E. <Other Annexes>
Slide 67:
Systems Engineering Documentation and NTCIP
NTCIP 1202 Test Procedures
It is anticipated that Test Procedures may be developed as part of a future revision of NTCIP 1202 v03. Annex C is a placeholder, at present.
- NTCIP 1203 v03
Slide 68:
![This slide contains a graphic with the word "Case Study" in large letters. A placeholder graphic of a traffic control center indicating that a real-world case study follows.](a315b2ppt44.jpg)
Slide 69:
Anaheim Case Study
![Gray label with the text "Connected Vehicles"](a315b2ppt45.jpg)
NTCIP 1202 Standard Testing Project
- Request for Proposals (RFP) Closed February 26, 2020
-
Project will:
-
Develop test procedures for all NTCIP 1202 v03 requirements
- Part 1: All features included in NTCIP 1202 v02
- Part 2: All additional features
- Test three vendors
- Provide public domain test software
- Produce a final report
Slide 70:
Interim Guidance
NTCIP 1202 Standard Testing Project
-
Develop a project PRL based on NTCIP 1202 v03 PRL
- See Modules A315a and A315b Part 1
- Make sure to extend with any customizations (e.g., dialogs)
- Require compliance to the project PRL
-
Require testing per test procedures being developed by Anaheim
- Should identify a time limit for waiting on the Anaheim deliverables
-
Testing should be performed independently from manufacturer
- Agency
- Consultant
- Another agency
Slide 71:
![Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.](a315b2ppt46.jpg)
Slide 72:
Question
Which of the below is an appropriate way to test an ASC for conformance to NTCIP 1202 v03?
Answer Choices
- Using test procedures contained in Annex C of the standard
- Using Anaheim test procedures (when available)
- Connecting to system and see if it works
- Trusting the vendor
Slide 73:
Review of Answers
a) Using test procedures contained in Annex C of the standard
Incorrect Annex C of NTCIP 1202 v03 is currently a placeholder that does not contain any test procedures
b) Using Anaheim test procedures (when available)
Correct! The Anaheim project aims to develop procedures for all NTCIP 1202 v03 requirements
c) Connecting to system and see if it works
Incorrect While this might provide some insights as whether the device will work under normal conditions, it will omit major tests
d) Trusting the vendor
Incorrect Trust does not equate to testing
Slide 74:
Summary
Module A315b Part 1
Concepts taught in previous Part 1:
- Identify NTCIP 1202 v03 Standard Requirements
- Explain the Purpose and Benefits of the RTM
- Prepare a Project-Level RTM
- Prepare an ASC Specification
Slide 75:
Module Summary
- Manage Special Considerations for NTCIP 1202: Infrastructure
- Manage Special Considerations for NTCIP 1202: Functionality
- Incorporate Requirements Not Supported by Standardized Objects
- Testing NTCIP 1202 v03 Conformance
Slide 76:
The ASC Curriculum
MODULE 31. A315a:
Understanding User Needs for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 v03 Standard
Module 32: A315b Part 1:
Specifying Requirements for ASC Based on NTCIP 1202 Standard v03 - Part 1 of 2
Module 42: A315b Part 2:
Specifying Requirements for ASC Based on NTCIP 1202 v03 Standard - Part 2 of 2
Module 35: T315:
Applying Your Test Plan to the NTCIP 1202 v03 ASC Standard
Slide 77:
Next Course Module
Module T315: Applying Your Test Plan to the NTCIP 1202v03 ASC Standard
Concepts taught in next module (Learning Objectives):
- Recognize the importance of testing ASCs
- Apply the rules for developing a sample ASC test plan
- List rules for developing test case specifications and procedures
- Develop sample test case specifications and procedures
- Understand testing results for NTCIP 1202v03
Slide 78:
Thank you for completing this module.
Feedback
Please use the Feedback link below to provide us with your thoughts and comments about the value of the training.
Thank you!
↑ Return to top