Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 1: Research Overview (2021)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

22 Chapter 4 builds on the ndings from the literature review and stakeholder engagement to conceptualize the connected vehicle environment, develop user needs, identify relevant applica- tions of connected vehicle technologies, and describe use cases for these applications. e infor- mation described serves as the foundation for the model ConOps and SyRS documents presented in Chapter 5. 4.1 Rural Connected Vehicle System e project team developed an initial context diagram in Task 3, building on the capabilities of existing rural systems and adding new ones enabled by connected vehicle technologies. e context diagram was then revised based on the feedback received from stakeholders through the dierent engagement eorts. Figure 8 shows the nal context diagram that showcases the actors and components of the proposed system as well as the interconnection among these components and external interfaces for a typical rural agency to enable connected vehicle deployment. e white boxes in this context diagram are the actors. It is expected that these new connected vehicle capabilities will be integrated with existing ITS systems, adding the ability to collect more granular and timely information directly from vehicles and to disseminate warnings, advisories, and other messages directly to vehicles rather than posting messages on dynamic message signs (DMS) and more conventional ITS devices. e context diagram is a representation of the functional view—not to be interpreted as the physical view that is developed later (aer the concept phase). User needs (see Section 4.2) are written relative to the context diagram and with feedback from the panel and stakeholders. As depicted in Figure 8, there will be new actors that are necessary parts of a rural connected vehicle deployment. To be consistent with prior connected vehicle projects and U.S. DOT-funded projects, the denitions are drawn from the U.S. DOT’s Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT) Physical Objects (6) and are consistent with Society of Automotive Engineers (SAE) J3067 Surface Vehicle Information Report, Candidate Improve- ments to Dedicated Short Range Communications (DSRC) Message Set Dictionary [SAE J2735 (7)] Using Systems Engineering Methods (8). It is important to note that some actors might not change signicantly from their current situation. e reader is referred to the model ConOps for an in-depth description of the context diagram, the actors, and their interactions. Note that the development of actors and descriptions was an iterative process involving team member discussion and was guided by project panel input. C H A P T E R   4 Rural Connected Vehicle Needs, Systems, and Applications Findings

Rural Connected Vehicle Needs, Systems, and Applications Findings 23   4.2 User Needs Dra high-level needs or need statements that capture the desired capability (i.e., not fully developed, well-written needs) for the actors were developed to document specic user needs that were further dened and developed in the model ConOps. e purpose of developing need statements in Task 3 was to present an initial set of needs to the project panel for review and feedback before advancing to Phase 2. To be consistent with existing connected vehicle deploy- ments and U.S. DOT-funded projects, the proposed set of user needs is drawn from the U.S. DOT’s ARC-IT Service Packages (9) and the WYDOT CV Pilot ConOps (10), and are consistent with SAE J3067 Surface Vehicle Information Report, Candidate Improvements to Dedicated Short Range Communications (DSRC) Message Set Dictionary [SAE J2735] Using Systems Engineering Methods. Except for the WYDOT CV Pilot, many of the user needs found in the literature were devel- oped for urban environments. e user needs developed as part of this research have been revised and tailored for a rural connected vehicle environment and represent the highest priority needs from the survey, the interviews, and the conrmation webinar conducted December 17, 2019. e project team developed user needs for six major rural connected vehicle groups (with subgroups) as listed: • Center-Specic Needs – Backoce – Maintenance Management System – Traveler Information System – Emergency Management/Public Safety System – Other Jurisdiction TMS – Weather Service System (Source: Noblis 2020.) Figure 8. Context diagram for the proposed system.

