Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 2: Model Concept of Operations (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.

6 Scope Volume 2 of NCHRP Research Report 978 serves as a model Concept of Operations (ConOps) document to guide agencies responsible for rural corridors as they assess their needs, operational concepts, and scenarios for connected vehicle deployment. is document was created under NCHRP Project 08-120, “Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors.” e objectives of this research project are to identify (1) connected vehicle applica- tions that will be most relevant on rural corridors; (2) scalable ways connected vehicles may be integrated into transportation agencies’ trac operations and management plans; (3) connected vehicles and cyber-physical infrastructure requirements within rural corridors; (4) the antici- pated roles and responsibilities of agencies in authorizing, deploying, operating, and maintain- ing ITS and other TSMO technologies within rural corridors; and (5) the related stang and resource needs. e research uses a systems engineering approach to develop a model ConOps to guide agencies responsible for rural corridors as they begin to assess their needs, operational concepts, scenarios, and requirements for connected vehicle deployment. As such, the structure of this document is based on the IEEE Standard 1362-1998, IEEE Guide for Information Technology— System Denition—Concept of Operations (ConOps) Document. Several stakeholder outreach activities were conducted during the development of this model ConOps. e rst set focused on eliciting user needs. Input was collected via survey, interviews with stakeholders, and a conrmation webinar. Targeted stakeholders include all state agencies listed in the AASHTO Committee on Transportation System Operations (CTSO), county- and city-level agencies from American Public Works Association (APWA) Technical Committee and FHWA Local Technical Assistance Program (LTAP), tribal communities from U.S. DOT Tribal Communities and Tribal Technical Assistance Program (TTAP), and connected vehicle stakeholders identied by the project team. 1.1 Background Across the United States, state and local agencies are preparing to deploy infrastructure to support connected vehicles. ese systems are being deployed to address some of transportation’s biggest challenges in the areas of safety, mobility, and eciency. While most connected vehicle projects have focused primarily on applications in urban areas, there is signicant interest and potential in deploying, operating, and maintaining connected vehicles on rural corridors. Rural corridors exist in all states, ranging from more traditionally rural states, like South Dakota, to states perceived to be more urban, like California. Rural corridors serve as a bridge to other states, support the agriculture and energy industries, connect economically challenged citizens in remote locations to employers, enable the movement of people and freight, and provide access to America’s tourist attractions. S E C T I O N 1

Scope 7   For purposes of this document, a rural corridor refers to highway facilities ranging from limited access interstates in sparsely populated areas to principal roadways that connect small towns. e focus is on a mostly linear travel pattern with limited infrastructure deployment on the corridor, not on the wider surrounding area. Rural corridors oen include (1) long stretches of highway with limited power, communications, and ITS infrastructure, (2) long distances between cities or services for travelers, (3) dierent trac and roadway characteristics (e.g., higher posted speed limits, higher percentage of truck volume, and roadway geometry), and (4) signicant incident-related rerouting distances. Rural corridors face many transportation challenges unique to the rural environment. Congestion in rural areas is oen related to incidents, stalled vehicles, tourism, or special events. Rural congestion can have a signicant impact on freight movement, manufacturing processes, competitiveness, and productivity. Safety is also a major challenge on rural corridors; according to the 2016 American Community Survey, rural areas accounted for 50% of all trac fatalities in 2016. Fatalities are prevalent across the country with many states having large percentages of fatalities on rural roads compared with urban roads (see Figure 3). Rural incidents are more likely to be at higher speeds than urban incidents, and response times are longer. As connected vehicles continue their progress from research testbeds to operational deploy- ments, agencies must nd scalable ways to integrate connected vehicle infrastructure, systems, and subsystems into their existing trac management systems (TMSs) and trac operations and management activities. Agencies will ultimately decide the extent to which connected vehicle infrastructure and applications should be deployed to meet their local needs. To do this, eective long-term planning is paramount for deploying, operating, and maintaining connected vehicle infrastructure on rural corridors. Connected vehicle solutions have signicant promise to accommodate the unique characteristics and needs associated with rural corridors; however, these same technologies also require signicant resources to buy, integrate, and test with existing systems and processes (see Figure 4). [Source: Noblis from NHTSA data (2016).] Figure 3. Percentage of trafc fatalities on rural roads by state.

8 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors Successful connected vehicle deployments will ensure that local needs and challenges are addressed, measurable goals and objectives are set, and appropriate connected vehicle applica- tions and solutions are identied. For some, the tendency might be to forego upfront planning and jump straight into vendor-driven deployments. Although many perceive this approach as a means to expedite deployment, this buy-install-hope mindset increases project risk. As a result, agencies will likely nd themselves backing into requirements that may or may not address the problem the agency is trying to solve. Some acquired solutions may be proprietary, which means they cannot be incorporated into an overarching solution that can be implemented across state and jurisdictional boundaries. Conversely, while the benets of following a systems engineering process are well-documented, many agencies continue to nd the process to be cumbersome. To help in these situations, model systems engineering documents oer a starting point for agencies as they begin to deploy connected vehicles. e model documents developed in this project are intended to help agencies leverage the work of others to develop their tailored documents faster, better, and more eectively. As shown in Figure 5, input from a diverse group of rural and connected vehicle stakeholders captured in a model ConOps should clearly articulate the potential user groups, user needs, proposed systems, and operational concepts that are typical for a rural corridor. Agencies can use these model systems engineering documents to develop their customized, local ConOps and SyRS documents, saving the agency time and money while ensuring that their deployments address rural challenges and are eective, secure, and interoperable. 1.2 Document Overview e structure of this ConOps document follows IEEE Standard 1362-1998 and contains the following sections: • Section 1, Scope, provides an overview of the model ConOps for rural connected vehicle corridors. (Source: Noblis 2020, graphics developed by the U.S. DOT in support of the CV Pilots Deployment Program.) Figure 4. Rural corridor characteristics drive connected vehicle application and infrastructure deployments.

Scope 9   • Section 2, Referenced Documents and Resources, identies the documents, surveys, and interviews conducted in developing the ConOps document. • Section 3, Current System or Situation, describes typical rural agency systems or situations as they currently exist. For the model ConOps, this section will describe how a typical rural agency operates and the various components or systems that are typically in place. • Section 4, Justication for and Nature of Changes, describes the shortcomings of the current system or situation that motivated the development of a new system or the modi- cation of an existing system (i.e., why are connected vehicles needed). It describes the user needs and provides a transition from Section 3 of the ConOps, which describes the current system or situation, to Section 5 of the ConOps, which describes the proposed system. • Section 5, Concepts for the Proposed System, describes the proposed system that results from the user needs specied in Section 4 of the ConOps. is section describes the proposed system in a high-level manner, indicating the operational features that are to be provided without specifying design details. • Section 6, Operational Scenarios, includes 10 operational scenarios. A scenario is a step-by- step description of how the proposed system should operate and interact with its users and its external interfaces under a given set of circumstances. Scenarios are described in a manner that will allow readers to walk through them and gain an understanding of how various parts of the proposed system function and interact. e scenarios tie together all parts of the system, the users, and other entities by describing how they interact. • Section 7, Summary of Impacts, describes the operational impacts of the proposed system on the users, the developers, and the support and maintenance organizations. It describes impacts such as expected safety benets, requirements for additional equipment/services/ soware, requirements for additional sta, new processes, need for protection of Personally Identiable Information (PII), and other impacts. • Section 8, Analysis of the Proposed System, provides an analysis of the benets, limita- tions, advantages, disadvantages, alternatives, and trade-os considered for the proposed system. 1.3 System Overview is ConOps is intended to serve as a model document that rural agencies can use as they develop their own project-specic ConOps. As such, the document describes generic stake- holders, systems, and processes that exist in a typical rural area. ese items may take dierent forms depending on the agency. For example, some rural agencies may have a Backoce system that is housed in a large brick and mortar transportation management center (TMC) while other rural agencies may have a workstation that is used to operate ITS devices. (Source: Noblis 2020.) Figure 5. Model systems engineering documents help ensure interoperable deployments.

10 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors Rural agencies are interested in deploying infrastructure to support connected vehicles to augment their existing ITS/Operations objectives. In most cases, agencies seek to improve safety and mobility while enhancing agency efficiency. Connected vehicles are expected to augment and enhance existing ITS/Operations strategies, thus helping agencies further meet their goals. Connected vehicles provide the opportunity for rural agencies to receive more granular data from equipped vehicles and to disseminate information directly to vehicles. Equipped vehicles may interact with other vehicles or infrastructure systems via wireless communications tech- nologies to enable or utilize a variety of applications to improve rural transportation, including safety and operations. Connectivity may take several forms and utilize various communica- tions technologies, both currently available and those under development. Potential types of communications include the following: • Short Range Wireless. Direct wireless communication [5.9 GHz Dedicated Short Range Communications (DSRC), proposed cellular vehicle-to-everything (C-V2X)/PC5 mode, etc.)] between and among nearby vehicles, other equipped roadway users, and Connected Vehicle Roadside Equipment. • Wide-Area Wireless. Wireless communication (cellular tower-based network/Uu, two-way radio) between roadway users (equipped vehicles and non-motorized roadway users with devices) and centers. • Wide-Area Broadcast. One directional wireless communication (satellite, wide-area radio broadcast) from center to roadway users (and field ITS Roadway Equipment) over a region or greater area. Standards and interoperability play key roles for connected vehicles in this project, as com- pared with standalone proprietary solutions that may have similarities in architecture. For example, devices with incompatible wireless interfaces would not be able to communicate with each other. Technologies will continue to evolve, and therefore, the specific deployment approach should consider the current state of industry before concept development. A context diagram for a typical rural connected vehicle deployment is depicted in Figure 6. It should be noted that new software, hardware, and equipment deployed as part of a connected vehicle deployment should be integrated, where applicable, or included as part of existing systems that rural agencies currently use to manage and operate the transportation system. For example, rather than deploying a new Backoffice system for connected vehicles, it will likely be more beneficial for agencies to integrate new functionality and modules into their existing TMS. The system of interest is delineated by the dotted line. Items inside the box are components that are included as part of the connected vehicle system. Items outside the box are items with which the connected vehicle system will interface. As shown in the diagram, the connected vehicle system comprises the following: • Backoffice represents the Backoffice connected vehicle system. This will likely be a module or component of an agency’s existing TMS. It is responsible for the Backoffice functionality of the connected vehicle system, including collecting, disseminating, and managing connected vehicle devices and data exchanges. Please see “Note to reader” at the end of this section for information about how FHWA’s TMS design and architecture relate to this model ConOps. • Cloud serves as a mechanism for rural agencies to store and communicate information that can be accessed by personal information devices (PIDs) and onboard units (OBUs). For example, a rural agency may upload signal phase and timing (SPaT) and MAP information to the Cloud that OBUs can access and download.

