National Academies Press: OpenBook
« Previous: Acronyms and Abbreviations
Page 43
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 43
Page 44
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 44
Page 45
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 45
Page 46
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 46
Page 47
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 47
Page 48
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 48
Page 49
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 49
Page 50
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 50
Page 51
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 51
Page 52
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 52
Page 53
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 53
Page 54
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 54
Page 55
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 55
Page 56
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 56
Page 57
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 57
Page 58
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 58
Page 59
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 59
Page 60
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 60
Page 61
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 61
Page 62
Suggested Citation:"Appendix - Needs-to-Requirements Traceability Matrix." National Academies of Sciences, Engineering, and Medicine. 2021. Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification. Washington, DC: The National Academies Press. doi: 10.17226/26387.
×
Page 62

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.

A-1   Needs-to-Requirements Traceability Matrix Needs-to-Requirements Traceability Matrix (NRTM) is a crucial tool for ensuring that your system requirements cover all the user needs. e development of the NRTM will quickly high- light any gaps that exist within your system requirements and allow you to address those gaps early. A best practice is to track traceability between a user need and a requirement during the initial development process. en, as the requirement base stabilizes, create the NRTM. As the systems engineering processes progress, additional traceability should be added between the requirements and system design as well as among the requirements, test cases, and test procedures. Depending on the complexity of the system, the number of requirements or the number of design elements you may need to develop a separate Requirements Traceability Matrix (RTM) or Verication Cross Reference Matrix (VCRM) to track the requirements to design and requirements to test. During the development of test plans, each requirement should be assigned a verication method, which should be tracked in these types of traceability matrices. A P P E N D I X Note to reader: During the creation of this model SyRS, the project team identified system requirements that had no user need to which they could logically be traced. These requirements dealt primarily with physical aspects of the Connected Vehicle Roadside Equipment and OBU. To remedy this gap, this document proposes adding five new user needs. Normally, this would be sent to a configuration control board, or whatever mechanism exists within your systems engineering process for change requests, for approval before these user needs would be added to the ConOps. This demonstrates the value of creating the traceability matrix, so these gaps can be addressed early when it is easier and cheaper to fix them. The final model ConOps will reflect these five new user needs. Note for the design phase: e next phase of the systems engineering process is design, followed by implementation, integration, and test. roughout these phases, the NRTM should be expanded into a RTM. e RTM should trace all requirements to design elements that are detailed in a System Design Document (SDD). Each requirement should also be traced to specic test cases/test procedures, to ensure that the system fully meets its requirements. is full lifecycle traceability is an important tool to ensure that all the user needs are ultimately met by the deployed system.

A-2 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors Table 20. Example needs-to-requirements traceability matrix. User Need ID User Need Req ID Requirement C01 The Backoffice needs the capability to collect, aggregate, and fuse near real-time traffic-conditions (e.g., speeds). FR-01.01 The OBU shall broadcast messages containing traffic-conditions data in accordance with SAE J2735 defined messages. FR-01.02 The Connected Vehicle Roadside Equipment shall collect traffic-conditions data from OBUs traveling through its coverage area. FR-01.03 The Data Collection subsystem shall collect traffic-conditions data from ITS Roadway Equipment. FR-01.04 The Data Collection subsystem shall collect traffic-conditions data from Connected Vehicle Roadside Equipment. FR-01.05 The Data Collection subsystem shall collect traffic-conditions data from Rural Agency Personnel. FR-01.06 The Data Collection subsystem shall collect traffic-conditions data from third-party service providers. FR-01.07 The Data Collection subsystem shall collect traffic-conditions data from other Traffic Management Center systems. FR-01.08 The Data Fusion subsystem shall fuse traffic-conditions data from multiple sources collected from the Data Collection subsystem. 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). FR-02.01 The Data Collection subsystem shall collect location-specific work zone data from the Maintenance Management System. FR-02.02 The Data Collection subsystem shall collect location-specific work zone data (e.g., location, lanes) from Rural Agency Personnel (rural work zone crew). FR-02.03 The Data Collection subsystem shall collect location-specific work zone data from other Traffic Management Center systems. FR-02.06 The Data Fusion subsystem shall fuse work zone data from multiple sources collected from the Data Collection subsystem. FR-02.09 The Decision Support subsystem shall retrieve stored fused work zone data for dissemination. C03 The Backoffice needs the capability to collect, aggregate, and fuse near real-time incident information (e.g., location, severity). FR-04.01 OBUs shall broadcast a DN when they have been involved in an incident. FR-04.02 OBUs shall store DNs received from other OBUs until broadcast to Connected Vehicle Roadside Equipment. FR-04.03 OBUs shall send DNs to Connected Vehicle Roadside Equipment when the DN service is advertised. FR-04.04 Connected Vehicle Roadside Equipment shall collect DNs from OBUs. FR-04.05 Connected Vehicle Roadside Equipment shall collect incident data from OBUs. FR-04.06 The Data Collection subsystem shall collect incident data from ITS Roadway Equipment. FR-04.07 The Data Collection subsystem shall collect DN data from Connected Vehicle Roadside Equipment. FR-04.08 The Data Collection subsystem shall collect incident data from Connected Vehicle Roadside Equipment. FR-04.11 The Data Fusion subsystem shall fuse DN data and incident data. C04 The Backoffice needs the capability to collect, aggregate, and fuse accurate, near real-time and location-specific environmental and road weather data. FR-03.01 The OBU shall broadcast messages containing road weather data in accordance with SAE J2735 defined messages. FR-03.02 The Connected Vehicle Roadside Equipment shall collect road weather data from OBUs traveling through its predetermined geographic coverage area. FR-03.04 The Data Collection subsystem shall collect road weather data corresponding to configurable geographic coverage area from Weather Service System. FR-03.05 The Data Collection subsystem shall collect road weather data from ITS Roadway Equipment. ITS Roadway Equipment may include environmental sensing stations. FR-03.06 The Data Collection subsystem shall collect road weather data corresponding to predetermined geographic coverage areas from third-party service providers. FR-03.07 The Data Collection subsystem shall collect reported road weather data from Connected Vehicle Roadside Equipment. FR-03.08 The Data Collection subsystem shall collect road weather data corresponding to predetermined geographic coverage areas from other Traffic Management Center systems. The data collected could be from an agency RWIS. FR-03.11 The Data Fusion subsystem shall fuse weather data from multiple sources collected from the Data Collection subsystem. FR-03.12 The Data Storage subsystem shall store fused road weather data. EIR-01 The interface between the Backoffice system and the NWS shall be in accordance with the NWS API Web Service. C05 The Backoffice needs the capability to collect, aggregate, and fuse information about freight-related events (e.g., runaway truck, bridge hit, etc.). FR-04.09 The Data Collection subsystem shall collect incident data from third-party service providers. FR-04.10 The Data Collection subsystem shall collect incident data from the Cloud. FR-04.14 The Data Dissemination subsystem shall provide fused DN and incident information to the Maintenance Management System.

Needs-to-Requirements Traceability Matrix A-3   Table 20. (Continued). User User Req ID Requirement The Backoffice needs the capability to analyze and act on traffic conditions (e.g., speeds). FR-01.10 The Decision Support subsystem shall analyze stored traffic-conditions data to determine if a traffic event is occurring. FR-01.11 The Data Dissemination subsystem shall send traffic event information to Connected Vehicle Roadside Equipment. FR-01.12 The Data Dissemination subsystem shall send traffic event information to ITS Roadway Equipment. FR-01.13 The Data Dissemination subsystem shall send traffic event information to third-party providers. FR-01.14 The Data Dissemination subsystem shall send traffic event information to other Traffic Management Center systems. FR-01.15 Connected Vehicle Roadside Equipment shall send traffic event information to OBUs utilizing SAE C06 J2735 defined messages. FR-01.16 The OBU shall be capable of receiving traffic event information in SAE J2735 defined messages. FR-01.17 The OBU shall present traffic event information to the driver. FR-02.16 The OBU shall be capable of receiving work zone information in SAE J2735 defined messages. FR-05.04 The OBU shall be capable of receiving rural safety information in SAE J2735 defined messages. C07 The Backoffice needs the capability to analyze and act on work zone data (e.g., location, lanes affected). FR-02.08 The Decision Support subsystem shall analyze stored work zone data to determine if the current work zone information needs to be updated. FR-02.10 The Decision Support subsystem shall send updated work zone information to the Data Dissemination subsystem. FR-02.12 The Data Dissemination subsystem shall send work zone information to Connected Vehicle Roadside Equipment. FR-02.13 The Data Dissemination subsystem shall send work zone information to ITS Roadway Equipment. FR-02.14 The Data Dissemination subsystem shall send work zone information to other Traffic Management Center systems. FR-02.17 The OBU shall present work zone information to the driver. FR-05.05 The OBU shall present rural safety information to the driver. C08 The Backoffice needs the capability to analyze and act on incident information. FR-04.13 The Decision Support subsystem shall analyze fused DN and incident data to determine where an incident has occurred. FR-04.15 The Data Dissemination subsystem shall provide incident information to Emergency Management/Public Safety System. C09 The Backoffice needs improved capability to analyze and act on accurate, timely, and location-specific environmental and road weather data. FR-02.15 Connected Vehicle Roadside Equipment shall send work zone information to OBUs utilizing SAE J2735 defined messages. FR-03.13 The Decision Support subsystem shall analyze stored road weather data to determine if a road weather event is occurring. FR-03.14 The Data Dissemination subsystem shall send road weather event information to Connected Vehicle Roadside Equipment. FR-03.15 The Data Dissemination subsystem shall send road weather event information to third-party service providers and SSPs. FR-03.16 The Data Dissemination subsystem shall send road weather event information to ITS Roadway Equipment. FR-03.17 The Data Dissemination subsystem shall send road weather event information to other Traffic Management Center systems. FR-03.18 Connected Vehicle Roadside Equipment shall broadcast road weather event information to OBUs utilizing SAE J2735 defined messages. FR-03.19 The Cloud shall provide OBU-equipped vehicles with relevant road weather advisories/diversions. C10 The Backoffice needs improved capability to analyze and act on information about freight-related events (e.g., runaway truck, bridge hit event). FR-04.13 The Decision Support subsystem shall analyze fused DN and incident data to determine where an incident has occurred. FR-04.14 The Data Dissemination subsystem shall provide fused DN and incident information to the Maintenance Management System. FR-04.16 The Data Dissemination subsystem shall provide fused DN and incident information to the Fleet and Freight Management System. 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). FR-06.03 The Data Collection subsystem shall collect freight operations data from the Maintenance Management System. FR-06.04 The Data Collection subsystem shall collect freight operations data from Rural Agency Personnel. FR-06.07 The Data Collection subsystem shall collect freight operations data from Connected Vehicle Roadside Equipment. FR-06.09 The Data Storage subsystem shall store freight operations data. FR-06.11 The Data Dissemination subsystem shall send freight operations information to the Cloud. Need ID Need (continued on next page)

