spat challenge webinar series webinar … · spat challenge webinar series webinar #1: initial spat...

SPaT Challenge Webinar SeriesWebinar #1: Initial SPaT Challenge Activities

2:00 – 3:30 PM (Eastern) | March 6, 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• Introduction to the SPaT Webinar Series Blaine Leonard, Utah DOT

• Systems Engineering Approach to the SPaT Challenge Ray Starr, Minnesota DOT Dean Deeter, Athey Creek Consultants

• Costs, Procurement, and Corridor Selection Blaine Leonard, Utah DOT

• Q&A

Introduction to the SPaT Webinar SeriesBlaine Leonard, Utah DOT

5

Update on V2I Deployment Coalition (V2I DC) Phase 2

• V2I DC activities have resumed • https://transportationops.org/V2I/V2I-overview• SPaT Challenge activities will continue under the

Strategic Initiatives Technical Working GroupStrategic Initiatives

TWG

SPaTChallenge

Resource Team

SPaT Challenge Tactical Working

Group

6

Update on V2I DC Phase 2• Strategic Initiatives Working Group (Phase 1 TWG 1) Chaired by Greg Larson, Caltrans Meets 4th Thursday of every month at 2pm ET Next meeting: March 22 at 2pm ET

• Technical Resources Working Group (Phase 1 TWG 4) Chaired by Faisal Saleem, MCDOT Meets 2nd Wednesday of every month at 11am ET

• Peer Exchange & Outreach Working Group Chaired by Ed Seymour, TTI

• To be added to or removed from one or more groups, visit: https://www.surveymonkey.com/r/V2IDC_TWGs

7

SPaT ChallengeWhat is the Challenge?To challenge state and local public sector transportation IOOs to cooperate together to achieve deployment of DSRC infrastructure with SPaT broadcasts in at least one corridor or network (approximately 20 signalized intersections) in each state by January 2020

8

SPaT ChallengeWhat is SPaT? A Signal Phase and Timing (SPaT) message defines the current intersection signal light phasesCurrent state of all lanes at intersection are provided, as well as any active pre-emption or priority.SPaT message defined by SAE J2735 (a subject of a subsequent webinar)

9

SPaT Challenge

Why do this Challenge?To provide IOOs with an entry into DSRC-based V2I deployment and gain valuable procurement, licensing, installation, and operation experience, which in turn will:

Lay ground work for more advanced V2I deployments Show a commitment to OEMs and applications developers Analogous to early fiber deployments – most benefits came later

10

SPaT ChallengeWhat are the benefits?• Be more prepared for DSRC-equipped

vehicles and on-board V2I applications• Useful as testing site for future applications• Supports deployment of V2I applications that

build on SPaT at intersections: Smart Transit Signal Priority Red Light Violation Warning Intelligent Signal Systems Eco-Driver

11

SPaT ChallengeWhat is the long-term goal?• Widespread deployment of V2I applications at

intersections will lead to: Improved safety for drivers and pedestrians Improved mobility for traveling public, transit, freight,

snow plows, and other fleet vehicles

• High penetration rates in vehicles Agency vehicles and OEM-produced vehicles able to

utilize and benefit from SPaT broadcasts

• We have to start small . . . And scale up!

12

SPaT Challenge Website

One-stop shop for SPaT-related information• Overview• Current map

with SPaTdeployment details and contacts

• Resources

https://transportationops.org/spatchallenge

13

SPaT Challenge Website

+ New ConOps Document+ Webinar Schedule and Recordings

14

Upcoming SPaT Challenge Webinars• Design Considerations, Part 1

March 20, 2018 2:00-3:30pm ET Signal controller interface and creation of SPaT messages Examples of designs for assembling SPaT messages DSRC licensing

• Design Considerations, Part 2 April 17, 2018 2:00-3:30pm ET MAP messages and vehicle position correction

• MAP Creator Tool Demonstration April 24, 2018 1:00-2:30pm ET Live technical demonstration and step-by-step training on using the MAP creator tool

