Connected Vehicle Pilot Deployment Program Phase 1, System Requirements Specification (SyRS) - Tampa (THEA)

Transcription

1 Connected Vehicle Pilot Deployment Program Phase 1, System Requirements Specification (SyRS) - ampa (HEA) Final Report August 2016 FHWA-JPO

2 Produced by Connected Vehicle Pilot Deployment Program Phase 1 ampa Hillsborough Expressway Authority (HEA) U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office Notice his document is disseminated under the sponsorship of the Department of ransportation in the interest of information exchange. he United States Government assumes no liability for its contents or use thereof. he U.S. Government is not endorsing any manufacturers, products, or services cited herein and any trade name that may appear in the work has been included only because it is essential to the contents of the work. i

3 echnical Report Documentation Page 1. Report No. FHWA-JPO Government Accession No. 3. Recipient s Catalog No. 4. itle and Subtitle Connected Vehicle Pilot Deployment Program Phase 1, System Requirements Specification (SyRS) ampa (HEA) 5. Report Date August Performing Organization Code 7. Author(s) 8. Performing Organization Report No. Stephen Novosad, HNB; Steve Johnson, HNB; Victor Blue, HNB; David Miller, Siemens; Joe Waggoner, HEA; Bob Frey, HEA 9. Performing Organization Name And Address 10. Work Unit No. (RAS) ampa Hillsborough Expressway Authority 1104 East wiggs Street, Suite 300 ampa, Florida Sponsoring Agency Name and Address U.S. Department of ransportation S Joint Program Office 1200 New Jersey Avenue, SE Washington, DC Contract or Grant No. DFH6115R ype of Report and Period Covered Final Report 14. Sponsoring Agency Code 15. Supplementary Notes COR: Govind Vadakpat, CO: Sarah Khan, 16. Abstract his document describes the System Requirements Specification (SyRS) for the ampa Hillsborough Expressway Authority (HEA) Connected Vehicle (CV) Pilot Deployment. his SyRS describes the current system requirements derived from the user needs, Concept of Operations, Security Management Operating Concept, Safety Management Plan, and the Performance Measurement and Evaluation Support Plan. he requirements describe what the system does; not how it will be done. his document will be used as the basis for the high level design. he requirements have traceability back to the Concept of Operations and user needs and forward to the high level design. A separate traceability matrix documents this process. 17. Key Words ntelligent ransportation Systems, ntelligent Vehicles, Crash Warning Systems, Connected Vehicle Pilot Deployment, Collision Avoidance, V2V, V2, Vehicle Communication, SyRS 18. Distribution Statement No restrictions 19. Security Classif. (of this report) 20. Security Classif. (of this page) 21. No. of Pages 22. Price Unclassified Unclassified 41 Form DO F (8-72) Reproduction of completed page autho ii

4 Version History # Date Author (s) Summary of Changes Draft 3/21/16 HEA nitial draft release for USDO review and comment Final 5/2/2016 HEA Updated UC requirements after USDO comment and walkthrough and added UC definitions from walkthrough. Final 5/23/2016 HEA Updated the system requirements to reflect the changes from the walkthrough. Final 6/3/2016 HEA Reorganized some of the system requirements (security, safety) to reference the appropriate documents rather than repeat requirements from the documents to ensure consistent documentation Final 8/22/16 HEA Address USDO comments; added verification method column to requirements tables. Final 8/31/16 HEA Addressed remaining USDO comments iii

5 able of Contents 1 ntroduction System Purpose System Scope Definitions and Acronyms Referenced Documents System Overview General System Description System Context User Characteristics Drivers Bus Operators Street car Operators Pedestrians MC Operators System Modes and States Major System Capabilities Use Case 1 - Morning Peak Hour Queues Requirements Use Case 2 - Wrong Way Entries Requirements Use Case 3 - Pedestrian Safety Requirements Use Case 4 Bus Rapid ransit Signal Priority Optimization, rip imes and Safety Requirements Use Case 5 - ECO Line Street car Street Car Conflicts Requirements Use Case 6 - Enhanced Signal Coordination and raffic Progression Requirements Major System Conditions Safety Requirements Performance Measures System Requirements Major System Constraints Assumptions and Dependencies Operational Scenarios System Capabilities, Conditions, and Constraints Physical Construction iv

6 3.1.2 Durability Adaptability Environmental Conditions System Performance Characteristics System Security Requirements nformation Management Requirements System Operations System Human Factors System Maintainability Requirements System Reliability Requirements Policy and Regulation Requirements System Lifecycle Sustainment List of ables able 1.1: Acronym List... 1 able 1.2: Glossary of erms... 4 able 1.3: References... 6 able 2.1 Requirement Nomenclature able 2.2 Use Case 1 Morning Peak Hour Queues System Requirements able 2.3 Use Case 2 Wrong Way Entries System Requirements able 2.4 Use Case 3 Pedestrian Safety System Requirements able 2.5 Use Case 4 Bus Rapid ransit Signal Priority Optimization, rip imes and Safety System Requirements able 2.6 Use Case 5 ECO Line Street car Conflicts System Requirements able 2.7 Use Case 6 Enhanced Signal Coordination and raffic Progression System Requirements able 2.8 Safety Requirements able 2.9 Performance Measures System Requirements able 2.10 System Wide and Use Case/Application Constraints able 2.11 Pilot Assumptions able 2.12 Pilot Risks able 3.1 Security Requirements able 3.2 Personal Data nformation Management Requirements able 3.3 System Generated Data Requirements able 3.4 Maintainability Requirements able 3.5 Reliability Requirements able 3.6 Policy and Regulation Requirements v

