Environment System Requirements 1 This material is based upon work - - PowerPoint PPT Presentation
Connected Vehicle Environment System Requirements 1 This material is based upon work supported by the U.S. Department of Transportation under Agreement No. DTFH6116H00013. Any opinions, findings, and conclusions or recommendations expressed in
1
This material is based upon work supported by the U.S. Department of Transportation under Agreement No. DTFH6116H00013. 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.
2
3
RYAN BOLLO Project Manager, City of Columbus rjbollo@columbus.gov TOM TIMCHO Technical Lead, WSP tom.timcho@wsp.com CHRISTOPHER TOTH CV Systems Engineer, WSP christopher.toth@wsp.com
4
PURPOSE OF THIS WEBINAR
WEBINAR CONTENT
WEBINAR PROTOCOL
noise
website
TODAY’S AGENDA
01 | 02 | 03 |
78 APPLIED • COLUMBUS WON
5
VISION: T
responsive, innovative and safe mobility solutions. MISSION: T
equitable access to transportation can have positive impacts
OUTCOMES:
6
7
8
Vehicle Type Quantity
Light-Duty Vehicle Private Vehicle 1019 City Fleet Vehicle 200 COTA Supervisor Vehicle 25 Emergency Vehicle Fire Truck/EMS 30 Police Cruiser 80 Heavy-Duty Vehicle Platoon Truck 10 Transit Vehicle CEAV 6 COTA Transit Bus* (fixed-route) 350 COTA Paratransit Bus 80
Total 1,800
*Quantity may vary slightly depending on operational needs. Source: City of Columbus
9
Class Application
Light-Duty Vehicle Emergency Vehicle Heavy-Duty Vehicle Transit Vehicle Traffic Manager Transit Manager
V2V Safety Emergency Electronic Brake Light X Forward Collision Warning X Intersection Movement Assist X Lane Change Warning/ Blind Spot Warning X V2I Mobility TransitSignal Priority X X Freight Signal Priority/ Intent to Platoon Priority X Emergency Vehicle Preemption X Vehicle Data for Traffic Operations X TransitVehicle Interaction Event Recording X V2I Safety Red Light Violation Warning X Reduced Speed School Zone X
For more information, please see the Connected Vehicle Environment Concept of Operations
10
11
Development Process
group categories.
system sub-components.
constraints, and interfaces as described by the ConOps.
12
Functional Group Common DSRC Messages Roadside Equipment Traffic Management Center Transit Management Center V2I Mobility V2I Safety V2V Safety Vehicle Onboard Equipment
Platooning Provider Central Management System
Traffic Signal Controller / School Zone Signal
RSU Traffic CV Management System HDV OBU
HDV Databus
LDV OBU
LDV Databus
Network Time Source
Location and Time Source (GNSS) Loc and Time Data Source (GNSS)
Ohio CORS Transit Vehicle OBU
Transit Vehicle Databus
Emergency Vehicle OBU
Emergency Vehicle Databus Other OBU
Transit CV Management System Smart Columbus Operating System Security and Credentials Management System LDV Operator
Human Interface (existing)
(Internet)
(Internet)
(Internet)
Traffic CV
Transit CV
Emergency Vehicle Operator
System Boundary System Boundary
Step 1: Break down system into functional group categories.
13
Functional Group Common DSRC Messages Roadside Equipment Traffic Management Center Transit Management Center V2I Mobility V2I Safety V2V Safety Vehicle Onboard Equipment System Boundary System Boundary
Step 1: Break down system into functional group categories.
Platooning Provider Central Management System
Traffic Signal Controller / School Zone Signal
RSU Traffic CV Management System HDV OBU
HDV Databus
LDV OBU
LDV Databus
Network Time Source
Location and Time Source (GNSS) Loc and Time Data Source (GNSS)
Ohio CORS Transit Vehicle OBU
Transit Vehicle Databus
Emergency Vehicle OBU
Emergency Vehicle Databus Other OBU
Transit CV Management System Smart Columbus Operating System Security and Credentials Management System LDV Operator
Human Interface (existing)
(Internet)
(Internet)
(Internet)
Traffic CV
Transit CV
Emergency Vehicle Operator
14
Step 2: Develop technical requirements for system components
15
Step 3: Link requirements with user needs, constraints, and interfaces as described by the ConOps
16
17
TONY ENGLISH Lead System Design for Wyoming CV Pilot Trihydro
MIKE SCHULMAN Program Manager, Crash Avoidance Metrics Partnership JIAQI MA Assistant Professor, NEXT Mobility Lab Lead, University of Cincinnati NICK HEGEMIER Managing Director of Infrastructure, Ohio Department of Transportation
18
19 19
INTEROPERABILITY SYSTEM REQUIREMENTS
Communication on specific interfaces (internal and external) are constrained to specific standards so that the CVE can be easily expanded and will be able to interact with external systems that use the same widely-accepted standards
20 20
INTEROPERABILITY SYSTEM REQUIREMENTS
RequirementID Description CVE-CN1648-V01 All CVE components that utilize DSRC shall comply with all of the following:
1. SAE J2735_201603 - Dedicated Short Range Communications (DSRC) Message Set Dictionary. 2. SAE J 2945/1 - On-Board System Requirements for V2V Safety Communications 3. SAE J 2945/4 (draft) - DSRC Messages for Traveler Information and Basic Information Delivery 4. IEEE 802.11p - Wireless Access in Vehicular Environments. 5. IEEE 1609.2 - IEEE Standard for Wireless Access in Vehicular Environments -- Security Services for Applications and Management Messages 6. IEEE 1609.3 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Networking Services. 7. IEEE 1609.4 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Multi-Channel Operation. 8. NTCIP 1202 - NTCIP Object Definitions for Actuated Traffic Controllers. 9. NTCIP 1211 - NTCIP Objects for Signal Control and Prioritization (SCP)
CVE-FN1308-V01 An RSU shall acquire time from the Location and Time Source (LTS) interface in accordance with J2945/1 section 6.2.4. CVE-FN1309-V01 An RSU shall acquire location from the LTS interface in accordance with J2945/1 section 6.2.1. CVE-FN1311-V01 An RSU shall use Coordinated Universal Time (UTC) time for all logged data (e.g., events logs, probe vehicle data) based on the format defined in J2735 section 6.19 and epoch of January 1st 1970.
21 21
INTEROPERABILITY QUESTIONS/FEEDBACK
1. Aside from adhering to existing communications and messaging standards, what other requirements should be included to maximize the likelihood of interoperability with other CV systems? 2. Are there certain data elements in standards that should be included or interpreted differently? For instance, are there optional field of J2735 that are critical to implement? 3. Are there any messages that are being considered for future standards that should be considered for the CV Environment?
22 22
CV APPLICATION SYSTEM REQUIREMENTS
Requirements that describe and constrain the communications and functions that enable CV Applications V2V Safety V2I Safety V2I Mobility
23 23
CV APPLICATION SYSTEM REQUIREMENTS
RequirementID Description
CVE-FN1298-V01 An LDV OBU (host) shall issue an alert to the LDV Operator via the HMI when the OBU-equipped (host) vehicle will enter an RSU-equipped school zone over the active school zone speed limit CVE-FN1299-V01 An LDV OBU (host) shall issue an alert when the OBU-equipped (host) vehicle is inside of an RSU- equipped school zone over the active school zone speed limit CVE-FN1300-V01 The LDV OBU (host) shall parse received RSMs to identify the school zone speed limit (J2945/4). CVE-FN1301-V01 The LDV OBU (host) shall parse received RSMs to identify when the school zone speed limit is active. CVE-FN1302-V01 The LDV OBU (host) shall parse received RSMs to identify the applicable regions of use geographical path (J2945/4). CVE-FN1303-V01 The LDV OBU (host) shall issue a school zone alert when all of the following conditions are concurrently met:
1. OBU-equipped (host) vehicle is traveling towards the segment where the situational awareness applies. 2. The OBU-equipped (host) vehicle is expected to enter the school zone but not below the school zone speed limit (given its current location, motion, and expected braking rate). 3. During active school zone hours
CVE-FN1304-V01 The LDV OBU (host) shall issue a school zone alert when all of the following conditions are concurrently met:
1. OBU-equipped (host) vehicle is within the segment where the situational awareness applies. 2. OBU-equipped (host) vehicle is traveling above the school zone speed limit. 3. During active school zone hours
24 24
CV APPLICATION QUESTIONS/FEEDBACK
1. Columbus wants to make sure that it is deploying applications that are deployment-ready. What level of specificity is needed in the requirements to ensure this? 2. What is the best way to verify these applications meet their functional/performance requirements and have been demonstrated in an operational environment? 3. Is there a strong use case for which it may be beneficial to use data available though the OBD-II port vs. data gathered from sensors on the OBU for populating the BSM and for use in safety applications?
25 25
HMI REQUIREMENTS
Requirements that constrain the manner in which the driver is alerted (output of CV applications). Apply methods used by CV pilot sites for choosing the type of HMI to implement.
Source: https://www.kaspersky.com/blog/evolution-of-human-car-interaction/6953/
26 26
HMI SYSTEM REQUIREMENTS
RequirementID Description
CVE-IF1246-V01 An LDV OBU shall issue alerts to the LDV Operator via an HMI CVE-FN1123-V01 The HMI shall present alerts to drivers using a devise that drivers are familiar with and limits driver interaction. CVE-FN1286-V01 An LDV OBU (host) shall issue an alert to the LDV Operator via the HMI when a red-light violation will occur at an RSU-equipped intersection CVE-FN1202-V01 The LDV OBU shall provide messages that can be seen and/or heard by the LDV Operator via the HMI from the LDV Vehicle Operator's normal seating position CVE-FN1214-V01 The LDV OBU Auditory signals (via the HMI) shall be loud enough to overcome masking sounds from road noise, the cab environment, and other equipment CVE-FN1213-V01 The LDV OBU shall provide a visual output that is similar in look and feel from various applications when presenting information to LDV Operators via the HMI
27 27
HMI QUESTIONS/FEEDBACK
1. What should be considered when designing output that is presented to drivers? 2. Given that Columbus will be undertaking a recruitment effort to have these devices installed on private vehicles, are there any aspects of an HMI that will make a private citizen more or less inclined to participate? 3. What factors should go into deciding which HMI to procure? Given that Columbus is looking to procure (not design from scratch) an HMI, should requirements governing the types of alerts guide the selection of an HMI, or is it more reasonable to allow the selected HMI to constrain the design of the alerts?
28 28
OPERATIONAL SYSTEM REQUIREMENTS
Specifes system security processes, how updates should be managed, and outlines how the system is monitored Outlines the responsibilities of each actor in the CVE
29 29
OPERATIONAL SYSTEM REQUIREMENTS
RequirementID Description
CVE-MT1595-V01 DPS shall maintain a list of OBU equipment and contact information for vehicle owners that have OBUs installed CVE-MT1593-V01 DPS shall manage Support Staff to troubleshoot and diagnose RSU and OBU issues. CVE-FN1449-V01 The Traffic CV Management System shall monitor the status of RSUs CVE-PR1458-V01 The Traffic CV Management System shall notify designated personnel within five minutes of a monitored function becoming unavailable CVE-SR1459-V01 Monitoring systems shall be used to detect abnormal unauthorized activity on an IP connection. CVE-SR1460-V01 The Traffic CV Management System shall monitor the DSRC communications performance to detect DoS attacks CVE-SR1461-V01 The Traffic CV Management System should investigate and monitor the data traffic usage to detect unapproved use of the IP connection CVE-FN1463-V01 The Traffic CV Management System shall monitor tamper alert devices
30 30
OPERATIONS QUESTIONS/FEEDBACK
1. What is the best way to provide application/functional updates to OBUs after they have been installed in private vehicles? How should equipment failure be handled, considering we are not intending to have face-to-face engagements with drivers? 2. What changes in traffic management activities should the Department of Public Service expect to operate and maintain the CV Environment once it is installed?
31 31
NEXT STEPS – PROCUREMENT
System Requirements provide specifications and constraints on hardware, software, and services (such as installation) that will ultimately be procured A balance must be found between existing City policy for procurement, and the processes that will be developed for procuring CV equipment.
32 32
PROCUREMENT QUESTIONS/FEEDBACK
1. Is it recommended that the same vendor be used to supply both the software and hardware for a given device? 2. What are the advantages and disadvantages of using multiple OBU vendors? Multiple RSU vendors?
33
Installation Development Ongoing – March 2019 Interface Control Document December 2018 – April 2019 System Design February 2019 – August 2019 Test Plan May 2019 – September 2019 Equipment and Service Procurement January 2019 – July 2019 Deploy / T est on roadside and in vehicles August 2019 – August 2020 CV Environment Live July 2020
34
USDOT SMART CITY CHALLENGE PROGRAM INQUIRIES: Kate Hartman, Chief - Research, Evaluation and Program Management Intelligent Transportation Systems Joint Program Office Kate.Hartman@dot.gov SMART COLUMBUS INQUIRIES: Alyssa Chenault, Communications Project Manager anchenault@columbus.gov Upcoming Smart Columbus Webinars:
Requirement – 11/15
Requirements – 11/28
Connected Electric Autonomous Vehicles and Truck Platooning – 1/30
Webinar recording and materials will be available at itsa.org and smart.columbus.gov
35
Public comment period open for the CONNECTED VEHICLE ENVIRONMENT System Requirements:
B-SysReq-CVE-FINAL%20v1.1.pdf
36
37
Contact: SmartColumbus@columbus.gov Columbus.gov/smartcolumbus @SmartCbus LEARN MORE