24 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors – Fleet and Freight Management System – Event Promoters – ird-Party Providers • Field-Specic User Needs – ITS Roadway Equipment • Agency-Personnel-Specic User Needs – Rural Agency Personnel (Note: some of the Rural Agency Personnel needs are embedded in the Center needs.) • Support Environment-Specic User Needs – Security Needs – Positioning and Timing System • Vehicle-Specic Needs – Basic Vehicle – Commercial Vehicle – Public Safety Vehicle – Maintenance and Construction Vehicle – Vulnerable Road User • System-Level Needs e user needs developed here are compliant with systems engineering criteria for a well- written need, which are dened as follows: • Uniquely Identiable: Each need must be uniquely identied (i.e., each need shall be assigned a unique number and title). • Major Desired Capability (MDC): Each need shall express a major desired (corridor-level) capability in the system, regardless of whether the capability exists in the current system or situation or is a gap. • Solution Free: Each need shall be solution free, thus giving designers exibility and latitude to produce the best feasible solution. • Capture Rationale: Each need shall capture the rationale or intent as to why the capability is needed in the system. Table 5 provides examples of Center-Specic Needs that focus on the Backoce. Each need on the table has a unique ID and brief description (e.g., C for Center followed by a two-digit number). Complete descriptions of the user needs presented here, and of all six groups and respective subgroups, can be found in the model ConOps. It is also important to note that these needs should be seen as samples; agencies will need to tailor specic system-level user needs indi- vidually to match their particular needs. 4.3 Connected Vehicle Applications Relevant to Rural Corridors Table 6 lists several examples of the connected vehicle applications that could augment opera- tions of rural agencies through improved processes and strategies. ese applications are grouped by the same six topic areas identied in the Task 2 literature review eort. e reader is referred to the model ConOps for a detailed description of the applications. In addition, connected vehicle applications are expected to continue development and innovation over time as new capabilities and data become available. e level of maturity for an individual application may range from prototype to currently operational. Agencies should review and understand the range of applica- tions and the status of supporting standards. e following list of links to applicable resources may be of use to practitioners at an early stage in the concept development phase. • Application prototyping and assessment has been a focus of federal connected vehicle research and development activity: https://www.its.dot.gov/pilots/cv_pilot_apps.htm.

Rural Connected Vehicle Needs, Systems, and Applications Findings 25   • Additional information about trac management applications can be found on the Connected Vehicle Pilots website: https://www.its.dot.gov/pilots/pilots_mobility.htm. • For additional information about implementation of work zone applications and U.S. DOT support of a Work Zone Data Exchange specification, see CV Pilot Deployment Program Phase 1, Concept of Operations (ConOps), ICF/WYDOT (Phase 2 Update) and https://www. transportation.gov/av/data/wzdx. • Additional information about road weather applications can be found on the CV Pilots website: https://www.its.dot.gov/pilots/pilots_roadweather.htm. • For additional information about incident response and management applications imple- mented in two CV Pilot projects, see CV Pilot Deployment Program Phase 1, Concept of Operations (ConOps), ICF/WYDOT (Phase 2 Update) and CV Pilot Deployment Program Phase 1, Concept of Operations (ConOps)—New York City. • Information about the ITS/connected vehicle standards program can be found at https:// www.standards.its.dot.gov/LearnAboutStandards/CV_apps. • ARC-IT provided information for specic services (or functions) and data ows in service pack- ages at https://local.iteris.com/arc-it/html/servicepackages/servicepackages-areaspsort.html. 4.4 Use Cases Dra high-level summary use cases, or use-case synopses, were developed to document specic use cases that were further dened and developed in the model ConOps. e purpose for devel- oping the use-case synopsis in Task 3 was to present an initial set for the project panel to review and give feedback before the project team developed more detailed use cases in the model ConOps. Center-Specific Needs Backoffice C01 The Backoffice needs the capability to collect, aggregate, and fuse near real-time traffic conditions (e.g., speeds). Traffic conditions may be obtained from a variety of sources, including ITS Roadway Equipment (e.g., loop detectors), Other Center Systems, third-party providers, and from vehicles through Connected Vehicle Roadside Equipment and the Cloud. Connected vehicles will provide probe data through basic safety messages (BSMs) to the Backoffice that can be aggregated with other traffic data to support traffic management strategies, including but not limited to traffic signal operations, disseminating information on queue warnings or delays, and disseminating traveler information. C02 The Backoffice needs the capability to collect, aggregate, and fuse location-specific, accurate, and near real-time information about work zones (e.g., reduced speeds, lanes affected, and delays). Work zone information may be obtained from the Maintenance Management System, Other Center Systems, and directly from the field (e.g., smart work zone technology or maintenance and construction crews). Connected Vehicle Roadside Equipment and the Cloud allow vehicles and field crews to share more accurate information about work zones with the Backoffice. The Backoffice will use this enhanced work zone data to support work zone management strategies, including disseminating information about work zones, monitoring traffic conditions around work zones, and implementing traffic control strategies including variable speed limits. … … C10 The Backoffice needs improved capability to analyze and act on information about freight-related events (e.g., runaway truck, bridge hit event). Using fused freight-related events data, including data from Connected Vehicle Roadside Equipment and the Cloud, the Backoffice will be able to analyze and disseminate notification of runaway truck ramp use to include ramp location, severity and type of incident, and infrastructure damage, such as bridge hits, to support timely incident and maintenance response. C11 The Backoffice needs improved capability to provide infrastructure information to commercial vehicle operators (e.g., steep grade information, bridge height information, curve warnings, truck parking). Connected Vehicle Roadside Equipment and the Cloud will allow the Backoffice to provide information directly to commercial vehicles on the location of steep grades, low bridge heights, curve warnings, truck parking, and other information that can be used to improve commercial vehicle safety. Providing this information directly to commercial vehicle operators will enable them to have advance notification thereby increasing safety. Table 5. Example of user needs: Center-specic needs.

