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.
15  S E C T I O N 3 At the highest level, system requirements must de ne all the functions that the system must perform at a technical level. For ITS and connected vehicle systems, this usually includes collecting data, analyzing data, securing data and devices, sending information to other entities or system elements, and commanding/controlling devices within the system. In addition to de ning the technical functions, the requirements should also de ne any tech- nical constraints placed on the system as well as any performance-related constraints. e system requirements should be more technically detailed than the user needs but without prescribing a speci c system design. Ensuring that the design and development team has the necessary latitude to develop innovative solutions will generally result in more ecient system developments. Writing good, clear, and complete requirements is essential to the success of the system design phase. If there are ambiguities in a requirement, then the system designer may inter- pret how to meet that requirement in a way that is di erent from what was intended. e following guidance is consolidated from multiple guides on writing system requirements from entities such as INCOSE and IEEE. Good functional requirements are necessary, concise (minimal, understandable), attainable (achievable or feasible), complete (standalone), consistent, unambiguous, and veri able. Requirements should follow a simple grammar (see Figure 4): ⢠Actor [the System] ⢠Action [shall do/not do something to] ⢠Target [the object of the action] ⢠Constraint [how, how o en, how many, how fast] ⢠Condition/Localization [if, when, where] Requirements written in this manner are usually considered âwell-formedâ requirements and will help ensure that system designers have enough information to design a technical solution. e NASA Systems Engineering Handbook has an appendix on writing good requirements that can be a valuable resource when developing system requirements. It can be found here at Ã. One nal consideration to make when developing system requirements is to ensure that they are veri able. As the system is designed and implemented, it will eventually enter the veri cation and validation phase. At that phase, test cases will be developed to ensure that all system require- ments are met, with each test case having traceability to one or more system requirements. Each requirement will be assigned a veri cation method: Inspection, Analysis, Demonstration, or Test. When writing system requirements, it is important to think about how you would verify that the requirement was met. If a requirement does not have an obvious way of being veri ed, that requirement should be revised to make it veri able. System Requirements
16 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors Note to reader: Many of the requirements in this section are taken in part or whole from the New York City (NYC), Tampa Hillsborough Expressway Authority (THEA), and Wyoming Department of Transportation (WYDOT) CV Pilots funded by the U.S. DOT. The CV Pilots used a systems engineering process when developing their ConOps and SyRS, which went through multiple reviews before the final versions were posted. These requirements provide an excellent starting point for any organization that is developing connected vehicle environments. Where appropriate these requirements have been updated for the rural setting. Links to the CV Pilots SyRS documents can be found in Section 1.3. 3.1 Functional Requirements Functional requirements form the backbone of what this system needs to accomplish. e functional requirements described in this section are primarily derived from Section 4.2.1, Section 5.2, and Section 6 of the model ConOps. ese requirements describe the speci c functions of the system in technical detail but will not prescribe the design. ese may include de ning the type of data to be collected, where that data is collected from, and what outputs from any analysis of that data may be. e following functional requirements de ne speci c functions using di erent types of data that are produced, collected, broadcast, fused, or stored. e types of data elements are de ned in Table 3. When developing a SyRS for a production system, create individual requirements for each data element to ensure the system designers and developers have speci c direction. For the sake of brevity, this model SyRS de nes requirements at the data-type level (see Table 3). Similar to the types of data, there is information that is produced by the system via analysis of the data that is collected and stored. e functional requirements de ne what types of informa- tion the system produces, and that information may have many di erent elements or formats de ned within it. When creating a SyRS for a production system, create individual require- ments for each information element to ensure that the system designers and developers have more speci c direction. For the sake of brevity, this model SyRS de nes requirements at the information-type level (see Table 4). e functional system requirements (FR) are presented in Table 5. Note to reader: The functional system requirements may need to be broken down to the subsystem and element level, depending on the complexity of the system under development. For this model SyRS, these requirements are not further broken down into the subsystems listed within the Backoffice system found in the Concept Diagram of the Current System. Figure 4. Example functional requirement.
System Requirements 17  T raffic C o nd itio ns Vehicle Speed ( mph/ kph) , Vehicle Acceleration, Brake Status Basic Safety Message ( BSM) , Probe Data Message ( PDM) , CCTV, L oop Detector W o rk Z o ne W ork Z one L ocation, Detailed W ork Z one Map ( where lane closures start and end) Traffic Management Data Dictionary ( TMDD) W ork Z one F ormat, W ork Z one Data Ex change ( W Z Dx) F ormat Ro ad W eath er Brake Status, W indshield W iper Status, Pavement Sensor, Environmental Sensor BSM, PDM, Road W eather Message ( RW M) , Environment Senor System ( ESS) Management Information Base ( MIB) Obj ect Incid ent Distress Notification ( DN) , Airbag Status, Antilock brake status, vehicle disabled, Incident L ocation BSM, DN Rural S afety Roadway G eometry and Potential H aza rds, F ield Sensor Data, Pedestrian L ocation, Pedestrian Crossing Information, SPaT Information, Pedestrian Detection Sensors Traveler Information Message ( TIM) , Personal Safety Message ( PSM) , National Transportation Communication for ITS Protocol ( NTCIP) 1202 MIB Obj ects F reig h t O p eratio ns Vehicle W eight Restrictions, Vehicle H eight Restrictions, Parking Restrictions, Road G rade Information, Vehicle Size , Trailer L ength, Vehicle- Specific Closures, Vehicle- Specific Advisories BSM Part II, TMDD D ata T y p e D ata E lements S o urces o f D ata Table 3. Functional requirements by data type. Info rmatio n T y p e Info rmatio n E lements Info rmatio n F o rmats T raffic E v ent Traffic Delays, Traffic W arnings, Q ueue L ength Traveler Information Message ( TIM) , Roadside Safety Message ( RSM) , Dynamic Message Signs ( DMS) W o rk Z o ne W ork Z one L ocation, Detailed W ork Z one Map ( where lane closures start and end) TIM, RSM, Traffic Management Data Dictionary ( TMDD) W ork Z one F ormat, W ork Z one Data Ex change ( W Z Dx ) F ormat, DMS Ro ad W eath er E v ent F og, Icy Pavement/ Bridge, F looding, W eather Advisories, W eather Alerts, Road Treatment Actions, Road Treatment Plans TIM, RSM, DMS Incid ent Distress Notification ( DN) , L ocation, Severity, Number of DN Vehicles Involved, Airbag Status Rural S afety Roadway G eometry and Potential H aza rd Information, SPaT Information, Pedestrian W arnings TIM, RSM, SPaT Message F reig h t O p eratio ns Vehicle H eight W arning, Vehicle W eight W arning, Road G rade W arning, Vehicle- Specific Closures, Vehicle- Specific Advisories TIM, RSM, DMS, TMDD Table 4. Functional requirements by information types.
18 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors F unctio nal Requirements F R-01 The following system requirements define the functions of the traffic management applications. F R-01. 01 The OBU shall broadcast messages containing traffic- conditions data in accordance with SAE J2735 defined messages. F R-01. 02 The Connected Vehicle Roadside Equipment shall collect traffic- conditions traveling through its coverage area. F R-01. 03 The Data Collection subsystem shall collect traffic- conditions data from ITS Roadway Equipment. F R-01. 04 The Data Collection subsystem shall collect traffic- conditions data from Connected Vehicle Roadside Equipment. F R-01. 05 The Data Collection subsystem shall collect traffic- conditions data from Rural Agency Personnel. F R-01. 06 The Data Collection subsystem shall collect traffic- conditions data from third- party service providers. F R-01. 07 The Data Collection subsystem shall collect traffic- conditions data from other Traffic Management Center systems. F R-01. 08 The Data F usion subsystem shall fuse traffic- conditions data from multiple sources collected from the Data Collection subsystem. F R-01. 09 The Data Storage subsystem shall store fused traffic- conditions data. F R-01. 10 The Decision Support subsystem shall analyz e stored traffic- conditions data to determine if a traffic event is occurring. F R-01. 11 The Data Dissemination subsystem shall send traffic event information to Connected Vehicle Roadside Equipment. F R-01. 12 The Data Dissemination subsystem shall send traffic event information to ITS Roadway Equipment. F R-01. 13 The Data Dissemination subsystem shall send traffic event information to third- party providers. F R-01. 14 The Data Dissemination subsystem shall send traffic event information to other Traffic Management Center systems. F R-01. 15 Connected Vehicle Roadside Equipment shall send traffic event information to OBUs utiliz ing SAE J2735 defined messages. F R-01. 16 The OBU shall be capable of receiving traffic event information in SAE J2735 defined messages. F R-01. 17 The OBU shall present traffic event information to the driver. F R-02 The following requirements define the functions of the work zo ne management applications. F R-02. 01 The Data Collection subsystem shall collect location- specific work zo ne data from the Maintenance Management System. F R-02. 02 The Data Collection subsystem shall collect location- specific work zo ne data ( e.g., location, lanes) from Rural Agency Personnel ( rural work z one crew) . F R-02. 03 The Data Collection subsystem shall collect location- specific work zo ne data from other Traffic Management Center systems. F R-02. 04 The Data Collection subsystem shall collect work zo ne data from event promoters. F R-02. 05 The Data Collection subsystem shall collect work zo ne data from the Connected Vehicle Roadside Equipment. F R-02. 06 The Data F usion subsystem shall fuse work zo ne data from multiple sources collected from the Data Collection subsystem. F R-02. 07 The Data Storage subsystem shall store fused work zo ne data. F R-02. 08 The Decision Support subsystem shall analyz e stored work zo ne data to determine if the current work zo ne information needs to be updated. Table 5. Functional system requirements.
System Requirements 19  F R-02. 09 The Decision Support subsystem shall retrieve stored fused work zo ne data for dissemination. F R-02. 10 The Decision Support subsystem shall send updated work zo ne information to the Data Dissemination subsystem. F R-02. 11 The Data Dissemination subsystem shall send work zo ne information to the Maintenance Management System. F R-02. 12 The Data Dissemination subsystem shall send work zo ne information to Connected Vehicle Roadside Equipment. F R-02. 13 The Data Dissemination subsystem shall send work zo ne information to ITS Roadway Equipment. F R-02. 14 The Data Dissemination subsystem shall send work zo ne information to other Traffic Management Center systems. F R-02. 15 Connected Vehicle Roadside Equipment shall broadcast work zo ne information to OBUs utiliz ing SAE J2735 defined messages. F R-02. 16 The OBU shall be capable of receiving work zo ne information in SAE J2735 defined messages. F R-02. 17 The OBU shall present work zo ne information to the driver. F R-02. 18 The OBU shall be capable of broadcasting data in SAE J2735 defined message format. F R-03 The following requirements define the functions of the road weather management applications. F R-03. 01 The OBU shall broadcast messages containing road weather data in accordance with SAE J2735 defined messages. F R-03. 02 The Connected Vehicle Roadside Equipment shall collect road weather data from OBUs traveling through its predetermined geographic coverage area. F R-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. F R-03. 04 The Data Collection subsystem shall collect road weather data corresponding to configurable geographic coverage area from W eather Service System. F R-03. 05 The Data Collection subsystem shall collect road weather data from ITS Roadway Equipment. ITS Roadway Equipment may include environmental sensing stations. F R-03. 06 The Data Collection subsystem shall collect road weather data corresponding to predetermined geographic coverage areas from third- party service providers. F R-03. 07 The Data Collection subsystem shall collect reported road weather data from Connected Vehicle Roadside Equipment. F R-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 road weather information system ( RW IS) . F R-03. 09 The Data Collection subsystem shall collect location- specific road weather data from the Maintenance Management System. F R-03. 10 The Data Collection subsystem shall collect location- specific treatment actions and plans from the Maintenance Management System. F R-03. 11 The Data F usion subsystem shall fuse weather data from multiple sources collected from the Data Collection subsystem. F R-03. 12 The Data Storage subsystem shall store fused road weather data. F R-03. 13 The Decision Support subsystem shall analyz e stored road weather data to determine if a road weather event is occurring. F R-03. 14 The Data Dissemination subsystem shall send road weather event information to Connected Vehicle Roadside Equipment. F R-03. 15 The Data Dissemination subsystem shall send road weather event information to third- party service providers and SSPs. F unctio nal Requirements Table 5. (Continued). (continued on next page)
20 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors F R-03. 16 The Data Dissemination subsystem shall send road weather event information to ITS Roadway Equipment. F R-03. 17 The Data Dissemination subsystem shall send road weather event information to other Traffic Management Center systems. F R-03. 18 Connected Vehicle Roadside Equipment shall broadcast road weather event information to OBUs utiliz ing SAE J2735 defined messages. F R-03. 19 The Cloud shall provide OBU- equipped vehicles with relevant road weather advisories/ diversions. F R-03. 20 The Decision Support subsystem shall analyz e fused road weather data and send recommended road weather maintenance actions to the Maintenance Management System. F R-03. 21 The Data Dissemination subsystem shall send location- specific road weather event information to the Maintenance Management System. F R-03. 22 The Data Dissemination subsystem shall send location- specific road weather event information to the Traveler Information System. F R-03. 23 The Data Dissemination subsystem shall send location- specific road weather event information to the Emergency Management/ Public Safety System. F R-03. 24 The Data Dissemination subsystem shall make location- specific road weather event information available to F leet and F reight Management System. F R-03. 25 The Data Dissemination subsystem shall send road weather data and conditions to third- party service providers for locations of interest. F R-03. 26 The Data Dissemination subsystem shall send road weather event information to Rural Agency Personnel. F R-03. 27 The Data Dissemination subsystem shall configure the dissemination flows based on Rural Agency Personnel selection. F R-03. 28 The Data Dissemination subsystem shall configure the data presentation ( level of detail) based on Rural Agency Personnel selection. F R-04 The following requirements define the functions of the incident response and management applications. F R-04. 01 OBUs shall broadcast a DN when they have been involved in an incident. F R-04. 02 OBUs shall store DNs received from other OBUs until broadcast to Connected Vehicle Roadside Equipment. F R-04. 03 OBUs shall send DNs to Connected Vehicle Roadside Equipment when the DN service is advertised. F R-04. 04 Connected Vehicle Roadside Equipment shall collect DNs from OBUs. F R-04. 05 Connected Vehicle Roadside Equipment shall collect incident data from OBUs. F R-04. 06 The Data Collection subsystem shall collect incident data from ITS Roadway Equipment. F R-04. 07 The Data Collection subsystem shall collect DN data from Connected Vehicle Roadside Equipment. F R-04. 08 The Data Collection subsystem shall collect incident data from Connected Vehicle Roadside Equipment. F R-04. 09 The Data Collection subsystem shall collect incident data from third- party service providers. F R-04. 10 The Data Collection subsystem shall collect incident data from the Cloud. F R-04. 11 The Data F usion subsystem shall fuse DN data and incident data. F R-04. 12 The Data Storage subsystem shall store the fused DN and incident data. F R-04. 13 The Decision Support subsystem shall analyz e fused DN and incident data to determine where an incident has occurred. F R-04. 14 The Data Dissemination subsystem shall provide fused DN and incident information to the Maintenance Management System. F unctio nal Requirements Table 5. (Continued).
System Requirements 21  F R-04. 15 The Data Dissemination subsystem shall provide incident information to Emergency Management/ Public Safety System. F R-04. 16 The Data Dissemination subsystem shall provide fused DN and incident information to the F leet and F reight Management System. F R-04. 17 The Data Collection subsystem shall collect incident data from Emergency Management/ Public Safety System. F R-05 The following requirements define the functions of the rural safety strategies applications. F R-05. 01 Connected Vehicle Roadside Equipment shall collect rural safety data from ITS Roadway Equipment. F R-05. 02 Connected Vehicle Roadside Equipment shall collect rural safety data from mobile units ( pedestrian/ bicycle devices that send PSMs) . F R-05. 03 Connected Vehicle Roadside Equipment shall broadcast rural safety information utiliz ing SAE J2735 messages. F R-05. 04 The OBU shall be capable of receiving rural safety information in SAE J2735 defined messages. F R-05. 05 The OBU shall present rural safety information to the driver. F R-06 The following requirements define the functions of the freight operations applications. F R-06 . 01 OBUs shall broadcast freight operations data utiliz ing SAE J2735 defined messages. F R-06 . 02 Connected Vehicle Roadside Equipment shall collect freight operations data from OBUs. F R-06 . 03 The Data Collection subsystem shall collect freight operations data from the Maintenance Management System. F R-06 . 04 The Data Collection subsystem shall collect freight operations data from Rural Agency Personnel. F R-06 . 05 The Data Collection subsystem shall collect freight operations data from the Traveler Information System. F R-06 . 06 The Data Collection subsystem shall collect freight operations data from other Traffic Management Center systems. F R-06 . 07 The Data Collection subsystem shall collect freight operations data from Connected Vehicle Roadside Equipment. F R-06 . 08 The Data Collection subsystem shall collect freight operations data from F leet and F reight Management System. F R-06 . 09 The Data Storage subsystem shall store freight operations data. F R-06 . 10 The Data Dissemination subsystem shall send freight operations information to Connected Vehicle Roadside Equipment. F R-06 . 11 The Data Dissemination subsystem shall send freight operations information to the Cloud. F R-06 . 12 The Data Dissemination subsystem shall send freight operations information to F leet and F reight Management Systems. F R-06 . 13 The Data Dissemination subsystem shall send freight operations information to third- party service providers. F R-06 . 14 Connected Vehicle Roadside Equipment shall broadcast freight operations information to OBUs utiliz ing SAE J2735 defined messages. F R-06 . 15 The Cloud shall send freight operations information to OBUs. F R-06 . 16 The Data Dissemination subsystem shall provide freight operations information to the Traveler Information System. F unctio nal Requirements Table 5. (Continued).
22 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors 3.2 Physical Requirements is section describes the requirements for the physical aspects of rural connected vehicle deployment. Physical requirements refer to the hardware aspects of the devices or elements of the system. ese requirements de ne size constraints on a device, the environments the device must operate in, and how durable the device needs to be. e physical requirements are grouped into four categories: Construction, Durability, Adaptability, and Environmental Conditions. 3.2.1 Construction ese construction requirements de ne the physical aspects of the device, including what types of ports the device will have, any speci c mounting con gurations, and other physical characteristics of the device (see Table 6). 3.2.2 Durability e physical durability requirements detail what types of adverse conditions the device must be able to withstand (see Table 7). ese requirements may specify when a device must be removed and replaced. P h y sical Requirements P RC -01 Connected Vehicle Roadside Equipment shall be connected to the backhaul network from roadside cabinets. P RC -02 Connected Vehicle Roadside Equipment antennas shall be installed to provide effective connection. P RC -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. P RC -02. 2 Connected Vehicle Roadside Equipment G lobal Positioning System ( G PS) antenna shall be positioned to have a clear view of the sky for all seasons. P RC -03 Connected Vehicle Roadside Equipment shall be connected to power from roadside cabinets. P RC -03. 1 All connections to the Connected Vehicle Roadside Equipment shall be protected from lightning and power surges. P RC -03. 2 Connected Vehicle Roadside Equipment shall not overload the Type 2 PoE+ ( IEEE 802.3at- 2009) 25.5- watt power supplies provided. P RC -03. 3 Connected Vehicle Roadside Equipment shall withstand electrostatic discharge ( ESD) from ex ternal sources and electrical distribution. P RC -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. P RC -05 Connected Vehicle Roadside Equipment shall be able to resume normal function within 2 minutes of restoration of power. P RC -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.) P RC -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. P RC -06 . 2 OBUs installations shall be performed professionally by technicians trained in the installation of connected vehicle equipment. P RC -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. Table 6. Physical requirements: construction (PRC).
System Requirements 23  P h y sical Requirements P RC -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 ex trication) . P RC -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. P RC -21 The OBU installed on emergency vehicles shall provide at least two G PIO ( general purpose input/ output) ports for interfacing with emergency/ public safety vehicle lights and sirens. P RC -22 The OBU installers shall document installation information. ( Note to installer: Ex amples of installation parameters are the OBU serial number, vehicle number, vehicle class, software version, fleet/ agency information, configurable vehicle parameters, and vehicle size / weights) . P RC -23 Connected Vehicle Roadside Equipment installers shall document installation information. ( Note to installer: Ex amples of installation parameters are RSU location, height above roadway, power type, backhaul communication type, serial number, and software version) . P RC -24 All OBUs shall have a F IPS ( F ederal Information Processing Standard) 140- 2 level 2 H ardware Security Module for key storage. P RC -25 All RSUs shall have a F IPS 140- 2 level 2 H ardware Security Module for key storage. P RC -09 The OBU shall withstand electromagnetic interference ( EMI) from light- and heavy- duty vehicle sources. P RC -10 The OBU shall withstand ESD from light- and heavy- duty vehicle sources. P RC -11 The OBU design shall prevent battery drain. P RC -12 The user interface for the OBU shall be visible to the driver, minimiz ing potential distraction. P RC -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. P RC -14 The OBU shall be able to resume normal function within 1 minute of vehicle start. P RC -15 Management and data collection servers shall be installed in the Backoffice protected physical space. P RC -16 The OBU shall contain an OBD- II port, J- bus, or CAN bus. P RC -17 The OBU shall conform to the associated SAE interface requirements for OBD- II port, J- bus, or CAN bus. P RC -18 The OBU interface to the CAN bus, J- bus, or OBD- II shall not degrade or interfere with the vehicle' s normal operation. P RC -07 The OBU shall operate on the voltage supplied by the host vehicle. P RC -08 The current drawn by the OBU shall not ex ceed 60 watts. P h y sical Requirements S p ecific D ev ice/ S y stem/ S ub sy stem P RD -01 Backoffice servers shall have their power source augmented by an uninterruptable power supply ( UPS) . P RD -02 Roadside cabinets shall have their power source augmented by an UPS. P RD -03 The fleet maintenance personnel shall replace OBUs damaged by improper maintenance, tampering, or mishap. P RD -04 The DOT maintenance personnel shall replace RSUs damaged by improper maintenance, tampering, or mishap. P RD -05 The OBU shall be able to detect and reboot after a disruptive software glitch. P RD -06 The DOT maintenance personnel shall be able to reboot RSUs after a disruptive software glitch. Table 7. Physical requirements: durability (PRD). Table 6. (Continued).
24 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors 3.2.3 Adaptability e connected vehicle devices will meet all the indicated adaptability requirements listed within this section (see Table 8). ey address how the system will continue to operate a er the initial deployment, which may entail system expansion, and explain how the system will continue to evolve as new standards, so ware, and hardware are developed. 3.2.4 Environmental Conditions is section de nes system requirements that address environmental conditions that devices need to operate within (see Table 9). ese include traditional weather-related conditions (heat, humidity, moisture, etc.) as well as conditions a person operating a vehicle or device may experience. 3.3 System Performance Characteristics is section de nes the performance requirements for speci c aspects of the system (see Table 10). ese include quantitative criteria covering endurance capabilities of the equip- ment required to meet the user needs under stipulated environmental and other conditions, including operational session duration and planned utilization rate. Performance requirements will also include time-based elements where certain actions must be taken within a speci c amount of time. P h y sical Requirements P RE -01 The audible message volume from the OBU shall be distinguishable from other sounds in light- and heavy- duty vehicles. P RE -02 The audible message volume from the OBU shall be verified in real traffic environments. P RE -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.) P RE -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) . Table 9. Physical requirements: environmental (PRE). P h y sical Requirements P RA -01 The connected vehicle deployment applications shall have modifiable algorithms and software parameters for tuning the systemâ s operation. P RA -02 The OBU shall have upgradable hardware components for improving the device performance upon ex pansion of the system. P RA -03 The RSU shall have upgradable hardware components for improving the device performance upon ex pansion of the system. P RA -04 The backhaul shall have upgradable bandwidth to support system growth. P RA -05 The Backoffice shall have upgradable performance to support system growth. P RA -06 The Backoffice shall have upgradable storage to support system growth. Table 8. Physical requirements: adaptability (PRA).
System Requirements 25  S y stem P erfo rmance Requirements S P R-01 All OBUs shall use the same G PS time source and common accuracy configuration as the DOT infrastructure used for the Backoffice and RSUs. S P R-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 agencyâ s connected vehicle applications, 250 milliseconds is an ex ample that has been used for the NY C CV Pilot and is not prescriptive.) S P R-03 The OBUs shall process all radio messages at a minimum rate of 10 H z with SCMS integration. This includes all messages on all channels [ e.g., BSM, TIM, Signal Status Message ( SSM) , Signal Request Message ( SRM) , MAP, SPaT, etc.) in addition to Internet Protocol ( IP) communications traffic] . S P R-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. Also, see appendix of the W Y DOT SyRS for an ex ample.) S P R-05 The OBUs shall be certified through OmniAir ( or other certification entity) for connected vehicle use. S P R-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.) S P R-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.) S P R-07 . 1 The OBU shall retain a rolling log with the last 10 seconds history of sent BSMs at 10 H z . S P R-07 . 2 The OBU shall retain a rolling log with the last 10 seconds history of received BSMs at 10 H z. S P R-07 . 3 Each BSM log entry shall identify the BSM as a local or remote vehicle. S P R-07 . 4 Each driver alert log shall include 10 seconds before the alert for the local vehicle BSMs at 10 H z . S P R-7 . 5 Each driver alert log shall include 10 seconds before the alert for the remote vehicle BSMs at 10 H z. S P R-07 . 6 F or the first 60 seconds duration of driver alerts, the OBU shall log local BSMs at 10 H z. S P R-07 . 7 F or the first 60 seconds duration of driver alerts, the OBU shall log remote BSMs at 10 H z. S P R-07 . 8 F or driver alerts lasting beyond 60 seconds, after the first 60 seconds, local BSM logging shall log at 1 H z. S P R-07 . 9 F or driver alerts lasting beyond 60 seconds, after the first 60 seconds, remote BSM logging shall log at 1 H z. S P R-07 . 10 After a driver alert ends, the OBU shall log 10 seconds of local and remote BSMs at 10 H z. S P R-07 . 11 Each OBU log entry shall include a Coordinated Universal Time ( UTC) stamp accurate to 10 milliseconds. S P R-07 . 12 The OBU shall log each MAP from the nearest RSU. S P R-07 . 13 The OBU shall log each SPaT from the nearest RSU. S P R-07 . 14 The OBU shall log each TIM from the nearest RSU. S P R-07 . 15 The OBU shall log each PDM from the nearest RSU. S P R-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.) S P R-09 The OBU shall include an accelerometer for each of the three ax es. S P R-10 The OBU shall continuously update its location as described in SAE J2945/ 1. S P R-11 The OBU shall be able to upload event logs through an RSU when the service is available to the Backoffice. Table 10. System performance requirements (SPR). (continued on next page)
26 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors 3.4 System Security System security is of the utmost importance from both a personally identi able information (PII) perspective as well as a system intrusion (hacking) perspective. e requirements in the section are more numerous and detailed than in other sections to assist agencies with what was commonly described in agency interviews as a concern and an area of knowledge that could use augmentation with existing sta (see Table 11). e system security requirements in this section focus on describing those security systems that are speci c to connected vehicle deployments. S y stem S ecurity Requirements S S R-01 The connected vehicle environment shall have mechanisms for identifying misbehaving devices and minimiz ing misbehaving devicesâ impact on connected vehicle communications. S S R-01. 01 Connected Vehicle Roadside Equipment and OBUs shall detect misbehaving devices as defined in the L ist of Misbehaviors F ile found at https: / / github.com/ Noblis/ Misbehavior- Detection. S S R-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. S S R-01. 03 Connected Vehicle Roadside Equipment and OBUs shall download Certificate Revocation L ists ( CRL s) from the SCMS. S S R-01. 04 Connected Vehicle Roadside Equipment and OBUs shall use their CRL s to validate signed connected vehicle messages. S S R-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. S S R-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. S S R-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 vehiclesâ speeds and traj ectories) . d) The host vehicle constitutes a threat to a pedestrian using a connected vehicle equipped PID. e) Other potential threat situations arise, such as infrastructure siz e restrictions, speed compliance, red- light violations, and other safety applications. Table 11. System security requirements (SSR). S y stem P erfo rmance Requirements S P R-12 Connected Vehicle Roadside Equipment shall process all radio messages at a minimum rate of 10 H z with SCMS integration. S P R-13 Connected Vehicle Roadside Equipment shall interface with signal controllers, vehicles, and pedestrians. ( Details are defined in the design phase.) S P R-14 Connected Vehicle Roadside Equipment shall be certified through OmniAir ( or other certification entity) for connected vehicle use. S P R-15 Connected Vehicle Roadside Equipment shall log all received BSMs at a rate configurable by the Device Control and Monitoring system up to 10 H z . S P R-16 Each Connected Vehicle Roadside Equipment log entry shall include a UTC stamp accurate to 10 milliseconds. S P R-17 Connected Vehicle Roadside Equipment shall send logs to the Backoffice every 5 minutes. Table 10. (Continued).
System Requirements 27  (continued on next page) S y stem S ecurity Requirements S S R-15 If the host processor fails the integrity checks, it shall not allow any privileged application to operate. S S R-16 The host processor shall conduct an integrity check to ensure that stored root Certification Authority ( CA) certificates have not been modified since they were last accessed. S S R-17 If the integrity check fails, the device shall rej ect all incoming signed messages that chain back to those root CA certificates as invalid. S S R-18 The discretionary access control mechanisms of the host processor operating system ( OS) shall be configured to specify the set of roles that has ex ecute permissions on each private key stored within the H ardware Security Module ( H SM) . S S R-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. S S R-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. S S R-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. S S R-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. S S R-22 The host processor OS shall allow processes that correspond to privileged applications to operate without ex plicit authentication by a user. S S R-23 The host processor OS shall allow processes that update private key material within the H SM to operate without ex plicit authentication by a user. S S R-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. S S R-25 The host processor OS shall allow processes to write private key material to the H SM. S S R-26 The host processor OS shall require ex plicit authentication for processes that modify or inspect ex ecuting processes. S S R-27 The OS shall not allow processes that read private cryptographic key material from the H SM. S S R-05 All W ireless Access in Vehicular Environments ( W AVE) devices ( i.e., PID, OBU, RSU) shall comply with IEEE 1609.2: Standard for W AVEâS ecurity Services for Applications and Management Messages. S S R-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 proj ect, and it is important to get devices from vendors with support for over- the- air ( OTA) updates and in a functional state. TH EA created additional details about this requirement in the Security Management Operating Concept sections TH EA- SEC- 034 through TH EA- SEC- 051.) S S R-07 The host processor and its operating software shall be delivered such that required security protections are implemented. ( Note to agency: W hen devices are enrolled in the SCMS, security protections are required.) S S R-08 If the host processor is initialize d 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.) S S R-09 Any W AVE 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. S S R-10 The host processor and its operating software shall perform an integrity check on boot. S S R-11 If the host processor and its operating software determine there is an error during the integrity check, it shall not continue. S S R-11. 01 If the host processor and its operating software determine there is an error during the integrity check, it shall log the error. S S R-12 The host processor integrity checks shall require the use of a hardware - protected value. S S R-13 The host processor shall not allow any privileged application to request digital signing until the integrity checks have passed. S S R-14 If the host processor fails the integrity checks, it shall not grant access for any process to private keys. Table 11. (Continued).
28 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors S y stem S ecurity Requirements S S R-38 A Message Authentication Code shall not be used to protect the software unless the Message Authentication Code key is unique to the H SM. S S R-39 Cryptographic information shall be managed based on F IPS 140- 2. [ Note to agency: H ere are some specific items to consider with cryptographic information assembled by the TH EA 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 F IPS 140- 2 Annex B and is capable of evaluation at the Common Criteria ( CC) evaluation assurance level ( EAL ) 2, or an equivalent trusted OS.] S S R-40 To protect plaintex t 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 ex ecute stored cryptographic software and firmware. S S R-41 To protect plaintex t 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. S S R-42 To protect plaintex t 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. S S R-43 To protect plaintex t 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 ex ecute stored cryptographic software and firmware. S S R-44 The OS shall prevent all operators without the appropriate permissions ( i.e., non- system admin) and ex ecuting processes from modifying ex ecuting cryptographic processes ( i.e., loading and ex ecuting cryptographic program images) . S S R-45 The OS shall prevent operators without the appropriate permissions ( i.e., non- system admin) and ex ecuting processes from reading cryptographic software stored within the cryptographic boundary. S S R-28 The host processor shall require that all software installed be signed by a root of trust contained in the H SM. S S R-29 The integrity of the verification key shall be protected by H SM. S S R-30 The host processor shall require that software be installed only by an authenticated user. S S R-31 The vendor- supplied update mechanism for the host processor shall include mechanisms to prevent updates from being rolled back. S S R-32 If an update fails, the host processor shall notify the update mechanism of the failure. S S R-33 If the update mechanism receives an update failure, it shall publish a notification of the failure and request authoriza tion to instruct the host processor to roll back. S S R-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. ) S S R-34. 01 All cryptographic software shall be managed in a form that protects software from unauthoriz ed disclosure and/ or modification. ( Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) S S R-34. 02 All cryptographic firmware shall be managed in a form that protects firmware from unauthoriz ed disclosure and/ or modification. ( Note to agency: This should cover both source code and binaries. Verify with a certificate of compliance from the vendor.) S S R-35 The H SM shall be certified by one of the approved certification entities or if they are not available, the H SM shall be self- certified by the vendor at a minimum. S S R-36 A cryptographic mechanism using an approved integrity technique shall be applied to all cryptographic software and firmware components within the H SM. S S R-37 If the H SM itself calculates the Message Authentication Code when the software is installed using a secret key known only to the H SM 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. Table 11. (Continued).
System Requirements 29  (continued on next page) S y stem S ecurity Requirements S S R-56 OBU devices shall support the ability to reset default usernames and passwords by users with Administrative functions ( ENG , MRG , and Admin) . S S R-57 OBUs shall meet F IPS- 140- 2 L evel 2 or equivalent. S S R-58 OBUs shall not support remote access of the connected vehicle applications. S S R-59 OBUs shall support role- based authentication to enable physical access. S S R-6 0 OBUs shall support physical access to support bootstrapping activities. S S R-6 1 The OBU shall support a secure session protocol to the TMC for protecting the firmware download. S S R-6 2 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.) S S R-6 3 The OBU shall implement a download protocol that permits resumption of incomplete downloads instead of requiring an incomplete download to be restarted. S S R-6 4 The OBU shall obtain certificates via IPv6 connectivity through the RSU. S S R-6 5 The SCMS application programming interfaces ( APIs) shall track the ex pected ex piry times of OBU enrollment certificates. S S R-6 6 Communication between the OBU and the SCMS shall operate in an encrypted, end - to- end connection in accordance with the published SCMS interface. S S R-6 7 The OBU shall log an event report every second for which channel busy ratios go above a configurable threshold. S S R-6 8 Connected Vehicle Roadside Equipment shall support setting the â certificate geographic regionâ to be requested for â application certificates.â S S R-6 9 The system administrators shall configure the Connected Vehicle Roadside Equipment to request application certificates with only designated geographic locations. S S R-7 0 Connected Vehicle Roadside Equipment supplier shall provide the enrollment certificate for each RSU. S S R-7 1 Connected Vehicle Roadside Equipment supplier shall provide the serial number for each RSU. S S R-46 The H SM shall maintain two roles: User, who can ex ecute software and firmware, write and delete cryptographic keys, and install signed software and firmware; and Security Officer, who can install unsigned software and firmware if specializ ed new software and firmware are being tested and troubleshot. S S R-47 Activities carried out by the User role shall not be ex plicitly authenticated, once the User role has successfully logged in. S S R-48 In a networked architecture that includes the host processor, other processors, and the H SM, the host processor shall authenticate itself to the H SM with an authentication mechanism based in hardware with the same physical security as the H SM. S S R-49 If the OBU determines that it has been blacklisted, it shall cease transmission of BSMs. S S R-50 The OBU shall prevent incoming messages with invalid conditions from being acted on per criteria in the IEEE 1609.2. S S R-51 The OBU shall carry out misbehavior checking on the remote vehicle BSM data. S S R-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.] S S R-52-01 OBUs shall use temporary identifiers to protect transmissions against inadvertently providing PII. S S R-52-02 OBUs shall use one- time identifiers to protect transmissions against inadvertently providing PII. S S R-53 All OBU unused media ports shall be sealed with a removable tamper- evident seal, at a minimum. S S R-54 PID devices shall support security requirements identified in SAE J2945/ 1, such as the BSM transmission and reception security profile. S S R-55 OBU devices shall support security requirements identified in SAE J2945/ 1, such as the BSM transmission and reception security profile. Table 11. (Continued).
30 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors S y stem S ecurity Requirements S S R-8 3. 02 The RSU W SA for certificate download shall advertise a channel other than 178 or 172 if DSRC is being used. S S R-8 4 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. S S R-8 5 Connected Vehicle Roadside Equipment shall support IPv6 tunneling over IPv4. S S R-8 6 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. S S R-8 7 Connected Vehicle Roadside Equipment shall report over a management interface if channel busy ratios go above a configurable threshold. S S R-8 8 PIDs shall meet F IPS 140- 2 L evel 2 or equivalent. S S R-8 9 PIDs shall not support remote access of the connected vehicle applications. S S R-9 0 ITS Roadway Equipment communications shall be developed to meet F IPS 140- 2 L evel 2 or equivalent. S S R-9 1 New field cabinets shall include tamper alerts. S S R-9 2 New field cabinet tamper alerts shall be sent to the TMC when the tamper seal is broken. S S R-9 3 ITS Roadside Equipment devices shall support remote authenticated access. S S R-9 4 Connected Vehicle datasets shall be required to have PII information removed before being made publicly available. [ Note to agency: Connected vehicle datasets may contain PII ( BSM around home/ work, installation documentation, driver identification for training, etc.) . W hen this is the case, precautions should be taken to ensure this is protected from unauthoriz ed ex posure.] S S R-9 5 Monitoring systems shall be enabled and used to perform intrusion detection for connected vehicle systems. S S R-9 6 Monitoring systems for connected vehicle systems shall be enabled and used to detect abnormal unauthorize d activity on an IP connection. S S R-9 7 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) . S S R-9 8 No person shall transfer connected vehicle PII information in an unencrypted state. S S R-7 2 Connected Vehicle Roadside Equipment shall support a secure session protocol to the TMC for protecting the firmware download. S S R-7 3 Connected Vehicle Roadside Equipment shall implement a download protocol that permits resumption of incomplete downloads instead of requiring an incomplete download to be restarted. S S R-7 4 Connected Vehicle Roadside Equipment shall meet the W AVE Service Advertisement ( W SA) security profile covered in IEEE 1609.3 ( 2016) . S S R-7 5 Connected Vehicle Roadside Equipment shall meet the SPaT, MAP, and TIM security profiles. S S R-7 6 Connected Vehicle Roadside Equipment shall support security requirements identified in Section 6.5 of SAE J2945/ 1. S S R-7 7 Connected Vehicle Roadside Equipment shall support the ability to reset default usernames and passwords by users with Administrative functions ( ENG , MRG , and Admin) . S S R-7 8 Connected Vehicle Roadside Equipment shall meet F IPS 140- 2 L evel 2 or equivalent. S S R-7 9 Connected Vehicle Roadside Equipment shall support remote authenticated access. S S R-8 0 Connected Vehicle Roadside Equipment shall support physical access to support bootstrapping activities. S S R-8 1 Connected Vehicle Roadside Equipment shall support role- based authentication to enable physical access. S S R-8 2 Connected Vehicle Roadside Equipment unused media ports shall be sealed with a removable tamper- evident seal, at a minimum. S S R-8 3 The RSU shall broadcast the W SA for certificate download on control channel 178 if DSRC is being used. S S R-8 3. 01 The RSU W SA for certificate download shall contain an advertisement for IPv6 services. Table 11. (Continued).
System Requirements 31  Information Management Requirements 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. 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.) 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. Table 12. Information management requirements. 3.5 Information Management Information management de nes the system requirements for managing the data within the system (see Table 12). e connected vehicle system shall manage participantsâ personal data and system-generated data. 3.6 System Operations System-generated data is created by the applications as part of their functionality. is data may be used by other applications to perform calculations and analysis such that the applica- tions can perform their intended function. All devices (i.e., RSU, OBU, and PID) create system- generated data. 3.6.1 System Human Factors e Human Use Approval and Informed Consent outlines the interaction between partici- pants and the connected vehicle devices. Participants will not be required to react to alerts or
32 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors warnings from devices they are presented with. However, participants may act because of the alert they received (e.g., applying the brake, turning around). ese actions are outside the control of the rural connected vehicle system. Participants will be trained on what alerts mean and possible responses. It is up to the participant to evaluate the overall situation and determine their best course of action based on their knowledge and experience. ese requirements are written from the point of view of state/local eet vehicle users that have connected vehicle devices in their vehicles; however, these may also apply to any private or commercial vehicle operators that are installing connected vehicle devices participating in your system (see Table 13). 3.6.2 System Maintainability System maintainability describes the requirements necessary to perform planned mainte- nance and emergency maintenance during the operation of the rural connected vehicle system in a timely and ecient manner. Table 14 describes these requirements. H uman F acto rs Requirements H F R-01 The system administrator shall be able to change the volume level of the audio output ( e.g., speakers) . ( Note to agency: The W Y DOT CV Pilot deployed two OBUs: one with user- controlled speaker volume and one with administrative control. W Y DOT found user- controlled volume was less effective. W hich OBU to use should be a decision made by each deploying agency.) H F R-02 The OBU shall have the ability to operate in either silent mode or active mode. H F R-03 The OBU shall record events without audibly notifying the driver when operating in silent mode. H F R-04 The OBU shall record events while audibly notifying the driver when operating in active mode. H F R-05 The OBU shall set the application alert mode to silent mode or active mode per the most recent parameters downloaded. H F R-06 The location where the H uman Machine Interface ( H MI) 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. H F R-07 The H MI shall minimize the â eyes off the roadâ time when presenting information for an application. H F R-08 The H MI shall provide messages that can be read from the driverâ s normal seating position. H F R-09 The H MI shall include both a visual and auditory interface for presenting alerts and advisories. H F R-10 The H MI shall maintain a consistent structure across applications for presenting information to drivers and inputs to the system. H F R-11 Auditory signals shall be loud enough to overcome masking sounds from road noise, the cab environment, and other equipment. H F R-12 H MI characteristics shall be customiza ble to reflect driver preferences. Preferences that shall be customiza ble are as follows: ⢠Brightness ⢠Contrast tex t size ⢠Display contrast ⢠Mounting eye position H F R-13 The H MI shall notify the driver of the power status of the device with the screen graphics ( i.e., off, powering up, and online) . H F R-14 The H MI shall allow the driver to see the system settings of the device with screen graphics ( i.e., version, brightness, volume, font size ) . H F R-15 The H MI shall allow the driver to see application availability with screen graphics ( i.e., failed, operating, disabled) . H F R-16 The H MI shall allow the driver to see pending updates for the device with screen graphics ( i.e., applications, firmware, OS) at bootup. Table 13. Human factors requirements (HFR).
System Requirements 33  System Maintainability Requirements 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. 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 Confidentiality/Integrity/Availability (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 forward collision warning (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 radio frequency (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. Table 14. System maintainability requirements (SMR). (continued on next page)
34 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors S y stem M aintainab ility Requirements S M R-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. S M R-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. S M R-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. S M R-25 The OBU RF L og Entries shall be stored in the OBU local memory. S M R-26 The OBU RF log entries shall be purged after 7 days. S M R-27 The OBU RF log space shall be sufficient to store 7 days of interactions with the ex pected number of vehicles and the ex pected number of RSUs ( assuming an ex pected number of entries per day) . ( Note to agency: The ex pected number of vehicle interactions and RSU interactions will vary based on density of RSUs and vehicles in the rural deployment. F or ex ample, NY C CV Pilot ex pected about 5,000/ day, and W Y DOT ex pected about 500/ day. Update numbers based on the agency deployment ex pectation.) S M R-28 If the OBU RF log files ex ceed the space allocated, then the oldest data shall be written over without damaging newer log files. S M R-29 The following requirements shall apply to the OBU RF data monitoring, uploading, and purging. S M R-29 . 1 The OBU shall monitor the control channel when the OBU encounters an RSU that supports the RF data upload. S M R-29 . 2 The OBU shall upload the contents of the RF logs to the Backoffice systems. S M R-29 . 3 The OBU shall purge the logs after they have been acknowledged by the RSU. S M R-30 The OBU shall authenticate all transactions to retrieve the RF logs. S M R-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. S M R-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. S M R-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. S M R-34 Once the RF log data is received and acknowledged by the Backoffice system, it shall be purged from the Connected Vehicle Roadside Equipment. S M R-35 Connected Vehicle Roadside Equipment shall authenticate all transactions to retrieve its RF logs. S M R-36 Connected Vehicle Roadside Equipment shall allow recording of the RF signal level for any message received. S M R-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 z ones on trailers.) S M R-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. S M R-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. S M R-40 Connected Vehicle Roadside Equipment communication shall be restored in accordance with the agency DOT response time for critical field equipment. S M R-41 Connected Vehicle Roadside Equipment hardware failures shall be addressed in accordance with the agency DOT response time for critical field equipment. S M R-42 Connected Vehicle Roadside Equipment application issues shall be responded to in accordance with the agency DOT response time for critical field equipment. S M R-43 Planned Connected Vehicle Roadside Equipment maintenance shall be scheduled in accordance with the agency DOT response time for critical field equipment. S M R-44 Planned Connected Vehicle Roadside Equipment maintenance shall be performed during off- peak hours of the agency DOT' s operation. S M R-45 OBU failures shall be logged at the time they are reported. Table 14. (Continued).
System Requirements 35  S y stem Reliab ility Requirements S p ecific D ev ice/ S y stem/ S ub sy stem S RR-01 The OBU shall revert to a failsafe mode when unable to perform its normal operations. S RR-02 Connected Vehicle Roadside Equipment shall revert to a failsafe mode when unable to perform its normal operations. S RR-03 The OBU shall report a self- diagnosed failure of itself or one of its software modules ( 1) to Connected Vehicle Roadside Equipment attempting to install new firmware or parameters and ( 2) to a device connected to the OBUâ s maintenance port. S RR-04 Connected Vehicle Roadside Equipment shall report a self- diagnosed failure through the backhaul to the Backoffice. S RR-05 The Backoffice system shall be available 24 hours a day, 365 days a year with downtime periods that do not ex ceed 24 consecutive hours. Table 15. System reliability requirements (SRR). S y stem M aintainab ility Requirements S M R-46 Support staff shall be trained to troubleshoot and diagnose Connected Vehicle Roadside Equipment, OBU, and PID issues. S M R-47 The Backoffice shall provide the Backoffice administration team the ability to push out OTA firmware updates to the OBUs. S M R-48 The Backoffice shall provide the Backoffice administration team the ability to push out OTA H MI updates to the OBUs. S M R-49 The Backoffice shall provide the Backoffice administration team the ability to push out OTA control parameter updates to the OBUs. S M R-50 The Backoffice shall provide the Backoffice administration team the ability to push out firmware updates to the RSUs. Table 14. (Continued). 3.6.3 System Reliability e rural connected vehicle system divides system reliability into RSU, OBU (or PID), and data. System reliability requirements should be expressed in quantitative terms and should de ne the conditions under which the reliability requirements are to be met. Table 15 de nes the base system reliability requirements. Readers should add speci c requirements consistent with the agencyâs reliability policies and practices. 3.7 Policy and Regulation Organizational policies, external regulatory policies, and normal business practices describe how these policies and practices a ect system operation and performance. Table 16 de nes the policy and regulation requirements for the model SyRS. Additional requirements related to speci c policies or regulations may be necessary for individual states or localities. P o licy and Reg ulatio n Requirements P RR-01 Proper F ederal Communications Commission ( F CC) licensing to broadcast messages from Connected Vehicle Roadside Equipment shall be obtained before device installation. P RR-02 The OBU installation procedure shall stipulate wire routing. Table 16. Policy and regulation requirements (PRR).
36 Initiating the Systems Engineering Process for Rural Connected Vehicle Corridors 3.8 System Lifecycle Sustainment System lifecycle sustainment describes the quality activities, such as review, measurement collection, and analysis, to realize a quality system. During the initial stages of the systems engi- neering process, the produced documents, such as ConOps, SyRS, Safety Management Plan, Security Management Operating Concept, and Performance Measurement Management Plan, to name a few, are reviewed by stakeholders, partners, and other interested parties. Comments on these documents are addressed to form a complete picture of the system. ese reviews ensure the system is based on quality concepts. As the project progresses, the continued review of systems engineering documentation and peer review of application development products promote the successful implementation of the requirements, which trace back to the user needs. In the testing phase of systems engineering, the system is tested on several levels, sometimes de ned as unit testing, module/subsystem testing, integration testing, and acceptance testing. Once the system is deployed and initial data is archived, the performance measurement evaluation process begins. Performance measures determine if and how much the system is improving the issues/situations that exist. Using the same data, system quality and reliability can be accessed. If the data shows the appropriate data is being sent and received by devices and the appropriate alerts are being broadcast, the system is seen as functioning properly within its parameters. Error logs are monitored to determine if some part of the system may be experi- encing problems. As the data is analyzed and experience is gained using the system, new ideas and enhance- ments will be realized. ese ideas and enhancements will be analyzed to determine the impact they could have on improving the system and fed back into the systems engineering process. For this model SyRS, one system lifecycle sustainment requirement is identi ed (see Table 17). S y stem L ifecy cle S ustainment Requirements Specific Device/ System/ Subsystem L C R-01 The OBU shall meet OmniAir certification criteria based on procurement documents. Table 17. System lifecycle sustainment requirements (LCR).