7 Chapter 1 ntroduction 1 ntroduction 1.1 System Purpose he HEA CV Pilot aims to meet the purposes set forth in the USDO s Broad Agency Announcement (BAA) to advance and enable safe, interoperable, networked wireless communications among vehicles, the infrastructure, and travelers personal communications devices and to make surface transportation safer, smarter, and greener. he HEA CV Pilot aims to demonstrate the kinds of improvements that can be made in an urban environment, with ampa s Central Business District (CBD) as the example site. HEA is deploying site-tailored collections of applications that address specific local needs while laying a foundation for additional local/regional deployment, and providing transferable lessons learned for other prospective deployers across the nation. 1.2 System Scope he HEA CV Pilot Deployment (Herein referred to as the Pilot ) in downtown ampa aims to create a connected urban environment to measure the effect and impact of CVs in ampa s vibrant downtown. o the vision of a connected downtown, the proposed Pilot offers several CV applications that can be deployed in ampa s CBD and environs. his environment has a rich variety of traffic, mobility and safety situations that are amenable to V2V, V2, and V2X solutions. he deployment area is within a busy downtown and offers a tolled expressway with street-level interface, bus and street car service, high pedestrian densities, special event trip generators and high dynamic traffic demand over the course of a typical day. hese diverse environments in one concentrated deployment area collectively encompass many traffic situations that allow for deployment and performance testing of CV applications. he scope of the Pilot will comprise HEA/City of ampa (Co) Combined raffic Management Center (MC) Operations, Hillsborough Area Regional ransit (HAR) Bus Operations, Co signal Operations and Maintenance (O&M), CV-Pilot System Development, CV-Pilot Design, Deployment and O&M, Key Agency Partners, Stakeholders and System Users, and Sustainability Models/Partners. 1.3 Definitions and Acronyms he following table defines selected project specific terms used throughout this System Requirements document. able 1.1: Acronym List Acronym/Abbreviation AE BAA BR BSM CA Definition All Electronic oll Broad Agency Announcement Bus Rapid ransit Basic Safety Message Certificate Authority U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 1

8 Chapter 1 ntroduction Acronym/Abbreviation CAMP CBD CC CCV ConOps Co CRL CSW CV CVRA DENM DMS DSRC EE EEBL FCW HAR HSM HUA -SG DS EEE MA PS P RB S JPO LMM MAFB MHM MOU MUCD Definition Collision Avoidance Metric Partnership Central Business District Common Criteria Closed Circuit elevision Concept of Operations City of ampa Certificate Revocation List Curve Speed Warning Connected Vehicle Connected Vehicle Reference mplementation Architecture Decentralized Environmental Notification Message Dynamic Message Sign Dedicated Short Range Communications End Entity Emergency Electronic Brake Light Forward Collision Warning Hillsborough Area Regional ransit Hardware Security Module Human Use Approval ntelligent raffic Signal System ntrusion Detection Systems nstitute of Electrical and Electronics Engineers ntersection Movement Assist ntrusion Protection Systems nternet Protocol nstitutional Review Board ntelligent ransportation System Joint Program Office Low, Moderate, Moderate MacDill Air Force Base Moderate, High, Moderate Memorandum of Understanding Manual of Uniform raffic Control Devices U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 2

9 Chapter 1 ntroduction Acronym/Abbreviation O&M OBU OEM ORDS OS OSADP PD POC PSM RDE REL RLVW RSU RM SCMS SE SE- SM SOP SPa SRM SSM HEA M P MC OD SP USDO V2 V2V V2X VN VM Definition Operations and Maintenance Onboard Unit Original Equipment Manufacturers Object Registration and Discovery Service Operating System Open Source Application Development Portal Personal nformation Device Proof of Concept Personal Safety Message Research Data Exchange Reversible Express Lane Red Light Violation Warning Roadside Unit Requirements raceability Matrix Security Credential Management System System Engineering System Engineering ool for ntelligent ransportation System Monitoring Standard Operating Procedure Signal Phase and iming Signal Request Message Signal Status Message ampa Hillsborough Expressway Authority raveler nformation Message ransportation ncentive Program raffic Management Center ime of Day ransit Signal Priority United States Department of ransportation Vehicle to nfrastructure Vehicle to Vehicle Vehicle to Device Vehicle dentification Number Verification Method U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 3