A-4 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors Table 20. (Continued). User User Req ID Requirement FR-06.14 Connected Vehicle Roadside Equipment shall broadcast freight operations information to OBUs utilizing SAE J2735 defined messages. FR-06.15 The Cloud shall send freight operations information to OBUs. C12 The Data Storage System needs to be able to store data collected from the Connected Vehicle System, Other Systems, and Field Devices. FR-01.09 The Data Storage subsystem shall store fused traffic-conditions data. FR-02.07 The Data Storage subsystem shall store fused work zone data. FR-04.12 The Data Storage subsystem shall store the fused DN and incident data. C13 The Data Storage System needs to provide an interface for configuring and controlling how data is stored. IMR-17 The Backoffice system shall provide an interface for configuring all of the subsystems that reside within it including Data Collection, Device Control and Monitoring, Data Storage, Data Fusion, Data Dissemination, Decision Support Systems. C14 The Maintenance Management System needs to be able to receive road condition data (e.g., incident, road weather, freight-related info, wildlife detection). FR-02.11 The Data Dissemination subsystem shall send work zone information to the Maintenance Management System. FR-03.20 The Decision Support subsystem shall analyze fused road weather data and send recommended road weather maintenance actions to the Maintenance Management System. FR-03.21 The Data Dissemination subsystem shall send location-specific road weather event information to the Maintenance Management System. C15 The Maintenance Management System needs the capability to provide accurate and timely data (e.g., construction/work zone, road weather data) to the Backoffice. FR-03.09 The Data Collection subsystem shall collect location-specific road weather data from the Maintenance Management System. FR-03.10 The Data Collection subsystem shall collect location-specific treatment actions and plans from the Maintenance Management System. C16 Traveler Information System needs the capability to receive fused data and information from the Backoffice. FR-03.22 The Data Dissemination subsystem shall send location-specific road weather event information to the Traveler Information System. FR-06.16 The Data Dissemination subsystem shall provide freight operations information to the Traveler Information System. C17 Traveler Information System needs the capability to provide accurate and timely data and information (e.g., alerts, advisories) to the Backoffice. FR-06.05 The Data Collection subsystem shall collect freight operations data from the Traveler Information System. FR-06.06 The Data Collection subsystem shall collect freight operations data from other Traffic Management Center systems. FR-06.10 The Data Dissemination subsystem shall send freight operations information to Connected Vehicle Roadside Equipment. C18 The Emergency Management/Public Safety System needs the capability to receive fused traffic-conditions data (e.g., incident, road weather, freight-related events, wildlife detection). FR-03.23 The Data Dissemination subsystem shall send location-specific road weather event information to the Emergency Management/Public Safety System. FR-05.01 Connected Vehicle Roadside Equipment shall collect rural safety data from ITS Roadway Equipment. FR-05.02 Connected Vehicle Roadside Equipment shall collect rural safety data from Mobile Units (pedestrian/bicycle devices that send PSMs). FR-05.03 Connected Vehicle Roadside Equipment shall broadcast rural safety information utilizing SAE J2735 messages. C19 The Emergency Management/Public Safety System needs the capability to provide incident information data to the Backoffice (e.g., location, severity, types of vehicles involved). FR-04.17 The Data Collection subsystem shall collect incident data from Emergency Management/Public Safety System. C20 Other Jurisdiction TMSs need the capability to receive fused data and information (e.g., road or lanes closure, adverse weather, seasonal events) from the Backoffice. FR-01.14 The Data Dissemination subsystem shall send traffic event information to other Traffic Management Center systems. FR-02.14 The Data Dissemination subsystem shall send work zone information to other Traffic Management Center systems. FR-03.17 The Data Dissemination subsystem shall send road weather event information to other Traffic Management Center systems. C21 Other Jurisdiction TMSs need the capability to provide accurate and timely data and information to the Backoffice, especially as it relates to closures, adverse weather, seasonal events, and tourist locations for rural areas with limited situational awareness. FR-01.07 The Data Collection subsystem shall collect traffic-conditions data from other Traffic Management Center systems. FR-02.03 The Data Collection subsystem shall collect location-specific work zone data from other Traffic Management Center systems. Need ID Need

Needs-to-Requirements Traceability Matrix A-5   Table 20. (Continued). User User Req ID Requirement FR-03.08 The Data Collection subsystem shall collect road weather data corresponding to predetermined geographic coverage areas from other Traffic Management Center systems. The data collected could be from an agency RWIS. C22 The Weather Service System needs the capability to provide accurate and timely data and information (e.g., air temperature, humidity, precipitation, visibility) about areas prone to fast-changing conditions, such as fog, whiteouts, sandstorms to the Backoffice. FR-03.06 The Data Collection subsystem shall collect road weather data corresponding to predetermined geographic coverage areas from third-party service providers. C23 Fleet and Freight Management System needs the capability to receive data and information fused from the Backoffice. FR-03.24 The Data Dissemination subsystem shall make location-specific road weather event information available to Fleet and Freight Management System. FR-06.08 The Data Collection subsystem shall collect freight operations data from Fleet and Freight Management System. FR-06.12 The Data Dissemination subsystem shall send freight operations information to Fleet and Freight Management Systems. C24 Event Promoters need to provide event information (e.g., date, time, estimated duration, location, and any other information pertinent to traffic movement in the surrounding area) to the Backoffice. FR-02.04 The Data Collection subsystem shall collect work zone data from event promoters. C25 Third-Party Providers need the capability to receive traffic and travel conditions from the Backoffice system. FR-03.25 The Data Dissemination subsystem shall send road weather data and conditions to third-party service providers for locations of interest. FR-06.13 The Data Dissemination subsystem shall send freight operations information to third-party service providers. C26 Third-Party Providers need to provide traffic data to the Backoffice. FR-01.06 The Data Collection subsystem shall collect traffic-conditions data from third-party service providers. F01 ITS Roadway Equipment needs to receive traffic monitoring data (e.g., preemption, priority signal) from the Backoffice and the Connected Vehicle. FR-03.03 The Connected Vehicle Roadside Equipment shall collect road weather data from OBUs installed on agency DOT construction and maintenance vehicles in accordance with SAE J2735 messages. FR-06.02 Connected Vehicle Roadside Equipment shall collect freight operations data from OBUs. FR-01.12 The Data Dissemination subsystem shall send traffic event information to ITS Roadway Equipment. SPR-13 Connected Vehicle Roadside Equipment shall interface with signal controllers, vehicles, and pedestrians. (Note: Details will be defined in the design phase.) F02 ITS Roadway Equipment needs to provide an interface for Backoffice to gather traffic and environmental data (e.g., signal phase, road condition). FR-02.05 The Data Collection subsystem shall collect work zone data from the Connected Vehicle Roadside Equipment. FR-01.03 The Data Collection subsystem shall collect traffic-conditions data from ITS Roadway Equipment. AP01 Rural Agency Personnel need the capability to receive accurate, timely, and location-specific information to support operation and management of the rural corridor (e.g., plan incident response quicker, implement traffic management strategies, set up geofencing for work zones). FR-03.26 The Data Dissemination subsystem shall send road weather event information to Rural Agency Personnel. AP02 Rural Agency Personnel need the capability to analyze, control, and configure data and information. FR-03.27 The Data Dissemination subsystem shall configure the dissemination flows based on Rural Agency Personnel selection. FR-03.28 The Data Dissemination subsystem shall configure the data presentation (level of detail) based on Rural Agency Personnel selection. SPR-06 The OBU shall log vehicle operational data (e.g., hard break, steering turns, accelerations based on accelerometers). (Note: Details will be defined in the design phase.) SPR-07 The OBU shall log vehicle performance measures data (e.g., driver alerts, BSM history, message reception, etc.). (Note: Details will be defined in the design phase.) SPR-07.1 The OBU shall retain a rolling log with the last 10 seconds history of sent BSMs at 10 Hz. SPR-07.2 The OBU shall retain a rolling log with the last 10 seconds history of received BSMs at 10 Hz. SPR-07.3 Each BSM log entry shall identify the BSM as a local or remote vehicle. SPR-07.4 Each driver alert log shall include 10 seconds before the alert for the local vehicle BSMs at 10 Hz. SPR-07.5 Each driver alert log shall include 10 seconds before the alert for the remote vehicle BSMs at 10 Hz. SPR-07.6 For the first 60 seconds duration of driver alerts, the OBU shall log local BSMs at 10 Hz. SPR-07.7 For the first 60 seconds duration of driver alerts, the OBU shall log remote BSMs at 10 Hz. SPR-07.8 For driver alerts lasting beyond 60 seconds, after the first 60 seconds, local BSM logging shall log at 1 Hz. SPR-07.9 For driver alerts lasting beyond 60 seconds, after the first 60 seconds, remote BSM logging shall log at 1 Hz. SPR-07.10 After a driver alert ends, the OBU shall log 10 seconds of local and remote BSMs at 10 Hz. SPR-07.11 Each OBU log entry shall include a UTC stamp accurate to 10 milliseconds. SPR-07.12 The OBU shall log each MAP from the nearest RSU. SPR-07.13 The OBU shall log each SPaT from the nearest RSU. Need ID Need (continued on next page)