Scope 11   • Connected Vehicle Roadside Equipment represents the connected vehicle roadside devices that are used to send messages to, and receive messages from, nearby vehicles using Dedicated Short Range Communications (DSRC) or other alternative wireless communications tech- nologies (e.g., C-V2X). Communications with adjacent eld equipment and Backoce centers that monitor and control the roadside unit (RSU) are also supported. is device operates from a xed position and may be permanently deployed or be a portable device that is located temporarily in the vicinity of a trac incident, road construction, or special event. It includes a processor, data storage, and communications capabilities that support secure communica- tions with passing vehicles, other eld equipment, and centers. • PIDs provide the capability for pedestrian and cyclist travelers to send and receive formatted traveler information based on personal input and personal updates. Capabilities include traveler information, trip planning, and route guidance. e PID (frequently, a smartphone) provides travelers with the capability to receive route planning and other personally focused transportation services from the infrastructure in the eld, at home, at work, or while en route. PIDs may operate independently or may be linked with connected vehicle equip- ment. For example, a PID may include DSRC or C-V2X communications. • OBUs provide the vehicle-based sensory, processing, storage, and communications functions that support ecient, safe, and convenient travel. e vehicle OBU includes general capabilities that apply to passenger cars, trucks, and motorcycles. Many of these capabilities apply to all vehicle types, including personal vehicles, commercial vehicles, emergency vehicles, transit vehicles, and maintenance vehicles. From this perspective, the vehicle OBU includes the common interfaces and functions that apply to all motorized vehicles. e radio(s) supporting vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications are a key com- ponent of the OBU. Both one-way and two-way communications options support a spectrum of information services from basic broadcast to advanced personalized information services. External systems and components include the following: • Other Centers represent Other Centers (or systems) with which the Backoce connected vehicle system may interface. Examples of Other Centers the Backoce may interface with (Source: Noblis 2020.) Figure 6. High-level context diagram for a rural connected vehicle deployment.