10 Chapter 1 ntroduction Acronym/Abbreviation VRFV WAF WAVE WSA Definition Vehicle urning Right in Front of ransit Vehicle Web Application Firewalls Wireless Access in Vehicular Environment WAVE Service Advertisement able 1.2: Glossary of erms erm Automobile App Authentication Buffer ime Center/Agency (MC) Center/Agency (MAFB): Center/Agencies (HAR Operations Center): Center Connected V2 Management Classification Curve Speed Warning (CSW) Emergency Electronic Brake Light (EEBL) Forward Collision Warning (FCW) Definition A light vehicle (e.g., car or pickup truck), motorcycle, moped, or other powered wheel vehicle that is legal to operate on streets. Software application Agency vehicles append a Vehicle dentification Number (VN) to BSM, creating a Signal Request Message (SRM) that is compared to a data base of authorized vehicles. Authenticated SRMs are used for emergency vehicle preemption and bus priority. SRM can also be used in applications where participants agree to reveal their identities for research purposes, such as comparing the end to end travel time of an authorized vehicle broadcasting SRM to the incremental travel times of private vehicles broadcasting BSM. his is the time from when the pedestrian countdown ends and the opposing signals turns green Stakeholders of the systems located in the MC, i.e. owners/operators Stakeholders of the systems located at MacDill Air Force Base, i.e. owners/operators Stakeholders of the systems located at HAR, i.e. owners/operators Roadside Unit (RSU) Management software system located within the MC that manage a wide area Network of RSUs, and not part of the MC Regional raffic Management Researchers need to determine the effect of the applied technology without violating participant privacy. Participant BSM and PSM use the vehicle size classification field to classify the BSMs into groups: Control Group: Equipped, but not enabled reated Group: Equipped and enabled Proxy Group: Unequipped Each group is sufficiently large to correlate data without identifying participants. An application where alerts are provided to the driver approaching a curve at a speed that may be too high for safe travel. An application where the driver is alerted to hard braking in upstream traffic. his provides downstream drivers with additional time to look for, and assess situations developing ahead. An application where alerts are presented to the driver to help avoid or mitigate the severity of crashes into the rear end of other vehicles on the road. Forward crash U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 4

11 Chapter 1 ntroduction erm ntersection Movement Assist (MA) ntelligent raffic Signal System (-SG) Mobile Accessible Pedestrian Signal (PED-SG) Probe-enabled Data Monitoring (PeDM) Pedestrian in a Signalized Crosswalk (PED-X) Proxy App PSM Roadway Signal Control ampa ntersection Devices ERL HEA RSU MC MC ntersection Safety MC Regional raffic Management ransit Signal Priority (SP) Vehicle urning Right in Front of ransit Vehicle (VRFV) Definition warning responds to a direct and imminent threat ahead of the host vehicle. An application that warns the driver when it is not safe to enter an intersection for example, when something is blocking the driver s view of opposing or crossing traffic. An overarching system optimization application accommodating signal priority, preemption and pedestrian movements. An application that allows for an automated call from the smart phone to the traffic signal, as well as cues to safely navigate the crosswalk. An application that utilizes communication technology to transmit real time traffic data between vehicles and roadside equipment. An application that warns drivers when pedestrians, within the crosswalk are in the intended path of the vehicle. Proxy App is used to create BSM for unequipped vehicles and PSM for unequipped pedestrians. raditional vehicle and pedestrian detectors issue an occupancy call to the Proxy Application running in an RSU when a vehicle or pedestrian is detected. he Proxy App broadcasts a Dedicated Short Range Communications (DSRC) BSM as if the unequipped vehicle were broadcasting the BSM or as if the unequipped pedestrian were broadcasting the PSM. he speed data is determined by the detector (Doppler) or by detecting calls from two detector zones separated by a known distance (trap). he location data is determined by the detector zone placement. he heading data is determined by the lane direction. he vehicle size data is set to identify a proxy BSM for research purposes. Personal Safety Message with the same information as BSM but operating on WiFi for use by Personal nformation Device (PDs), such as smart phones. RSUs within range of both PDs and OnBoard Units (OBUs) are used to translate the wireless media between DSRC and WiFi. he traffic signal control software application installed in traffic signal controllers he physical roadside equipment excluding the HEA RSUs raffic Engineering Research Laboratory, a joint Florida DO and Florida State University partnership for traffic equipment standards and testing development research DSRC roadside radios conforming to USDO requirements he physical MC room and communications infrastructure; excluding the existing MC software system. ntersection Safety software system located within the MC that manages and collects intersection safety data, not the safety application running at the roadside and not part of the MC Regional raffic Management raffic Management software system located within the MC that manages the wide area network of signal controllers, not part of the Center Connected V2 Management An application that provide signal priority (green) to transit at intersections and along arterial corridors. An application that warns transit vehicle operators of the presence of vehicles attempting to go around the transit vehicle to make a right turn as the transit vehicle departs from a stop. U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 5

12 Chapter 1 ntroduction 1.4 Referenced Documents he following table lists the references used to develop the concepts in this document. able 1.3: References # Document (itle, source, version, date, location) FHWA, USDO Guidance Summary for Connected Vehicle Pilot Site Deployers Concept of Operations and the CVRA/SE- ool, Draft report: FHWA-JPO , September FHWA, USDO, Broad Agency Announcement No. DFH6115R00003, January 30, FHWA, USDO, Systems Engineering for ntelligent ransportation Systems, An ntroduction for ransportation Professionals, January HEA, Final Needs Summary, November 23, Connected Vehicle Pilot Deployment Program Phase 1, Concept of Operations (ConOps) ampa (HEA) Connected Vehicle Pilot Deployment Program Phase 1, Performance Measurement and Evaluation Support Plan ampa (HEA) Connected Vehicle Pilot Deployment Program Phase 1, Safety Management Plan ampa (HEA) Connected Vehicle Pilot Deployment Program Phase 1, Security Management Operational Concept ampa (HEA) 9 HEA CV Pilot Project Stakeholder SyRS Review Panel Roster, March 23, HEA, he Connected Vehicle Pilot Deployment Program, Phase 1, March 26, (HEA CV Pilot Proposal.) 11 CVRA website, http: iteris.com/cvria/, accessed November 30, SE- Download Page, accessed November 30, EEE Guide for Developing System Requirements Specifications, EEE Std 1233, 1998 Edition (R2002) USDO Guidance Summary for Connected Vehicle Site Deployers System Requirements and the CVRA/SE- ool Draft Report, September EEE Standard for Wireless Access in Vehicular Environments Security Services for Applications and Management Messages, March 1, SAE J2945/1 V5- On-Board System Requirements for V2V Safety Communications U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 6