A-6 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors Table 20. (Continued). User User Req ID Requirement SPR-07.14 The OBU shall log each TIM from the nearest RSU. SPR-07.15 The OBU shall log each PDM from the nearest RSU. SPR-08 The OBU shall monitor the delivery of audio alerts to the driver. (Note: Monitor delivery of audio alerts is intended to be a system that can listen for the audio alert and verify the correct alert is heard. This is to ensure the speaker is operational and at an appropriate volume to overcome ambient noise.) SPR-09 The OBU shall include an accelerometer for each of the three axes. SPR-10 The OBU shall continuously update its location as described in SAE J2945/1. SPR-11 The OBU shall be able to upload event logs through an RSU when the service is available to the Backoffice. SPR-15 Connected Vehicle Roadside Equipment shall log all received BSMs at a rate configurable by the Device Control and Monitoring system up to 10 Hz. SPR-16 Each Connected Vehicle Roadside Equipment log entry shall include a UTC stamp accurate to 10 milliseconds. SPR-17 Connected Vehicle Roadside Equipment shall send logs to the Backoffice every 5 minutes. IIR-01 The interface between the Backoffice system and signal controllers shall be in accordance with NTCIP 1202 v3a. IIR-02 The interface between the Backoffice system and DMSs shall be in accordance with NTCIP 1203 v3. IIR-03 The interface between the Backoffice system and environmental sensor systems shall be in accordance with NTCIP 1204 v3. IIR-04 The interface between the Backoffice system and Connected Vehicle Roadside Equipment shall be in accordance with NTCIP 1218 v1. SE01 The Backoffice needs to provide mechanisms for securing transportation systems communications between devices. IMR-01 The system shall protect participan ’ personal information including name, address, vehicle make/model, driver’ license number at a minimum. IMR-02 Personal information collected when registering participants shall be electronically stored separately from connected vehicle data (i.e., BSMs, alerts). IMR-03 Personal data access shall require a login with password protection. IMR-04 PII shall be removed from data before data is released to any public data exchange. IMR-05 Data (i.e., BSMs) generated and received by vehicles (i.e., OBUs) shall be stored on a storage device connected locally to the vehicle. IMR-06 Messages (i.e., alerts) transmitted and received by RSUs shall be stored on a storage device connected locally to the RSU. IMR-07 Data locally stored on OBUs shall be transmitted wirelessly to RSUs through a secure communications connection. IMR-08 Data locally stored on RSUs shall be transmitted to the Backoffice through a secure communications connection. IMR-09 The frequency at which data locally stored on OBUs is transmitted to the Backoffice shall be determined by the ability of those devices to transmit the data wirelessly. IMR-10 The frequency at which data locally stored on RSUs is transmitted to the Backoffice shall be determined based on the RSUs’ storage capacity. IMR-11 The Backoffice shall securely archive the system-generated data to protect against a single point of failure. IMR-12 Access to the Backoffice shall require a login and password. IMR-13 Access to the Backoffice shall be limited to authorized personnel. IMR-14 ITS Roadway Equipment shall allow remote configuration from authorized users at the Traffic Management Center. SSR-90 ITS Roadway Equipment communications shall be developed to meet FIPS 140-2 Level 2 or equivalent. SSR-91 New field cabinets shall include tamper alerts. SSR-92 New field cabinet tamper alerts shall be sent to the TMC when the tamper seal is broken. SSR-93 ITS Roadside Equipment devices shall support remote authenticated access. SSR-94 Connected Vehicle datasets shall be required to have PII information removed before data is made publicly available. [Note to agency: Connected vehicle datasets may contain PII (BSM around home/work, installation documentation, driver identification for training, etc. When this is the case, precautions should be taken to ensure this is protected from unauthorized exposure.)] SSR-95 Monitoring systems shall be enabled and used to perform intrusion detection for connected vehicle systems. SSR-96 Monitoring systems for connected vehicle systems shall be enabled and used to detect abnormal unauthorized activity on an IP connection. SSR-97 All participant data for the connected vehicle implementation shall be encrypted with minimum standards, password-protected, and maintained separately from the application and performance measurement data (separate systems, login, and user access, at a minimum). SSR-98 No person shall transfer connected vehicle PII information in an unencrypted state. SE02 The Backoffice needs to provide interfaces for securing connected vehicle communications. SSR-34 All cryptographic software and firmware shall be developed using best practices. (Note to agency: This should come with a certificate of compliance from the vendor.) Need ID Need

Needs-to-Requirements Traceability Matrix A-7   Table 20. (Continued). User User Req ID Requirement SSR-34.01 All cryptographic software shall be managed in a form that protects software from unauthorized disclosure and/or modification. (Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) SSR-34.02 All cryptographic firmware shall be managed in a form that protects firmware from unauthorized disclosure and/or modification. (Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) SSR-35 The HSM shall be certified by one of the approved certification entities or if they are not available, the HSM shall be self-certified by the vendor at a minimum. SSR-36 A cryptographic mechanism using an approved integrity technique shall be applied to all cryptographic software and firmware components within the HSM. SSR-37 If the HSM itself calculates the Message Authentication Code when the software is installed using a secret key known only to the HSM and uses this secret key to verify the software on boot or if the software provider has a unique shared key with each distinct device and uses this to authenticate the software, the message authentication code shall be used. SSR-38 A Message Authentication Code shall not be used to protect the software unless the Message Authentication Code key is unique to the HSM. SSR-39 Cryptographic information shall be managed based on FIPS 140-2. (Note to agency: Here are some specific items to consider with cryptographic information assembled by the THEA CV Pilot. Cryptographic software and firmware, cryptographic keys, and control and status information shall be under the control of an OS that meets the functional requirements specified in the Protection Profiles listed in FIPS 140-2 Annex B and is capable of evaluation at the CC EAL2, or an equivalent trusted OS.) SSR-40 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can execute stored cryptographic software and firmware. SSR-41 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authent ication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can modify (i.e., write, replace, and delete) the following cryptographic module software or firmware components stored within the cryptographic boundary: cryptographic programs and cryptographic data. SSR-42 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can read the following cryptographic software components stored within the cryptographic boundary: cryptographic data. SSR-43 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can execute stored cryptographic software and firmware. SSR-44 The OS shall prevent all operators without the appropriate permissions (i.e., non-system admin) and executing processes from modifying executing cryptographic processes (i.e., loading and executing cryptographic program images). SSR-45 The OS shall prevent operators without the appropriate permissions (i.e., non-system admin) and executing processes from reading cryptographic software stored within the cryptographic boundary. SSR-46 The HSM shall maintain two roles: User, who can execute software and firmware, write and delete cryptographic keys, and install signed software and firmware, and Security Officer, who can install unsigned software and firmware in the event that specialized new software or firmware is being tested and troubleshot. SSR-47 Activities carried out by the User role shall not be explicitly authenticated, once the User role has successfully logged in. SSR-48 In a networked architecture that includes the host processor, other processors, and the HSM, the host processor shall authenticate itself to the HSM with an authentication mechanism based in hardware with the same physical security as the HSM. SE03 OBUs need to be able to connect to a SCMS to replenish their security certificates, update their CRL, and report misbehavior. PRC-24 All OBUs shall have a FIPS 140-2 level 2 HSM for key storage. SSR-01 The connected vehicle environment shall have mechanisms for identifying misbehaving devices and minimizing misbehaving devices' impact on connected vehicle communications. SSR-01.01 Connected Vehicle Roadside Equipment and OBUs shall detect misbehaving devices as defined in the List of Misbehaviors File found at https://github.com/Noblis/Misbehavior-Detection. SSR-01.02 Connected Vehicle Roadside Equipment and OBUs shall report misbehaving devices to the SCMS via the mechanisms described in Misbehavior Report and Application Specification for Connected Vehicle Pilot Deployment found at https://github.com/Noblis/Misbehavior-Detection. SSR-01.03 Connected Vehicle Roadside Equipment and OBUs shall download CRLs from the SCMS. SSR-01.04 Connected Vehicle Roadside Equipment and OBUs shall use their CRLs to validate signed connected vehicle messages. SSR-02 Each connected vehicle device shall verify received messages per IEEE 1609.2 and per the relevant security profiles before using them for operations in any application. Need ID Need (continued on next page)

