spat challenge webinar series spat ch… · • security credential management stephen novosad,...

SPaT Challenge Webinar SeriesWebinar #6: Deployment and Validation

2:00 – 3:30 PM (Eastern) | June 12, 2018

2

Webinar Logistics

• All lines are muted

• Webinar will be recorded

• Submit questions and comments in chat or Q&A section of webinar window

• Questions will be answered at webinar conclusion

3

Agenda• Welcome and Introduction

Blaine Leonard, Utah DOT

• Security Credential Management Stephen Novosad, HNTB

• Verifying SPaT Deployments’ Compatibility with Vehicles Jay Parikh, CAMP

• Michigan DOT Completed SPaT Deployment Verification Joe Gorman, Michigan DOT

• USDOT CAV Support Services Chris Stanley, Leidos – FHWA Saxton Lab

• Q&A

4

SPaT ChallengeTo challenge state and local public sector transportation infrastructure owners and operators (IOOs) to deploy DSRC infrastructure with SPaT (and MAP) broadcasts in at least one corridor or network (approximately 20 signalized intersections) in each state by January 2020

20 intersections in 50 states by 2020!

Two years of progress:35 Locations

25 States

500 RSUs Operating

2340 RSUs Planned

5

SPaT Challenge Webinars to Datehttps://transportationops.org/spatchallenge/webinarseries

• Five webinars conducted to date Recordings available in full or by topic on SPaT

Challenge website

1. Initial SPaT Challenge Activities (March 6) SPaT Challenge introduction Systems Engineering Approach Overview of Model Concept of Operations and

Requirements documents Costs, Procurement, and Corridor Selection

https://transportationops.org/spatchallenge/webinarseries

6


2. Design Considerations, Part 1 (March 20) SPaT Messages, Data Assembly, and the Signal

Controller Interface V2I Hub Overview Agency experience with deploying on-board units

3. Design Considerations, Part 2 (April 17) Overview of MAP Messages Utah DOT’s MAP Message Creation Approach Vehicle Position Correction Need and Solutions


7


4. MAP Creator Tool Demonstration (April 24) USDOT MAP Creator Tool (Leidos / Saxton Lab) Information about accessing/using the Tool

5. Design Considerations, Part 3 (May 15) RSU Specification v4.1 Roadside Equipment & Backhaul Communications DSRC Licensing


8

SPaT Challenge Websitehttps://transportationops.org/spatchallenge

https://transportationops.org/spatchallenge/resources

9

SPaT Challenge Websitehttps://transportationops.org/spatchallenge


10

SPaT Challenge Resource Pagehttps://transportationops.org/spatchallenge/resources


11

Next SPaT Challenge Webinar• Operational SPaT Deployments July 17, 2018 2:00-3:30pm ET Presentations on 4 SPaT Operational

Deployments highlighting lessons learned Q&A

Register and find more information at: https://transportationops.org/spatchallenge/webinarseries


SCMS, Security, and How It Affects The SPaT ChallengeSteve Novosad, HNTB

13

Agenda• SCMS Purpose• Security in a Perfect World Versus Reality• SCMS Function• Why SPaT Needs SCMS• Applications Certificates• SCMS Limitations• Protection

14

SCMS Purpose

• A secure credential system allows the receiver to authenticates the broadcasted information.

• This creates a mechanism for trust.• Time based expiration of credential prevents

tracking using the credentials. • PII is compromised only if third party

correlate able information are available

15

What We Would Like

16

Closer to Reality

17

SCMS Guarantees Trust in the Message

• SCMS is designed to preserve privacy up to a predictable level

• SCMS will not protect your infrastructure• SCMS cannot coexist with insecure

infrastructure

18

SPaT without SCMS?

• Other Apps will Not Trust your Broadcast Information

• Ensuring Public Privacy is Preserved will be Challenging

• RSUs can Receive Signed Messages

19

Where does the Application Certificate come from?

• Certified RSU Receives an Enrollment Certificate Stores on a Hardware Security Module

• Enrollment Certificates Associated with One or More Provider Service

Identifier (PSID)• Connected Vehicle Applications Grouped and Categorized According to PSID’s

20

Where does the Application Certificate come from?

