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.

32 e model ConOps and model SyRS are intended to be in support of 23 CFR 940.11 that states “All ITS projects funded with highway trust funds shall be based on a systems engineering analysis” (12) and to leverage the ARC-IT but with a focus on rural connected vehicle implementations. ese documents also specify sample use cases and build in users’ needs with requirements to directly describe the areas of improvement connected vehicles can bring to rural safety, situational awareness, and ecient trac movement. e project team was tasked with developing model ConOps and model SyRS. ese documents were based on FHWA Rule 940 and FHWA guidance. e project team used the IEEE Standard 1362–1998, IEEE Guide for Information Technology— System Denition—Concept of Operations (ConOps) Document (13), and IEEE 1233–1998 Guide for Developing System Requirements Specications (14) as templates for the model documents and tailored them for this project. ese two standards and others were harmonized in a newer standard 29148–2011: International Organization for Standardization (ISO)/International Electro- technical Commission (IEC)/IEEE International Standard, Systems and soware engineering— Life cycle processes—Requirements engineering (15) (current version is 2018). Annex A of 29148 is similar and adapted from IEEE standard 1362. Sections 5 and 8.3 of 29148 are adapted from IEEE standard 1233. Implementers are free to choose the standard that best meets their agency needs. e project team elected to use the two IEEE standards. To be consistent with existing connected vehicle deployments and U.S. DOT-funded projects, the needs are closely 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 Engi- neering Methods. 5.1 Audience and How to Use the Model Documents As model documents, ConOps and SyRS are meant to be used by rural agencies actively seeking to deploy connected vehicle technologies along their corridors. ese model documents contain information that will apply in general to most current and proposed systems and are intended to be a starting point for readers. ey address the core, common priorities and provide base docu- ments that a deploying agency can customize to t their specic project and situation. ey are not written for a specic implementation and do not address a transportation agency’s unique operations and system management. For information about the systems engineering artifacts and process beyond concept and requirements development, see the Preface of the model ConOps (NCHRP Research Report 978, Volume 2). When using the model documents, readers should pay attention to the callout boxes labeled Note to reader (see the following example). ese are used to dierentiate between C H A P T E R   5 Model Documents

Model Documents 33   “model ConOps/SyRS text” and “how to adapt the text” and to assist the reader in tailoring the model documents. Note to reader: The deficiencies or limitations of the current ITS and processes presented in this section are based on feedback from project stakeholders interviewed during the development of this report. These problems or challenges within the current environment are representative of many rural settings, but they do not represent a comprehensive list of issues all agencies experience in rural corridors. The reader is encouraged to use this information as a starting point then, to tailor/add to/delete information based on the specific agency situation. Note to reader: The key sections of this SyRS are Section 3, System Requirements; Section 4, System Interfaces; and Appendix A: Needs-to-Requirements Traceability Matrix. 5.2 Model Concept of Operations e ConOps is a foundation document that directs the technical course for the project. It is used to convey a high-level view of the system to be developed that each stakeholder can under- stand and how it will be operated and maintained. It aims to identify high-level user needs and system capabilities later used to develop the requirements of the proposed system (see Section 5.3 for an overview of the model SyRS). e ConOps document serves as the bridge between the early project motivations and the technical requirements. It is technology-independent and focuses on the functionality of the proposed system. It is important to note that a ConOps does not specify “how” but rather “what” should be achieved with a focus on the user needs, the enhancements to current practice enabled by the connected vehicles, the functionality desired to meet the user needs, and the impacts during the development phase. e primary intended audience for this ConOps document is rural trans- portation agencies that seek to deploy connected vehicle solutions for their rural corridors. 5.2.1 Model ConOps Objective and Purpose e ConOps document serves two additional purposes. e rst is to communicate the user’s needs for, and expectations of, the proposed system. ese needs provide a description of the way stakeholders desire to conduct business on a day-to-day basis. e ConOps document aims to identify high-level user needs and system capabilities that will be used to develop the require- ments of the proposed system. e ConOps document derives from extensive interviews with the stakeholders. e ConOps document development allows stakeholders to provide their input on what they want the proposed system to do. e document is the users’ document and should reect all their needs accurately. 5.2.2 Model ConOps Overview e model ConOps was developed in such a way that its sections and content are customizable so that deploying agencies can better describe the current conditions and needs, how a typical

