2018 SPaT Challenge Peer Exchange

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.

1. Functional Capabilities
   1. Broadcast SPaT
   2. Broadcast MAP
   3. Receive Basic Safety Messages (BSMs) (required for 4.1 spec)
   4. Application-specific requirements (optional)
      1. Software development kit (SDK)
      2. Documentation
      3. Feature Set 1, Feature Set 2, etc.
2. Certification testing
   1. Devices (external/vendor-supplied)
3. Unit-level testing
4. Local testing/field calibration
5. System integration testing
   1. Confirm message set from RSU
6. Application testing
   1. Application output testing (potentially led by OEMs)
7. 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).

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.

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)

• 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 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).

Some agencies around the country are considering non-spat applications which can also be very valuable since it will help with enhancing public safety. It would be interesting to have a resource that list all the connected vehicle applications (both SPaT and non-SPaT) that are pursued in real world by public agencies. We need to effectively communicate the value of these applications and also educate people on the fact that OEMs are moving toward a Connected and Automated Vehicle (CAV) world. MCDOT is currently working on finalizing con-ops for V2V emergency vehicle pre-emption applications project. The intent is to inform other drivers that an emergency vehicle is nearby.