13 Chapter 1 ntroduction 1.5 System Overview he System Overview can be found in the Connected Vehicle Pilot Deployment Program Phase 1, Concept of Operations (ConOps) ampa (HEA) Chapter 7.. U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 7

14 Chapter 2 General System Description 2 General System Description 2.1 System Context he Pilot area is contained within the ampa CBD. n order to bound each Use Case, they are defined to a specific location(s). Each Use Case is composed of at least two applications which when implemented will work together to address the issues/needs of the Use Case. n some instances, these Use Case locations overlap or intersect; making it possible for Use Case/applications to interact with one another. 2.2 User Characteristics User Characteristics identify the user types who interact with the system. For each user type, their role, where they participate, and devices they use or interact with are discussed. Within the Pilot, the following user types are defined: Drivers Bus operators Street car operators Pedestrians MC Operators Drivers Drivers are defined as any person who operates a vehicle with an OBU installed. hese vehicles are defined as passenger vehicles including pickup trucks, SUVs, etc. (also known as light vehicles). Drivers will operate their vehicles as they normally do. For those OBU equipped vehicles; drivers will receive warnings/alerts. he estimated number of OBU equipped vehicles is 1,500. hese warnings/alerts may be audible or visible. Drivers participating in the Pilot are primarily commuters who travel thru downtown to work Bus Operators Bus operators are defined as people who operate the HAR buses in which OBUs are installed. hese buses operate on fixed routes. Bus drivers will receive audible or visual messages from OBUs indicating when they have priority or have been denied priority to the travel through the upcoming intersection. Bus driver will receive messages indicating their priority has been revoked due to higher priority vehicles such as first responders. hese buses traverse routes that may start and/or end outside the deployment area, but during some portion of the route, the bus travels through the deployment area including Marion Street and East Kennedy Boulevard and Jackson Street. he estimated number of buses equipped is Street car Operators Street car operators are defined as people who operate ECO street cars in which OBUs are installed. he street cars operate on a fixed route using rail. Street car operators shall receive audible or visual messages from OBUs indicating a vehicle is turning in front of the street car as it approaches an intersection. Street car operators shall receive audible or visual message from OBUs indicating a pedestrian may conflict with the street car. he street car s route is primarily within the deployment area. he estimated number of equipped street cars is 9. U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 8

15 Chapter 2 General System Description Pedestrians Pedestrians are defined as people who are on foot and who have an enabled PD. Florida law classifies a bicyclist riding on a sidewalk as a pedestrian. Pedestrians shall receive audible messages from PDs indicating they may be in conflict with a vehicle or street car. Pedestrians will be located on wiggs near the courthouse, Meridian Avenue, and Channelside (along the street car route). he estimated number of equipped pedestrians is MC Operators MC Operators staff the HEA MC where they manage and operate the reversing of the REL and the signal system in downtown. he MC is located within HEA s administration building and staffed by the Co. he operators work within the MC at workstations and have a video wall showing the expressway and the signal systems. Operators will receive alerts from the Master Server and based on the operating procedures will take the appropriate action such as modifying signal timing plans, contacting police/fhp, and other activities. 2.3 System Modes and States As the system is composed of multiple devices; potentially hosting several applications, the system mode is viewed on a more micro level. With devices deployed across the deployment area and outside the deployment area (i.e., vehicles), viewing the Pilot as a single system is not considered. he mode will be composed of the status of a device, its ability to communicate, and the operational status of the installed applications. here are three modes: Normal mode. Degradation mode Error mode Normal mode is defined by a device and its applications operating as required. Degradation mode is defined as something unexpected occurring and part of the device may not be functioning as required. Error Mode is defined as a complete failure of the device including communication failure. Each device (Roadside Unit [RSU], Onboard Unit [OBU], and Personal nformation Device [PD]) is considered to be in normal mode when the device is operating as designed and the applications are functioning as designed. A device enters Degradation mode when there is failure of one or more of the applications or a portion of the hardware fails. When an application fails, data is not being received, processed and transmitted for those application(s). he other applications continue to function as designed receiving, processing and transmitting data. When a portion of the device hardware fails, the application may or may not be able to perform its functions. Error mode is entered when a device completely fails or loses the ability to communicate. OBUs mode cannot be determined in real time. Mode changes by these devices will be discovered when the vehicle s data is downloaded. f there is a complete failure of the device, then it will be readily apparent the device is nonoperational. f the device is operating, but one of the applications has failed, this will be determined after the data has been downloaded and analyzed. OBU failures may be determined more efficiently as drivers may notice the OBU is not functioning properly and bring the vehicle in for OBU maintenance. U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 9