Table 6. Example connected vehicle applications by topic area. Application Description Traffic Management Probe Data Enabled Traffic Monitoring (PDETM) Utiliz es communication technology to transmit real-time traffic data between vehicles to the Backoffice. Intelligent Traffic Signal System Uses connected data from vehicles, pedestrians, and nonmotoriz ed travelers. This is an overarching system optimiz ation application that accommodates transit or freight signal priority, preemption, and pedestrian movements to maximiz e overall network performance. Transit Signal Priority Provides signal priority to transit vehicles at intersections and along arterial corridors. Transit signal priority may be a significant issue for some agencies; however, for the project stakeholders it was not rated as a high-criticality area; therefore, did not warrant further attention. Dynamic Speed H armoniz ation Recommends target speeds in response to congestion, incidents, and road conditions to maximiz e throughput and reduce crashes. Q ueue W arning Provides drivers timely warnings of existing and impending queues. W ork Z one Management W ork Z one W arning (W Z W ) Provides information about the conditions that exist in a work z one that the host vehicle is approaching that could present unsafe conditions for the workers or the host vehicle, such as obstructions in the vehicle’ s travel lane, lane closures, lane shifts, speed reductions, or vehicles entering/exiting the work z one. W ork Z one Data Exchange (W Z Dx) Specification Enables infrastructure owners and operators (IOOs) agencies to make harmoniz ed work z one data available for third-party use. R oad W eather Management Enhanced Maintenance Decision Support System (MDSS) Acquires road weather data from connected and other general public vehicles to recommend treatment plans and weather response plans to snowplow operators and drivers of maintenance vehicles. Vehicle Data Translator W hen installed on road-service vehicles, such as snowplows, it collects road and atmospheric conditions data and transmits them to other portions of the road weather management network. W eather Response Traffic Information (W xTINFO) Uses connected vehicle data and communications systems to enhance the operation of variable speed limit systems and improve work z one safety during severe weather events. Motorist Advisories and W arnings (MAW ) Uses road weather data from connected vehicles to provide information to travelers on deteriorating road and weather conditions on specific roadway segments. Spot W eather Information W arning Uses standalone weather systems to warn drivers about inclement weather conditions (i.e., fog, wind, adverse surface conditions, etc.) that may impact travel conditions. Incident R esponse and Management Distress Notification (DN) Uses V2V and V2I communication to warn drivers in the vicinity and alert the TMC operators of a distressed vehicle (e.g., airbag deployed, vehicle disabled). Emergency Communications and Evacuation Information Alerts the drivers within the area of influence in the form of spoken warning. R ural Safety Management Stop Sign G ap Assist (SSG A) W arns stopped drivers at a stop-controlled intersection of oncoming cross traffic. This can be useful in rural intersections. Curve Speed W arning (CSW ) W arns drivers that the vehicle’ s current speed may be too high to safely traverse one or more upcoming curves, potentially leading to roadway departure. Stop Sign Violation W arning (SSVW ) W arns drivers that they may violate an upcoming stop sign based on their speeds and distance to the stop sign. Railroad Crossing Violation W arning (RCVW ) W arns drivers of the need to stop for crossing or approaching trains at an at-grade rail crossing. Reduced Speed Z one W arning (RSZ W ) W arns drivers of excessive speeds compared with the posted speed limit in reduced speed z ones and of changed roadway configurations. Safe Intersection Crossing Uses connected vehicle infrastructure to connect pedestrians with the traffic signal system to improve the safety of intersection crossings and increase independent mobility. Freight Management Freight-Specific Traveler Information Provides information tailored to freight and their needs, including parking and specific traveler information and road conditions (e.g., weather, alternate routes/diversions, height/weight restrictions, and weigh-in-motion (W IM)/e- Permitting). Oversiz e Vehicle W arning Provides warning to drivers of oversiz e vehicles (overheight/overlength/overwidth) about restricted clearances (e.g., tunnel and/or bridge clearances) ahead. Freight DNs Trucks that may have to use runaway ramps at steep grades may be able to send DNs to the Backoffice. z z z z H z z Q W W k Z W Z W W Z W z ’ z W Z W Z z z R W W W W z W W W W R R y G G W W W W ’ W W W W W W Z W Z W W z W z W z