A-8 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors User User Req ID Requirement SSR-03 Each connected vehicle device shall not create or transmit messages for any usage scenario if the usage scenario requires it to use 1609.2 certificates, and it does not currently have valid certificates for that usage scenario. SSR-04 A device shall verify a connected vehicle message when any of the following conditions is met: a) A device identifies the message as containing a new DE_TemporaryID value. b) The message results in the issuance of an advisory, warning, or alert. c) The remote vehicle constitutes a potential threat (define potential threat as a vehicle that may collide with the host vehicle based on both vehicle’ peeds and trajectories). d) The host vehicle constitutes a threat to a pedestrian using a connected vehicle equipped PID. e) Other potential threat situations such as infrastructure size restrictions, speed compliance, red-light violations, and other safety applications. SSR-05 All WAVE devices (i.e., PID, OBU, RSU) shall comply with IEEE 1609.2: Standard for WAVE— Security Services for Applications and Management Messages. SSR-06 The host processor and its operating software shall be delivered in an operational state. (Note to agency: The devices will go through many revisions in a project, and it is important to get devices from vendors with support for OTA updates and in a functional state. THEA created additional details about this requirement in the Security Management Operating Concept sections THEA-SEC-034 through THEA-SEC-051.) SSR-07 The host processor and its operating software shall be delivered such that required security protections are implemented. (Note to agency: When devices are enrolled in the SCMS, security protections are required.) SSR-08 If the host processor is initialized in a manufacturing state, the required protections shall not be required. (Note to agency: If the devices are not enrolled in the SCMS, security protections are not required.) SSR-09 Any WAVE devices designed so they can return from the operating state to the manufacturing state shall wipe all privileged applications from the processor and all keys as part of the transition. SSR-10 The host processor and its operating software shall perform an integrity check on boot. SSR-11 If the host processor and its operating software determine there is an error during the integrity check, it shall not continue. SSR-11.01 If the host processor and its operating software determine there is an error during the integrity check, it shall log the error. SSR-12 The host processor integrity checks shall require the use of a hardware-protected value. SSR-13 The host processor shall not allow any privileged application to request digital signing until the integrity checks have passed. SSR-14 If the host processor fails the integrity checks, it shall not grant access for any process to private keys. SSR-15 If the host processor fails the integrity checks, it shall not allow any privileged application to operate. SSR-16 The host processor shall conduct an integrity check to ensure that stored root CA certificates have not been modified since they were last accessed. SSR-17 If the integrity check fails, the device shall reject all incoming signed messages that chain back to those root CA certificates as invalid. SSR-18 The discretionary access control mechanisms of the host processor OS shall be configured to specify the set of roles that has execute permissions on each private key stored within the HSM. SSR-19 The discretionary access control mechanisms of the host processor OS shall be configured to specify the set of roles that can modify (i.e., write, replace, and delete) the keys within the host processor boundary. SSR-20 The discretionary access control mechanisms of the host processor OS shall be configured to specify the set of roles that can read data stored within the host processor boundary. SSR-20.01 The discretionary access control mechanisms of the host processor OS shall be configured to specify which data can be read by each role. SSR-21 The discretionary access control mechanisms of the host processor OS shall be configured to specify the set of roles that can enter cryptographic keys. SSR-22 The host processor OS shall allow processes that correspond to privileged applications to operate without explicit authentication by a user. SSR-23 The host processor OS shall allow processes that update private key material within the HSM to operate without explicit authentication by a user. SSR-24 The host processor OS shall allow processes to install new software or firmware if that software or firmware is signed by the original developer/manufacturer. SSR-25 The host processor OS shall allow processes to write private key material to the HSM. SSR-26 The host processor OS shall require explicit authentication for processes that modify or inspect executing processes. SSR-27 The OS shall not allow processes that read private cryptographic key material from the HSM. SSR-28 The host processor shall require that all software installed be signed by a root of trust contained in the HSM. SSR-29 The integrity of the verification key shall be protected by HSM. SSR-30 The host processor shall require that software be installed only by an authenticated user. Need ID Need Table 20. (Continued).

Needs-to-Requirements Traceability Matrix A-9   User User Req ID Requirement SSR-31 The vendor-supplied update mechanism for the host processor shall include mechanisms to prevent updates from being rolled back. SSR-32 If an update fails, the host processor shall notify the update mechanism of the failure. SSR-33 If the update mechanism receives an update failure, it shall publish a notification of the failure and request authorization to instruct the host processor to roll back. SSR-34 All cryptographic software and firmware shall be developed using best practices. (Note to agency: This should come with a certificate of compliance from the vendor.) SSR-34.01 All cryptographic software shall be managed in a form that protects software from unauthorized disclosure and/or modification. (Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) SSR-34.02 All cryptographic firmware shall be managed in a form that protects firmware from unauthorized disclosure and/or modification. (Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) SSR-35 The HSM shall be certified by one of the approved certification entities or if they are not available, the HSM shall be self-certified by the vendor at a minimum. SSR-36 A cryptographic mechanism using an approved integrity technique shall be applied to all cryptographic software and firmware components within the HSM. SSR-37 If the HSM itself calculates the Message Authentication Code when the software is installed using a secret key known only to the HSM and uses this secret key to verify the software on boot or if the software provider has a unique shared key with each distinct device and uses this to authenticate the software, the message authentication code shall be used. SSR-38 A Message Authentication Code shall not be used to protect the software unless the Message Authentication Code key is unique to the HSM. SSR-39 Cryptographic information shall be managed based on FIPS 140-2. (Note to agency: Here are some specific items to consider with cryptographic information assembled by the THEA CV Pilot. Cryptographic software and firmware, cryptographic keys, and control and status information shall be under the control of an OS that meets the functional requirements specified in the Protection Profiles listed in FIPS 140-2 Annex B and is capable of evaluation at the CC EAL2, or an equivalent trusted OS.) SSR-40 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can execute stored cryptographic software and firmware. SSR-41 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can modify (i.e., write, replace, and delete) the following cryptographic module software or firmware components stored within the cryptographic boundary: cryptographic programs and cryptographic data. SSR-42 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can read the following cryptographic software components stored within the cryptographic boundary: cryptographic data. SSR-43 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can execute stored cryptographic software and firmware. SSR-44 The OS shall prevent all operators without the appropriate permissions (i.e., non-system admin) and executing processes from modifying executing cryptographic processes (i.e., loading and executing cryptographic program images). SSR-45 The OS shall prevent operators without the appropriate permissions (i.e., non-system admin) and executing processes from reading cryptographic software stored within the cryptographic boundary. SSR-46 The HSM shall maintain two roles: User, who can execute software and firmware, write and delete cryptographic keys, and install signed software and firmware, and Security Officer, who can install unsigned software and firmware in the event that specialized new software or firmware is being tested and troubleshot. SSR-47 Activities carried out by the User role shall not be explicitly authenticated, once the User role has successfully logged in. SSR-48 In a networked architecture that includes the host processor, other processors, and the HSM, the host processor shall authenticate itself to the HSM with an authentication mechanism based in hardware with the same physical security as the HSM. SSR-49 If the OBU determines that it has been blacklisted, it shall cease transmission of BSMs. SSR-50 The OBU shall prevent incoming messages with invalid conditions from being acted on per criteria in the IEEE 1609.2. SSR-51 The OBU shall carry out misbehavior checking on the remote vehicle BSM data. SSR-65 The SCMS API shall track the expected expiry times of OBU enrollment certificates. SSR-66 Communication between the OBU and the SCMS shall operate in an encrypted, end-to-end connection in accordance with the published SCMS interface. Need ID Need Table 20. (Continued). (continued on next page)

A-10 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors Table 20. (Continued). User User Req ID Requirement SE04 RSUs need to be able to connect to a SCMS to replenish their security certificates, update their CRLs, and report misbehavior. PRC-25 All RSUs shall have a FIPS 140-2 level 2 HSM for key storage. SSR-01 The connected vehicle environment shall have mechanisms for identifying misbehaving devices and minimizing misbehaving devices' impact on connected vehicle communications. SSR-01.01 Connected Vehicle Roadside Equipment and OBUs shall detect misbehaving devices as defined in the List of Misbehaviors File found at: https://github.com/Noblis/Misbehavior-Detection. SSR-01.02 Connected Vehicle Roadside Equipment and OBUs shall report misbehaving devices to the SCMS via the mechanisms described in Misbehavior Report and Application Specification for CV Pilot Deployment found at https://github.com/Noblis/Misbehavior-Detection. SSR-01.03 Connected Vehicle Roadside Equipment and OBUs shall download CRLs from the SCMS. SSR-01.04 Connected Vehicle Roadside Equipment and OBUs shall use their CRLs to validate signed connected vehicle messages. SSR-02 Each connected vehicle device shall verify received messages per IEEE 1609.2 and per the relevant security profiles before using them for operations in any application. SSR-03 Each connected vehicle device shall not create or transmit messages for any usage scenario if the usage scenario requires it to use 1609.2 certificates, and it does not currently have valid certificates for that usage scenario. SSR-04 A device shall verify a connected vehicle message when any of the following conditions is met: a) A device identifies the message as containing a new DE_TemporaryID value. b) The message results in the issuance of an advisory, warning, or alert. c) The remote vehicle constitutes a potential threat (define potential threat as a vehicle that may collide with the host vehicle based on both vehicle’ peeds and trajectories). d) The host vehicle constitutes a threat to a pedestrian using a connected vehicle equipped PID. e) Other potential threat situations such as infrastructure size restrictions, speed compliance, red-light violations, and other safety applications. SSR-05 All WAVE devices (i.e., PID, OBU, RSU) shall comply with IEEE 1609.2: Standard for WAVE— Security Services for Applications and Management Messages. SSR-06 The host processor and its operating software shall be delivered in an operational state. (Note to agency: The devices will go through many revisions in a project and it is important to get devices from vendors with support for OTA updates and in a functional state. THEA created additional details about this requirement in the Security Management Operating Concept sections THEA-SEC-034 through THEA-SEC-051.) SSR-07 The host processor and its operating software shall be delivered such that required security protections are implemented. (Note to agency: When devices are enrolled in the SCMS, security protections are required.) SSR-08 If the host processor is initialized in a manufacturing state, the required protections shall not be required. (Note to agency: If the devices are not enrolled in the SCMS, security protections are not required.) SSR-09 Any WAVE device designed so they can return from the operating state to the manufacturing state shall wipe all privileged applications from the processor and all keys as part of the transition. SSR-10 The host processor and its operating software shall perform an integrity check on boot. SSR-11 If the host processor and its operating software determine there is an error during the integrity check, it shall not continue. SSR-11.01 If the host processor and its operating software determine there is an error during the integrity check, it shall log the error. SSR-12 The host processor integrity checks shall require the use of a hardware-protected value. SSR-13 The host processor shall not allow any privileged application to request digital signing until the integrity checks have passed. SSR-14 If the host processor fails the integrity checks, it shall not grant access for any process to private keys. SSR-15 If the host processor fails the integrity checks, it shall not allow any privileged application to operate. SSR-16 The host processor integrity check shall carry out a check that stored root CA certificates have not been modified since they were last accessed. SSR-17 If the integrity check fails, the device shall reject all incoming signed messages that chain back to those root CA certificates as invalid. SSR-18 The discretionary access control mechanisms of the host processor OS shall be configured to specify the set of roles that has execute permissions on each private key stored within the HSM. SSR-19 The discretionary access control mechanisms of the host processor OS shall be configured to specify the set of roles that can modify (i.e., write, replace, and delete) the keys within the host processor boundary. SSR-20 The discretionary access control mechanisms of the host processor OS shall be configured to specify the set of roles that can read data stored within the host processor boundary. SSR-20.01 The discretionary access control mechanisms of the host processor OS shall be configured to specify which data can be read by each role. Need ID Need