16 Chapter 2 General System Description When determining the system state, the focus will be on the RSUs. hese devices can provide a heartbeat to the MC which can be monitored. he OBUs and PD are not considered as there is no reliable means to know if these devices are always operating as required. he RSU device states are: Operational Partial Failure Failed When the device is operational, an RSU is known to be up and operating and communications with the MC. Partial failure of an RSU indicates that the RSU is not operating as required. An RSU is considered nonoperational when the communications with the RSU is down (interrupted) or the RSU itself has some failure preventing it from operating normally. he RSU is considered to be in a failed state when an RSU is inoperative. 2.4 Major System Capabilities he system requirements for the six Use Cases are defined in this chapter. Each Use Case and the user needs associated with the Use Case were reviewed as well as discussions with the stakeholders to derive the system requirements. For each of the selected Connected Vehicle Reference mplementation Architecture (CVRA) applications, the system requirements defined and approved within the CVRA SE- tool are included by reference. he nomenclature for the requirement identifiers is defined as follows: HEA-xxx-zzz able 2.1 Requirement Nomenclature dentifier Position HEA xxx Zzz Definition dentifies the CV Pilot he first three characters identify the requirement type the requirement is associated with. (e.g., UC1 Use Case 1; SEC Security; etc.) Sequential number starting at 001 and is incremented by one for the next requirement. he numbering resets to 001 for each new requirement type. Note the column labeled VM standards for the Verification Method to be used in testing. he following methods will be used: A Analysis D - Demonstration nspection - est Use Case 1 - Morning Peak Hour Queues Requirements he requirements for this Use Case are identified in the table below able 2.2 Use Case 1 Morning Peak Hour Queues System Requirements U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 10

17 Chapter 2 General System Description HEA-UC SG application at wiggs and Meridian shall transmit southbound queue data to the REL CSW application per lane. Provide commute reliability HEA-UC1-002 he drivers shall receive CSW from CSW application on the vehicles HEA-UC SG application at wiggs and Nebraska shall transmit westbound queue length data to the CSW application on the REL per lane. HEA-UC1-004 he Electronic Emergency Brake Light warning (EEBL) application on the braking vehicle shall broadcast an EEBL warning when the vehicle deceleration exceeds predetermined value. HEA-UC1-005 he EEBL application on the receiving vehicle shall receive an EEBL warning from the braking vehicle. HEA-UC1-006 he EEBL application on the receiving vehicle shall process an EEBL warning from forward vehicles. HEA-UC1-007 he EEBL application shall warn the driver of vehicles exceeding the preset deceleration downstream to wiggs Street. HEA-UC1-008 Vehicles equipped with OBUs shall receive BSMs from other vehicles equipped with OBUs within DSRC range. HEA-UC1-009 he FCW in-vehicle application shall identify crash trajectories with other vehicles. HEA-UC1-010 he FCW application shall warn the driver of crash trajectories. Assumes the lead vehicle is also equipped with an OBU. HEA-UC1-011 he FCW application shall warn the driver no more than once when multiple warnings are received within a configurable timeframe. Handling of multiple warnings from aftermarket OBUs should match that of OEM OBUs, Request advice from CAMP to state detailed requirements based on safety pilot HEA-UC1-012 he -SG application at wiggs and Meridian shall receive BSMs from vehicles equipped with OBUs. HEA-UC SG application at wiggs and Meridian shall process BSMs to determine the queue length on the southbound approach from the REL. HEA-UC SG application at wiggs and Nebraska shall process BSMs to determine the queue length. HEA-UC SG application at wiggs and Meridian shall transmit the queue lengths to the HEA master server. HEA-UC SG application at wiggs and Nebraska shall transmit the queue lengths to the HEA master server. HEA-UC1-017 he Master Server shall receive and analyze the queue lengths from -SG application to the master server at wiggs and Nebraska. HEA-UC1-018 he Master Server shall receive the queue lengths from - SG application to the master server at wiggs and Meridian. U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 11

18 Chapter 2 General System Description HEA-UC1-019 he combination of signal controller and the -SG application shall modify the signal phase timing when the queue length exceeds a configurable threshold at wiggs and Meridian. HEA-UC1-020 he combination of signal controller and the -SG application shall modify the signal phase timing when the queue length exceeds a configurable threshold at wiggs at Nebraska. HEA-UC SG application shall prioritize queues that limit safe stopping distance as Priority as defined in the -SG requirements. HEA-UC1-022 he RSU CSW application shall broadcast a recommended standard speed. HEA-UC1-023 he vehicle CSW application shall receive the recommended standard speed. HEA-UC1-024 he vehicle CSW application shall adjust the recommended speed based on the southbound queue length from -SG application on wiggs and Meridian. he delay time is equivalent to the queue that forms in the right turn lane and onto the shoulder. HEA-UC1-025 he vehicle CSW application shall convert the recommended standard speed to an appropriate speed based on the vehicle type. e.g., passenger cars, commercial vehicles, transit could have different recommended safe speeds in a curve. HEA-UC1-026 he RSU CSW application shall calculate and transmit the recommended curve speed to the HEA Master Server. HEA-UC1-027 MC operators shall be able to access standard curve speed. HEA-UC1-028 A traditional vehicle detector shall issue a call to the proxy app when a vehicle occupies the detection zone. Proxy app is defined as the RSU application that converts traditional vehicle detector data into BSMs. HEA-UC1-029 he proxy app shall transmit a BSM when the traditional detector issues a call. HEA-UC1-030 Vehicles equipped with OBUs shall broadcast BSMs. HEA-UC1-031 he Master Server shall analyze the queue lengths from - SG application to the master server at wiggs and Meridian Use Case 2 - Wrong Way Entries Requirements he requirements for this Use Case are identified in the table below. able 2.3 Use Case 2 Wrong Way Entries System Requirements HEA-UC2-001 HEA-UC2-002 Vehicle traveling in the legal direction shall receive the BSM of vehicles traveling opposite the legal direction. Vehicles traveling in the legal direction shall identify crash trajectory of vehicles traveling opposite the legal direction. 10 times per second Calculates crash threat based on the location, heading, speed and elevation of both vehicles U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 12