Rural Connected Vehicle Needs, Systems, and Applications Findings 27   Use cases (also referred to as operational scenarios) are used in ConOps documents to provide a step-by-step description of how the proposed system should operate and interact with its users or actors. Use cases allow readers to gain an understanding of how the various parts of the proposed system function and interact. The use cases tie together all parts of the proposed system, the users or actors, and other entities by describing how they interact. User needs (see Section 4.2) and use cases are closely related. Use cases are typically used to derive and validate user needs. Use cases and user needs development is an iterative process to help identify holes and gaps in the user needs until the system owner is satisfied. ARC-IT uses service packages to represent specific services like traffic signal control, road weather for freight carriers, and incident scene safety monitoring. The ARC-IT Service Packages are not use cases or scenarios per se; however, each service package contains a set of needs and requirements. As such, similar to the user needs, the use cases were developed to be consistent with existing connected vehicle deployments and U.S. DOT-funded projects. These use cases are also drawn from the U.S. DOT’s ARC-IT Service Packages and are consistent with SAE J3067 Surface Vehicle Information Report, Candidate Improvements to Dedicated Short Range Communications (DSRC) Message Set Dictionary [SAE J2735] Using Systems Engineering Methods. Also, similar to user needs, many of the use cases found in the literature were developed primarily for urban environments. The use cases developed in this research have been revised and tailored for a rural connected vehicle environment and present the highest priority operational scenarios/use cases articulated through the survey, the interviews, and the confirmation webinar conducted December 17, 2019. The project team based the format of the use cases on the SAE J3067 format for operational scenarios categories and ISO 19091 Intelligent transport systems—Cooperative ITS—Using V2I and I2V communications for applications related to signalized intersections (11). The project team developed 10 representative use cases that are likely to be of interest and rele- vance in rural corridors. These use cases are not meant to be a comprehensive list of all possible needs in rural corridors or to be prescriptive, but rather to provide a starting point for further tailoring. The selected representative use cases present new capabilities that can augment and be integrated into existing traffic operations and management systems. A brief description of each use case is provided. 1. General Situational Awareness. This use case describes the collection of current infrastruc- ture and traffic condition data from multiple sources that may include existing ITS Roadway Equipment, onboard unit (OBU)-equipped vehicles, and Centers and other systems (e.g., Traveler Information System) and third-party service providers. Probe data can be used to directly measure or infer current conditions. The collected data may be aggregated and fused (which may require reconciling location reference systems) with other sources for further data consolidation and to be disseminated to other systems and vehicle operators. 2. Rural Corridor Traffic Management and Operations Strategies. This use case describes actions a transportation agency/system/subsystem may take for management and opera- tions of rural corridors that support harmonizing traffic conditions [e.g., Dynamic Speed Harmonization (SPD-HARM) application]. Information, static and dynamic, may be based on data from multiple sources that may include OBU-equipped vehicles. The collected data is then used to support operations (and possibly decisionmaking). This includes managing ITS Roadway Equipment, Connected Vehicle Roadside Equipment, and the information systems that notify other systems of the operational strategy. 3. Road Weather Management. This use case describes the collection, fusion with other sources, and dissemination of accurate, timely, location-specific road weather information to travelers, including connected vehicles, in the form of advisories and alerts. The environmental data collected is used to detect unsafe conditions, road closures at specific points, and environmental hazards (e.g., icy road conditions, high winds, and dense fog) so operational centers and deci- sion support systems can make decisions on corrective actions to take.