• RSU Authenticates with SCMS With the Enrollment Certificate Receives Application Certificates.

• Application Certificates are Stored On the Hardware

• Security Module in the RSU• Application Certificates Must be Refreshed

Periodically

21

Enrollment Certificates away from the RSU

• What if RSUs Do Not Have a Dedicated Connection to the SCMS?

• Application Certificates Could Flow Through The Center To Field Network Right Conditions Must Exists An Entity in the Traffic Management Network is

Designated to Hold the Enrollment Certificate. Hardware Security Module Must be in the Traffic

Management Network Connected to the RSU.

22

Limitations of SCMS• Guarantees Trust in the source of the message• Enrollment Certificates are Only Available to

Certified Devices Certified by Approved Certification Laboratories

• Will Not Guarantee the Data is Valid• Will Not Protect Transportation Infrastructure

Systems• Hardware Security Modules are Not a DIY Item Required to be Certified According to Established

Standards (FIPS-140-2 Level 2 for US)

23

Protecting the RSU Data

• How is the RSU Communicating with the Controller?• How is the RSU/controller Communicating with the

Traffic Management Center?• What is being Communicated Between These

Devices?• How can Unauthorized Network Traffic be Detected

and Blocked?• How can Software Tampering be Prevented,

Detected, and Restored?

24

Protecting Our Networks

• Segment the Network SCMS vs Non-SCMS• Monitor All Data Traffic on the SCMS Network• Use Virtual Private Networks• Assume Your Field Cabinets will be Compromised• Establish Policy and Training for Field

Technicians – they’re your first responder to any problems.

25

Early Adopter Considerations

• Be Aware of the Risk• Lessons Learned Reach out to Other SPaT Challenge Sites Reach out to CV Pilots Sites

• Initiate Discussions with SCMS Vendors• Implement SCMS Now Rather Than Later

Verifying SPaT Deployments’ Compatibility with VehiclesJay Parikh, CAMP

SPaT and MAP Message Verification for Red Light Violation Warning

(RLVW)Jay Parikh, CAMP

June 12, 2018

Acknowledgement and Disclaimer

This material is based upon work supported by the U.S. Department of Transportation under Cooperative Agreement No. DTFH6114H00002.

Any opinions, findings, and conclusions or recommendations expressed in this publication are those of the Author(s) and do not necessarily reflect the view of the U.S. Department of Transportation.

June 12, 2018 28CAMP V2I Consortium Proprietary - The information

contained in this document is interim work product and subject to revision.

V2I Project Background

• The Federal Highway Administration awarded a Cooperative Agreement to the Crash Avoidance Metrics Partners, LLC (CAMP) to:

Provide a basis for CAMP and various Automotive Original Equipment Manufacturers (OEMs) and suppliers to work cooperatively on pre-competitive projects to develop crash avoidance and driver information applications

• The CAMP V2I Consortium consists of 9 Automotive OEMs: Ford, GM, Honda, Hyundai-Kia, Mazda, Nissan, Subaru, Volvo Truck, and VW/Audi

29June 12, 2018CAMP V2I Consortium Proprietary - The information


Agenda

• Introduction• RLVW Application• System Architecture

• Intersection Implementation Requirements• Standards and Documents• CAMP RLVW Minimum Performance Requirements

• Intersection Implementation Verification• Goals• Objective Verification• Message Level• Application Level

• SPaT/MAP Verification Document Structure



Red Light Violation Warning (RLVW)

• RLVW warns the driver of an equipped vehicle approaching signalized intersection when a potential of running the red light exists



RLVW Information Exchange

June 12, 2018 32

RSU at a signalized intersection interfaces with:• a traffic signal controller• optional DGPS/RTCM correction base station

Roadside Unit (RSU)

On-Board Unit (OBU)

CAMP V2I Consortium Proprietary - The information contained in this document is interim work product and

subject to revision.

Implementation Requirements

RSU Specification -

• As per USDOT DSRC Specifications Document v4.1• General hardware and software requirements

Message Specification -• SPaT and MAP message as per the SAE J2735 (201603 version) standard

SCMS EE Requirements -• Integration into the SCMS• Security enrollment process, etc.