Needs-to-Requirements Traceability Matrix A-11   Table 20. (Continued). User User Req ID Requirement SSR-21 The discretionary access control mechanisms of the host processor OS shall be configured to specify the set of roles that can enter cryptographic keys. SSR-22 The host processor OS shall allow processes that correspond to privileged applications to operate without explicit authentication by a user. SSR-23 The host processor OS shall allow processes that update private key material within the HSM to operate without explicit authentication by a user. SSR-24 The host processor OS shall allow processes to install new software or firmware if that software or firmware is signed by the original developer/manufacturer. SSR-25 The host processor OS shall allow processes to write private key material to the HSM. SSR-26 The host processor OS shall require explicit authentication for processes that modify or inspect executing processes. SSR-27 The OS shall not allow processes that read private cryptographic key material from the HSM. SSR-28 The host processor shall require that all software installed be signed by a root of trust contained in the HSM. SSR-29 The integrity of the verification key shall be protected by HSM. SSR-30 The host processor shall require that software be installed only by an authenticated user. SSR-31 The vendor-supplied update mechanism for the host processor shall include mechanisms to prevent updates from being rolled back. SSR-32 If an update fails, the host processor shall notify the update mechanism of the failure. SSR-33 If the update mechanism receives an update failure, it shall publish a notification of the failure and request authorization to instruct the host processor to roll back. SSR-34 All cryptographic software and firmware shall be developed using best practices. (Note to agency: This should come with a certificate of compliance from the vendor.) SSR-34.01 All cryptographic software shall be managed in a form that protects software from unauthorized disclosure and/or modification. (Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) SSR-34.02 All cryptographic firmware shall be managed in a form that protects firmware from unauthorized disclosure and/or modification. (Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) SSR-35 The HSM shall be certified by one of the approved certification entities, or if they are not available, the HSM shall be self-certified by the vendor at a minimum. SSR-36 A cryptographic mechanism using an approved integrity technique shall be applied to all cryptographic software and firmware components within the HSM. SSR-37 If the HSM itself calculates the Message Authentication Code when the software is installed using a secret key known only to the HSM and uses this secret key to verify the software on boot or if the software provider has a unique shared key with each distinct device and uses this to authenticate the software, the message authentication code shall be used. SSR-38 A Message Authentication Code shall not be used to protect the software unless the Message Authentication Code key is unique to the HSM. SSR-39 Cryptographic information shall be managed based on FIPS 140-2. (Note to agency: Here are some specific items to consider with cryptographic information assembled by the THEA CV Pilot. Cryptographic software and firmware, cryptographic keys, and control and status information shall be under the control of an OS that meets the functional requirements specified in the Protection Profiles listed in FIPS 140-2 Annex B and is capable of evaluation at the CC EAL2, or an equivalent trusted OS.) SSR-40 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can execute stored cryptographic software and firmware. SSR-41 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can modify (i.e., write, replace, and delete) the following cryptographic module software or firmware components stored within the cryptographic boundary: cryptographic programs, cryptographic data. SSR-42 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can read the following cryptographic software components stored within the cryptographic boundary: cryptographic data. SSR-43 To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the OS shall be configured to specify the set of roles that can execute stored cryptographic software and firmware. SSR-44 The OS shall prevent all operators without the appropriate permissions (i.e., non-system admin) and executing processes from modifying executing cryptographic processes (i.e., loading and executing cryptographic program images). SSR-45 The OS shall prevent operators without the appropriate permissions (i.e., non-system admin) and executing processes from reading cryptographic software stored within the cryptographic boundary. Need ID Need (continued on next page)

A-12 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors Table 20. (Continued). User User Req ID Requirement SSR-46 The HSM shall maintain two roles: User, who can execute software and firmware, write and delete cryptographic keys, and install signed software and firmware, and Security Officer, who can install unsigned software and firmware in the event that specialized new software or firmware is being tested and troubleshot. SSR-47 Activities carried out by the User role shall not be explicitly authenticated, once the User role has successfully logged in. SSR-48 In a networked architecture that includes the host processor, other processors, and the HSM, the host processor shall authenticate itself to the HSM with an authentication mechanism based in hardware with the same physical security as the HSM. SSR-70 Connected Vehicle Roadside Equipment supplier shall provide the enrollment certificate for each RSU. SSR-71 Connected Vehicle Roadside Equipment supplier shall provide the serial number for each RSU. SSR-83 The RSU shall broadcast the WSA for certificate download on control channel 178 if DSRC is being used. SSR-83.01 The RSU WSA for certificate download shall contain an advertisement for IPv6 services. SSR-83.02 The RSU WSA for certificate download shall advertise a channel other than 178 or 172 if DSRC is being used. SSR-86 Communication between the Connected Vehicle Roadside Equipment and the SCMS shall operate in an encrypted, end-to-end connection in accordance with the published SCMS interface. SE05 The Positioning and Timing Systems need to provide an external time source the connected vehicle system uses as the basis for time. SPR-01 All OBUs shall use the same GPS time source and common accuracy configuration as the DOT infrastructure used for the Backoffice and RSUs. SE06 The Positioning and Timing Systems need to provide a common geographic reference for the connected vehicle system devices. SSR-68 Connected Vehicle Roadside Equipment shall support setting the “certificate geographic region” to be requested for “application certificates.” SSR-69 The system administrators shall configure the Connected Vehicle Roadside Equipment to request application certificates with only designated geographic locations. V01 OBUs need to provide an interface to gather situational data (e.g., OBD-II, CAN Bus) from a vehicle. PRC-16 The OBU shall contain an OBD-II port, J-bus, or CAN bus. PRC-17 The OBU shall conform to the associated SAE interface requirements for OBD-II port, J-bus, or CAN bus. PRC-18 The OBU interface to the CAN bus, J-bus, or OBD-II shall not degrade or interfere with vehicle's normal operation. PRC-19 The OBU interface to the CAN bus, J-bus, or OBD-II shall not interfere with the vehicle's passenger safety systems (e.g., restraints and extrication). PRC-20 The OBU’s interface to the CAN bus, J-bus, or OBD-II shall provide situational data (e.g., airbag deployment, traction control, antilock brake activation, and vehicle disabled) to the OBU. PRC-21 The OBU installed on emergency vehicles shall provide at least two GPIO ports for interfacing with emergency/public safety vehicle lights and sirens. PRC-22 The OBU installers shall document installation information. (Note to installer: Examples of installation parameters are the OBU serial number, vehicle number, vehicle class, software version, fleet/agency information, configurable vehicle parameters, and vehicle size/weights.) PRR-02 The OBU installation procedure shall stipulate wire routing. V02 OBUs need to access positioning and timing data to populate connected vehicle messages. SPR-01 All OBUs shall use the same GPS time source and common accuracy configuration as the DOT infrastructure used for the Backoffice and RSUs. LCR-01 The OBU shall meet OmniAir certification criteria based on procurement documents. V03 OBUs need to provide the ability to support additional privileges for special-use vehicles, such as emergency/public safety vehicles and maintenance/construction vehicles. PRC-06 OBUs shall be installed in vehicle types identified by the agency. (Note to agency: The connected vehicle environment may have within its agency, safety, maintenance/construction, commercial and passenger/private connected vehicle equipped vehicles.) PRC-21 The OBU installed on emergency vehicles shall provide at least two GPIO ports for interfacing with emergency/public safety vehicle lights and sirens. FR-03.03 The Connected Vehicle Roadside Equipment shall collect road weather data from OBUs installed on agency DOT construction and maintenance vehicles in accordance with SAE J2735 messages. V04 OBUs need to be able to broadcast messages in accordance with connected vehicle standards (SAE J2735). FR-02.18 The OBU shall be capable of broadcasting data in SAE J2735 defined message format. FR-06.01 OBUs shall broadcast freight operations data utilizing SAE J2735 defined messages. LCR-01 The OBU shall meet OmniAir certification criteria based on procurement documents. SPR-02 The OBUs shall provide the alerts to the driver within 250 milliseconds of being triggered by the application. (Note: The timing needs to be based on what is required for the agen ’ connected vehicle applications, 250 milliseconds is an example that has been used for the NYC CV Pilot and is not prescriptive.) Need ID Need