28 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors 4. Freight-Specific Situational Awareness. This use case describes how the Backoffice collects current freight-specific infrastructure conditions, such as truck-parking locations/status and truck/freight route restrictions, from multiple sources. The information, both real-time and static, is then disseminated through different means, such as directly to Fleet and Freight Management System and commercial vehicle operator mobile devices, or directly to OBUs as commercial vehicles approach roadway exits with key facilities, such as parking or restricted routes. An alternative operational scenario about providing oversize/overweight permit infor- mation to commercial managers is provided. 5. Incident Detection, Verification, and Traveler Information (does not include all aspects of incident response and management). This use case describes using connected vehicle DN capabilities to supplement traditional ITS, thereby potentially providing faster and more accurate detection and verification of incidents, as well as capturing more detailed informa- tion about the incident. Information from connected vehicles can be fused with other sources of data to support emergency management with a richer, more accurate, and detailed inci- dent response (e.g., location, severity, alternate routes). Incident information can be sent to connect vehicles via Connected Vehicle Roadside Equipment. Additionally, this information can be provided to traditional ITS (e.g., emergency response agencies, other jurisdictions, DMS, 511, website). 6. Infrastructure to Vehicle (I2V) Freight-Specific Information and Advisories. This use case describes providing freight-specific information in high-risk areas and the monitoring and timely reporting of freight-related infrastructure events. The Backoffice provides freight- specific information to commercial vehicle OBUs using Connected Vehicle Roadside Equipment at strategic or high-risk locations to support in-vehicle notifications of alerts/warnings. For non-connected commercial vehicles, information can be provided through traditional ITS Road- way Equipment. Alternative operational scenarios about oversize/overheight vehicle warnings to truck drivers of potential infrastructure (e.g., bridge, tunnel), excessive speed approaching sharp curve, and notification of runaway truck ramp use are provided. 7. Work Zone Management. This use case describes how connected vehicle data can be used to complement available ITS Roadway Equipment/Devices at work zones in monitoring traffic conditions. Rural environments can have limited infrastructure and power, making the use of traditional ITS more difficult. Accurate, specific, and timely work zone information can enable faster and more accurate alerts to drivers of OBU-equipped vehicles when the vehicle trajec- tory warrants (e.g., providing RSZW). Alternative operational scenarios about OBU-equipped vehicles providing additional near real-time traffic conditions data to the Backoffice and Main- tenance Management System via the Connected Vehicle Roadside Equipment, Rural Agency Maintenance Personnel using smart infrastructure tools are provided. 8. Animal Crossing Warning. This use case supports the sensing and warning systems used to detect the presence of animals/wildlife in areas prone to high counts of vehicle-wildlife inci- dents and areas with a heavy concentration of wildlife frequently crossing sections of rural corridors. Wildlife presence can be detected by infrastructure-based systems using radar or infrared. This information can then be passed on to connected vehicles through Connected Vehicle Roadside Equipment and to non-connected vehicle drivers through roadside signage warning systems. By providing warnings, the system supports active protection for animals/ wildlife and helps drivers avoid collision with wildlife. An alternative operational scenario using in-vehicle sensors (e.g., radar, infrared) to detect large animals (e.g., deer, bear, moose) and then relay the warning to other equipped vehicles and Connected Vehicle Roadside Equipment is provided. 9. Pedestrian/Cyclist. This use case supports the sensing and warning systems used to interact with pedestrians, cyclists, and other nonmotorized users that operate on rural roadways, or on pathways that intersect the main vehicle roadways, specifically near national parks, and other tourist and seasonal venues. These connected systems allow automated warning or active