• After implementation• correct operation needs to be verified

• compliance with specification and requirements

• assure accuracy of transmitted information

• Goals• Track accuracy and consistency of implemented intersections

• Nation-wide compatibility

• Levels of Verification• System Level (required – as per the RSU spec., SCMS EE req.)

• Message Level (required – as per SAE standard)

• Application (Receiver) Level (optional but highly recommended)

June 12, 2018 34

Implementation Verification



SPaT Challenge –SPaT / MAP Message Verification

Objective:• Develop SPaT/MAP verification process to aid state and local DOTs in verifying deployments made

as part of the SPaT Challenge

Scope:• Verification to confirm:

• intersection is broadcasting properly formatted SPaT and MAP messages as per the standards

• data contained in the broadcast messages are accurate

Outcome:• Validated process and lessons learned document for IOO SPaT challenge

Status:• Conducted verification in coordination with MDOT• Revised verification process document with lessons learned



Verification Document Structure

• V2I Safety Application System Architecture• RSU and OBU Architecture

• Minimum Performance Requirements• SPaT, MAP, Message Transmission, etc.

• SPaT and MAP Verification of an Installation• System level, message level and optional application level

• Validation of Verification Steps• Outcome of Verification and Observations

• Satellite Based Positioning System Error and Correction Techniques• Position Correction for Different Intersection Configurations

June 12, 2018CAMP V2I Consortium Proprietary - The information


36

SPaT Challenge Verification Document Revised - October 30, 2017

Version 1.2

CAMP’s OBU and RSU Subsystems

OBU:

• On board embedded system that includes a DSRC radio, computing platform and necessary I/O interfaces

• GPS receiver• On board display for HMI/DVI• Application s/w

RSU:• Based on USDOT DSRC RSU Specification

• Traffic Signal Controller compliant with the NTCIP 1202 Standard

• Optional differential GPS (DGPS)/RTCM correction base station



37

MPR for RLVW Application

• Message transmission requirements• Required vs. optional message data elements for the

application • Interpretation of the data elements and their use• Timing accuracy requirements• Intersection mapping accuracy requirements



Levels of Verification

• System-Level (required) to Ensure:• The system is built according to the USDOT RSU specifications, NTCIP and SCMS

EE requirements• The system-level verification is NOT included as part of the verification document and it relies

upon referenced documents

• Message-Level (required) to Ensure:• The messages transmitted by the RSU are as per the SAE J2735 2016 standard

(proper encoding, data elements and format)• The transmitted data content is validated for correctness and accuracy

• Application (receiver)-Level (optional but highly recommended) to Ensure:• Transmitted information is correct for operation of the RLVW application

• MAP of all lanes are provided

• SPaT is correctly associated with the mapped lanes and verified against the signal light



Verification Steps of an Implementation

1. Input to describe an intersection (reference point, lanes, node points, etc.)

2. Convert input to vendor specific “configuration file” (for example xml file) and input to RSU

3. Interface with signal controller and broadcast SPaTand MAP

4. MAP message verification• Capture MAP message• Compare and verify with user input

5. SPaT message verification• Capture SPaT message • Compare and verify SPaT from the signal controller

with received SPaT message

June 12, 2018 40

5



Message Level Verification

SPaT

• Time stamp• Intersection State List

• Intersection Reference ID• Movement List• Signal Group ID

• Signal phase time change details

MAP Attributes

• Valid PSID, msgid• Node points

• Distance• Accuracy

• Stop bar location• MAP attributes

• Maneuver • Direction• Associated Signal Group



SPaT Message – Required Data



42

SPaT Message SAE J2735 (201603)

RLVW Application

timeStamp MinuteOfTheYear (DE) Optional Required

intersections IntersectionStateList (Sequence of IntersectionState) (DF) Required Required

IntersectionState (DF)

id IntersectionReferenceID (DE) Required Required

revision MsgCount (DE) Required Required

status IntersectionStatusObject (DE) Required Required

timeStamp Dsecond (DE) Optional Required

states MovementList (Sequence of MovementState) (DF) Required Required

MovementState (DF)

signalGroup SignalGroupID (DE) Required Requiredstate-time-speed MovementEventList (Sequence of MovementEvent)