• Design Considerations, Part 3 May 15, 2018 2:00-3:30pm ET Backhaul infrastructure, intersection, and roadside equipment specification, design and

installation

• Deployment & Validation June 12, 2018 2:00-3:30pm ET Procurement, validation, verification, and security of SPaT deployments

Systems Engineering Approach to the SPaT ChallengeRay Starr, Minnesota DOT

16

Why a Systems Engineering Approach?

• Federal funding requires it• System that meets user needs• Needs are not missed• Common understanding of intent• Basis for testing• Stakeholder roles• Especially valuable for implementing non-

routine systems

17

Systems Engineering“Vee” Diagram

Source: FHWAhttps://www.fhwa.dot.gov/cadiv/segb/

18

Concept of Operations (ConOps)


19

• Scope/Background• System overview (Context Diagram)• Operational needs• Concept(s) (apps & functions)• User oriented operational descriptions• Operational scenarios

Concept of Operations (ConOps)

20

System Requirements


21

• Itemized requirements• Verification method Demonstration, test, analysis, inspection

• References for requirement• Traceability to needs

System Requirements

22

Minnesota’s SPaT Deployment

Planning Phase Scope of Work• ConOps• System requirements• Data governance plan & tech support• System security plan• Project deployment plan• Design support• Construction inspection support

23

Minnesota’s ConOps (First Draft)

24

Minnesota’s ConOps (First Draft)Challenge

Need

IDNeed

Roadway User Needs

General Equipped Vehicle Operator/Self‐Equipped Driver NeedsIn‐Vehicle equipment runningapplications need intersectiondata to support thoseapplications

UN‐CC‐1.01‐v01

Signal Phase and Timing. A General Equipped VehicleOperator Driver/Self‐Equipped Driver needs advance noticeof signal phase and timing changes to safely approach anintersection

Drivers may be unaware thatthey are approaching a shortterm mobile work zone orsnow plow actively engaging inoperations

UN‐CC‐1.02‐v01

Dynamic Roadway Maintenance Activity Awareness. AGeneral Equipped Vehicle Operator Driver/Self‐EquippedDriver needs to be aware of dynamic maintenance activities(e.g. snow plowing, pothole filling) in/along the path oftravel

General Vehicle Operator isnot aware of pedestrian incrosswalk due to a‐pillarocclusion

UN‐CC‐1.03‐v01

Pedestrian in Crosswalk Awareness. A General EquippedVehicle Operator Driver/Self‐Equipped Driver needsincreased awareness of a pedestrian in a crosswalk whenmaking a movement at a signalized intersection due toocclusion by the vehicle a‐pillar to reduce the likelihood of apedestrian crash

25

Minnesota’s ConOps (First Draft)User Class Use Cases

SPaT Vehicle‐Pedestrian Intersection Conflict Warning

Snow Plow Signal Priority

CV Data Mgmt

Third‐Party Traffic

Signal Data Sharing

Mobile Work Zone Warning System

General Equipped Vehicle Operator

X X X

Self‐Equipped Driver X* X* X* XUnequipped Driver XSnow Plow Operator X X

Pedestrian XTraveler Information

ProviderX

Work Zone Worker XTraffic Manager X X X X

26

Scenario Diagram

Key Actions and Flow of Events

Source Step Key Action Comments

General 1

Traffic Signal turns green (permitted) for the vehicle and for opposing traffic

Solid green bulb (no left turn arrow) indicates a permitted left turn

Pedestrian 2

Simultaneously receives a walk signal and begins to cross the crosswalk to the left of the vehicle

Crosswalk is in the intended path of the vehicle

CC System 3

Issues notification to general equipped vehicle operator that there is a pedestrian in the crosswalk.

As the system properly detects a potential conflict between the vehicle and the pedestrian

General EquippedVehicle Operator

4

Advances into the intersection and stops, waiting for opposing traffic to clear