Rural Connected Vehicle Needs, Systems, and Applications Findings 29   protection for nonmotorized users. They integrate traffic, pedestrian, and cyclist information from roadside or intersection detectors, and new forms of data from wirelessly connected non- motorized traveler-carried mobile devices, to assist nonmotorized travelers on when to cross and how to remain aligned with the crosswalk or pathway based on real-time Signal Phase and Timing (SPaT), and connected vehicle map message (MAP) information, if traffic signal controller is present. In some cases, priority will be given to nonmotorized travelers, such as persons with disabilities who need additional crossing time, or in special conditions (e.g., large crowds) where nonmotorized travelers may warrant priority or additional crossing time. The system also provides warnings to nonmotorized users of possible infringement of the crossing or pathway by approaching vehicles. 10. Non-Signalized Intersection Safety. This use case describes improving safety at high-risk non- signalized intersections on rural corridors where only the minor road has posted stop signs and includes divided highways with no posted stop signs on the major road. This entails the integration of data from connected vehicle OBUs, Connected Vehicle Roadside Equipment, and ITS Roadway Equipment (e.g., vehicle detection, such as inductive loops, radar, Light Detec- tion and Ranging (LiDAR), cameras, and roadside signage warning systems). The intent is to help drivers on a minor road stopped at an intersection or turning off a divided highway understand the state of activities associated with that intersection by providing a warning of unsafe gaps on the major road. All available sensor information data (major road, minor road, and median sensors) is collected and used to compute the dynamic state of the intersection to issue appropriate warnings and alerts. If OBU-equipped vehicles can detect a crash, DN can be transmitted. If both mainline and minor road vehicles are OBU-equipped, then applications such as Intersection Movement Assist (IMA) and left-turn assist (LTA) could be used. The model ConOps provides a more comprehensive description of each use case. In it, the following information is provided: Goal(s), Constraint(s), Geographic Scope, Actors, Illustration (example), Preconditions, Main and Alternate Flow(s), Post-Conditions, Information Require- ments, and Related User Needs. Table 7 provides an example of a use case that illustrates the description for Incident Detection, Verification, and Traveler Information. The model ConOps document includes the complete set, which covers additional use cases.

30 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors 2. The Connected Vehicle Roadside Equipment receives the DN message from the OBU- equipped vehicle. 3. The Connected Vehicle Roadside Equipment transmits the DN message to the Backoffice. 4. The Backoffice operator (Rural Agency Personnel) may be prompted to act when a DN or mayday message is received. The Backoffice also fuses BSM and Probe Message Data from OBU-equipped connected vehicles with traditional ITS data at the Backoffice. Together this information is used to identify potential backups or delays near the incident. Other data sources for incident detection may be used to help detect or verify this incident, including information from a CAD system, ITS Roadway Equipment (sensors, CCTV cameras), third- party service providers (traveler reported, e.g., crowd-sourced data provided through smartphone apps). verification of incidents, and detailed information about the incident. Information from connected vehicles can be fused with other sources of data to support emergency management with a richer, more accurate, and detailed incident response (e.g., location, severity, alternate routes). Incident information can be sent to equipped connected vehicles (e.g., travelers, first responders, agency maintenance fleet) via Connected Vehicle Roadside Equipment. Additionally, this information can be provided to traditional ITS (e.g., emergency response agencies, other jurisdictions, DMS, 511, website). The incorporation of connected vehicles can aid in quicker incident response and more timely information to travelers. Goal Improved incident detection, verification, and dissemination of more accurate near real-time incident information to responders and travelers. Non-equipped travelers benefit from faster reporting of incidents, verification, and more accurate information. Constraints • Other traditional ITS Roadway Equipment is located along the corridor; however, given the rural setting, it does not provide full coverage (e.g., DMS sand detectors are sparse, camera coverage is limited to verify incidents). Geographic Scope Rural corridors with long stretches of divided highways with limited and long distances between services, limited communications and power, and lack of alternate routes. Rural corridors may be subject to heavy travel during tourist seasons. Actors • OBU-equipped vehicles (e.g., agency response, emergency management, travelers) • Connected Vehicle Roadside Equipment/Cloud • Backoffice • ITS Roadway Equipment • Emergency Management/Public Safety System(s) that may be connected to a CAD system • Maintenance Management System • Satellite Service Providers/Third-Party Service Providers • Other Jurisdiction TMSs Illustration (example) Preconditions 1. Connected Vehicle Roadside Equipment located along a rural corridor may be operated by a TMC or partnership thereof (e.g., tourist venue, rural transit agency). Main Flow 1. The use case begins when (a) an OBU-equipped vehicle has been involved in an incident and transmits/triggers a DN (e.g., mayday message). If the OBU-equipped vehicle involved in the incident is not within broadcast range of Connected Vehicle Roadside Equipment, when the next OBU-equipped vehicle comes within broadcast range, it receives the DN (or mayday message) from the OBU-equipped incident vehicle. See Alternate Flow(s) for two additional ways the use case may begin. Incident Detection, Verification, and Traveler Information (does not include all aspects of incident response and management) Short Description This use case describes using connected vehicles to supplement traditional ITS thereby potentially providing faster and more accurate detection (using connected vehicles implementing DNs) and Table 7. Incident response and management use-case synopses with addressed need statements.

