VS16: Vehicle Cooperative Maneuvers
This service package provides coordinated merge and lane change operations between connected vehicles, whether automated or not. It covers all levels of cooperation including status sharing, intent-sharing, agreement-seeking and prescriptive cooperation as defined in SAE J3216.
Relevant Regions: Australia, Canada, European Union, and United States
- Enterprise
- Functional
- Physical
- Goals and Objectives
- Needs and Requirements
- Sources
- Security
- Standards
- System Requirements
- Implementations
Enterprise
Development Stage Roles and Relationships
Installation Stage Roles and Relationships
Operations and Maintenance Stage Roles and Relationships
(hide)
| Source | Destination | Role/Relationship |
|---|---|---|
| Basic Vehicle Maintainer | Basic Vehicle | Maintains |
| Basic Vehicle Manager | Basic Vehicle | Manages |
| Basic Vehicle Manager | Driver | System Usage Agreement |
| Basic Vehicle Owner | Basic Vehicle Maintainer | System Maintenance Agreement |
| Basic Vehicle Owner | Basic Vehicle Manager | Operations Agreement |
| Basic Vehicle Owner | Driver | Application Usage Agreement |
| Basic Vehicle Owner | Driver | Vehicle Operating Agreement |
| Basic Vehicle Owner | Vehicle Maintainer | Maintenance Data Exchange Agreement |
| Basic Vehicle Owner | Vehicle Owner | Expectation of Data Provision |
| Basic Vehicle Owner | Vehicle User | Service Usage Agreement |
| Basic Vehicle Supplier | Basic Vehicle Owner | Warranty |
| Connected Vehicle Roadside Equipment Maintainer | Connected Vehicle Roadside Equipment | Maintains |
| Connected Vehicle Roadside Equipment Manager | Connected Vehicle Roadside Equipment | Manages |
| Connected Vehicle Roadside Equipment Manager | Connected Vehicle Roadside Equipment Operator | System Usage Agreement |
| Connected Vehicle Roadside Equipment Operator | Connected Vehicle Roadside Equipment | Operates |
| Connected Vehicle Roadside Equipment Owner | Connected Vehicle Roadside Equipment Maintainer | System Maintenance Agreement |
| Connected Vehicle Roadside Equipment Owner | Connected Vehicle Roadside Equipment Manager | Operations Agreement |
| Connected Vehicle Roadside Equipment Owner | Driver | Application Usage Agreement |
| Connected Vehicle Roadside Equipment Owner | Vehicle Maintainer | Maintenance Data Exchange Agreement |
| Connected Vehicle Roadside Equipment Owner | Vehicle Owner | Expectation of Information Provision |
| Connected Vehicle Roadside Equipment Owner | Vehicle User | Service Usage Agreement |
| Connected Vehicle Roadside Equipment Supplier | Connected Vehicle Roadside Equipment Owner | Warranty |
| Driver | Basic Vehicle | Operates |
| Driver | Vehicle | Operates |
| Emergency Personnel | Emergency Vehicle OBE | Operates |
| Emergency Vehicle OBE Maintainer | Emergency Vehicle OBE | Maintains |
| Emergency Vehicle OBE Manager | Emergency Personnel | System Usage Agreement |
| Emergency Vehicle OBE Manager | Emergency Vehicle OBE | Manages |
| Emergency Vehicle OBE Owner | Driver | Application Usage Agreement |
| Emergency Vehicle OBE Owner | Driver | Vehicle Operating Agreement |
| Emergency Vehicle OBE Owner | Emergency Vehicle OBE Maintainer | System Maintenance Agreement |
| Emergency Vehicle OBE Owner | Emergency Vehicle OBE Manager | Operations Agreement |
| Emergency Vehicle OBE Owner | Vehicle Maintainer | Maintenance Data Exchange Agreement |
| Emergency Vehicle OBE Owner | Vehicle Owner | Expectation of Data Provision |
| Emergency Vehicle OBE Owner | Vehicle User | Service Usage Agreement |
| Emergency Vehicle OBE Supplier | Emergency Vehicle OBE Owner | Warranty |
| ITS Roadway Equipment Maintainer | ITS Roadway Equipment | Maintains |
| ITS Roadway Equipment Manager | ITS Roadway Equipment | Manages |
| ITS Roadway Equipment Manager | Maint and Constr Field Personnel | System Usage Agreement |
| ITS Roadway Equipment Owner | Connected Vehicle Roadside Equipment Maintainer | Maintenance Data Exchange Agreement |
| ITS Roadway Equipment Owner | Connected Vehicle Roadside Equipment Operator | Application Usage Agreement |
| ITS Roadway Equipment Owner | Connected Vehicle Roadside Equipment Owner | Information Exchange and Action Agreement |
| ITS Roadway Equipment Owner | Connected Vehicle Roadside Equipment User | Service Usage Agreement |
| ITS Roadway Equipment Owner | ITS Roadway Equipment Maintainer | System Maintenance Agreement |
| ITS Roadway Equipment Owner | ITS Roadway Equipment Manager | Operations Agreement |
| ITS Roadway Equipment Owner | Multi-Access Edge Computing Maintainer | Maintenance Data Exchange Agreement |
| ITS Roadway Equipment Owner | Multi-Access Edge Computing Operator | Application Usage Agreement |
| ITS Roadway Equipment Owner | Multi-Access Edge Computing Owner | Information Exchange and Action Agreement |
| ITS Roadway Equipment Owner | Multi-Access Edge Computing User | Service Usage Agreement |
| ITS Roadway Equipment Supplier | ITS Roadway Equipment Owner | Warranty |
| Maint and Constr Field Personnel | ITS Roadway Equipment | Operates |
| Multi-Access Edge Computing Maintainer | Multi-Access Edge Computing | Maintains |
| Multi-Access Edge Computing Manager | Multi-Access Edge Computing | Manages |
| Multi-Access Edge Computing Manager | Multi-Access Edge Computing Operator | System Usage Agreement |
| Multi-Access Edge Computing Operator | Multi-Access Edge Computing | Operates |
| Multi-Access Edge Computing Owner | Driver | Application Usage Agreement |
| Multi-Access Edge Computing Owner | Multi-Access Edge Computing Maintainer | System Maintenance Agreement |
| Multi-Access Edge Computing Owner | Multi-Access Edge Computing Manager | Operations Agreement |
| Multi-Access Edge Computing Owner | Vehicle Maintainer | Maintenance Data Exchange Agreement |
| Multi-Access Edge Computing Owner | Vehicle Owner | Expectation of Information Provision |
| Multi-Access Edge Computing Owner | Vehicle User | Service Usage Agreement |
| Multi-Access Edge Computing Supplier | Multi-Access Edge Computing Owner | Warranty |
| Other Vehicle OBEs Operator | Other Vehicles | Operates |
| Other Vehicles Maintainer | Other Vehicles | Maintains |
| Other Vehicles Manager | Other Vehicle OBEs Operator | System Usage Agreement |
| Other Vehicles Manager | Other Vehicles | Manages |
| Other Vehicles Owner | Driver | Application Usage Agreement |
| Other Vehicles Owner | Driver | Vehicle Operating Agreement |
| Other Vehicles Owner | Other Vehicles Maintainer | System Maintenance Agreement |
| Other Vehicles Owner | Other Vehicles Manager | Operations Agreement |
| Other Vehicles Owner | Vehicle Maintainer | Maintenance Data Exchange Agreement |
| Other Vehicles Owner | Vehicle Owner | Expectation of Data Provision |
| Other Vehicles Owner | Vehicle User | Service Usage Agreement |
| Other Vehicles Supplier | Other Vehicles Owner | Warranty |
| Vehicle Maintainer | Vehicle | Maintains |
| Vehicle Manager | Driver | System Usage Agreement |
| Vehicle Manager | Vehicle | Manages |
| Vehicle Owner | Basic Vehicle Maintainer | Maintenance Data Exchange Agreement |
| Vehicle Owner | Basic Vehicle Owner | Expectation of Data Provision |
| Vehicle Owner | Basic Vehicle User | Service Usage Agreement |
| Vehicle Owner | Connected Vehicle Roadside Equipment Maintainer | Maintenance Data Exchange Agreement |
| Vehicle Owner | Connected Vehicle Roadside Equipment Operator | Application Usage Agreement |
| Vehicle Owner | Connected Vehicle Roadside Equipment Owner | Expectation of Data Provision |
| Vehicle Owner | Connected Vehicle Roadside Equipment User | Service Usage Agreement |
| Vehicle Owner | Driver | Application Usage Agreement |
| Vehicle Owner | Driver | Vehicle Operating Agreement |
| Vehicle Owner | Multi-Access Edge Computing Maintainer | Maintenance Data Exchange Agreement |
| Vehicle Owner | Multi-Access Edge Computing Operator | Application Usage Agreement |
| Vehicle Owner | Multi-Access Edge Computing Owner | Expectation of Data Provision |
| Vehicle Owner | Multi-Access Edge Computing User | Service Usage Agreement |
| Vehicle Owner | Other Vehicle OBEs Operator | Application Usage Agreement |
| Vehicle Owner | Other Vehicle OBEs Operator | Vehicle Operating Agreement |
| Vehicle Owner | Other Vehicles Maintainer | Maintenance Data Exchange Agreement |
| Vehicle Owner | Other Vehicles Owner | Expectation of Data Provision |
| Vehicle Owner | Other Vehicles User | Service Usage Agreement |
| Vehicle Owner | Vehicle Maintainer | System Maintenance Agreement |
| Vehicle Owner | Vehicle Manager | Operations Agreement |
| Vehicle Supplier | Vehicle Owner | Warranty |
Functional
This service package includes the following Functional View PSpecs:
Physical
The physical diagram can be viewed in SVG or PNG format and the current format is SVG.SVG Diagram
PNG Diagram
Includes Physical Objects:
| Physical Object | Class | Description |
|---|---|---|
| Basic Vehicle | Vehicle | 'Basic Vehicle' represents a complete operating vehicle. It includes the vehicle platform that interfaces with and hosts ITS electronics and all of the driver convenience and entertainment systems, and other non-ITS electronics on-board the vehicle. Interfaces represent both internal on-board interfaces between ITS equipment and other vehicle systems and other passive and active external interfaces or views of the vehicle that support vehicle/traffic monitoring and management. External interfaces may also represent equipment that is carried into the vehicle (e.g., a smartphone that is brought into the vehicle). Internal interfaces are often implemented through a vehicle databus, which is also included in this object. Note that 'Vehicle' represents the general functions and interfaces that are associated with personal automobiles as well as commercial vehicles, emergency vehicles, transit vehicles, and other specialized vehicles. |
| Connected Vehicle Roadside Equipment | Field | 'Connected Vehicle Roadside Equipment' (CV RSE) represents the Connected Vehicle roadside devices (i.e., Roadside Units (RSUs)) equipped with short range wireless (SRW) communications technology, as well as any other supporting equipment that leverage the RSU and are not described by other objects (e.g., a local roadside processor). CVRSE are used to send messages to, and receive messages from, nearby vehicles and personal devices equipped with compatible communications technology. Communications with adjacent field equipment and back office centers that monitor and control the RSE are also supported. This device operates from a fixed position and may be permanently deployed or a portable device that is located temporarily in the vicinity of a traffic incident, road construction, or a special event. It includes a processor, data storage, and communications capabilities that support secure communications with passing vehicles, other field equipment, and centers. |
| Driver | Vehicle | The 'Driver' represents the person that operates a vehicle on the roadway. Included are operators of private, transit, commercial, and emergency vehicles where the interactions are not particular to the type of vehicle (e.g., interactions supporting vehicle safety applications). The Driver originates driver requests and receives driver information that reflects the interactions which might be useful to all drivers, regardless of vehicle classification. Information and interactions which are unique to drivers of a specific vehicle type (e.g., fleet interactions with transit, commercial, or emergency vehicle drivers) are covered by separate objects. |
| Emergency Vehicle OBE | Vehicle | The 'Emergency Vehicle On-Board Equipment' (OBE) resides in an emergency vehicle and provides the processing, storage, and communications functions that support public safety-related connected vehicle applications. It represents a range of vehicles including those operated by police, fire, and emergency medical services. In addition, it represents other incident response vehicles including towing and recovery vehicles and freeway service patrols. It includes two-way communications to support coordinated response to emergencies. A separate 'Vehicle OBE' physical object supports the general vehicle safety and driver information capabilities that apply to all vehicles, including emergency vehicles. The Emergency Vehicle OBE supplements these general capabilities with capabilities that are specific to emergency vehicles. |
| ITS Roadway Equipment | Field | 'ITS Roadway Equipment' represents the ITS equipment that is distributed on and along the roadway that monitors and controls traffic and monitors and manages the roadway. This physical object includes traffic detectors, environmental sensors, traffic signals, highway advisory radios, dynamic message signs, CCTV cameras and video image processing systems, grade crossing warning systems, and ramp metering systems. Lane management systems and barrier systems that control access to transportation infrastructure such as roadways, bridges and tunnels are also included. This object also provides environmental monitoring including sensors that measure road conditions, surface weather, and vehicle emissions. Work zone systems including work zone surveillance, traffic control, driver warning, and work crew safety systems are also included. |
| Multi-Access Edge Computing | Field | 'Multi-Access Edge Computing' ((MEC) previously known as mobile edge computing) represents computing devices that operate and are managed like a cloud server, but are deployed at the edge of a network (typically a cellular network, but it could be any network). While not in strict proximity to the transportation network, these systems do benefit from vastly decreased distances to the roadway compared to central systems, and so can provide lower latency than strictly backoffice systems |
| Other Vehicles | Vehicle | 'Other Vehicle OBEs' represents other connected vehicles that are communicating with the host vehicle. This includes all connected motorized vehicles including passenger cars, trucks, and motorcycles and specialty vehicles (e.g., maintenance vehicles, transit vehicles) that also include the basic 'Vehicle OBE' functionality that supports V2V communications. This object provides a source and destination for information transfers between connected vehicles. The host vehicle on-board equipment, represented by the Vehicle OBE physical object, sends information to, and receives information from the Other Vehicle OBEs to model all connected vehicle V2V communications in ARC-IT. |
| Potential Obstacles | Field | 'Potential Obstacles' represents any object that possesses the potential of being sensed and struck and thus also possesses physical attributes. Potential Obstacles include roadside obstructions, debris, animals, infrastructure elements (barrels, cones, barriers, etc.) or any other element that is in a potential path of the vehicle. Note that roadside objects and pieces of equipment that can become obstacles in a vehicle’s path can include materials, coatings, or labels (e.g., barcodes) that will improve the performance of the vehicle-based sensors that must detect and avoid these obstacles. See also 'Vulnerable Road Users' that more specifically represents the physical properties of shared users of the roadway that must also be detected. |
| Vehicle | Vehicle | This 'Vehicle' physical object is used to model core capabilities that are common to more than one type of Vehicle. It provides the vehicle-based general sensory, processing, storage, and communications functions that support efficient, safe, and convenient travel. Many of these capabilities (e.g., see the Vehicle Safety service packages) apply to all vehicle types including personal vehicles (including motorcycles), commercial vehicles, emergency vehicles, transit vehicles, and maintenance vehicles. From this perspective, the Vehicle includes the common interfaces and functions that apply to all motorized vehicles. The radio(s) supporting V2V and V2I communications are a key component of the Vehicle. Both one-way and two-way communications options support a spectrum of information services from basic broadcast to advanced personalized information services. Advanced sensors, processors, enhanced driver interfaces, and actuators complement the driver information services so that, in addition to making informed mode and route selections, the driver travels these routes in a safer and more consistent manner. This physical object supports all six levels of driving automation as defined in SAE J3016. Initial collision avoidance functions provide 'vigilant co-pilot' driver warning capabilities. More advanced functions assume limited control of the vehicle to maintain lane position and safe headways. In the most advanced implementations, this Physical Object supports full automation of all aspects of the driving task, aided by communications with other vehicles in the vicinity and in coordination with supporting infrastructure subsystems. |
| Vehicle Characteristics | Vehicle | 'Vehicle Characteristics' represents the external view of individual vehicles of any class from cars and light trucks up to large commercial vehicles and down to micromobility vehicles (MMVs). It includes vehicle physical characteristics such as height, width, length, weight, and other properties (e.g., magnetic properties, number of axles, occupants, emissions) of individual vehicles that can be sensed and measured or classified. This physical object represents the physical properties of vehicles that can be sensed by vehicle-based or infrastructure-based sensors to support vehicle automation and traffic sensor systems. The analog properties provided by this terminator represent the sensor inputs that are used to detect and assess vehicle(s) within the sensor's range to support safe AV operation and/or responsive and safe traffic management. |
| Vulnerable Road Users | Personal | 'Vulnerable Road Users' represents any roadway user not in a motorized vehicle capable of operating at the posted speed for the roadway in question, and also any roadway user in a vehicle not designed to encase (and thus protect) its occupants. This includes pedestrians, cyclists, wheelchair users, two-wheeled scooter micromobility users, as well as powered scooters and motorcycles. Note that this terminator represents the physical properties of vulnerable road users and their conveyance that may be sensed to support safe vehicle automation and traffic management in mixed mode applications where a variety of road users share the right-of-way. See also 'Pedestrian' and 'MMV User' Physical Objects that represent the human interface to these vulnerable road users. |
Includes Functional Objects:
| Functional Object | Description | Physical Object |
|---|---|---|
| EV V2V Safety | 'EV V2V Safety' sends alert messages and exchanges lane change and merge intent with surrounding connected vehicles to improve awareness of the emergency vehicle and enable it to perform lane change and merge maneuvers in a more automated fashion. | Emergency Vehicle OBE |
| MEC Cooperative Vehicle Automation | 'MEC Cooperative Vehicle Automation' provides infrastructure support for Cooperative Driving Automation (CDA), monitoring information shared by passing vehicles and providing information to passing vehicles to support cooperative driving. | Multi-Access Edge Computing |
| MEC Intersection Safety | 'MEC Intersection Safety' uses cellular communications to support connected vehicle applications that improve intersection safety. It communicates with nearby vehicles and ITS infrastructure to alert and warn drivers of potential stop sign, red light, and non-motorized user crossing conflicts or violations. There may be constraints related to performance related to communications with participants using network operators foreign to the MEC. | Multi-Access Edge Computing |
| Roadway Surveillance | 'Roadway Basic Surveillance' monitors traffic conditions using fixed equipment such as loop detectors, CCTV cameras, , RADARs and LIDARs. | ITS Roadway Equipment |
| RSE Cooperative Vehicle Automation | 'RSE Cooperative Vehicle Automation' provides infrastructure support for Cooperative Driving Automation (CDA), monitoring information shared by passing vehicles and providing information to passing vehicles to support cooperative driving. | Connected Vehicle Roadside Equipment |
| RSE Intersection Safety | 'RSE Intersection Safety' uses short range communications to support connected vehicle applications that improve intersection safety. It matches information from multiple sensors or sources to produce vehicle or VRU location data with higher confidence than that from a sole sensor or source. It communicates with approaching vehicles and ITS infrastructure to alert and warn drivers of potential stop sign, red light, and non-motorized user crossing conflicts or violations. | Connected Vehicle Roadside Equipment |
| Vehicle Basic Safety Communication | 'Vehicle Basic Safety Communication' exchanges current vehicle characteristics, location, and motion (including past and intended maneuver) information with other vehicles in the vicinity and the infrastructure, uses that information to calculate vehicle paths, and warns the driver when the potential for an impending collision is detected. If available, map data is used to filter and interpret the relative location and motion of vehicles in the vicinity. Information from on-board sensors (e.g., radars and image processing) are also used, if available, in combination with the V2V communications to detect non-equipped vehicles and corroborate connected vehicle data. This object represents a broad range of implementations ranging from basic Vehicle Awareness Devices that only broadcast vehicle location and motion and provide no driver warnings to advanced integrated safety systems that coordinate maneuvers and may, in addition to warning the driver, provide collision warning information to support automated control functions that can support control intervention. This object can also support broadcasting other vehicle information required for passing through a specific roadway segment such as variables that describe vehicle's characteristics and parameters, driver's preferences in terms of vehicle motion and behavior, etc. | Vehicle |
| Vehicle Control Automation | 'Vehicle Control Automation' provides lateral and/or longitudinal control of a vehicle to allow 'hands off' and/or 'feet off' driving, automating the steering, accelerator, and brake control functions. It builds on the sensors included in 'Vehicle Safety Monitoring' and 'Vehicle Control Warning', receives warnings from 'Vehicle Intersection Movement', and uses the information about the area surrounding the vehicle to safely control the vehicle. It covers the range of incremental control capabilities from driver assistance systems that take over steering or acceleration/deceleration in limited scenarios with direct monitoring by the driver to full automation where all aspects of driving are automated under all roadway and environmental conditions, including providing, receiving, and acting on cooperation-related messaging. | Vehicle |
| Vehicle Control Warning | 'Vehicle Control Warning' monitors areas around the vehicle and provides warnings to a driver so the driver can take action to recover and maintain safe control of the vehicle. It includes lateral warning systems that warn of lane departures and obstacles or vehicles to the sides of the vehicle and longitudinal warning systems that monitor areas in the vehicle path and provide warnings when headways are insufficient or obstacles are detected in front of or behind the vehicle. It includes on-board sensors, including radars and imaging systems, and the driver information system that provides the visual, audible, and/or haptic warnings to the driver. | Vehicle |
Includes Information Flows:
| Information Flow | Description |
|---|---|
| detected obstacles | Notification of a nearby non-vehicular object that does not appear to be equipped with a short range communications device but is detectable using onboard vehicle or infrastructure sensors. This could be anything from a construction barrel to a pedestrian or animal. The flow communicates detected object location, physical characteristics, observable kinematics and confidence in those measures. |
| detected unequipped vehicles and VRUs | Notification of a nearby vehicle (light vehicle, commercial vehicle, MMV etc.) or vulnerable road user that does not appear to be equipped with a short range communications device but is detectable using onboard vehicle or infrastructure sensors. The flow communicates detected vehicle/VRU location, physical characteristics, observable kinematics and confidence in those measures. |
| driver input | Driver input to the vehicle on-board equipment including configuration data, settings and preferences, interactive requests, and control commands. |
| driver input information | Driver input received from the driver-vehicle interface equipment via the vehicle bus. It includes configuration data, settings and preferences, interactive requests, and control commands for the connected vehicle on-board equipment. |
| driver update information | Information provided to the driver-vehicle interface to inform the driver about current conditions, potential hazards, and the current status of vehicle on-board equipment. The flow includes the information to be presented to the driver and associated metadata that supports processing, prioritization, and presentation by the DVI as visual displays, audible information and warnings, and/or haptic feedback. |
| driver updates | Information provided to the driver including visual displays, audible information and warnings, and haptic feedback. The updates inform the driver about current conditions, potential hazards, and the current status of vehicle on-board equipment. |
| host vehicle status | Information provided to the ITS on-board equipment from other systems on the vehicle platform. This includes the current status of the powertrain, steering, and braking systems, and status of other safety and convenience systems. In implementations where GPS is not integrated into the Vehicle On-Board Equipment, the host vehicle is also the source for data describing the vehicle's location in three dimensions (latitude, longitude, elevation) and accurate time that can be used for time synchronization across the ITS environment. |
| intersection geometry | The physical geometry of an intersection covering the location and width of each approaching lane, egress lane, and valid paths between approaches and egresses. This flow also defines the location of stop lines, cross walks, specific traffic law restrictions for the intersection (e.g., turning movement restrictions), and other elements that support calculation of a safe and legal vehicle path through the intersection. |
| intersection status | Current signal phase and timing information for all lanes at a signalized intersection. This flow identifies active lanes and lanes that are being stopped and specifies the length of time that the current state will persist for each lane. It also identifies signal priority and preemption status and pedestrian crossing status information where applicable. It may also include future signal phase and timing information. |
| merge order commands | Instructions for automated vehicles to merge in traffic, including order of merge, lane and other information necessary to consolidate merging vehicles into a single lane. |
| physical presence | Detection of an obstacle. Obstacle could include animals, incident management and construction elements such as cones, barrels and barriers, internal structures such as pillars and poles, rocks in roadway, etc. |
| potential conflict in progress | Information indicating an unusual situation that might indicate potential for a collision. |
| vehicle characteristics | The physical or visible characteristics of individual vehicles that can be used to detect, classify, and monitor vehicles and imaged to uniquely identify vehicles and characterize their performance (e.g., speed, occupants, emissions). |
| vehicle control | Control commands issued to vehicle actuators that control steering, throttle, and braking and other related commands that support safe transition between manual and automated vehicle control. This flow can also deploy restraints and other safety systems when a collision is unavoidable. |
| vehicle control event | Notification that the vehicle has performed an emergency maneuver or action that could impact the safety of surrounding vehicles. This includes hard braking and activation of traction/stability control systems or other actions that warrant immediate notification of surrounding vehicles. The information flow conveys the current vehicle location, path, and current control actions. This may also include the list of maneuvers includes lane changes/departures and overtaking/passing maneuvers. |
| vehicle location and motion | Data describing the vehicle's location in three dimensions, heading, speed, acceleration, braking status, and size. |
| vehicle maneuver coordination | Statements of intent, permission and status of a lane change or merge operation by a connected vehicle |
| vehicle path prediction | The predicted future vehicle path of travel. This flow includes an indication of the future positions of the transmitting vehicle that can be used by receiving vehicles to support coordinated driving maneuvers and enhance in-lane and out-of-lane threat classification. |
| vehicle profile | Information about a vehicle such as vehicle make and model, fuel type, engine type, size and weight, vehicle performance and level of control automation, average emissions, average fuel consumption, passenger occupancy, or other data that can be used to classify vehicle eligibility for access to specific lanes, road segments, or regions or participation in cooperative vehicle control applications. |
| vulnerable road user presence | Detection of pedestrians, cyclists, and other vulnerable road users. This detection is based on physical characteristics of the user and their conveyance, which may be enhanced by design and materials that facilitate sensor-based detection and tracking of vulnerable road users. |
Goals and Objectives
Associated Planning Factors and Goals
| Planning Factor | Goal |
|---|---|
| B. Increase the safety of the transportation system for motorized and nonmotorized users; | Reduce fatalities and injuries |
Associated Objective Categories 
| Objective Category |
|---|
| Safety: Vehicle Crashes and Fatalities |
Associated Objectives and Performance Measures
Since the mapping between objectives and service packages is not always straight-forward and often situation-dependent, these mappings should only be used as a starting point. Users should do their own analysis to identify the best service packages for their region.
Needs and Requirements
| Need | Functional Object | Requirement | ||
|---|---|---|---|---|
| 01 | The Connected Vehicle needs to be able to coordinate a lane change/merge with other vehicles. | EV V2V Safety | 01 | The vehicle shall send maneuver intent information to nearby vehicles and send execution status until the maneuver is completed. |
| MEC Cooperative Vehicle Automation | 01 | The field element shall collect vehicle status information from nearby vehicles. | ||
| 02 | The field element shall provide information supporting cooperative driving to nearby vehicles. | |||
| 03 | The field element shall collect information about detected vehicles and other road users from other field elements. | |||
| 04 | The field element shall collect information about detected vehicles and other road users from vehicles. | |||
| RSE Cooperative Vehicle Automation | 01 | The field element shall collect vehicle status information from nearby vehicles. | ||
| 02 | The field element shall provide information supporting cooperative driving to nearby vehicles. | |||
| 03 | The field element shall collect information about detected vehicles and other road users from other field elements. | |||
| 04 | The field element shall collect information about detected vehicles and other road users from vehicles. | |||
| Vehicle Basic Safety Communication | 16 | The vehicle shall exchange maneuver intent information with nearby vehicles. | ||
| 17 | The vehicle shall respond to maneuver intent information with an indication of acceptance or rejection, as appropriate to the situation. | |||
| 02 | The Driver needs to receive warnings from the vehicle to avoid safety compromising situations with nearby vehicles during lane changes/merges. | MEC Cooperative Vehicle Automation | 03 | The field element shall collect information about detected vehicles and other road users from other field elements. |
| 04 | The field element shall collect information about detected vehicles and other road users from vehicles. | |||
| Roadway Surveillance | 07 | The field element shall detect vehicles and vulnerable road users and share this information with roadside communications equipment. This supports detection of vehicles and vulnerable road users that do not have operable short range communications capabilities. | ||
| RSE Cooperative Vehicle Automation | 03 | The field element shall collect information about detected vehicles and other road users from other field elements. | ||
| 04 | The field element shall collect information about detected vehicles and other road users from vehicles. | |||
| Vehicle Control Warning | 05 | The vehicle shall provide warnings to the driver based on information received from other vehicles regarding potentially hazardous road conditions, road hazards, or pending/in-progress vehicle maneuvers. | ||
| 03 | The Connected Vehicle needs to adapt vehicle control to safety accommodate pending and in progress lane changes/merges in the vicinity. | MEC Cooperative Vehicle Automation | 03 | The field element shall collect information about detected vehicles and other road users from other field elements. |
| 04 | The field element shall collect information about detected vehicles and other road users from vehicles. | |||
| MEC Intersection Safety | 02 | The roadway equipment shall communicate with approaching vehicles to alert and warn drivers of potential stop sign, red light, and non-motorized user crossing conflicts or violations. | ||
| 05 | The roadway equipment shall send to Connected Vehicles intersection signal timing information in order for the vehicle to determine if it will safely cross the intersection given its current speed and location. | |||
| Roadway Surveillance | 07 | The field element shall detect vehicles and vulnerable road users and share this information with roadside communications equipment. This supports detection of vehicles and vulnerable road users that do not have operable short range communications capabilities. | ||
| RSE Cooperative Vehicle Automation | 03 | The field element shall collect information about detected vehicles and other road users from other field elements. | ||
| 04 | The field element shall collect information about detected vehicles and other road users from vehicles. | |||
| RSE Intersection Safety | 02 | The roadway equipment shall communicate with approaching vehicles to alert and warn drivers of potential stop sign, red light, and non-motorized user crossing conflicts or violations. | ||
| 05 | The roadway equipment shall send to Connected Vehicles intersection signal timing information in order for the vehicle to determine if it will safely cross the intersection given its current speed and location. | |||
| Vehicle Control Automation | 16 | The vehicle shall be capable of performing control actions based upon information received from other vehicles regarding their status. This includes intersection-related status, maneuver coordination, and other status information received from vehicles in the vicinity. | ||
Related Sources
| Document Name | Version | Publication Date |
|---|---|---|
| None |
Security
In order to participate in this service package, each physical object should meet or exceed the following security levels.
| Physical Object Security | ||||
|---|---|---|---|---|
| Physical Object | Confidentiality | Integrity | Availability | Security Class |
| Basic Vehicle | ||||
| Connected Vehicle Roadside Equipment | Moderate | High | Moderate | Class 3 |
| Emergency Vehicle OBE | Low | High | Low | Class 3 |
| ITS Roadway Equipment | Moderate | High | Moderate | Class 3 |
| Multi-Access Edge Computing | Moderate | High | Moderate | Class 3 |
| Other Vehicles | Low | High | Moderate | Class 3 |
| Potential Obstacles | ||||
| Vehicle | Low | High | Moderate | Class 3 |
| Vehicle Characteristics | ||||
| Vulnerable Road Users | ||||
In order to participate in this service package, each information flow triple should meet or exceed the following security levels.
| Information Flow Security | |||||
|---|---|---|---|---|---|
| Source | Destination | Information Flow | Confidentiality | Integrity | Availability |
| Basis | Basis | Basis | |||
| Basic Vehicle | Vehicle | driver input information | Moderate | High | High |
| Internal vehicle flow that if reverse engineered could enable third party vehicle control. Largely a competitive question, could be set LOW if manufacturer and operator are not concerned with this type of compromise. | Includes vehicle control commands, which must be timely and accurate to support safe vehicle operation. | Includes vehicle control commands, which must be timely and accurate to support safe vehicle operation. | |||
| Basic Vehicle | Vehicle | host vehicle status | Low | Moderate | High |
| Unlikely that this includes any information that could be used against the originator. | This can be MODERATE or HIGH, depending on the application: This is used later on to determine whether a vehicle is likely going to violate a red light or infringe a work zone. This needs to be correct in order for the application to work correctly. | Since this monitors the health and safety of the vehicle and that information is eventually reported to the driver, it should be available at all times as it directly affects vehicle and operator safety. | |||
| Connected Vehicle Roadside Equipment | Vehicle | detected unequipped vehicles and VRUs | Not Applicable | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| Connected Vehicle Roadside Equipment | Vehicle | intersection geometry | Low | High | Moderate |
| Map data intended for general use by any C-ITS component than needs it. No information here includes PII or anything else that, if viewed by someone other than the participant, would lead to harm. | Map data is used for a host of application purposes. This widespread use means that any corruption in the data has a widespread and far reaching effect. | Occasional outages of this flow will delay updates and lead to a loss of accurate function of some applications. Depending on the application this could be HIGH. | |||
| Connected Vehicle Roadside Equipment | Vehicle | intersection status | Not Applicable | High | Moderate |
| This data is intended for all vehicles in the immediate area of the sender. | If this is compromised, the Vehicle OBE will receive messages that are inconsistent with what the traffic signals are displaying. This could lead to confusion and reduce the ability of the application to provide value. | If this is down, the Vehicle OBE doesn’t get the information it needs to stay in synch with the actual signal state, reducing or eliminating the value add from having this application. We assume that the Vehicle OBE will detect a lack of availability and choose not to send out-of-date information, so a failure of availability cannot have worse consequences than a failure of integrity which we have previously assessed at MEDIUM. | |||
| Connected Vehicle Roadside Equipment | Vehicle | merge order commands | Not Applicable | High | Moderate |
| By design this needs to be readable by vehicles in a given area. | Since this flow directs action between moving vehicles, and alteration of data contents would have a safety impact. | If this flow cannot be satisfied then vehicle movements will be compromised, limiting traffic flow. Could be LOW or MODERATE, depending on the operational environment. | |||
| Connected Vehicle Roadside Equipment | Vehicle | potential conflict in progress | Not Applicable | High | Moderate |
| Typically this information should be distributed to all that might be impacted, and so in a given area should be directly observable. | Direct safety impact, so must be correct or negative impact on safety and mobility. | Ideally this flow is always availalble, but given practical constraints that is impractical, and this flow is also an overlap with other safety-driving functions. | |||
| Connected Vehicle Roadside Equipment | Vehicle | vehicle maneuver coordination | Low | High | Low |
| Data contained within this flow is intended to alert other nearby vehicles to a desired or impending movement by the source vehicle. The data does include identifiers indicating the sending vehicle, which needs to be recognized and protected as appropriate. It may be impractical to encrypt this data to meet performance requirements, and in any event no more than one vehicle would be identified and only in the field environment, so mass collection of this information would be difficult. | This flow is core to automated vehicle merge and lane change operations; flaws in the data could result in a crash, and so integrity should be ensured to the highest practical level. | L4/5 ADS will operate more smoothly if this flow works, but as the vehicle fleet will include L0 vehicles for the foreseeable future, any ADS must use other methods to ensure safe operation anyway. May be MODERATE in ADS-dedicated facilities. | |||
| Driver | Vehicle | driver input | Moderate | High | High |
| Data included in this flow may include origin and destination information, which should be protected from other's viewing as it may compromise the driver's privacy. | Commands from from the driver to the vehicle must be correct or the vehicle may behave in an unpredictable and possibly unsafe manner | Commands must always be able to be given or the driver has no control. | |||
| Emergency Vehicle OBE | Vehicle | vehicle maneuver coordination | Low | High | Low |
| Data contained within this flow is intended to alert other nearby vehicles to a desired or impending movement by the source vehicle. The data does include identifiers indicating the sending vehicle, which needs to be recognized and protected as appropriate. It may be impractical to encrypt this data to meet performance requirements, and in any event no more than one vehicle would be identified and only in the field environment, so mass collection of this information would be difficult. | This flow is core to automated vehicle merge and lane change operations; flaws in the data could result in a crash, and so integrity should be ensured to the highest practical level. | L4/5 ADS will operate more smoothly if this flow works, but as the vehicle fleet will include L0 vehicles for the foreseeable future, any ADS must use other methods to ensure safe operation anyway. May be MODERATE in ADS-dedicated facilities. | |||
| ITS Roadway Equipment | Connected Vehicle Roadside Equipment | detected unequipped vehicles and VRUs | Moderate | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. However, all communications between field infrastructure should be protected from viewing to prevent attackers from analyzing traffic and developing attack methods. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| ITS Roadway Equipment | Multi-Access Edge Computing | detected unequipped vehicles and VRUs | Moderate | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. However, all communications between field infrastructure should be protected from viewing to prevent attackers from analyzing traffic and developing attack methods. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| Multi-Access Edge Computing | Vehicle | detected unequipped vehicles and VRUs | Not Applicable | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| Multi-Access Edge Computing | Vehicle | intersection geometry | Low | High | Moderate |
| Map data intended for general use by any C-ITS component than needs it. No information here includes PII or anything else that, if viewed by someone other than the participant, would lead to harm. | Map data is used for a host of application purposes. This widespread use means that any corruption in the data has a widespread and far reaching effect. | Occasional outages of this flow will delay updates and lead to a loss of accurate function of some applications. Depending on the application this could be HIGH. | |||
| Multi-Access Edge Computing | Vehicle | intersection status | Not Applicable | High | Moderate |
| This data is distributed using a variety of mechanisms, some of which are localized broadcast; it is desireable that all potential users get this information. | If this flow is not accurate or delivered in a timely fashion then a large variety of mobility and safety services that depend on it will not work properly. | If this flow is not accurate or delivered in a timely fashion then a large variety of mobility and safety services that depend on it will not work properly. | |||
| Multi-Access Edge Computing | Vehicle | merge order commands | Not Applicable | High | Moderate |
| By design this needs to be readable by vehicles in a given area. | Since this flow directs action between moving vehicles, and alteration of data contents would have a safety impact. | If this flow cannot be satisfied then vehicle movements will be compromised, limiting traffic flow. Could be LOW or MODERATE, depending on the operational environment. | |||
| Multi-Access Edge Computing | Vehicle | potential conflict in progress | Not Applicable | High | Moderate |
| Typically this information should be distributed to all that might be impacted, and so in a given area should be directly observable. | Direct safety impact, so must be correct or negative impact on safety and mobility. | Ideally this flow is always availalble, but given practical constraints that is impractical, and this flow is also an overlap with other safety-driving functions. | |||
| Multi-Access Edge Computing | Vehicle | vehicle maneuver coordination | Low | High | Low |
| Data contained within this flow is intended to alert other nearby vehicles to a desired or impending movement by the source vehicle. The data does include identifiers indicating the sending vehicle, which needs to be recognized and protected as appropriate. It may be impractical to encrypt this data to meet performance requirements, and in any event no more than one vehicle would be identified and only in the field environment, so mass collection of this information would be difficult. | This flow is core to automated vehicle merge and lane change operations; flaws in the data could result in a crash, and so integrity should be ensured to the highest practical level. | L4/5 ADS will operate more smoothly if this flow works, but as the vehicle fleet will include L0 vehicles for the foreseeable future, any ADS must use other methods to ensure safe operation anyway. May be MODERATE in ADS-dedicated facilities. | |||
| Other Vehicles | Vehicle | detected obstacles | Not Applicable | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| Other Vehicles | Vehicle | detected unequipped vehicles and VRUs | Not Applicable | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| Other Vehicles | Vehicle | vehicle location and motion | Not Applicable | High | Moderate |
| This data is intentionally transmitted to everyone via a broadcast. Much of its information content can also be determined via other visual indicators | BSM info needs to be accurate and should not be tampered with | BSM must be broadcast regularly to make data available for other vehicle OBEs, but availability cannot be guaranteed over a wireless medium | |||
| Other Vehicles | Vehicle | vehicle maneuver coordination | Low | High | Low |
| Data contained within this flow is intended to alert other nearby vehicles to a desired or impending movement by the source vehicle. The data does include identifiers indicating the sending vehicle, which needs to be recognized and protected as appropriate. It may be impractical to encrypt this data to meet performance requirements, and in any event no more than one vehicle would be identified and only in the field environment, so mass collection of this information would be difficult. | This flow is core to automated vehicle merge and lane change operations; flaws in the data could result in a crash, and so integrity should be ensured to the highest practical level. | L4/5 ADS will operate more smoothly if this flow works, but as the vehicle fleet will include L0 vehicles for the foreseeable future, any ADS must use other methods to ensure safe operation anyway. May be MODERATE in ADS-dedicated facilities. | |||
| Other Vehicles | Vehicle | vehicle path prediction | Not Applicable | High | Moderate |
| This data is intentionally transmitted to other vehicles operating in a cluster. | Vehicle path data is critical to the performance of a group of vehicles in a vehicle cluster scenario. Incorrect data here could trigger a severe accident scenario. | Some vehicle cluster scenarios cannot function without this flow. Worst case is that some vehicles will drop from the platoon however, which while significant to mobility does not have a direct severe consequence. | |||
| Other Vehicles | Vehicle | vehicle profile | Low | High | Moderate |
| Includes no PII and probably includes information that could be observed, so no need for obfuscation. | Vehicle profile data is critical to the performance of a group of vehicles in a vehicle cluster scenario. Incorrect data here could trigger a severe accident scenario. | This flow enables various services; if the flow is not available the vehicle may not be able to use those services, and also may be charged incorrectly. | |||
| Potential Obstacles | Vehicle | physical presence | |||
| Vehicle | Basic Vehicle | driver update information | Low | Moderate | Moderate |
| This information is all presented to the vehicle operator. Encrypting this information may make it harder to reverse engineer vehicle systems, and may defeat criminal tracking tools when the vehicle has already been compromised. Unless those scenarios are of concern to the operator or manufacturer, this can safely be set LOW. | Any information presented to the operator of a vehicle should be both accurate and timely. By definition this includes safety information, but given that the driver has other means of learning about most threats, it seems difficult to justify HIGH. If HIGH is warranted, it should apply to both availability and integrity. | Any information presented to the operator of a vehicle should be both accurate and timely. By definition this includes safety information, but given that the driver has other means of learning about most threats, it seems difficult to justify HIGH. If HIGH is warranted, it should apply to both availability and integrity. | |||
| Vehicle | Basic Vehicle | vehicle control | Moderate | High | High |
| Internal vehicle flow that if reverse engineered could enable third party vehicle control. Largely a competitive question, could be set LOW if manufacturer and operator are not concerned with this type of compromise. | Includes vehicle control commands, which must be timely and accurate to support safe vehicle operation. | Includes vehicle control commands, which must be timely and accurate to support safe vehicle operation. | |||
| Vehicle | Connected Vehicle Roadside Equipment | detected obstacles | Not Applicable | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| Vehicle | Connected Vehicle Roadside Equipment | detected unequipped vehicles and VRUs | Not Applicable | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| Vehicle | Connected Vehicle Roadside Equipment | vehicle control event | Low | Moderate | Moderate |
| This data is intentionally transmitted to everyone via a broadcast. It can also be determined via other visual indicators. | This message is an indication of a potential hazard and should not be easy to forge. False messages here may lead to confusion that causes a traffic accident. | This message is an indication of a potential hazard. If it isn’t received it increases the risk to other road users. If a vehicle is infringing on an intersection, it must report this. | |||
| Vehicle | Connected Vehicle Roadside Equipment | vehicle location and motion | Not Applicable | High | Moderate |
| This data is intentionally transmitted to everyone via a broadcast. Much of its information content can also be determined via other visual indicators | Incorrect information could lead to the system not operating properly. If the system does not properly know where the vehicle is, it cannot make an accurate decision about whether there is going to be a pedestrian in the crosswalk that the vehicle is approaching. This can have a safety impact.; DISC: NYC believes this to be MODERATE | This data is required for the system to operate properly. If this data is not available, the system cannot give accurate warning information. | |||
| Vehicle | Connected Vehicle Roadside Equipment | vehicle path prediction | Not Applicable | High | Moderate |
| This data is intentionally transmitted to other vehicles operating in a cluster. | Path prediction is intended for collision avoidance applications, which have high integrity requirements to avoid potentially catastrophic consequences. | Path prediction is intended for collision avoidance applications, which ideally would have HIGH availability requirements, but given the constraints of the wireless medium are reduced to MODERATE. | |||
| Vehicle | Connected Vehicle Roadside Equipment | vehicle profile | Low | High | Moderate |
| Includes no PII and probably includes information that could be observed, so no need for obfuscation. | As this information will be used to determine the vehicle's ability to access services or be charged usage fees, it must be correct and not easily forgeable. | This flow enables various services; if the flow is not available the vehicle may not be able to use those services, and also may be charged incorrectly. | |||
| Vehicle | Driver | driver updates | Not Applicable | Moderate | Moderate |
| This data is informing the driver about the safety of a nearby area. It should not contain anything sensitive, and does not matter if another person can observe it. | This is the information that is presented to the driver. If they receive incorrect information, they may act in an unsafe manner. However, there are other indicators that would alert them to any hazards, such as an oncoming vehicle or crossing safety lights. | If this information is not made available to the driver, then the system has not operated correctly. | |||
| Vehicle | Multi-Access Edge Computing | detected obstacles | Not Applicable | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| Vehicle | Multi-Access Edge Computing | detected unequipped vehicles and VRUs | Not Applicable | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| Vehicle | Multi-Access Edge Computing | vehicle control event | Low | Moderate | Moderate |
| This data is intentionally transmitted to everyone via a broadcast. It can also be determined via other visual indicators. | BSM info needs to be accurate and should not be tampered with, suggesting HIGH. From NYC: Integrity would need to be high if there were no mitigations against bad data in incoming BSMs. In fact, there are two mitigations: plausibility checking, and misbehavior reporting plus revocation. Taking these into account the security requirements are met by requiring an integrity level of MODERATE on these information flows. RES: Sided with NYC due to mitigation documentation. | BSM must be broadcast regularly to make data available for other vehicle OBEs, but cannot guarantee wireless communication | |||
| Vehicle | Multi-Access Edge Computing | vehicle location and motion | Not Applicable | High | Moderate |
| This data is intentionally transmitted to everyone via a broadcast. Much of its information content can also be determined via other visual indicators | Incorrect information could lead to the system not operating properly. If the system does not properly know where the vehicle is, it cannot make an accurate decision about whether there is going to be a pedestrian in the crosswalk that the vehicle is approaching. This can have a safety impact. | This data is required for the system to operate properly. If this data is not available, the system cannot give accurate warning information. | |||
| Vehicle | Multi-Access Edge Computing | vehicle path prediction | Not Applicable | High | Moderate |
| This data is intentionally transmitted to other vehicles operating in a cluster. | Path prediction is intended for collision avoidance applications, which have high integrity requirements to avoid potentially catastrophic consequences. | Path prediction is intended for collision avoidance applications, which ideally would have HIGH availability requirements, but given the constraints of the wireless medium are reduced to MODERATE. | |||
| Vehicle | Multi-Access Edge Computing | vehicle profile | Low | High | Moderate |
| Includes no PII and probably includes information that could be observed, so no need for obfuscation. | As this information will be used to determine the vehicle's ability to access services or be charged usage fees, it must be correct and not easily forgeable. | This flow enables various services; if the flow is not available the vehicle may not be able to use those services, and also may be charged incorrectly. | |||
| Vehicle | Other Vehicles | detected obstacles | Not Applicable | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| Vehicle | Other Vehicles | detected unequipped vehicles and VRUs | Not Applicable | High | Moderate |
| This data is intended to be shared with all nearby vehicles, traffic control devices and vulnerable road users; it is essentially public. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. If manipulated or incorrect, a crash may occur; though vehicles able to use this data also have sensory capabilities, this flow will often contain data describing objects/vehicles/VRUs that are obscured and not observable by on-board sensors. | This data may be used as input to vehicle situational awareness and thus trigger crash-avoidance actions. This data enable collision avoidance actions that are impractical without it, as vehicles able to use this data to sense-by-proxy other vehicles/VRUs/obstacles that are obscured by on-board sensors. Considered MODERATE and not HIGH only because the lack of availability reverts to existing operations and does not actively make safety worse. | |||
| Vehicle | Other Vehicles | vehicle location and motion | Not Applicable | High | Moderate |
| This data is intentionally transmitted to everyone via a broadcast. Much of its information content can also be determined via other visual indicators | BSM info needs to be accurate and should not be tampered with | BSM must be broadcast regularly to make data available for other vehicle OBEs, but availability cannot be guaranteed over a wireless medium | |||
| Vehicle | Other Vehicles | vehicle maneuver coordination | Low | High | Low |
| Data contained within this flow is intended to alert other nearby vehicles to a desired or impending movement by the source vehicle. The data does include identifiers indicating the sending vehicle, which needs to be recognized and protected as appropriate. It may be impractical to encrypt this data to meet performance requirements, and in any event no more than one vehicle would be identified and only in the field environment, so mass collection of this information would be difficult. | This flow is core to automated vehicle merge and lane change operations; flaws in the data could result in a crash, and so integrity should be ensured to the highest practical level. | L4/5 ADS will operate more smoothly if this flow works, but as the vehicle fleet will include L0 vehicles for the foreseeable future, any ADS must use other methods to ensure safe operation anyway. May be MODERATE in ADS-dedicated facilities. | |||
| Vehicle | Other Vehicles | vehicle path prediction | Not Applicable | High | Moderate |
| This data is intentionally transmitted to other vehicles operating in a cluster. | Vehicle path data is critical to the performance of a group of vehicles in a vehicle cluster scenario. Incorrect data here could trigger a severe accident scenario. | Some vehicle cluster scenarios cannot function without this flow. Worst case is that some vehicles will drop from the platoon however, which while significant to mobility does not have a direct severe consequence. | |||
| Vehicle | Other Vehicles | vehicle profile | Low | High | Moderate |
| Includes no PII and probably includes information that could be observed, so no need for obfuscation. | Vehicle profile data is critical to the performance of a group of vehicles in a vehicle cluster scenario. Incorrect data here could trigger a severe accident scenario. | This flow enables various services; if the flow is not available the vehicle may not be able to use those services, and also may be charged incorrectly. | |||
| Vehicle Characteristics | ITS Roadway Equipment | vehicle characteristics | |||
| Vehicle Characteristics | Vehicle | vehicle characteristics | |||
| Vulnerable Road Users | Vehicle | vulnerable road user presence | |||
Standards
The following table lists the standards associated with physical objects in this service package. For standards related to interfaces, see the specific information flow triple pages. These pages can be accessed directly from the SVG diagram(s) located on the Physical tab, by clicking on each information flow line on the diagram.
| Name | Title | Known Issues | Physical Object |
|---|---|---|---|
| CTI 4001 RSU | Roadside Unit (RSU) Standard | Connected Vehicle Roadside Equipment | |
| CTI 4501 CI Implementation Guide | Connected Intersections Implementation Guide | Not a standard: The document's title indicates that the document is a "guide" however the document contains requirements written using "shall" statements and includes conformance tables with mandatory requirements. The result is a level of ambiguity as to the enforceability of the "requirements." | Connected Vehicle Roadside Equipment |
| ISO 15623 Fwd Collision Performance | Intelligent transport systems -- Forward vehicle collision warning systems -- Performance requirements and test procedures | Vehicle | |
| ISO/SAE PAS 22736 Automation Taxonomy | Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles | Vehicle | |
| ITE 5301 ATC ITS Cabinet | Intelligent Transportation System Standard Specification for Roadside Cabinets | ITS Roadway Equipment | |
| NEMA TS 8 Cyber and Physical Security | Cyber and Physical Security for Intelligent Transportation Systems | ITS Roadway Equipment | |
| SAE J3016 Automation Taxonomy | Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles | Vehicle | |
| SAE J3251 CDA Pedestrian Collision Avoidance | Cooperative Driving Automation (CDA) Feature: Perception Status Sharing for Occluded Pedestrian Collision Avoidance | Vehicle | |
| SAE J3316 CDA Reference Architecture | Draft not available (Critical): under development | Vehicle | |
| SAE J3361 Antenna requirements | V2X Antenna Coverage and Test Requirements for US FHWA Class 1 and Class 3-13 Class Vehicles | Draft not available (Critical): under development | Emergency Vehicle OBE |
| Vehicle | |||
| SAE J5001 OBU Standard | Onboard Unit Standard for Connected Vehicles | Draft not available (Critical): under development | Emergency Vehicle OBE |
| Vehicle |
System Requirements
| System Requirement | Need | ||
|---|---|---|---|
| 001 | The system shall detect vehicles and vulnerable road users and share this information with roadside communications equipment. This supports detection of vehicles and vulnerable road users that do not have operable short range communications capabilities. | 02 | The Driver needs to receive warnings from the vehicle to avoid safety compromising situations with nearby vehicles during lane changes/merges. |
| 03 | The Connected Vehicle needs to adapt vehicle control to safety accommodate pending and in progress lane changes/merges in the vicinity. | ||
| 002 | The system shall send maneuver intent information to nearby vehicles and send execution status until the maneuver is completed. | 01 | The Connected Vehicle needs to be able to coordinate a lane change/merge with other vehicles. |
| 01 | The Connected Vehicle needs to be able to coordinate a lane change/merge with other vehicles. | ||
| 003 | The system shall provide information supporting cooperative driving to nearby vehicles. | 01 | The Connected Vehicle needs to be able to coordinate a lane change/merge with other vehicles. |
| 004 | The system shall exchange maneuver intent information with nearby vehicles. | 01 | The Connected Vehicle needs to be able to coordinate a lane change/merge with other vehicles. |
| 01 | The Connected Vehicle needs to be able to coordinate a lane change/merge with other vehicles. | ||
| 02 | The Driver needs to receive warnings from the vehicle to avoid safety compromising situations with nearby vehicles during lane changes/merges. | ||
| 03 | The Connected Vehicle needs to adapt vehicle control to safety accommodate pending and in progress lane changes/merges in the vicinity. | ||
| 005 | The system shall respond to maneuver intent information with an indication of acceptance or rejection, as appropriate to the situation. | 01 | The Connected Vehicle needs to be able to coordinate a lane change/merge with other vehicles. |
| 01 | The Connected Vehicle needs to be able to coordinate a lane change/merge with other vehicles. | ||
| 02 | The Driver needs to receive warnings from the vehicle to avoid safety compromising situations with nearby vehicles during lane changes/merges. | ||
| 03 | The Connected Vehicle needs to adapt vehicle control to safety accommodate pending and in progress lane changes/merges in the vicinity. | ||
| 006 | The system shall be capable of performing control actions based upon information received from other vehicles regarding their status. This includes intersection-related status, maneuver coordination, and other status information received from vehicles in the vicinity. | 03 | The Connected Vehicle needs to adapt vehicle control to safety accommodate pending and in progress lane changes/merges in the vicinity. |
| 03 | The Connected Vehicle needs to adapt vehicle control to safety accommodate pending and in progress lane changes/merges in the vicinity. | ||
| 007 | The system shall provide warnings to the driver based on information received from other vehicles regarding potentially hazardous road conditions, road hazards, or pending/in-progress vehicle maneuvers. | 02 | The Driver needs to receive warnings from the vehicle to avoid safety compromising situations with nearby vehicles during lane changes/merges. |
| 03 | The Connected Vehicle needs to adapt vehicle control to safety accommodate pending and in progress lane changes/merges in the vicinity. | ||