(DF)Required Required

MovementEvent (DF)

eventState MovementPhaseState (DE) Required Required

timing TimeChangeDetails (DF) Optional Required

minEndTime TimeMark (DE) Required Required

maxEndTime TimeMark (DE) Optional Optional

likelyTime TimeMark (DE) Optional Optional

MAP Message – Required Data



43

MAP Message SAE J2735 (201603)

RLVW Application

msgIssueRevision MsgCount (DE) Required Requiredintersections IntersectionGeometryList (Sequence of IntersectionGeometry) (DF) Optional Required

IntersectionGeometry (DF)id IntersectionReferenceID (DF) Required Required

id IntersectionID (DE)revision MsgCount (DE) Required RequiredrefPoint Position3D-2 (DF) Required Required

lat Latitude (DE) Required Requiredlong Longitude (DE) Required Required

laneWidth LaneWidth (DE) Optional RequiredLaneList (Sequence of GenericLane) (DF) Required Required

GenericLane (DF)laneID LaneID (DE) Required Requiredmaneuvers AllowedManeuvers (DE) Optional RequiredNodeList (DF) Required Required

nodes NodeSet (Sequence of Node) (DF)Node (DF)

delta NodeOffsetPointXY (DE)[Any representation Node-XY-20b through Node-XY-32b]

connectsTo ConnectsToList (Sequence of Connection) (DF) Optional RequiredConnection (DF)

connectingLane ConnectingLane (DF) Required Requiredlane LaneID (DE) Required Requiredmaneuver AllowedManeuvers (DE) Optional Required

signalGroup SignalGroupID (DE) Optional Required

Test Case - 1: Verification of an Implemented

Intersection

On Mound Road at 12 Mile and 13 Mile road intersections (4 lanes going north & south, 2 lanes going east & west)

• Message level verification:• RSU was transmitting 2015 version of SPaT / MAP, later

updated to 2016 version

• Application (receiver) level:• Issues identified in received SPaT:

• Incorrect “time remaining to next phase” for green phase

• RSU transmitted “time remaining for pedestrian crossing”

• “Red phase” indicated as “flashing red”

• Issue identified in received MAP:• Only the right two lanes going north & south are mapped



44

12 Mile and Mound

13 Mile and Mound

Image Source: © 2016 Google Map Data. Used with permission.

Test Case - 2: Verification of an Implemented

Intersection

On Telegraph and West Nine Mile Road• Message level verification:

• RSU is transmitting 2016 version of SPaT / MAP

• Application (receiver) level:• Issues identified in received MAP:

• Lane count showed as 0

• Lanes are designated as egress lanes, the RLVW application need ingress lanes



45

Telegraph and W. nine Mile Road


Satellite Based Positioning System Error



Need for Position Accuracy

• In order for the vehicle to accurately identify the approach and associate with signal phase using the SPaT / MAP message, it is critical that the location of the vehicle (determined by the on-board GPS) is within required accuracy

• Satellites broadcast their signals in space with a certain accuracy, but what is received depends on additional factors

• This can be accomplished by a broadcast of position correction information



User Equivalent Range Error (UERE)

• Error components in the distance from a satellite to the receiver• Signal arrival time measurement• Atmospheric effects (changes slowly)

• Ionosphere - affects speed of the signal as they pass through earth’s atmosphere• Effects are smaller when satellite is directly overhead and greater for satellites near horizon

• Troposphere - humidity also causes a variable delay• Effects are localized and changes quickly• Atmospheric pressure - affects signal reception delay

• Ephemeris and clock errors• Receiver Noise• Multipath• Geometric dilution of precision

• Satellites have smaller angular separation (close together) in the sky – DOP value is high

• Satellites have wider angular separation – DOP is low, better positional accuracy

June 12, 2018 48

Source: https://en.wikipedia.org/wiki/Error analysis_for_the_Global_Positioning_SystemSource: http://www.gps.gov

Contributing Source

Error Range

Satellite Clocks ~ ± 2m

Orbit Errors ~ ± 2.5m

Ionospheric Delays ~ ± 5m

Tropospheric Delays

~ ± 0.5m

