Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification (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.

9   S E C T I O N 2 is section describes the proposed system that results from the desired changes or user needs specied in the model ConOps. It describes the proposed system in a high-level manner, indicating the operational features that are to be provided without specifying design details. General System Description 2.1 System Context Connected vehicles enable vehicles, roads and other infrastructure, and our smartphones to communicate and share vital transportation information through advanced wireless commu- nication technology. A key enabler to connected vehicles is wireless communication, which allows a vehicle to communicate with other vehicles, roadside equipment, pedestrians, and bicyclists. e underlying assumption for connected vehicle V2V communications is the direct communi- cations between devices used in the communications chain without the involvement of network infrastructure, such as access points or base stations. Two classes of devices exist in a connected vehicle ecosystem—OBUs located on or within vehicles and roadside units (RSUs) deployed in stationary locations near roadway facilities. To function safely, a connected vehicle needs to ensure the trustworthiness of communica- tion between vehicles. e source of each message needs to be trusted and message content needs to be protected from outside interference. Considering the stringent requirement of the applications described previously in a wireless environment with a sometimes harsh radio environment—including multipath interference limitations—it becomes a requirement for connected vehicles to support high-speed, low-latency wireless communications. In addition, the location accuracy for devices required for several of these applications to work needs to support lane level accuracy. SCMS is a critical component of a connected vehicle environment serving as a message secu- rity solution for V2X. It uses a Public Key Infrastructure (PKI)-based approach that employs specialized methods of encryption and certicate management optimized for anonymization to facilitate trusted communication. Note to reader: If you have a separate ConOps document containing a description of the proposed system that can be referenced in the SyRS, the creation of this General System Description is optional. For systems that are smaller in scale or scope, you may want to combine the ConOps and SyRS into one document that contains a section describing the proposed system.

10 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors e proposed system (see Figure 3) builds on the capabilities described in Section 2.3. 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 DMS and more conventional ITS devices. 2.2 System Modes and States is section details the dierent modes in which the agency operates under the proposed system. ese modes (see Table 1) could encompass several operational/management cases under normal or adverse conditions. Agencies may choose to add/delete as appropriate for their situation. 2.3 Major System Capabilities While each rural corridor may have unique objectives, deploying connected vehicle systems tends to have operational objectives that are based on enabling new capabilities for the agency. ese capabilities can be summarized as follows: • Collect new data from connected vehicles. e deployment of connected vehicles can allow agencies to collect more robust and granular data, reducing the latency and increasing the coverage of road condition reports. • Disseminate data to connected vehicles. Direct and constant communication with vehicles and drivers through advisories can support mobility and safety-oriented strategies, such as speed management, detours, parking, and presence of maintenance and emergency vehicles. (Source: Noblis 2020.) Figure 3. Context diagram for the proposed system.

General System Description 11   M o d e D efinitio n Mode 1: Normal Operating Conditions Indicates that all key systems and equipment are operating correctly. Some secondary systems and equipment may be partially or fully non- operational due to a localiz ed failure or scheduled maintenance; however, overall operations and management of the system are not significantly impacted, and remediation actions are already in place ( e.g., maintenance personnel were notified) . Mode 2: Degraded A subset of key systems and equipment is not functioning as intended. Depending on the nature of the degradation, several primary functionalities and processes may be unavailable. Some situations that could lead to this include but are not limited to the following: • Diminished Communications — L oss of connectivity between roadside infrastructure devices — W ireless attenuation — W ireless channel congestion — Unpowered device • Deficient OBU Data Q uality — Inaccurate G lobal Navigation Satellite System ( G NSS) data ( e.g., position, speed, and heading) — Unsynchronize d devices ( time) — Inability to process data promptly W hile this mode does not typically result in a safety issue, diminished management and operations capabilities may impact overall mobility and functionality of the system. Mode 3: F ailure Indicates a complete failure of systems and equipment. This primarily occurs as a result of ex acerbated issues listed in the degrade mode, such as regional loss of power or systemwide software malfunction. Due to the risk associated with a malfunctioning Backoffice system, all use cases would be suspended, and the proposed system would revert to pre- connected vehicle state of operations. Table 1. Modes of operation of the proposed system. • Improve accuracy of data disseminated to all travelers. Non-connected vehicle drivers will benet from receiving more accurate information through more traditional modes of communication (e.g., 511, mobile apps, and DMS). • Improve agency decision support capabilities. When fused with other data, connected vehicle data will enable agencies to improve their decision support capabilities. More gran- ular data is expected to improve decisionmaking for operating the transportation system. More timely and accurate data can also be shared with other agencies (e.g., adjacent TMCs, emergency responders, third-party service providers, etc.) to improve trac operations, incident response, and traveler information capabilities. 2.4 Major System Conditions e following are common system operational constraints: • System components have access to general Connected Vehicle Support Environment (Positioning and Timing Systems, SCMS/trust, etc.). • OBU-equipped vehicles meet certain basic requirements, such as positioning accuracy/ performance, transmission of Basic Safety Message (BSM) (e.g., SAE J2945/1).

12 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors • Connected Vehicle Roadside Equipment is anticipated to be only sparsely located along rural corridors. • Connected Vehicle Roadside Equipment is provisioned to send and receive messages to facilitate information receipt and dissemination. • Connected Vehicle Roadside Equipment meets RSU specication or RSU standard or other (to be determined) minimum performance requirements. • Connected Vehicle Roadside Equipment is strategically located along rural corridors to support traveler information messages (TIMs) in front of historically dangerous areas (blowing snow, ice, fog) or on approaches to tourist sites/rural transit connection facilities. • Power and backhaul communications to eld equipment (Connected Vehicle Roadside Equipment and ITS Roadway Equipment) are likely to be limited. Solar and wireless backhaul may be suitable under certain conditions. • Market penetration of OBU-equipped vehicles will inuence the eectiveness of many connected vehicle applications. For example, there needs to be sucient penetration of OBU-equipped vehicles that operate within the corridor to serve as probe vehicles. • Participation and data sharing with third-party service providers depend on acceptable value proposition and agreement. • resholds for advisory/alert and criteria are determined by original equipment manufac- turer (OEM) or vehicle application owner. • Traditional ITS is assumed to be functioning correctly as normal. e connected vehicle scenarios are intended to build on and enhance existing processes. • Geographic referencing is important to a variety of scenarios, and this may depend on the ability to translate consistently between multiple location referencing systems. 2.5 Major System Constraints is section describes any operational policies and constraints that apply to the proposed system or situation. Examples of operational constraints might include the following: • Hours of operation of the system or sta (e.g., limited services evenings, weekends, seasons). • Restrictive IT-related policies that must be followed. • Policies regarding the responsibilities of the deploying agency’s divisions that play a role in supporting connected vehicle equipment. • New agreements or modications to existing service-level agreements (SLAs) to support connected vehicle deployments and prioritize maintenance and support of the connected vehicle environment during the real-world demonstration phase. • Evaluation of Executive Sta/Agency Leadership and Legislative priorities is necessary to continue budgetary support and buy-in from decisionmakers. • Work force constraints require a careful analysis of job function changes due to the new connected vehicle deployment. • Development of clear memorandums of understanding on roles and responsibilities when collaborating with internal and external entities. • Limited access to proprietary information due to competitiveness concerns, especially when using dierent vendors. • Time and seasonal constraints for testing (e.g., having only one winter within the connected vehicle (CV) Pilot timeframe to test impact of the system on winter crashes). • Potential of adding in-vehicle distraction to drivers. • Lack reliable, cost-eective commercial power and communications services in areas within the scope of the CV Pilot. • Connected vehicle technology as well as the standards used to build the proposed system is continuously evolving. As such, system requirements (and design) will continue to evolve.

General System Description 13   2.6 Actor Characteristics is section denes the actors of the system and the roles and responsibilities of each of the users of the system. Table 2 is an example based on the proposed system context diagram (Figure 2) that includes users and stakeholders. e table should not be interpreted as a prescriptive description of the system users. States/agencies will be dierent and will need to assess their list of stakeholders. Agencies should consider updating their current organization structure/chart when revising/ tailoring their ConOps. 2.7 Assumptions and Dependencies is section details assumptions and dependencies made early in the planning stage to enable a clear denition of the proposed system. ese can include risks and opportunities for the rural agency. Examples of assumptions and dependencies include the following: • e number of connected vehicles that will be available for testing and demonstration • Connected vehicle users adhere to existing/new regulations associated with in-vehicle alerts and warnings • e penetration rate of connected vehicles and the impact this may have on the proposed system (e.g., higher number of RSUs and improved Backoce systems) U ser U ser C lass 911 Dispatchers F leet Owner Automotive OEMs Supplier Adj acent State DOT Operator City DOT Operator Cloud Providers Supplier Commercial Vehicle Operators F leet Driver Connected Vehicle Vendors Supplier Police— State and L ocal F leet Owner Event Promoters Supplier F ire and Rescue F leet Owner, Installer G eneral Public Maintainer Positioning and Timing Providers Supplier Satellite Service Providers Supplier State DOT— Operations System Owner State DOT— Maintenance Staff Maintenance SCMS Providers System Owner, Installer Third- Party Service Providers Supplier W eather Provider [ e.g., National W eather Service ( NW S) ] Supplier Table 2. Users and stakeholders.

14 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors • e role of expert sta within the agency on developing forecasts or operational strategies by segment based on the new information produced by the proposed system • Cost-eective real-time monitoring of key assets across the deployment area to support the proposed system 2.8 Operational Scenarios (or Use Cases) e operational scenarios (also called use cases) are documented in Section 6 of the model ConOps (NCHRP Research Report 978: Volume 2).