General 5 Opposing traffic clears the intersection

Pedestrian 6

Continues to cross and remains in the crosswalk

CC System 7

Continues to issue notification to general vehicle operator that there is a pedestrian in the crosswalk.

See Step 3 comment

Minnesota’s ConOps (First Draft)Use Case

Vehicle‐Pedestrian Intersection Conflict Warning

Scenario ID and Title

UC2‐S1: Normal Operating Conditions – Pedestrian in Signalized Crosswalk

Scenario Objective

Improve awareness of pedestrians to general equipped vehicle operators

Notify and warn general equipped vehicle operators when their path of travel is across a crosswalk with a pedestrian in it

Operational Event(s)

The system properly determines there is a pedestrian in the vehicle’s path

The system properly notifies the General Equipped Vehicle Operator of a pedestrian in the path of the vehicle

User(s)

User Role

Pedestrian Safely traverse the crosswalk at the intersection

General Equipped Vehicle Operator

Safely navigate through the intersection

Initial Conditions

A vehicle is waiting to make a permitted (not protected) left turn at a red light

Opposing traffic is queued at the same signalized intersection

A pedestrian is waiting to cross the opposing crosswalk, but is traveling against the flow of opposing traffic

The pedestrian has performed all required actions (e.g. pressing the pedestrian crossing push button) to receive a walk signal during the next cycle

Note: This scenario is generally applicable to any pedestrian movement and general equipped vehicle movement such that the path of the vehicle crosses the path of the pedestrian when the pedestrian has the right‐of‐way.

Post‐Conditions

The pedestrian safely crosses the intersection in the crosswalk

The general equipped vehicle operator completes the left turn without compromising the safety of the pedestrian

Traceability

UN‐CC‐1.03‐v01 Pedestrian in Crosswalk AwarenessUN‐CC‐4.01‐v01 Pedestrian in Crosswalk Safety

CC System Inputs

Detection (of Pedestrian) Map Input (from Traffic Manager) Position Correction Data (from NTRIP Caster) Raw Traffic Signal Data (from Traffic Signal

Controller) General Equipped Vehicle Location/Motion

(from GNSS)

CC System Outputs

Pedestrian in Crosswalk Notification (to General Equipped Vehicle Operator)

Pedestrian in Crosswalk Warning (to General Equipped Vehicle Operator)

27

Systems Engineering“Vee” Diagram


SPaT Challenge Model ConOps& RequirementsDean Deeter, Athey Creek Consultants

29

SPaT Challenge Model ConOps& Requirements Overview

Four Things I’d Like to Accomplish Today1. Introduce the Model ConOps &

Requirements Documents

2. Define the term “SPaT Infrastructure System”

3. Describe the Approach to the Documents

4. Share a Few Examples of Details

30

Introduction to the Model Documents

• SPaT Challenge Model Concept of Operations and Functional Requirements Two stand-alone but related documents Available online:

https://transportationops.org/spatchallenge/resources• Developed to help agencies plan a SPaT

infrastructure deployment• Written for transportation agencies to adapt to

various local site conditions, individual practices, and to address specific needs

• Represents initial “model” concepts• These are “working drafts” to serve as resources to

you. Not prescriptive in any way

31

Driver

Pedestrians

Defining “SPaT Infrastructure System”

Users who will Benefit

From SPaT Data

Traffic Signal Systems

Sources of SPaTData

32

Driver

Pedestrians

SPaT Enabled V2I Connected Vehicle Systems


From SPaT Data


Sources of SPaTData

SPaT Enabled Connected Vehicle

Systems

33

SPAT Infrastructure System

(the Focus of the ConOpsDocument)

Driver

Pedestrians



From SPaT Data

New infrastructure to securely communicate SPaT, MAP, and supporingdata to Vehicles and Pedestrian devices.

May also receive data from vehicles and pedestrian devices.


Sources of SPaTData

34

SPAT Infrastructure System

(the Focus of the ConOpsDocument) SPAT Vehicle System