12 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors include Maintenance Management Systems, Emergency Management/Public Safety Systems, Fleet and Freight Management Systems, Traveler Information Systems, Other Jurisdiction TMSs, Weather Service Systems, and Event Promoters. • Third-Party Service Providers include satellite service providers (e.g., SiriusXM) and third- party service providers that receive and disseminate information to vehicle systems and smartphones. Many of these services currently exist and are expected to be augmented by connected vehicle capabilities. • Connected Vehicle Support Environment includes necessary connected vehicle compo- nents required to ensure privacy, security, and interoperable connected vehicle solutions. It includes the Security Credential Management System (SCMS) and Positioning and Timing Systems. • Vehicles represent various types of vehicles that may be equipped with OBUs or vehicles that receive information from third-party providers. Vehicle types include basic passenger vehicles, commercial vehicles, public safety (police, fire, and EMS) vehicles, and maintenance and construction vehicles [e.g., agency maintenance vehicles, safety service patrols (SSPs), and snowplows]. • Vulnerable Road User (VRU) includes the individual, riding a bicycle or using human power to move (walk), who participates in shared use of the transportation network with motorized and non-motorized transportation modes. VRU represents those using non-motorized travel modes that sometimes share motor vehicle lanes. Cyclists and pedestrians provide input (e.g., a call signal requesting right of way at an intersection), and may be detected by connected vehicle and ITS services to improve safety. • Field Equipment represents equipment distributed on and along the roadway. The devices communicate with the Backoffice, which monitors and controls traffic flow as well as the road and environmental conditions. It could include traffic detectors, environmental sensors, traffic signal equipment, highway advisory radios (HAR), dynamic message signs (DMS), closed-circuit television (CCTV) cameras and video image processing systems, grade crossing warning systems, and ramp metering systems. Traffic signals are also included under Field Equipment. • Personnel represents rural agency staff (e.g., TMC operators and system administrators) who interface with the Backoffice system.

Scope 13   Note to reader: If you are new to systems engineering, please note that the physical location of servers and details related to subsystems and components; how software is distributed across subsystems; and how communications will be addressed relate to system design and architecture. These items will be addressed later in the systems engineering process after the system requirements are developed. The scope of NCHRP Project 08-120 is the ConOps and SyRS (Volumes 2 and 3, respectively, of NCHRP Research Report 978). These two documents focus on user needs and the associated requirements; they document “what” the system will do while leaving “how” this is accomplished to the System Architecture and System Design documents. The following diagram is similar to one presented in the report titled, “Review of Traffic Management Systems— State of the Practice” developed for the FHWA Office of Operations. It has been modified to contrast with Figure 6.