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

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

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

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

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

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

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

SPaT Challenge Websitehttps://transportationops.org/spatchallenge

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

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

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

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

What We Would Like

Closer to Reality

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

SPaT without SCMS?

• Other Apps will Not Trust your Broadcast Information

• Ensuring Public Privacy is Preserved will be Challenging

• RSUs can Receive Signed Messages

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

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

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.

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)

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?

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.

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

SPaT Challenge Verification Document Revised - October 30, 2017

Version 1.2

CAMP’s OBU and RSU Subsystems

• 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

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

Message Level Verification

• 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

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

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

12 Mile and Mound

13 Mile and Mound

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

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

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

Intersection Configuration:• Multiple lanes in each direction

• Near-far traffic lights in all direction

Complexity - Low:• Simple – Straight through and right

• 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

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

jparikh@campllc.org

Michigan DOT Completed SPaT Deployment VerificationJoe Gorman, Michigan DOT

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

Verification• System Level Verification RSU/Controller Communication

• Message Level Verification OTA Message Standards

• Application Level Verification Data elements for Applications

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

System Level

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

important.

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.

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

Message Level Verification

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

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.

Application Level Verification

Application

Message System

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.

Resources

SAE J2735 Standard

FCC DSRC Channel Allocation

FCC Universal Licensing System

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.

Helpdesk

• Device Testing

• Device Configuration Support

• Installation Support

• Frequently Asked Questions (FAQ)

• Supporting Documents and Links

Maintenance Machine

EthernetSwitch

Road Side Unit

EthernetCable

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

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

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

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.

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 ManagerChris.Stanley@Leidos.com

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

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

SPaT Challenge Webinar Series SPaT Ch… · • Security Credential Management Stephen Novosad,...

Documents

Spat Stat Manual

Hays County...shawn b. stover, hntb tbpe firm registration hntb corporation the hntb companies engineers archi tects planners 701 brazos, suite 450 austin, tx 441-5590 submitted by:

Mayra Rodriguez - SPAT

GSM SPAT IMAGE

Spat 082007 A

Descargas Atmosfericas spat

Exposicion spat

Spat Stat Intro

Draft Hntb Report Only 11-11-09

Getting Signal from Interval Data: Theory and Applications ...novosad/asher-novosad-rafkin-bounds.pdf · Charlie Rafkinx June 2019 Abstract ... Emily Blanchard, Raj Chetty, Eric Edmonds,

PaulDelaney SouthernCaliforniaEdison … · 2020. 1. 2. · Serial Projects Action Team (SPAT) – Update 26 Total SPAT Completed 106 Total SPAT completed in 2012 53 Total SPAT completed

SPaT Challenge SPaT Infrastructure System · SPaT Challenge Model Functional Requirements – Draft Page 1 1. Introduction 1.1 Background The American Association of State Highway

Mapa De Spat

Modelamiento Spat

REVISTA SPAT

Hays County...shawn b. stover, p.e. hntb tbpe f registration not hntb corporation the hntb copanies engineers archi tects planners brazos, suite 450 austin, rx 441-5990 139 ml west

Children's Spat Pattern

HNTB Vikings Stadium Proposal

Educational Investment Responses to Economic Opportunity ...novosad/adukia-asher-novosad-dise-roads.pdfWe thank Srinivas Balasubramanian, Jack Landry, Anwita Mahajan, Olga Namen, and

Indice de riesgo SPAT