Image from Utah DOT's MMITSS field trip demonstration
On February 14th - 16th, 2018 the National Operations center of excellence hosted the SPaT Challenge peer exchange in Utah DOT headquarters in Salt Lake City, Utah. In this peer exchange the State DOTs discussed and shared the successes and challenges of deploying SPaT Challenge. Click here to download the Peer Exchange Proceeding Document which provides a summary of the peer exchange conversation and content in the following subjects:
|Topic 1: SPaT Procurement & Deployment (Hardware & Software)||Topic 2: MAP Message Development||Topic 3: General notes on SPaT Challenge|
| || || |
Representatives from the following agencies participated in this peer exchange:
| || |
Attendees, representing eight regions and a total of eleven agencies, each presented on specific experiences and best practices for deploying SPaT Challenge. Several documents, reports, and presentations were shared as part of this peer exchange that can be found on NOCoE’s Peer Exchange Webpage. Click here to see a summary of agency status on deploying SPaT challenge. Additinally, you can view field demo & media coverage in appendix B of proceeding document. Interested in learning more about SPaT Challenge? Click here to view the SPaT Challenge Webinar Series. Click here to view the SPaT Challenge Progress through an interactive map on NOCoE’s website.
The following highlights some of the take aways from the peer exchange:
Implementation procedure and testing
A significant challenge associated with the deployment of any ITS equipment is testing and calibration. With the SPaT Challenge, many agencies have experienced difficulties associated with their planned deployment timelines due to inconsistent testing procedures, which results in a mismatch of expectations between the DOT and the contractor(s) responsible for deployment and maintenance. The steps below are the initial makings of a standardized testing procedure that could be built into a procurement document for DSRC and SPaT equipment. Note that these are high-level categorical considerations only; individual agencies would still need to decide if each of the elements make sense within the context of their own business processes, and what the specifics associated with each step would entail.
- Functional Capabilities
- Broadcast SPaT
- Broadcast MAP
- Receive Basic Safety Messages (BSMs) (required for 4.1 spec)
- Application-specific requirements (optional)
- Software development kit (SDK)
- Feature Set 1, Feature Set 2, etc.
- Certification testing
- Devices (external/vendor-supplied)
- Unit-level testing
- Local testing/field calibration
- System integration testing
- Confirm message set from RSU
- Application testing
- Application output testing (potentially led by OEMs)
- Operational troubleshooting
The testing procedures depend on the maturity of standards that is currently under development. The traffic controller testing process is a very similar process if not the same.
The CAMP specifications are met when data is received within minimum of 300 feet range (and more). This requirement is met for the agencies present at the peer exchange that have deployed CV DSRC road side units that broadcast SPaT (Arizona , Michigan, Utah, Florida, and California).
MAP creation methods
The following methods/procedures are used for creating a map:
- Manual creation
- FHWA MAP Creation Tool
- UDOT approach
- C++ process
- Mobile Lidar point clouds /HD map (There was a pooled fund study to create a LIDAR equipped device. Results: The map that was created was not exactly what we wanted)
- Aerial photography
- Private industry has high accuracy mapping capabilities (Should we work with them initially?)
FHWA’s Intersection MAP and SPaT creator tool has the support service where users can ask questions and receive support. This will allow submitting support and demonstration requests, reporting and tracking bugs, requesting new features, and providing feedback.
MAP level of accuracy
The transportation industry needs a standard/recommended practice for mapping methods; How good of a map do we need that would cover most of the connected vehicles applications? The number of nodes and level of accuracy and distance from intersection depends on the application we use (e.g. MMITTSS vs traffic count). It would be good if a resource could be created that included a template map for each application. What is the recommended level of accuracy for the following connected vehicle applications?
- In-vehicle applications
- Red light violation warning (Stop-bar accuracy)
- Signalized left turn assist
- Equal approach in departure (TOSCO)
- QA/QC needs
- Real-time operations needs
- Validation of traffic movements
- Lane accuracy against vehicle movements
- (Monitoring the quality of map)
MAP message creator tool
- USDOT has developed a tool library using SAE J2735 3/2016 that consists of the following:
- ISD Message Creator (Intersection MAP and SPaT): This tool allows a user to define the lanes and approaches of an intersection using a graphical interface. Once designed, the user can encode an ISD, MAP, or SPaT message as an ASN.1 UPER Hex string.
- Message Validator (for SDC/SDW messages): Use this tool to check versions of messages for accuracy against the specifications and standards prior to depositing into a warehouse.
- TIM Message Creator (Traveler Information): This tool allows users to build traveler information messages regarding sign and work zone details using a graphical interface. Once designed, the user can encode a TIM message as an ASN.1 UPER Hex string and deposit it to the SDW warehouse.
- The tools are Open source and free for download with a system support team.
- For a recorded tutorial on how to use MAP creator tool, refer to webinar, SPaT Challenge: MAP Creator Tool (April 24, 2018 1:00pm – 2:30pm ET)
The Utah DSRC MMITSS Project
The Utah DSRC MMITSS project goal is to provide conditional bus transit priority to improve schedule reliability. DSRC equipment was installed on a 11-mile urban arterial corridor (24 intersections). Currently, SPaT and MAP are broadcasting at each of these intersections. The MMITSS Operation includes the following steps (simplified):
- Bus comes into range of DSRC at intersection
- Connects to system
- Receives SPaT and MAP data
- GPS reports bus location
- MMITSS determines bus location in lane, distance to signal
- MMITSS queries bus schedule system
- If bus is late, MMITSS generates request for priority
- Priority request is sent to roadside
- MMITSS-AZ (Free Mode): Algorithm manages signal operation to accommodate bus priority request. MMITSS-Utah: Sends priority request to controller
- Sends National Transportation Communications for Intelligent Transportation System Protocol (NTCIP) command to controller – sets input PIN
Currently, four buses are equipped with OBUs on Utah’s Bus Route 217. With the MMITSS in place, Utah DOT is aiming to increase schedule reliability from 86% to 94%. A before-after study will be conducted in future to analyze the effect of this program after acquiring a reasonable-sized dataset. Click here to download the Utah DSRC MMITSS project slides. Also, Click here to see slides about UDOT’s methodology for creating NMAP files.
The agencies that were one of the first ones in the country that deployed RSU units and broadcasted SPaT, had invested extensive time and energy to reach the current level of maturity. New agencies can learn from the lessons they learned and find a partner that has been through this before.
Some of the examples of cross-department partnerships within the agency for deploying SPaT challenge:
- Surveying department (MCDOT and Utah)
- Construction projects Connected vehicle work zone and smarter road work zone (MCDOT)
- In the FCC licensing process, we worked with the wireless department for the county (MCDOT)
Some of the examples of external partnerships:
- Maricopa County DOT has limited number of OBUs (currently 14), but the department has reached out to people to encourage them to buy OBUs and put it on vehicles. First, they started by having OBUs on emergency vehicles. Then, they reached out to Homeowner Association asking for volunteers from the general public that wanted to participate. Strong neighborhood communications have helped MCDOT to bring public awareness to the issue. MCDOT is also looking to have OBUs on county vehicles. MCDOT is looking forward to collaborating with fire industry to investigate the possibility of having on board units on fire department vehicles (Also, Department of Homeland Security and Federal Emergency Management Agency could be potential supporters). MCDOT has also worked with Discovery Chanel Canada to create a video to demonstrate the connected vehicle technology. View this video in the NOCoE’s resource page for connected and automated vehicles (Source: MCDOT Communications YouTube Channel).