Driver

Pedestrians



From SPaT Data

New infrastructure to securely communicate SPaT, MAP, and supporingdata to Vehicles and Pedestrian devices.

May also receive data from vehicles and pedestrian devices.

Applications that will be installed on passenger or fleet vehicles to communicate with SPaTInfrastructure Systems to receive data, and use the data to support the drivers’ safety, mobility, and efficiency.

Personal Information Devices (a User of the SPaT

Infrastructure System)

Handheld devices that receive communications from the infrastructure and support pedestrians as they cross intersections


Sources of SPaTData

Direct Users of the SpaTInfrastructure System

35

SPaT Challenge Model ConOps• Focused on SPaT Infrastructure System• Needs and Operational Concepts written for – Indirect stakeholders:

Pedestrians and drivers Direct stakeholders:

SPaT Vehicle System equipped with applicationsPedestrian Personal Information Devices (PIDs)Traffic Signal System including system controlling the traffic

signals at the intersectionTraffic Data System including traffic conditions databases, central

signal control systems (CSCS), and Advanced Traffic Management Systems (ATMS)

Security Back End including the Security Credentials Management System

Traffic Engineering StaffMaintenance Staff

36

SPaT Challenge Model ConOps• V2I applications based on SPaT that are

considered in the Model ConOps

37

Section 2 – Current Situation and Needs

• Current System Overview• Stakeholders

Indirect Users Users Other Stakeholders

• Stakeholders Use of the SPaT Infrastructure System• Stakeholders Needs

ChallengeNeed

IDNeed

Indirect User Stakeholder NeedsDriver NeedsVehicles running red lights andentering signalized intersectionsis a safety concern, with anaverage of 700 fatalities eachyear, 90,000 injuries related toan average of 100,000 red lightrunning related crashes.

1.1 Drivers need a red light violation warning(RLVW) to help them avoid unintended redlight violations.

38

Section 3 – Operational Concept for the SPaT Infrastructure System

• How each user will interact with the SPaTInfrastructure System

• Users include humans and systems• Written as numbered lines for traceability by

the Requirements3.3 SPaTVehicleSystems’Perspective3.3.1 SPaT Vehicle Systems will receive current signal phase and timing (SPaT Data) from the SPaT

Infrastructure System for the approaching intersection. (Need 3.1)

3.3.1.1 For intersections equipped with SPaT Infrastructure Systems, SPaT Vehicle Systems will receive the SPaT Data upstream of the intersection, beginning at a distance that enables the SPaT Vehicle System to perform needed calculations and information display to drivers. (Need 8.3)

39

Section 4 – Operational Concept for SPaT, MAP, and Traffic Data

• Presents details about the use of J2735 SPaT and MAP Message, as well as details about Traffic Controller Data

• Our attempt to get as much of the information describing this data exchange into one document

40

Section 5 – Operational Scenario

• Initial Conditions• Sequence of Events Chronological description of the interactions of

the SPaT Infrastructure System with the users5.2 SequenceofeventsMap Message:

1. The SPaT Vehicle System receives the MAP message and validates the security credentials.

2. The SPaT Vehicle System checks the message revision number and determines it has never receivedthis revision of the MAP message (alternate ‐ the SPaT Vehicle System determines it has alreadyreceived this revision of the MAP message and skips step 3.)

3. The SPaT Vehicle System decodes the MAP message and determines

a. Intersection location.

b. Ingress and egress lane geometry and location.

c. Connections from ingress lanes to egress lanes via specific maneuvers.

a. The signal group IDs related to the connections.

41

SPaT Challenge Model Requirements• Contain industry input • Include relevant specifications and

standards• Define the minimal requirements to

maintain compatibility between broadcast SPaT messages and vehicle on-board units planned by automobile industry

• Requirements organization on next slide

42

Group 11: Manage Security Back End

Interface

Group 9: Manage Traffic Data

System Interface

Group 3: Manage User Interface