Rural Connected Vehicle Needs, Systems, and Applications Findings 31   R elated U ser N eeds C0 1, C0 3, C0 6 , C0 8 , C14, C18 , C19 , C20 , C21, C25, C26 F0 1, F0 2 AP0 1, AP0 2 SE0 1, SE0 2, SE0 3, SE0 4, SE0 5, SE0 6 V0 1, V0 2, V0 4 Note: User Need Identifiers (e.g., C0 1, AP0 1) relating to the use case are listed in the model ConOps, Section 4.2. 5. L ocation data from the OBU-equipped vehicle may be used to verify location of incident, or support verification. The Backoffice/Rural Agency Personnel operator may use other traditional data sources from the Emergency Management/Public Safety System to verify the incident (e.g., CAD system, State Police/Patrol on the scene). 6 . The Backoffice provides incident location information and other known information about the incident (e.g., severity, vehicle types) to Emergency Management/Public Safety System(s) and Maintenance Management System(s). Emergency Management/Public Safety System(s) conduct response per TMC/agency procedure/protocol. The Backoffice may communicate/coordinate with neighboring jurisdictions (i.e., Other Jurisdiction TMS) to get the nearest equipment to the scene. 7 . The Backoffice sends traveler information messages (TIMs) about the incident to vehicle OBUs via Connected Vehicle Roadside Equipment/Cloud. This information would include the incident location, warnings to expect delays, and alternate routes/diversions. Information may be sent to OBU-equipped vehicles and CAVs. Traveler information updates are also sent to ITS Roadway Equipment (DMS), website, 511 system and satellite service providers/third- party service providers, and so forth, as another mechanism for informing travelers of the incident. Using the incident location, the Backoffice can determine how far out messages need to be shared to account for limited or lack of alternate routes or diversions. 8 . Incident information can be updated as appropriate once Emergency Management/Public Safety System(s) and Maintenance Management System(s) personnel are on scene. Alternate Flow(s) 1a. An OBU-equipped AV detects slowed traffic and captures images of surroundings and sends message to Backoffice via Cloud, and/or third-party data provider, then to Backoffice. 2a. An OBU-equipped vehicle transmits probe vehicle data (PVD) message to Connected Vehicle Roadside Equipment indicating a data event snapshot (e.g., braking possibility indicating slowed traffic due to an event). 3a. The Connected Vehicle Roadside Equipment transmits the PVD message to the Backoffice. 4a. An incident could be detected possibly from PVD message. 5a. An incident could be detected possibly from an AV. Post- conditions 1. The Emergency Management/Public Safety System(s) and Maintenance Management System(s) personnel provide incident management and response according to TMC procedure/protocol (e.g., incident clearance, traffic management, and rerouting as required). 2. The OBU-equipped vehicle under distress is cleared according to normal traffic management procedure/protocol. 3. OBU-equipped vehicles proceed with travel following alternate routes or diversions as information is provided to the OBU application(s). 4. Non-OBU-equipped vehicles receive travel information to include alternate routes or diversions via other and traditional ITS means (e.g., radio, portable DMS, State Police/Patrol on scene). Information R eq uirements • OBU-Equipped Distressed Vehicle location • OBU-Equipped Distress Vehicle status (e.g., moving, stopped) • Vehicle Probe Data • BSMs Table 7. (Continued).