34 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors rural agency operates and manages a rural corridor, and the proposed system and its impact. The following is a high-level overview of the sections and respective content that can be found in the model ConOps. • Scope—Provides background on the envisioned project, a high-level overview of the proposed system, and the structure of the document. • References—Provides a list of the documents and other sources of information reviewed during the development of the model ConOps and cited in it. • Current System/Situation—Defines the stakeholders, systems, and other components that are normally in place and provides readers with an introduction to the problem domain. The purpose of describing the current system and situation (i.e., how rural corridors currently operate) is to allow readers to better understand how rural agencies currently operate and the operational challenges that they face. • Justification for Change—Describes the shortcomings of the current system/situation as portrayed by the group of project stakeholders and sheds light on the motivation for incor- porating connected vehicle capabilities into their existing systems. This section will bridge the gap between the existing system (previous section) and the new features being proposed (following section). • Proposed System—Describes the proposed connected vehicle system for a rural corridor. The proposed system and text in this section are intended to serve as a model for agencies to customize to meet their specific needs. The proposed system is based on the desired changes or user needs specified in the Justification for Change section. It describes the proposed system in a high-level manner, indicating the operational features that are to be provided without speci- fying design details. This section also provides the anticipated roles and responsibilities for the many stakeholders involved in authorizing, deploying, operating, and maintaining the proposed system as well as the related staffing and resource needs. • Operational Scenarios (or Use Cases)—Identifies a selection of representative use cases that are likely to be of interest and relevance in rural corridors, as presented in Section 4.4 of this report. These use cases are not meant to comprehensively cover all possible needs in rural corridors, but rather to provide illustrative and relevant starting points for further tailoring. For example, the flows described illustrate how the system may interact with external actors and systems in the operational scenario. However, the content is not prescriptive, and multiple variations are possible. These examples can be leveraged for project-specific concept devel- opment in addressing similar needs for a specific corridor. They can also be used to assist in structuring use cases for other scenarios being targeted beyond the 10 cases that were identi- fied based on stakeholder input. The content in the use cases is focused on the new capabilities relating to connected vehicles. • Summary of Impacts—Addresses the impacts to the rural agency’s daily operations and management; internal and external organization interactions; and temporary impacts during development of the connected vehicle capabilities and integration of connected vehicles with the existing systems. • Analysis of the Proposed System—Analyzes the benefits, limitations, advantages, disadvan- tages, and alternatives and trade-offs considered for the proposed system. 5.2.3 Considerations to Use the Model ConOps The model ConOps was written to be modular so that the readers can keep/edit the informa- tion applicable to their situation/project and delete/ignore those not applicable. As such, the document is provided as an editable Microsoft Word file, with all diagrams within the document being provided through a separate Microsoft PowerPoint (PPTX) file so practitioners can easily modify them.

Model Documents 35   e project team also provides some considerations for practitioners as they begin the devel- opment of their ConOps, detailed in Table 8. ese considerations are presented as a high-level list of stakeholders and data needed to develop each section of the ConOps. It should be noted that the information provided in Table 8 is not an exhaustive list and should not be considered as a one-to-one mapping of stakeholder involved to input/data needed because this information will vary depending on the agency and on the project. 5.3 Model System Requirements Specication e SyRS is the document where the technical details for a project are formed. is docu- ment takes the user needs from the ConOps and dissects them into more detailed and specic requirements, specifying what the system (or subsystem) must do, without specifying how the system must do it. As an example, a user need may say that transportation operators need to collect, fuse, and analyze trac management data. at user need would then be broken down into multiple requirements, stating what specic types of trac management data need to be collected, what sources that data needs to be collected from, and what sources of data need to be fused for analysis. • What are the current capabilities/functions? Justification for Changes • Traffic Management System (TMS) • Maintenance • Emergency Management Center (EMC) • What are the problems the agency is trying to solve? • What are the key issues/challenges of the agency? • What are the gaps the agency needs to address? • Have the needs been prioritized? Proposed System • Rural deploying agency • External related actors (third-party service providers, other TMS operators, etc.) • Are the important users/actors and interactions included? • Are these roles and responsibilities that need to be added? Operational Scenarios (Use Cases) • Rural deploying agency • Representatives of impacted users (e.g., trucking firms for freight scenarios) • Do the use cases cover the priorities of the stakeholders? • Is sufficient detail included to understand the scenario? • Is the representation considered to capture the key features from the user view? Summary of Impacts • Rural deploying agency • Representatives of impacted users (e.g., trucking firms for freight scenarios) • Are the expected impacts captured accurately? • Are there impacts that were not considered that should be added? Analysis of the Proposed System • Rural deploying agency • Representatives of impacted users (e.g., trucking firms for freight scenarios) • Are the expected benefits worthwhile to the stakeholder? • Are the trade-offs adequately considered? • Does the proposed system provide the most promising approach? Key Section Stakeholder Involved Input/Data Needed Scope • Deploying agency project manager • Is this a new system, or will new capabilities be added to an existing system or subsystem? • Who are the actors? • What is the system of interest? • What types of use cases are within the project scope? Current System/Situation • Agency employees using the system or sending/receiving data/information to/from the system • What is the objective of the current system/situation? • What is the current operating environment? Table 8. Starting point considerations for practitioners seeking to develop a ConOps.