Needs-to-Requirements Traceability Matrix A-13   Table 20. (Continued). User User Req ID Requirement SPR-03 The OBUs shall process all radio messages at a minimum rate of 10 Hz with SCMS integration. This includes all messages on all channels (e.g., BSM, TIM, SSM, SRM, MAP, SPaT, etc.) in addition to IP communications traffic. SPR-04 The OBU shall broadcast the BSM of the host vehicle per SAE standards. (Note to agency: See J2945/1 and J2735 for specific requirements for message dictionary and performance, set requirements for relevant messages, and performance requirements for connected vehicle applications. See also appendix of the WYDOT SyRS for an example.) SPR-05 The OBUs shall be certified through OmniAir (or other certification entity) for connected vehicle use. V05 OBU (Device) needs enhanced information about locations and events where they could intersect with shared use of the transportation network by motorized and non-motorized transportation modes. FR-01.01 The OBU shall broadcast messages containing traffic-conditions data in accordance with SAE J2735 defined messages. V06 OBU (Device) needs to be able to collect data from ITS Roadway Equipment about Vulnerable Road Users that are sharing the roadway with the Vehicle. FR-05.02 Connected Vehicle Roadside Equipment shall collect rural safety data from Mobile Units (pedestrian/bicycle devices that send PSMs). FR-05.03 Connected Vehicle Roadside Equipment shall broadcast rural safety information utilizing SAE J2735 messages. FR-05.04 The OBU shall be capable of receiving rural safety information in SAE J2735 defined messages. V07 OBU (Device) needs to be able to warn travelers and vehicle operators of the presence of Vulnerable Road Users at signalized and non-signalized intersections; seasonal tourist locations, such as national parks; or special events along rural corridors. FR-01.01 The OBU shall broadcast messages containing traffic-conditions data in accordance with SAE J2735 defined messages. FR-03.01 The OBU shall broadcast messages containing road weather data in accordance with SAE J2735 defined messages. FR-04.01 OBUs shall broadcast a DN when they have been involved in an incident. V08 Vulnerable Road Users need enhanced information about locations and events where they could intersect with shared use of the transportation network by motorized and non-motorized transportation modes. FR-05.02 Connected Vehicle Roadside Equipment shall collect rural safety data from Mobile Units (pedestrian/bicycle devices that send PSMs). FR-05.03 Connected Vehicle Roadside Equipment shall broadcast rural safety information utilizing SAE J2735 messages. SL01 The Backoffice system needs to protect itself from unauthorized access by external sources or entities. SSR-34.01 All cryptographic software shall be managed in a form that protects software from unauthorized disclosure and/or modification. (Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) SSR-34.02 All cryptographic firmware shall be managed in a form that protects firmware from unauthorized disclosure and/or modification. (Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) SSR-96 Monitoring systems for connected vehicle systems shall be enabled and used to detect abnormal unauthorized activity on an IP connection. IMR-12 Access to the Backoffice shall require a login and password. IMR-13 Access to the Backoffice shall be limited to authorized personnel. SL02 The Backoffice system needs to protect itself from unauthorized access by internal sources or entities. SSR-34.01 All cryptographic software shall be managed in a form that protects software from unauthorized disclosure and/or modification. (Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) SSR-34.02 All cryptographic firmware shall be managed in a form that protects firmware from unauthorized disclosure and/or modification. (Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) SSR-96 Monitoring systems for connected vehicle systems shall be enabled and used to detect abnormal unauthorized activity on an IP connection. IMR-12 Access to the Backoffice shall require a login and password. IMR-13 Access to the Backoffice shall be limited to authorized personnel. SL03 The Backoffice system needs to be interoperable among other regional and national connected vehicle systems. IIR-05 The interface between OBUs and Connected Vehicle Roadside Equipment shall be in accordance with the IEEE 1609 family of standards, and SAE J2735 and SAE J2945 family of standards. EIR-02 The interface between the Backoffice system and other TMCs for sharing Center-to-Center (C2C) information shall be the TMDD v3.1. EIR-03 The interface between the Connected Vehicle Roadside Equipment and the SCMS shall be in accordance with IEEE 1609.2.1. EIR-04 The interface between the OBU and the SCMS shall be in accordance with IEEE 1609.2.1. SL04 The Backoffice system needs to be operational 24 hours a day, 365 days a year. SRR-05 The Backoffice system shall be available 24 hours a day, 365 days a year with downtime periods that do not exceed 24 consecutive hours. Need ID Need (continued on next page)

A-14 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors Table 20. (Continued). User User Req ID Requirement SL05 The Backoffice system needs to be capable of being modified to increase its storage or functional capacity (e.g., the connected vehicle system shall allow for more devices and more device types to be added than are originally deployed). SMR-02 The Backoffice staff shall be able to monitor systemwide disk space availability. SMR-02.1 The Backoffice shall monitor the system for disk space availability of greater than 10% free space. This includes connected vehicle Backoffice functions for Data Collection, Data Fusion, Decision Support Systems, Device Control and Monitoring, Data Dissemination, Data Storage, and the Field ITS Roadway Equipment. SMR-02.2 The Backoffice shall send a notification to the maintenance team after a system component has less than 10% free disk space for 5 minutes. SL06 The Backoffice system needs to be easily modifiable to correct faults, improve performance or other attributes, or adapt to a changing environment. SMR-01 The Backoffice staff shall be able to monitor systemwide malfunctions. SMR-01.1 The Backoffice shall monitor the system for availability of ping services running. This includes connected vehicle Backoffice functions for Data Collection, Data Fusion, Decision Support Systems, Device Control and Monitoring, Data Dissemination, Data Storage, and the Field ITS Roadway Equipment. SMR-01.2 The Backoffice shall send a notification to the maintenance team after a system component is non- responsive for 5 minutes. SL07 The Backoffice system needs to consistently perform its required functions under stated conditions 24 hours a day 365 days a year. SMR-01 The Backoffice staff shall be able to monitor systemwide malfunctions. SMR-01.1 The Backoffice shall monitor the system for availability of ping services running. This includes connected vehicle Backoffice functions for Data Collection, Data Fusion, Decision Support Systems, Device Control and Monitoring, Data Dissemination, Data Storage, and the Field ITS Roadway Equipment. SMR-01.2 The Backoffice shall send a notification to the maintenance team after a system component is non- responsive for 5 minutes. SMR-02 The Backoffice staff shall be able to monitor systemwide disk space availability. SMR-02.1 The Backoffice shall monitor the system for disk space availability of greater than 10% free space. This includes connected vehicle Backoffice functions for Data Collection, Data Fusion, Decision Support Systems, Device Control and Monitoring, Data Dissemination, Data Storage, and the Field ITS Roadway Equipment. SMR-02.2 The Backoffice shall send a notification to the maintenance team after a system component has less than 10% free disk space for 5 minutes. PRD-01 Backoffice servers shall have their power source augmented by an UPS. PRD-02 Roadside cabinets shall have their power source augmented by an UPS. PRD-03 The fleet maintenance personnel shall replace OBUs damaged by improper maintenance, tampering, or mishap. PRD-04 The DOT maintenance personnel shall replace RSUs damaged by improper maintenance, tampering, or mishap. PRD-05 The OBU shall be able to detect and reboot after a disruptive software glitch. PRD-06 The DOT maintenance personnel shall be able to reboot RSUs after a disruptive software glitch. SL08 The Backoffice system needs to allow the system to be modified for use in applications or environments other than those for which it was specifically designed. PRA-01 The connected vehicle deployment applications shall have modifiable algorithms and software parameters for tuning the system’ operation. PRA-02 The OBU shall have upgradable hardware components for improving the device performance upon expansion of the system. PRA-03 The RSU shall have upgradable hardware components for improving the device performance upon expansion of the system. PRA-04 The backhaul shall have upgradable bandwidth to support system growth. PRA-05 The Backoffice shall have upgradable performance to support system growth. PRA-06 The Backoffice shall have upgradable storage to support system growth. SL09 The Backoffice system needs to have an intuitive, simple interface that allows drivers, administrators, rural agency personnel, and other staff to learn to operate, prepare inputs for, and interpret outputs of the system. HFR-01 The system administrator shall be able to change the volume level of the audio output (e.g., speakers). (Note to agency: The WYDOT CV Pilot deployed two OBUs: one with user-controlled speaker volume and one with administrative control. WYDOT found user-controlled volume was less effective. Which OBU to use should be a decision made by each deploying agency.) HFR-02 The OBU shall have the ability to operate in either silent mode or active mode. HFR-03 The OBU shall record events without audibly notifying the driver when operating in silent mode. HFR-04 The OBU shall record events while audibly notifying the driver when operating in active mode. HFR-05 The OBU shall set the application alert mode to silent mode or active mode per the most recent parameters downloaded. HFR-06 The location where the HMI is mounted shall be selected so that it does not obstruct the line of sight of the driver nor distract the driver from the primary task of driving. Need ID Need