19 Chapter 2 General System Description HEA-UC2-003 Vehicles traveling in the legal direction shall identify crash trajectory of cross street vehicles Calculates crash threat based on the location, heading, speed and elevation of both vehicles HEA-UC2-004 RSU at REL entrance shall host the existing 2-phase traffic signal control application. No signal display (i.e., physical traffic signals) to drivers, implements phase timers of an existing signal control application HEA-UC2-005 Signal control application Phase 1 at REL entrance shall be RED inbound and GREEN outbound during outbound times of day, HEA-UC2-006 Signal control application Phase 2 at REL entrance shall be GREEN inbound and RED outbound during inbound times of day. HEA-UC2-007 Signal control application at REL entrance shall transmit the latest published standard SPa message per J2735 current version. Compatible with the message payload and security of OEM Class 1 OBU HEA-UC2-008 Signal control application at REL entrance shall transmit the REL entrance lane geometry MAP message per J2735 current version. Compatible with the message payload and security of OEM Class 1 OBU HEA-UC2-009 Participating vehicles shall host the Red Light Violation application. Existing Red Light Violation Warning application installed on OBUs, no new development HEA-UC2-010 Red Light Violation Warning (RLVW) application shall receive the signal control application SPa message. HEA-UC2-011 RLVW application shall receive the MAP message. HEA-UC2-012 HEA-UC2-013 HEA-UC2-014 HEA-UC2-015 Red Light Violation application at the REL entrance shall warn drivers predicted to violate the RED phase. A roadside vehicle detector shall issue a call to the proxy app when a vehicle approaches the REL entrance. A roadside vehicle detector shall issue a call to the proxy app when a vehicle enters the REL entrance. Proxy app shall create a proxy RLVW when the advance detector call is asserted and followed by the local detection call is asserted during red phase. OBUs compare their location, heading, speed and elevation to the RSU SPA and MAP to predict RED violation indicating that the vehicle is on a wrongway trajectory Unequipped vehicles approaching the REL entrance are detected Unequipped vehicles entering the REL entrance are detected Advance detector call followed by local detection call during red phase predicts RLVW of unequipped vehicle. he distance between calls divided by the time between calls equals the violation speed HEA-UC2-016 RLVW application of violator shall issue a wrong-way alert to the wrong-way driver when the RLVW application leaves the REL MAP geometry during RED phase. OBU Red Light Violation app issues a wrong-way alert when the OBU passes through the MAP area while the signal phase is in red. Applies to both equipped and unequipped vehicles U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 13

20 Chapter 2 General System Description HEA-UC2-017 RLVW application of violator shall issue wrong-way alert to the RSU when the RLVW application checks out of the REL MAP geometry during RED phase. HEA-UC2-018 Wrong-way alert from the RSU shall be received at the master server. Wrong-way alerts received from violators at the HEA master server. HEA-UC2-019 Wrong-way alert from the RSU shall be stored at the master server. Wrong-way alerts received from violators at the HEA master server. HEA-UC2-020 Wrong-way alert from master server shall be received by law enforcement dispatch. Wrong-way alert received from violators is available to law enforcement dispatch and law enforcement officials. Need advice as to interface from master server to law enforcement Use Case 3 - Pedestrian Safety Requirements he requirements for this Use Case are identified in the table below. able 2.4 Use Case 3 Pedestrian Safety System Requirements HEA-UC3-001 he OBU shall receive Personal Safety Messages (PSM). HEA-UC3-002 he OBU shall determine if there is a potential conflict with a pedestrian. HEA-UC3-003 he OBU shall warn the driver upon determination of a potential conflict with a pedestrian. HEA-UC3-004 he OBU shall receive data from the RSU of a pedestrian entering the crosswalk. PSM from pedestrian is converted to BSM to vehicle by the crosswalk RSU. HEA-UC3-005 he PD shall warn the pedestrian in the crosswalk when a vehicle is approaching the crosswalk. HEA-UC3-006 he PD shall warn the pedestrian approaching the crosswalk when a vehicle is entering the crosswalk. HEA-UC3-007 he PD shall warn the pedestrian in a non-crosswalk area on the street when there is an impending vehicle conflict. HEA-UC3-008 he PD shall transmit PSM to the RSU. HEA-UC3-009 he RSU shall receive PD PSM. HEA-UC3-010 he RSU shall convert the PSM into a BSM.. HEA-UC3-011 he RSU shall send a converted BSM from a PSM over DSRC. HEA-UC3-012 he RSU shall receive vehicle BSMs. HEA-UC3-013 he RSU shall send a not in crosswalk message to PDs who are outside the crosswalk. HEA-UC3-014 he RSU shall convert vehicle BSMs into PSMs U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 14