36 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors 5.3.1 Model SyRS Objective and Purpose The key purpose of the SyRS is to provide the specific technical requirements for the system in enough detail for the system developers and designers to design the system without constraining those designs to specific solutions and technologies. If existing system constraints require the use of specific technologies, that is acceptable; however, the goal should be to provide the system designers and developers maximum flexibility in developing technical solutions. An important aspect of the SyRS is maintaining user needs-to-requirements traceability. Every user need in the ConOps should have at least one system requirement that will address that need. Conversely, there should be no system requirements that do not trace back to at least one user need. If, during the SyRS development process, a requirement is identified that cannot logically be traced back to an existing user need, then the ConOps should be reviewed and a discussion take place as to either developing a new user need or eliminating the need for that requirement. 5.3.2 Model SyRS Overview Like the model ConOps, the model SyRS was developed with customizable sections and content. The goal of the model SyRS was to provide example system requirements that apply to a typical rural ITS system. It is recommended that these system requirements be tailored to meet the specific need of your ITS systems. The following is a high-level overview of the sections of the model SyRS: • General System Description. This section is a high-level overview and summary of informa- tion contained in the model ConOps. It is not meant to replace the ConOps. It provides context for the system requirements sections. • Functional Requirements. This section defines specific functions using different types of data that are produced, collected, broadcast, fused, or stored. The types of data elements are in Table 9. • Physical Requirements. This section describes the requirements for the physical aspects of rural connected vehicle deployment. Physical requirements generally refer to the hardware aspects of the devices or elements of the system. These requirements typically define any size constraints on a device, the environments the device must operate in, and how durable the device needs to be. • System Performance Characteristics. This section defines the performance requirements for specific aspects of the system. These include quantitative criteria covering endurance capabilities of the equipment required to meet the user needs under stipulated environmental and other conditions, including operational session duration and planned utilization rate. Performance requirements will also include time-based elements, where certain actions must be taken within a specific amount of time. • System Security. This section defines the security requirements from the connected vehicle- specific security and personally identifiable information (PII) perspective as well as from the system intrusion (hacking) perspective. The requirements in the section are more numerous and detailed than other sections to assist agencies in an area that was commonly described in agency interviews as a concern and an area of knowledge that could use augmentation with existing staff. The system security requirements in this section focus on describing those secu- rity systems specific to connected vehicle deployments. • Information Management. This section defines the system requirements for managing the data within the system. These generally cover network functions, such as network bandwidth and storage needs. • System Operations. This section defines how systems operations are managed and maintained. These requirements include how personnel will interact with the system, maintain the system, and how reliable different parts of the system need to be.

Model Documents 37   • Policy and Regulation. is section denes the policy and regulatory requirements that might dene aspects of your system. is section will likely vary the most among dierent ITS systems. • System Lifecycle Sustainment. is section describes the quality activities, such as review, measurement collection, and analysis, to realize a quality system. • System Interfaces. is section describes the dierent internal and external system interfaces. ese requirements typically reference specic standards or APIs used to interact with the specic interface. • Needs-to-Requirements Traceability Matrix (NRTM). is section is the matrix that provides traceability between all the user needs in the model ConOps and all the system requirements in the model SyRS. is is crucial to good systems engineering practices and becomes invaluable when starting the design process. 5.3.3 Considerations for Using the Model SyRS Similar to the model ConOps, the SyRS was written to be modular so that readers can keep/ edit the requirements applicable to their proposed system/project and delete/ignore those not applicable. e SyRS is also provided as an editable Microso Word le, with all diagrams within the document being provided through a separate Microso PowerPoint (PPTX) le. In addition, the NRTM is provided as a Microso Word table that can be used as a template for practitioners. Microso Excel can be used as well as commercially available requirements management tools. e latter is typically used for large, complex systems development. Key Section Stakeholder Involved Input/Data Needed Functional Requirements • TMS staff • Incident management staff • Meteorology staff • Construction staff • Traffic Conditions • W ork Z one Information • Road W eather Conditions • Incident Notification • Rural Safety • Freight Operations Physical Requirements • Construction management • Vendor staff • Meteorology staff • Construction information • Equipment durability • Equipment adaptability • Environmental conditions System Performance Characteristics • Vendor staff (OBU and RSU) • TMS staff • OBU/RSU performance specs • L og management • Message type use • Center equipment specs System Security • Security Credential Management System (SCMS) Provider staff • TMS staff • Security staff • Message signatures, timing response, encryption • Device enrollment • SCMS vendor capabilities • OBU/RSU vendor security protection support Information Management • TMS staff • Fleet partner staff • Data collection needs • Data security protection needs • Data volume requirements System Operations • TMS and Executive staff • H uman use approval • O& M staff • O& M plan • Connected vehicle equipment monitoring plan Policy and Regulation • TMC and Executive staff • FCC, SCMS, SAE standards, IEEE standards, National Transportation Communications for ITS Protocol (NTCIP) standards System L ifecycle Sustainment • OmniAir staff • TMS staff • Project management staff • Certification standards and compliance Table 9. Considerations for practitioners seeking to develop a SyRS.

38 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors The project team provides considerations for practitioners as they move from conceptualizing their potential project to defining it, as detailed in Table 9. These considerations are presented as a list of stakeholders and inputs that should be involved (or considered) in the development, valida- tion, and testing of each group of requirements. It is important to note that while each of the sections of the model SyRS was developed to apply to an average rural ITS system, deployment agencies should tailor those sections to the specific needs and details of their ITS systems. This also entails ensuring the right stakeholders assess the feasibility of specific/applicable requirements and assume their responsibilities.