Receiver Noise ~ ± 0.3m

Multipath ~ ± 1m



https://en.wikipedia.org/wiki/Error_analysis_for_the_Global_Positioning_System

http://www.gps.gov/

Radio Technical Commission for Maritime (RTCM)for Position Correction

• What is RTCM?• Message standard and data format for GNSS• RTCM Special Committee 104 was formed to draft a standard

format for the correction messages to ensure an open real-time DGPS system

• The format is generally known as RTCM SC 104• RTCM is not instrument specific



RTCM SC-104 Versions

June 12, 2018 50

RTCM - 2.0 (Code correction DGPS)RTCM - 2.1 (Code + Phase correction RTK)

RTCM - 2.2 ( …+ GLONASS )

RTCM - 2.3 ( ….+ GPS Antenna Definition)

RTCM - 3.0 (….+ Network RTK & GNSS)• Message type 1001 – GPS L1 observations at 5 Hz• Message type 1005 – Antenna Reference Point (ARP)

coordinates at 2 Hz



Position Correction for Different Intersection Configurations



Open Sky Clear Visibility Satellite Intersections

June 12, 2018 52

2

1

1

1

1

2

2

Intersection Configuration:• Multiple lanes in each direction

• Near-far traffic lights in all direction

Complexity - Low:• Simple – Straight through and right

turn

• Maximum 2 signal phase associations – Straight and right turn movements

• Positioning challenge - Low

Position correction may not add significant benefit• Limited lane level map matching is

requiredImage Source: © 2018 Google Map Data. Used with permission.



Low/Poor Satellite Visibility Intersections

June 12, 2018 53

Intersection Configuration:• Typical no Near-far traffic lights

Complexity - High:• Multiple lanes in each direction

• Multiple signal phases in each direction

• Urban canyon, obstructed satellite visibility, makes it difficult to use correction

• Positioning challenge - High

Position correction would not provide required benefits




Open Sky Clear Visibility Satellite Intersections Complex SPaT / MAP

June 12, 2018 54

Intersection Configuration:• Typical, no near-far traffic lights

Complexity - High:• Multiple lanes and multiple signals

phases in each direction

• Lane level positioning is required

Position correction would certainly provide required benefits




Benefits from Position Correction

Benefit from Position Correction

Satellite Visibility

Intersection ConfigurationOpen Sky High Satellite Visibility Obstructed Satellite Visibility

Combination of Less Complex SPaT/MAP Configuration Some benefit can be achieved May not achieve desired benefit

Combination of Highly Complex SPaT/MAP Configuration

Most benefit can be achieved

Cannot achieve desired benefit



Thank you!Jay Parikh, CAMP

[email protected]

mailto:[email protected]

Michigan DOT Completed SPaT Deployment VerificationJoe Gorman, Michigan DOT

Completed SPaT Deployment Verification - Lessons LearnedJoe Gorman, Michigan Department of Transportation

59

Verification• System Level Verification RSU/Controller Communication

• Message Level Verification OTA Message Standards

• Application Level Verification Data elements for Applications

60

Intersections

• Mound Rd at 12 and 13 Mile Rd 8 lane divided with indirect lefts

• Telegraph Rd at 9 mile Rd 8 lane divided with indirect lefts

• Jefferson Avenue in Detroit Griswold St to Beaubien St Urban, Complex

60

MDOT

61

System Level

• Communication between Signal Controller and RSU. Technology and business process are both

important.

62

System Level – Signal Controllers

• Coordinated effort with Signals Division to update traffic signal controller specification standards.

• All new or upgraded traffic signals on the MDOT system will be CV-enabled moving forward.

63

System Level – Lessons Learned

• SPaT output from controller (V2I Hub, NTCIP 1202) may be a factor.

• New firmware may allow older hardware to support SPaT.

• Coordination with Traffic Signals Staff.• Coordinated system architecture

64

Message Level Verification

• Over the air broadcast should be formatted and encoded according to SAEJ2735_2016-03.

65

Message Level - Lessons Learned

• J2735 version control.• Map accuracy and encoding.• MAP/SPaT optional data elements.• Establish best practices for Map data

collection.• Establish best practices for SignalGroupID