21 Chapter 2 General System Description HEA-UC3-015 he RSU shall send a converted PSM from a vehicle BSMs over Wi-Fi HEA-UC3-016 he PD shall receive PSMs. HEA-UC3-017 he PD application, Mobile Accessible Pedestrian Signal (PED- SG), shall inform the pedestrian, they are not in the crosswalk Use Case 4 Bus Rapid ransit Signal Priority Optimization, rip imes and Safety Requirements he requirements for this Use Case are identified in the table below. able 2.5 Use Case 4 Bus Rapid ransit Signal Priority Optimization, rip imes and Safety System Requirements HEA-UC4-001 ransit vehicle shall send Signal Request Message (SRM) to RSU when vehicle matches the location of the intersection approach. A signal green is requested at approach to the intersection by the transit vehicle, or the current green is requested to be extended. HEA-UC4-002 SRM from transit vehicles shall be forwarded by the RSU to the transit central A green request is received by RSU and sent on to transit central. HEA-UC4-003 ransit central shall compare bus VN, location and time to bus schedule. ransit central authenticates the VN and other information. HEA-UC4-004 f bus is behind schedule, the transit central shall return the SRM to the originating RSU. ransit central grants priority, if the bus is behind schedule HEA-UC4-005 he SP shall request signal priority of the controller when SRM is received from transit central, and is of the highest priority. n case of a higher priority, such as rail gates or emergency vehicle, the RSU does not grant priority. HEA-UC4-006 SP shall receive priority status from the Controller Unit (CU). his ensures the intersection is going to Priority for that phase. HEA-UC4-007 SP shall send Signal Status Message (SSM) to bus. Priority status is sent to bus HEA-UC4-008 Bus shall receive SSM from SP. SSM has priority information for that bus. HEA-UC4-009 SSM shall be displayed as a bus driver notification. Driver may be accustomed to priority and assume priority, as lesson learned from other priority systems n case the bus priority is superseded by a higher priority, such as intersecting emergency vehicle HEA-UC4-010 Signal controllers shall prevent vehicles from blocking bus stop entrance when the bus is behind schedule. his allows a bus to enter/exit a stop by clearing the path to the stop of other vehicles by holding the green longer. HEA-UC4-011 SP shall issue an alert to participant pedestrians that a bus is approaching intersection where a bus is about to be given priority. U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 15

22 Chapter 2 General System Description HEA-UC4-012 Pedestrian Safety app on RSU shall issue an alert to pedestrians that bus is about to proceed. Not part of SP but ped safety at the SP locations HEA-UC4-013 ransit signal priority shall be implemented to control signals at streets crossing the bus route. SP provides green times to maintain schedule Use Case 5 - ECO Line Street car Street Car Conflicts Requirements he requirements for this Use Case are identified in the table below. able 2.6 Use Case 5 ECO Line Street car Conflicts System Requirements HEA-UC5-001 Street car OBUs shall determine the position of received vehicle BSMs within DSRC range. HEA-UC5-002 Street car OBUs shall determine the position of received participant PSMs within WiFi range. HEA-UC5-003 Street car OBUs shall broadcast BSMs. HEA-UC5-004 HEA-UC5-005 HEA-UC5-006 HEA-UC5-007 HEA-UC5-008 HEA-UC5-009 HEA-UC5-010 HEA-UC5-011 HEA-UC5-012 HEA-UC5-013 HEA-UC5-014 HEA-UC5-015 HEA-UC5-016 RSUs adjacent to street car line shall receive PSMs of in WiFi range pedestrians. RSUs adjacent to street car line shall inform in range PDs that the street car will be crossing the intersection. PD receiving information of street car crossing the intersection shall warn the pedestrian carrying the PD. Street car OBUs shall analyze its current position in relation to right turning vehicles to determine if right turning vehicle is in conflict to the street car's position. Street car OBUs shall produce a warning of a vehicle turning in front of the street car to street car operator. RSUs adjacent to the street car line shall send right turning vehicle warning to the Master Server. Street car OBUs shall analyze its current position in relation to pedestrians in intersection crossings. Street car OBUs shall produce a warning to the street car operator that equipped pedestrians are in conflict to the street car within a configurable threshold defaulted to 100 feet. RSUs adjacent to the street car line shall send pedestrian conflicts warnings to the Master Server. Street car OBUs shall store the warning message that a pedestrian is crossing the intersection. Vehicle OBUs shall receive PSMs from the RSUs adjacent to the street car line. Vehicle OBUs shall store the pedestrian crossing warning messages. Vehicle OBUs shall download pedestrians crossing warning messages to the master server U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 16