Needs-to-Requirements Traceability Matrix A-15   Table 20. (Continued). User User Req ID Requirement HFR-07 The HMI shall minimize the “eyes off the road” time when presenting information for an application. HFR-08 The HMI shall provide messages that can be read from the driver’ normal seating position. HFR-09 The HMI shall include both a visual and auditory interface for presenting alerts and advisories. HFR-10 The HMI shall maintain a consistent structure across applications for presenting information to drivers and inputs to the system. HFR-11 Auditory signals shall be loud enough to overcome masking sounds from road noise, the cab environment, and other equipment. HFR-12 HMI characteristics shall be customizable to reflect driver preferences. Preferences that shall be customizable are as follows: • Brightness • Contrast text size • Display contrast • Mounting eye position HFR-13 The HMI shall notify the driver of the power status of the device with the screen graphics (i.e., off, powering up, and online). HFR-14 The HMI shall allow the driver to see the system settings of the device with screen graphics (i.e., version, brightness, volume, font size). HFR-15 The HMI shall allow the driver to see application availability with screen graphics (i.e., failed, operating, disabled). HFR-16 The HMI shall allow the driver to see pending updates for the device with screen graphics (i.e., applications, firmware, OS) at bootup. F03 Connected Vehicle Roadside equipment needs to have infrastructure elements available to support power and network connections to the device. PRC-01 Connected Vehicle Roadside Equipment shall be connected to the backhaul network from roadside cabinets. PRC-02 Connected Vehicle Roadside Equipment antennas shall be installed to provide effective connection. PRC-02.1 Connected Vehicle Roadside Equipment antennas shall be mounted in locations that provide a clear path to the directions from which most connected vehicle device communications shall take place for all seasons. PRC-02.2 Connected Vehicle Roadside Equipment GPS antenna shall be positioned to have a clear view of the sky for all seasons. PRC-03 Connected Vehicle Roadside Equipment shall be connected to power from roadside cabinets. PRC-03.1 All connections to the Connected Vehicle Roadside Equipment shall be protected from lightning and power surges. PRC-03.2 Connected Vehicle Roadside Equipment shall not overload the Type 2 PoE+ (IEEE 802.3at-2009) 25.5-watt power supplies provided. PRC-03.3 Connected Vehicle Roadside Equipment shall withstand ESD from external sources and electrical distribution. PRC-04 Connected Vehicle Roadside Equipment shall provide evidence of tampering (e.g., opening of the case) through tamper-evident seals on media ports (e.g., USB) and screw holes. PRC-05 Connected Vehicle Roadside Equipment shall be able to resume normal function within two minutes of restoration of power. PRC-23 Connected Vehicle Roadside Equipment installers shall document installation information. (Note to installer: Examples of installation parameters are RSU location, height above roadway, power type, backhaul communication type, serial number, and software version.) PRE-03 Connected Vehicle Roadside Equipment shall be designed to operate properly in the local outdoor environment. (e.g., temperature, humidity, rain, fog, sun, lighting, snow, salt, shock, vibration, and wind). (Note: The RSU 4.1 specification has requirements for environmental testing in Section 3.2.) PRR-01 Proper FCC licensing to broadcast messages from Connected Vehicle Roadside Equipment shall be obtained before device installation. V09 OBUs need to have physical mounting locations and ports to support power and network connections to the device. PRC-06 OBUs shall be installed in vehicle types identified by the agency. (Note to agency: The connected vehicle environment may have within its agency, safety, maintenance/construction, commercial and passenger/private connected vehicle equipped vehicles.) PRC-06.1 OBUs shall be installed in a manner that the device is not visible, wiring for the device is not visible or minimally visible, and no holes or modifications to the vehicle are required. PRC-06.2 OBUs installations shall be performed professionally by technicians trained in the installation of connected vehicle equipment. PRC-06.3 OBU antenna installations shall be placed where they can support connected vehicle communications of at least 300 meters with another connected vehicle device with a clear line of sight. PRC-07 The OBU shall operate on the voltage supplied by the host vehicle. PRC-08 The current drawn by the OBU shall not exceed 60 watts. PRC-09 The OBU shall withstand electromagnetic interference (EMI) from light- and heavy-duty vehicle sources. PRC-10 The OBU shall withstand ESD from light- and heavy-duty vehicle sources. PRC-11 The OBU design shall prevent battery drain. Need ID Need (continued on next page)

A-16 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors Table 20. (Continued). User User Req ID Requirement PRC-12 The user interface for the OBU shall be visible to the driver minimizing potential distraction. PRC-13 The OBU shall provide evidence to detect tampering (e.g., opening of the case) through tamper- evident seals on all media ports and screw holes. PRC-14 The OBU shall be able to resume normal function within 1 minute of vehicle start. PRC-22 The OBU installers shall document installation information. (Note to installer: Examples of installation parameters are the OBU serial number, vehicle number, vehicle class, software version, fleet/agency information, configurable vehicle parameters, and vehicle size/weights.) PRE-01 The audible message volume from the OBU shall be distinguishable from other sounds in light and heavy-duty vehicles. PRE-02 The audible message volume from the OBU shall be verified in real traffic environments. PRE-04 The OBU shall be designed to operate in vehicles in the local outdoor environment at up to highway speeds without vehicle leaking or damage (e.g., temperature, humidity, rain, fog, sun, lightning, snow, salt, shock, vibration, and wind). PRR-02 The OBU installation procedure shall stipulate wire routing. SE03.01 OBUs need to provide security mechanisms to protect data stored, generated, and transmitted by the device. SSR-52 OBUs shall protect transmissions against inadvertently providing PII. [Note to agency: These protections should be considered for both broadcast (like BSM) and transactional (like log uploads or OTA updates) communications.] SSR-52-01 OBUs shall use temporary identifiers to protect transmissions against inadvertently providing PII. SSR-52-02 OBUs shall use one-time identifiers to protect transmissions against inadvertently providing PII. SSR-53 All OBU unused media ports shall be sealed with a removable tamper-evident seal, at a minimum. SSR-54 PID devices shall support security requirements identified in SAE J2945/1, such as the BSM transmission and reception security profile. SSR-55 OBU devices shall support security requirements identified in SAE J2945/1, such as the BSM transmission and reception security profile. SSR-56 OBU devices shall support the ability to reset default usernames and passwords by users with Administrative functions (ENG, MRG, and Admin). SSR-57 OBUs shall meet FIPS-140-2 Level 2 or equivalent. SSR-58 OBUs shall not support remote access of the connected vehicle applications. SSR-59 OBUs shall support role-based authentication to enable physical access. SSR-60 OBUs shall support physical access to support bootstrapping activities. SSR-61 The OBU shall support a secure session protocol to the TMC for protecting the firmware download. SSR-62 The OBU shall partition enough storage space for two firmware images (its current and new firmware). (Note to agency: This requirement is to help an OBU recover from a partial or failed update with the retention of the current and new firmware. The space required will be vendor-dependent.) SSR-63 The OBU shall implement a download protocol that permits resumption of incomplete downloads instead of requiring an incomplete download to be restarted. SSR-64 The OBU shall obtain certificates via IPv6 connectivity through the RSU. SSR-67 The OBU shall log an event report every second for which channel busy ratios go above a configurable threshold. SSR-88 PIDs shall meet FIPS 140-2 Level 2 or equivalent. SSR-89 PIDs shall not support remote access of the connected vehicle applications. SE04.01 Connected Vehicle Roadside Equipment needs to provide security mechanisms to protect data stored, generated, and transmitted by the device. SSR-72 Connected Vehicle Roadside Equipment shall support a secure session protocol to the TMC for protecting the firmware download. SSR-73 Connected Vehicle Roadside Equipment shall implement a download protocol that permits resumption of incomplete downloads instead of requiring an incomplete download to be restarted. SSR-74 Connected Vehicle Roadside Equipment shall meet the WSA security profile covered in IEEE 1609.3 (2016). SSR-75 Connected Vehicle Roadside Equipment shall meet the SPaT, MAP, and TIM security profiles. SSR-76 Connected Vehicle Roadside Equipment shall support security requirements identified in Section 6.5 of SAE J2945/1. SSR-77 Connected Vehicle Roadside Equipment shall support the ability to reset default usernames and passwords by users with Administrative functions (ENG, MRG, and Admin). SSR-78 Connected Vehicle Roadside Equipment shall meet FIPS 140-2 Level 2 or equivalent. SSR-79 Connected Vehicle Roadside Equipment shall support remote authenticated access. SSR-80 Connected Vehicle Roadside Equipment shall support physical access to support bootstrapping activities. SSR-81 Connected Vehicle Roadside Equipment shall support role-based authentication to enable physical access. SSR-82 Connected Vehicle Roadside Equipment unused media ports shall be sealed with a removable tamper-evident seal, at a minimum. SSR-84 Connected Vehicle Roadside Equipment shall implement a firewall blocking all IP access from devices to any IP address other than those approved for specific applications. SSR-85 Connected Vehicle Roadside Equipment shall support IPv6 tunneling over IPv4. Need ID Need