and IntersectionReferenceID.

66

Application Level Verification

66

Application

Message System

67

Application Level - Lessons Learned

• Ensure all optional data elements are included to support desired application.

• Need for longer approach in MAP may cause overlap.

• Establish best practices for message broadcast channels.

• Establish best practices for application support.

67

68

Resources

SAE J2735 Standard

FCC DSRC Channel Allocation

FCC Universal Licensing System

68

https://www.sae.org/standards/content/j2735_201603/

https://www.ecfr.gov/cgi-bin/text-idx?SID=127f95946e8468655a319b49cf50af76&mc=true&node=se47.5.90_1377&rgn=div8

http://wireless.fcc.gov/uls/index.htm?job=home

USDOT CAV Support ServicesChris Stanley

Support, resources, and equipment to support the deployment of Connected and Automated Vehicle (CAV) technologies.

CAV SUPPORT SERVICES

Chris Stanley, PMP, P.E. | Leidos, Inc.Saxton Transportation Operations Lab (STOL) Program Manager503.395.8105 Mobile | Office 202.493.3294

CAV Support Services

• Helpdesk

• Device Testing

• Device Configuration Support

• Installation Support

• Frequently Asked Questions (FAQ)

• Supporting Documents and Links

• Equipment Loan

• MAP Message Creation Tool

• TIM Message Creation Tool

• Message Validator Tool


Website: https://cvcs.samanage.com

Open an account to enable support requests, reporting and tracking bugs, requesting new features, and providing feedback.

https://cvcs.samanage.com/

Helpdesk


• Device Testing

• Device Configuration Support

• Installation Support

• Frequently Asked Questions (FAQ)

• Supporting Documents and Links

Maintenance Machine

EthernetSwitch

Road Side Unit

EthernetCable

EthernetCable

Surge

PoE

EthernetCable

EthernetCable

TMC

TMCBackhaul

VPNConnection

(remote)EthernetCable(local)

Display

Traffic SignalController

Power Supply

On-BoardUnit

ShieldedOutdoor-RatedEthernet Cable

TSC RSU GPS TMC MAP SPaT CSW

V2I HubPower Supply

TMC

TMCBackhaul

Equipment Loan Program

• Roadside Units (RSUs) – Infrastructure DSRC radios• Onboard Units (OBUs) – In-vehicle DSRC radios• DSRC Sniffers – Device to validate wireless

communications• V2I Trailers – Self-powered trailers with radios and traffic

signal controllers for mobile testing• V2I Test Device – Device with visual display to confirm

transmission of SAE J2735-03 messages

Tools

Website: https://webapp2.connectedvcs.com/

https://webapp2.connectedvcs.com/

Tools

MAP Message Creation Tool• With a graphical interface, this tool allows users to develop intersection

geometries for broadcast according to the SAE J2735-2016 standard.

Tools

TIM Message Creation Tool• This tool allows users to build

traveler information messages regarding sign and work zone details using a graphical interface

Message Validator• Use this tool to check versions

of messages for accuracy against the specifications and standards

CAV Support ServicesToll-free # 1-844-DOT-CVCS (1-844-368-2827) https://cvcs.samanage.com/

Business hours: Monday-Friday, 8:00AM - 5:00PM ESTToll-free #: 1-844-DOT-CVCS (1-844-368-2827)

Chris StanleyLeidosSaxton Transportation Operations Lab Program [email protected]

80

Next SPaT Challenge Webinar• Operational SPaT Deployments July 17, 2018 2:00-3:30pm ET Presentations on 4 SPaT Operational

Deployments highlighting lessons learned Q&A



81

Next SPaT Challenge Webinar• ond the SPaT Challenge August 14, 2018 2:00-3:30pm ET deployment of applications supported by SPaT

broadcasts and installation of on-board units (OBUs) on agency fleet vehicles as part of the Connected Fleet Challenge.



Q&ASubmit questions and comments in chat or Q&A section of webinar window

Upcoming SPaT Challenge WebinarsOperational SPaT Deployments July 17, 2018 2:00-3:30pm ETBeyond the SPaT Challenge: Applications and

the Connected Fleet Challenge August 14, 2018 2:00-3:30pm ET