Group 6: Manage SPaTVehicle System

Interface

Group 1: Manage Interface to SPaT

Sources

Interface with the Traffic Signal Controller

Broadcast 5.9 GHz DSRC Messages

Exchange data with the Traffic Data System

Configure data

exchanges

Include an interface for users to manage the SPaT infrastructure System and its data

Assemble the content needed for Standard SPaT Messages

Monitor Preemption & Priority Requests

Manage Conflicting Signal Request Messages (SRMs)

Request Preemption & Priority

Obtain Preemption & Priority Status

Assemble Standard Signal Status Messages (SSM)

Monitor Basic Safety Messages (BSM), Probe Vehicle Data (PVD) & Personal Safety Messages (PSM)

Convert BSM & PSM to Detector Calls

Aggregate BSM & PVD Data

Assemble Traffic Data Messages

Manage a Map database

Manage Map Dynamic Features

Assemble the content needed for MAP Message

Obtain Position Correction Data

Assemble SAE J2735 compliant position correction messages

Manage Reports

Manage Alerts

Provide Diagnostics

Reset the System

Configure System

Manage Logs

Obtain valid Security Credentials

Verify Received Message Credentials

Apply Security Credentials to broadcasts

Manage access to the system network

Traffic Signal Controller

Traffic Data System

Security Back End

Traffic Engineer

Personal Information Device

SPaT Vehicle System

Group 7: Manage Preemption / Priority

Group 8: Manage Vehicle & PID Data

Group 10: Manage Security

Group 2: Manage SPaTGroup 4: Manage Maps

Group 5: Manage Position Correction

Group 12: Provide Support

Maintenance Tech

Notes:Bold text and boxesrepresents minimumSPaT Functions to supportVehicle based applications

Interface with the Central Signal Control System

Central Signal Control System

Receive and process 5.9 GHz DSRC Messages

Publish Data over alternate

communications Mediums

Configure Messages

Manage MAP Data

Manage GPS Corrections

Manage Detection Zones

Assemble MAP messages that conform to the SAE J2735 standard message format

Assemble other standard MAP messages

Assemble SPaT messages that comply with other standardized message formats.

Assemble SPaT messages that conform to the SAE J2735 standard message format.

Include security to limit user access

Display information to users

Assemble other standard correction messages

Configure the security back end system

Obtain data for Position Correction messages

Receive Data over alternate


43


Interface


System Interface



Interface


Sources




Configure data

exchanges

















Manage Reports

Manage Alerts

Provide Diagnostics

Reset the System

Configure System

Manage Logs






Traffic Data System

Security Back End

Traffic Engineer


SPaT Vehicle System







Maintenance Tech







Configure Messages

Manage MAP Data














44


Interface


System Interface



Interface


Sources




Configure data

exchanges

















Manage Reports

Manage Alerts

Provide Diagnostics

Reset the System

Configure System

Manage Logs






Traffic Data System

Security Back End

Traffic Engineer


SPaT Vehicle System







Maintenance Tech







Configure Messages

Manage MAP Data














45


Interface


System Interface



Interface


Sources




Configure data

exchanges

















Manage Reports

Manage Alerts

Provide Diagnostics

Reset the System

Configure System

Manage Logs






Traffic Data System

Security Back End

Traffic Engineer


SPaT Vehicle System







Maintenance Tech







Configure Messages

Manage MAP Data














46


Interface


System Interface



Interface


Sources




Configure data

exchanges

















Manage Reports

Manage Alerts

Provide Diagnostics

Reset the System

Configure System

Manage Logs






Traffic Data System

Security Back End

Traffic Engineer


SPaT Vehicle System







Maintenance Tech







Configure Messages

Manage MAP Data














47

Model Requirements Document

• Example of a Requirement, and mapping to the Numbered Operational Concept

Group 2: Manage SPaTRequirements describing the functions of the SPaT Infrastructure to assemble the SPaT data into standard SPaT messages for broadcast.