Needs-to-Requirements Traceability Matrix A-17   Table 20. (Continued). User User Req ID Requirement SSR-86 Communication between the Connected Vehicle Roadside Equipment and the SCMS shall operate in an encrypted, end-to-end connection in accordance with the published SCMS interface. SSR-87 Connected Vehicle Roadside Equipment shall report over a management interface if channel busy ratios go above a configurable threshold. SPR-12 Connected Vehicle Roadside Equipment shall process all radio messages at a minimum rate of 10 Hz with SCMS integration. SPR-14 Connected Vehicle Roadside Equipment shall be certified through OmniAir (or other certification entity) for connected vehicle use. SL10 Connected Vehicle devices need to be able to be configured remotely by authorized personnel. SMR-03 The OBU shall have configurable parameters for tuning alert thresholds. SMR-04 The OBU parameter control functional entity shall meet the highest security requirements for an OBU application. (Note to agency: This requirement is derived via the CIA based on FIPS PUBS 199.) SMR-05 The parameter control message shall contain a version number that increments based on message payload updates. (Note to agency: the parameter control message is part of the OTA update system for the OBU that can update parameters for applications. For example, time to collision timing for FCW.) SMR-06 The OBUs from all suppliers shall implement the same parameter control implementation. (Note to agency: Parameter control implementation will be defined by the agency DOT in the System Design.) SMR-07 The OBU software components shall accommodate failures in hardware or adjacent software modules in a way that does not pose hazards. SMR-08 The Backoffice staff shall be able to monitor the connected vehicle deployment systemwide OBU malfunctions. SMR-09 Mobile devices in need of certificate updates shall switch to the RSU advertised channel. SMR-10 A connected vehicle device shall continue normal operations regardless of the number, rate, or content of the messages received. (Note to agency: WYDOT found that during large numbers (>15) of TIMs received from an RSU, BSMs delivery could not be maintained at 10 Hz. The solution was using separate threads for TIM reception and validation versus BSM creation and transmission.) SMR-11 A connected vehicle device shall continue normal operations regardless of the number, rate, or content of messages transmitted. SMR-12 The connected vehicle deployment Device Control and Monitoring Backoffice subsystem shall measure the RF received range of each OBU. SMR-13 The connected vehicle deployment Device Control and Monitoring Backoffice subsystem shall measure the RF monitoring range of each RSU. SMR-14 The OBU shall include a threat arbitrator for advisories and alerts presented to the driver in cases where multiple safety advisories are indicated simultaneously or overlapping. SMR-15 The OBU shall allow recording of the RF signal level for any message received. SMR-16 The OBU shall record the first BSM it hears from each unique OBU ID along with its own location and RF level information. SMR-17 The OBU shall record the first MAP message it hears from each RSU ID along with the contents of its own location at the time and the RF level. SMR-18 The OBU shall record the first SPaT message it hears from each RSU along with the contents of its own location at the time and the RF level. SMR-19 The OBU shall record the first TIM message it hears from each RSU along with the contents of its own location at the time and the RF level. SMR-20 The OBU shall record the first PDM message it hears from each RSU along with the contents of its own location at the time and the RF level. SMR-21 The OBU shall record the last MAP message it hears from each RSU along with the contents of its own location at the time and the RF level. SMR-22 The OBU shall record the last SPaT message it hears from each RSU along with the contents of its own location at the time and the RF level. SMR-23 The OBU shall record the last TIM message it hears from each RSU along with the contents of its own location at the time and the RF level. SMR-24 The OBU shall record the last PDM message it hears from each RSU along with the contents of its own location at the time and the RF level. SMR-25 The OBU RF Log Entries shall be stored in the OBU local memory. SMR-26 The OBU RF log entries shall be purged after 7 days. SMR-27 The OBU RF log space shall be sufficient to store 7 days of interactions with the expected number of vehicles and the expected number of RSUs assuming an expected number of entries per day. (Note to agency: The expected number of vehicle interactions and RSU interactions will vary based on density of RSUs and vehicles in the rural deployment. For example, NYC CV Pilot expected about 5,000/day, and WYDOT expected about 500/day. Update numbers based on the agency deployment expectation.) SMR-28 If the OBU RF log files exceed the space allocated, then the oldest data shall be written over without damaging newer log files. SMR-29 The following requirements shall apply to the OBU RF data monitoring, uploading, and purging. SMR-29.1 The OBU shall monitor the control channel when the OBU encounters an RSU that supports the RF data upload. Need ID Need (continued on next page)

A-18 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors Table 20. (Continued). User User Req ID Requirement SMR-29.2 The OBU shall upload the contents of the RF logs to the Backoffice systems. SMR-29.3 The OBU shall purge the logs after they have been acknowledged by the RSU. SMR-30 The OBU shall authenticate all transactions to retrieve the RF logs. SMR-31 The static Connected Vehicle Roadside Equipment shall record the first BSM message it hears from each OBU along with the time and the RF level. SMR-32 The static Connected Vehicle Roadside Equipment shall record the last BSM message it hears from each OBU along with the time and the RF level. SMR-33 The Connected Vehicle Roadside Equipment shall upload the data to the Backoffice system whenever its buffers are full or more than 5 minutes old. SMR-34 Once the RF log data is received and acknowledged by the Backoffice system, it shall be purged from the Connected Vehicle Roadside Equipment. SMR-35 Connected Vehicle Roadside Equipment shall authenticate all transactions to retrieve its RF logs. SMR-36 Connected Vehicle Roadside Equipment shall allow recording of the RF signal level for any message received. SMR-37 Mobile Connected Vehicle Roadside Equipment shall record the first BSM message it hears from each OBU along with the time and the RF level only when it is stopped. (Note to agency: Mobile RSU may be used at work zones on trailers.) SMR-38 Mobile Connected Vehicle Roadside Equipment shall record the last BSM message it hears from each OBU along with the time and the RF level only when it is stopped. SMR-39 Connected Vehicle Roadside Equipment communication failures shall be responded to within 1 business day in accordance with the agency DOT response time for critical field equipment. SMR-40 Connected Vehicle Roadside Equipment communication shall be restored in accordance with the agency DOT response time for critical field equipment. SMR-41 Connected Vehicle Roadside Equipment hardware failures shall be addressed in accordance with the agency DOT response time for critical field equipment. SMR-42 Connected Vehicle Roadside Equipment application issues shall be responded to in accordance with the agency DOT response time for critical field equipment. SMR-43 Planned Connected Vehicle Roadside Equipment maintenance shall be scheduled in accordance with the agency DOT response time for critical field equipment. SMR-44 Planned Connected Vehicle Roadside Equipment maintenance shall be performed during off-peak hours of the agency DOT's operation. SMR-45 OBU failures shall be logged at the time they are reported. SMR-46 Support staff shall be trained to troubleshoot and diagnose Connected Vehicle Roadside Equipment, OBU, and PID issues. SMR-47 The Backoffice shall provide the Backoffice administration team the ability to push out OTA firmware updates to the OBUs. SMR-48 The Backoffice shall provide the Backoffice administration team the ability to push out OTA HMI updates to the OBUs. SMR-49 The Backoffice shall provide the Backoffice administration team the ability to push out OTA control parameter updates to the OBUs. SMR-50 The Backoffice shall provide the Backoffice administration team the ability to push out firmware updates to the RSUs. SRR-01 The OBU shall revert to a failsafe mode when unable to perform its normal operations. SRR-02 Connected Vehicle Roadside Equipment shall revert to a failsafe mode when unable to perform its normal operations. SRR-03 The OBU shall report a self-diagnosed failure of itself or one of its software modules (1) to a Connected Vehicle Roadside Equipment attempting to install new firmware or parameters and (2) to a device connected to the OBU’s maintenance port. SRR-04 Connected Vehicle Roadside Equipment shall report a self-diagnosed failure through the backhaul to the Backoffice. IMR-15 Connected Vehicle Roadside Equipment shall allow remote configuration from authorized users at the Traffic Management Center. IMR-16 The Device Control and Monitoring subsystem shall configure the applications running on the Connected Vehicle Roadside Equipment. (Note: These would include traffic management applications, rural safety applications, road weather applications, etc.) Need ID Need

Abbreviations and acronyms used without definitions in TRB publications: A4A Airlines for America AAAE American Association of Airport Executives AASHO American Association of State Highway Officials AASHTO American Association of State Highway and Transportation Officials ACI–NA Airports Council International–North America ACRP Airport Cooperative Research Program ADA Americans with Disabilities Act APTA American Public Transportation Association ASCE American Society of Civil Engineers ASME American Society of Mechanical Engineers ASTM American Society for Testing and Materials ATA American Trucking Associations CTAA Community Transportation Association of America CTBSSP Commercial Truck and Bus Safety Synthesis Program DHS Department of Homeland Security DOE Department of Energy EPA Environmental Protection Agency FAA Federal Aviation Administration FAST Fixing America’s Surface Transportation Act (2015) FHWA Federal Highway Administration FMCSA Federal Motor Carrier Safety Administration FRA Federal Railroad Administration FTA Federal Transit Administration GHSA Governors Highway Safety Association HMCRP Hazardous Materials Cooperative Research Program IEEE Institute of Electrical and Electronics Engineers ISTEA Intermodal Surface Transportation Efficiency Act of 1991 ITE Institute of Transportation Engineers MAP-21 Moving Ahead for Progress in the 21st Century Act (2012) NASA National Aeronautics and Space Administration NASAO National Association of State Aviation Officials NCFRP National Cooperative Freight Research Program NCHRP National Cooperative Highway Research Program NHTSA National Highway Traffic Safety Administration NTSB National Transportation Safety Board PHMSA Pipeline and Hazardous Materials Safety Administration RITA Research and Innovative Technology Administration SAE Society of Automotive Engineers SAFETEA-LU Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users (2005) TCRP Transit Cooperative Research Program TDC Transit Development Corporation TEA-21 Transportation Equity Act for the 21st Century (1998) TRB Transportation Research Board TSA Transportation Security Administration U.S. DOT United States Department of Transportation

Transportation Research Board 500 Fifth Street, NW Washington, DC 20001 ADDRESS SERVICE REQUESTED ISBN 978-0-309-67435-5 9 7 8 0 3 0 9 6 7 4 3 5 5 9 0 0 0 0

Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

Rural corridors often include long stretches of highway with limited power, communications, and intelligent transportation systems (ITS) infrastructure; long distances between cities or services for travelers; different traffic and roadway characteristics; and significant incident-related rerouting distances.

The National Cooperative Highway Research Program's NCHRP Research Report 978: Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors, Volume 3: Model System Requirements Specification provides information that will apply in general to most current and proposed systems. It is intended to provide a base document that a deploying agency can customize to fit their project and situation.

Supplemental to this report are a research overview (Volume 1), a model concept of operations (Volume 2), and a PowerPoint presentation of context diagrams.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!