23 Chapter 2 General System Description HEA-UC5-017 HEA-UC5-018 HEA-UC5-019 HEA-UC5-020 RSUs adjacent to the street car line shall receive information about location and movement of the street car. PDs shall receive a street car collision warning from the RSUs adjacent to the street car line. PDs shall provide street car collision warning messages to the pedestrian. PDs shall provide vehicle collision warning messages to the pedestrian Use Case 6 - Enhanced Signal Coordination and raffic Progression Requirements he requirements for this Use Case are identified in the table below able 2.7 Use Case 6 Enhanced Signal Coordination and raffic Progression System Requirements HEA-UC6-001 he master server application shall send ravel imes to vehicles and nomadic devices. HEA-UC6-002 he master server application shall send MAFB gate queues to vehicles and nomadic devices. MAFB gate queues are the lines that form at each of the MAFB entrances and are provided to the master server from a 3 rd party app. HEA-UC6-003 he master server application shall send incident locations to vehicles and nomadic devices. HEA-UC6-004 PDs shall transmit PSMs HEA-UC6-005 Vehicle OBUs shall broadcast BSMs. HEA-UC SG application shall receive vehicles BSMs and PSMs. HEA-UC SG application shall measure intersection delay time HEA-UC SG shall archive Multi-Modal ntelligent raffic Signal Systems (MMSS)-measured intersection delay time at the MC Master Server. HEA-UC6-009 he Master Server shall present delay times for inclusion in the dataset as performance measurement data. HEA-UC6-010 he Master Server shall present delay times to the MC Operator. HEA-UC6-011 ravel times along Meridian Avenue shall be determined in a configurable time threshold (starting at 15 seconds). Based on consolidating BSM speeds and directions from multiple OBUs along the route. HEA-UC6-012 ravel times along Meridian Avenue shall be based on length of corridor and detection points. Based on consolidating BSM speeds and directions from multiple OBUs along the route. HEA-UC6-013 ravel times along Channelside Drive shall be determined with the most current data. HEA-UC6-014 ravel times along Selmon Expressway shall be determined with the most current data. HEA-UC SG shall publish travel times along Meridian Avenue to U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 17

24 Chapter 2 General System Description MAFB commuters. HEA-UC6-016 HEA-UC SG shall publish travel times along Channelside Drive to MAFB commuters. -SG shall publish travel times along Selmon Expressway to MAFB commuters. 2.5 Major System Conditions he system conditions requirements will focus on safety and performance measures. Safety requirements identify the state that must exist in order for the system to improve safety. Performance measurement requirements identify the data that is created to evaluate the effectiveness of the system. he tables below describe the safety and performance requirements Safety Requirements able 2.8 Safety Requirements HEA-SAF-001 Equipment, software, processes, and interfaces shall comply with EEE and SAE standards as prescribed by one of the USDO approved certification entities. HEA-SAF-002 Equipment, software, processes, and interfaces shall be tested for interoperability before deployment to ensure they meet those standards for interoperability. HEA-SAF-003 During operations the MC Operator and installation technicians shall performs checks on the equipment, software, interfaces, and processes on a six month basis at a minimum. D HEA-SAF-004 HEA shall maintain the RSUs installed along the roadside. D HEA-SAF-005 OBU/Application failure shall not affect the normal operation of the vehicle. HEA-SAF-006 RSU/Application failure shall not affect the safe operation of the signal controller. HEA-SAF-007 PD application failure shall not affect the normal operation of the PD. HEA-SAF-008 OBUs shall be installed properly in vehicles, buses, and street cars. HEA-SAF-009 RSUs shall be installed such that they receive GPS and DSRC signals. HEA-SAF-010 RSUs shall be installed near signal cabinets such that the RSU and signal controller can be connected. HEA-SAF-011 Participants shall bring their vehicles in for inspection within 14 days when the vehicle is involved in a crash. his is to ensure the equipment is working properly after the vehicle has been repaired. D HEA-SAF-012 he invehicle applications shall present information to D U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 18

25 Chapter 2 General System Description drivers using a device that drivers are familiar with and limit interaction. HEA-SAF-013 CV device suppliers shall provide and follow an approved quality management process in designing, constructing and producing their devices. HEA-SAF-014 he proposed user interface(s) shall be reviewed and approved by HEA and stakeholders. User interface definition will happen during the development of each application. HEA-SAF-015 Safety checks for OBU s and RSU s shall include the equipment reset functions upon power loss and restoration. HEA-SAF-016 Safety checks for OBU s and RSU s shall include the redundancy actions upon power loss and restoration. HEA-SAF-017 Safety checks for OBU s and RSU s shall include the security actions upon power loss and restoration. HEA-SAF-018 Safety checks for OBU s and RSU s shall include the equipment reset functions, redundancy, security, and actions upon power loss and restoration. HEA-SAF-019 Uninterruptible power supply units with sufficient holdup time (2 hours) to implement the response plans shall be installed at all signal controller cabinets as part of the pilot. Holdup time is o Be Determined as part of final design process. A HEA-SAF-020 Device installers shall be approved by the invehicle integrator to install devices in vehicles, buses, street cars. he purpose of this requirement is to minimize safety concerns over improper installed equipment and what affect it could have on participants. HEA-SAF-021 Device installers shall be approved by the infrastructure integrator to install devices in signal cabinets and along the roadside. he purpose of this requirement is to minimize safety concerns over improper installed equipment and what affect it could have on participants. HEA-SAF-022 Devices installed for the pilot shall have a fail safe mode. his mode causes the devices to respond in a manner that does not cause harm to the system, devices, participants or other users Performance Measures System Requirements able 2.9 Performance Measures System Requirements HEA-PFM-001 HEA-PFM-002 HEA-PFM-003 he Master Server shall collect historical or before CV treatment performance metrics for each CV App used in each Use Case if available. he Master Server shall store historical or before CV treatment performance metrics for each CV App used in each Use Case if available. he Master Server shall collect performance metrics for each CV App used during each Use Case HEA-PFM-004 he Master Server shall store performance metrics for each CV U.S. Department of ransportation ntelligent ransportation Systems Joint Program Office HEA 19