2.1 The SPaT Infrastructure System shall assemble the content needed for standard SPaT messages.

2.1.1 The SPaT Infrastructure System shall process the message containing SPaT data obtained from the Traffic Signal System and generate a SPaT message.

Minimum;RLVW

3.3.1.3

48

SPaT Challenge Model RequirementsRequirements classified as:• Minimum: necessary to achieve minimum SPaT broadcast

functionality to support Red Light Violation Warning (RLVW) • Optional: alternate approach to achieve minimum SPaT

functionality e.g. a different message format or communication mechanism

• Optional – minimum for application: necessary if additional functionality is desired; not needed for minimum functionality e.g. priority/preemption and data collection from vehicles

• Optional – recommended: improves system manageability, but not needed for minimum functionality e.g. reporting, log, and user management tools

49

Verifying and Validating SPaT Deployments

SPaT Challenge Verification Document: https://transportationops.org/content/spat-challenge-

verification-document• Developed by the Crash Avoidance Metrics

Partnership (CAMP) • Intent is to ensure: Deployments are compatible and meet minimum

requirements for on-board applications released by automobile manufacturers Compatibility with future Red Light Violation

Warning (RLVW) applications• More on this topic during Webinar #5

Costs, Procurement, and Corridor SelectionBlaine Leonard, Utah DOT

51

Corridor Selection• Select a Corridor / Area Infrastructure Compatibility

Signal Controllers Backhaul and Central Control of IntersectionsNumber of signals

Concept of OperationsConsider local conditions and needsIdentify partners and partnersFuture V2I Applications (Long-term Strategy)

Get on the NOCOE SPaT Challenge Map

52

Corridor Selection / Procurement• Define Operations / Requirements System Requirements

Messages Being Sent – SPaT and MAPMessages Being Received – BSMOther Messages (Application Dependent)

• SRM, SSM, TIM, etc

Performance RequirementsSecurity (SCMS)

53

Procurement• Procurement Approaches Government Procurement

Testing / Small QuantityFull Procurement

Partner / University Consultant

FasterOwnership / Maintenance

54

Procurement• Define Hardware Requirements RSU 4.1 Specification Outside Certification (pending) Specific Requirements

MessagesPerformanceSecurity

Software Development Kit (SDK)Needed for software development / modification

OBUs (optional)Number of radios (one vs two)

55

Procurement• Other Hardware Cabling Mounting Processor (optional)

56

Costs

• Disclaimer . . . Every deployment is different – lots of variables

Learning Curve – Experience of TeamConsultant vs In-house Efforts (or Combination)TestingApplications Beyond SPaTProcurement VariationsInstallation Parameters

We would love your input on cost experience!

57

Costs

• Hardware RSU

$1500 to $3200 Mounting Brackets, Cables, Power Supply

$200 to $600 OBU

$900 to $1500

58

Costs

• Engineering Design / Testing

$1000 to $8500 Installation / Integration

$2000 to $11,000Location of DSRC InstallationLane Closures / Night Work

Create MAP Data (future webinar)$400 to $1500Use of ToolLocal Mapping

Webinar Wrap-Up and Q&A

60

Next SPaT Challenge Webinar• Design Considerations, Part 1 March 20, 2018 2:00pm ET Minimum content for SPaT broadcasts to be

verified/validated Signal controller interface and creation of SPaT

messages Examples of designs for assembling SPaT messages DSRC licensing

• Registration: https://transportationops.org/event/webinar-2-spat-challenge-design-considerations-part-1

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

Upcoming SPaT Challenge WebinarsDesign Considerations, Part 1 March 20, 2018 2:00-3:30pm ETDesign Considerations, Part 2 April 17, 2018 2:00-3:30pm ETMAP Creator Tool Demonstration April 24, 2018 1:00-2:30pm ETDesign Considerations, Part 3 May 15, 2018 2:00-3:30pm ETDeployment & Validation June 12, 2018 2:00-3:30pm ET