Research, Development, and Technology

Turner-Fairbank Highway Research Center

6300 Georgetown Pike

McLean, VA 22101-2296

PUBLICATION NO. FHWA-HRT-22-116 NOVEMBER 2022 

FHWA Cooperative Automation 

Research: CARMA Proof of-Concept 

TSMO Use Case Testing: CARMA 

Cooperative Perception Low-Level 

Concept of Operations
FOREWORD 

The Federal Highway Administration’s (FHWA) Cooperative Driving Automation (CDA) 

Program, formerly known as the CARMASM Program, is an initiative to enable collaboration for 

research and development (R&D) of CDA technologies. The CDA Program develops and 

maintains an ecosystem of open-source software (OSS) tools, which together are known as the 

CARMA Ecosystem, to enable CDA research. The CARMA Ecosystem is a research 

environment that enables communication between vehicles and roadside infrastructure devices to 

support coordinated movement to improve safety, traffic throughput, and energy efficiency of 

the transportation network. 

In 2015, the FHWA’s Office of Operations Research and Development developed a cooperative 

adaptive cruise control proof-of-concept prototype that was installed in five research vehicles. 

From there, the CARMA Ecosystem further evolved through testing and integration. At the time 

of this writing, the CDA Program is advancing into automated driving systems (ADS) that 

leverage infrastructure to support cooperative automation strategies. This project expands 

CARMA functionality to include transportation systems management and operations (TSMO) 

strategies on surface arterials with intersections. Along with new capabilities of CARMA Streets 

and TSMO use cases, this project is also conducting research on how cooperative perception can 

be used to improve the transportation network by increasing situational awareness. 

This concept of operations (ConOps) is the last in a series of nine focused on transportation 

systems management and operations use cases and capabilities and is focused on cooperative 

perception (CP). It expands on the previous CP ConOps and provides additional details on the 

system framework and requirements of the CP feature in the CARMA Ecosystem for a particular

scenario. The intended audience for this report is CDA stakeholders, such as system developers, 

analysts, researchers, application developers, and infrastructure owners and operators. 

Brian Cronin, P.E. 

Director, Office of Safety and Operations 

Research and Development

Notice

This document is disseminated under the sponsorship of the U.S. Department of Transportation 

(USDOT) in the interest of information exchange. The U.S. Government assumes no liability for 

the use of the information contained in this document. 

The U.S. Government does not endorse products or manufacturers. Trademarks or

manufacturers’ names appear in this report only because they are considered essential to the 

objective of the document. 

Quality Assurance Statement 

The Federal Highway Administration (FHWA) provides high-quality information to serve 

Government, industry, and the public in a manner that promotes public understanding. Standards 

and policies are used to ensure and maximize the quality, objectivity, utility, and integrity of its 

information. FHWA periodically reviews quality issues and adjusts its programs and processes 

to ensure continuous quality improvement. 
TECHNICAL REPORT DOCUMENTATION PAGE

1. Report No.

FHWA-HRT-22-116

2. Government Accession No. 3. Recipient’s Catalog No.

4. Title and Subtitle

FHWA Cooperative Automation Research: CARMA 

Proof-of-Concept TSMO Use Case Testing: CARMA 

Cooperative Perception Low-Level Concept of Operations

5. Report Date

November 2022 

6. Performing Organization Code:

7. Author(s)

Yingyan Lou (ORCID: 0000-0001-9913-572X); David Hale 

(ORCID: 0000-0001-5486-9367); Michael McConnel; Amir 

Ghaisi (ORCID: 0000-0002-0986-9840); Mafruhatul Jannat 

(ORCID: 0000-0002-5218-3051); Sujith Racha (ORCID: 

0000-0002-5217-0779)

8. Performing Organization Report No.

9. Performing Organization Name and Address

Leidos, Inc.

11251 Roger Bacon Drive

Reston, VA 20190

10. Work Unit No.

(TRAIS)

11. Contract or Grant No.

DTFH6116D00030L (TO 19-360)

12. Sponsoring Agency Name and Address

U.S. Department of Transportation

Federal Highway Administration

1200 New Jersey Avenue, SE

Washington, DC 20590

13. Type of Report and Period Covered

Final Report; November 2021–April 2022

14. Sponsoring Agency Code

HRSO 

15. Supplementary Notes

Government task managers are Govindarajan Vadakpat (HRSO-50; ORCID: 0000-0001-9060-3216), Pavle 

Bujanovic (HRSO-40; ORCID: 0000-0001-6589-3207), Taylor Lochrane (HRSO-40; ORCID: 

0000-0002-1933-6554), and Steven Mortensen (FTA-TRI-10). 

16. Abstract

The Federal Highway Administration initiated the Cooperative Driving Automation (CDA) Program, formerly 

known as the CARMA Program, to advance the research and development of CDA to accelerate market readiness 

and deployment. CDA aims to improve the safety, traffic throughput, and energy efficiency of the transportation 

network by allowing road users and infrastructure to communicate and cooperate. CARMA cooperative perception 

(CP) is a feature of the CARMA Ecosystem that allows entities to share locally perceived data. CP is expected to 

improve perception performances of automated vehicles and CARMA Streets. The enhanced situational awareness 

is expected to enable more effective CDA safety and mobility applications This low-level concept of operations 

(ConOps) is published with the associated high-level ConOps.(1) This low-level ConOps focuses on the system 

framework and requirements of the CP feature in the CARMA Ecosystem for a particular scenario involving 

vulnerable road users crossing in controlled conflict areas.

17. Key Words

CARMA Streets, CARMA Ecosystem, cooperative 

perception, cooperative driving automation

18. Distribution Statement

No restrictions. This document is available to the public 

through the National Technical Information Service, 

Springfield, VA 22161.

http://www.ntis.gov

19. Security Classif. (of this report)

Unclassified

20. Security Classif. (of this page)

Unclassified

21. No. of Pages

54 

22. Price

N/A

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized.
 

ii

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

iii

TABLE OF CONTENTS

CHAPTER 1. INTRODUCTION ................................................................................................ 1

Identification ........................................................................................................................... 1

Objective .................................................................................................................................. 1

Background ............................................................................................................................. 1

FHWA Cooperative Driving Automation (CDA) Program and CARMA 

Ecosystem ........................................................................................................................... 1

Project Background ............................................................................................................. 4

Audience................................................................................................................................... 4

Document Structure................................................................................................................ 4

CHAPTER 2. CP OVERVIEW ................................................................................................... 7

CP in CARMA Ecosystem...................................................................................................... 7

CP Technical Considerations ................................................................................................. 8

CP Use Cases ........................................................................................................................... 9

CHAPTER 3. CP USE CASE: VRU CROSSING IN CONTROLLED 

CONFLICT AREAS ................................................................................................................... 11

CHAPTER 4. SITUATION 1..................................................................................................... 17

User-Oriented Operational Description ............................................................................. 17

Driver Perspective (connected but nonautomated vehicle) .............................................. 17

Vehicle Perspective (CAV)............................................................................................... 18

VRU Perspective ............................................................................................................... 18

Entities and Stakeholders ..................................................................................................... 19

Operational User Needs ........................................................................................................ 19

System Functional Requirements ........................................................................................ 20

Performance Metrics ............................................................................................................ 23

CHAPTER 5. SITUATION 2..................................................................................................... 25

User-Oriented Operational Description ............................................................................. 25

Driver Perspective (connected but nonautomated vehicle) .............................................. 25

Vehicle Perspective (CAV)............................................................................................... 25

VRU Perspective ............................................................................................................... 26

Entities and Stakeholders ..................................................................................................... 26

Operational Needs ................................................................................................................. 27

System Functional Requirements ........................................................................................ 27

Performance Metrics ............................................................................................................ 30

CHAPTER 6. SITUATION 3..................................................................................................... 31

User-Oriented Operational Description ............................................................................. 31

Driver Perspective (connected but nonautomated vehicle) .............................................. 31

Vehicle Perspective (CAV)............................................................................................... 32

VRU Perspective ............................................................................................................... 32

Entities and Stakeholders ..................................................................................................... 33

Operational Needs ................................................................................................................. 33

System Functional Requirements ........................................................................................ 33
 

iv

Performance Metrics ............................................................................................................ 35

CHAPTER 7. CONCLUSION ................................................................................................... 37

APPENDIX. HIGH-LEVEL SYSTEM REQUIREMENTS ................................................... 39

REFERENCES ............................................................................................................................ 47
 

v 

LIST OF FIGURES

Figure 1. Chart. Overview of SAE cooperation classes and automation levels. ............................ 2

Figure 2. Illustration. CARMA products. ....................................................................................... 3

Figure 3. Illustration. CP in the CARMA Ecosystem. .................................................................... 8

Figure 4. Illustration. CP through V2V communications to improve situational awareness: 

VRUs clearing intersection outside of allocated phase. ...................................................... 12

Figure 5. Illustration. Situation 1. ................................................................................................. 13

Figure 6. Illustration. Situation 2. ................................................................................................. 13

Figure 7. Illustration. Situation 3. ................................................................................................. 14

LIST OF TABLES

Table 1. Summary of CP operational scenarios.(1) .......................................................................... 9

Table 2. Operational user needs for Situation 1. ........................................................................... 20

Table 3. System functional requirements for Situation 1. ............................................................ 21

Table 4. Operational user needs for Situation 2. ........................................................................... 27

Table 5. System functional requirements for Situation 2. ............................................................ 28

Table 6. System functional requirements for Situation 3. ............................................................ 34

Table 7. CARMA CP operational needs. ...................................................................................... 39

Table 8. CARMA CP functional requirements. ............................................................................ 41
 

vi 

LIST OF ABBREVIATIONS

ADS automated driving system 

AV automated vehicle

C–ADS cooperative automated driving system 

CAV connected and automated vehicle

CDA cooperative driving automation 

COMM communications 

ConOps concept of operations 

CP cooperative perception

CPA cooperative perception application 

CS cybersecurity

DDT dynamic driving task 

DF data fusion 

FHWA Federal Highway Administration

HRSO Highway Research and Safety Operations 

Hz hertz

ITS intelligent transportation system

LiDAR light detection and ranging 

NIST National Institute of Standards and Technology 

ODP object detection and perception 

OSS open-source software

PoC proof-of-concept 

R&D research and development

radar radio detection and ranging 

RSE roadside equipment 

SPaT signal phasing and timing 

TCD traffic control device

TSMO transportation systems management and operations 

V2V vehicle-to-vehicle 

V2X vehicle-to-everything 

VRU vulnerable road user 
 

1 

CHAPTER 1. INTRODUCTION

IDENTIFICATION

This document is a low-level concept of operations (ConOps) for cooperative perception (CP) in 

the CARMA Ecosystem, sponsored by the Federal Highway Administration’s (FHWA) Office of 

Safety and Operations Research and Development (R&D), the Intelligent Transportation 

Systems Joint Program Office, and the Federal Transit Administration. This low-level ConOps is 

an initial step in the current CARMA development effort to define a particular scenario for 

proof-of-concept (PoC) demonstration and near-future development, as well as associated system 

requirements.

OBJECTIVE

This low-level ConOps is published with the associated high-level ConOps.(1)

 This low-level 

ConOps focuses on the system framework and requirements of the CP feature in the CARMA 

Ecosystem for a particular scenario. The particular scenario is Scenario 2 as defined in the 

high-level ConOps: vulnerable road users (VRUs) crossing in controlled conflict areas.(1) Three 

situations that fall into this scenario will be discussed in this low-level ConOps. All three 

situations involve a large vehicle (which can be a heavy vehicle, a transit vehicle, or an 

emergency response vehicle), a passenger vehicle equipped with cooperative automated driving 

systems (C–ADS), a VRU, and roadside sensing, computation, and communication 

infrastructure. This low-level ConOps will detail the operational needs and functional 

requirements of all CARMA components involved and serve as a reference document for 

algorithm development and implementation. 

BACKGROUND

FHWA Cooperative Driving Automation (CDA) Program and CARMA Ecosystem

The Office of Safety and Operations R&D performs transportation operations R&D for FHWA. 

Onsite R&D is conducted at the Saxton Transportation Operations Laboratory for FHWA and

operations R&D is conducted based on a national perspective of the transportation needs across

the United States.

Since 2015, the Office of Safety and Operations R&D spearheaded FHWA’s CDA Program, 

formerly known as the CARMA Program. The CDA Program is an FHWA initiative focused on 

transportation system improvements through research and testing for emerging automated 

driving and vehicle-to-everything (V2X) communication technologies. 

Using V2X communications, CDA allows equipped vehicles to communicate with each other, 

with roadside equipment (RSE), and with other road users. SAE International has standardized 

the classification of cooperation between vehicles. Similar to the levels of automation defined in 

SAE J3016TM, the new standard, SAE J3216TM, defines the classes of cooperation.

(2,3) Vehicles 

equipped with C-ADS can share their status and driving intent (classes A and B) and seek and 
C-ADS designed to accept and adhere to a command

C-ADS designed to attain mutual goals through 

coordinated actions

N/A

Potential for improved object and event detection2

Potential for improved object and event detection Potential for 2

improved object and 

event detection1

Potential for improved object and 

event detection1

E.g., Hand 

signals, lane 

assignment by 

officials

E.g., Hand 

signals, merge

E.g., Turn signal, 

merge

E.g., Brake lights, 

traffic signal

I will do as 

directed

Let's 

do this 

together

This is 

what I 

plan to do

Here I am 

and what 

I see

PRESCRIPTIVE

AGREEMENT 

SEEKING

INTENT SHARING 

STATUS SHARING 

CLASS D 

CLASS C 

CLASS B 

CLASS A 

CDA CLASSES

Relies on ADS to perform complete DDT under defined 

conditions (fallback condition performance varies 

between levels) 

Relies on driver to complete the 

DDT and to supervise feature 

performance in real time

E.g., Signage, 

TCD

NO COOPRATIVE 

AUTOMATION

Full driving 

automation

High driving 

automation

Conditional 

driving 

automation

Partial driving 

automation 

(longitudinal 

AND lateral 

vehicle motion 

control) 

Driver assistance 

(longitudinal OR 

lateral vehicle 

motion control) 

No driving

automation

(human does all

driving)

LEVEL 0 LEVEL 1 LEVEL 2 LEVEL 3 LEVEL 4 LEVEL 5

Type Partial Automation of DDT Complete Automation of DDT

RELATIONSHIPBETWEEN CLASSES OFCOOPERATIVE DRIVING 

AUTOMATION (CDA) J3216AND LEVELS OF AUTOMATION J3016

2 

enter cooperative driving agreements (classes C and D). Figure 1 summarizes the cooperation 

classes in relation to the levels of vehicle automation. 

© 2020 SAE International.

(3)

1

Improved object and event detection prediction through CDA Class A and Class B status and intent 

sharing may not always be realized, given that Level 1 and 2 driving automation features may be 

overridden by the driver at any time, and otherwise have limited sensing capabilities compared to 

Level 3, 4, and 5 ADS-operated vehicles. 2

Class A and B communications are one of many inputs to an ADS’s object and event detection and 

prediction capability, which may not be improved by the CDA message. 

DDT = dynamic driving task; N/A = not applicable; TCD = traffic control device.

Figure 1. Chart. Overview of SAE cooperation classes and automation levels. 

FHWA’s CDA Program has led to a suite of open-source software (OSS) for CDA, referred to as 

the CARMA Ecosystem, including both vehicle and infrastructure technologies. The CARMA 

Ecosystem currently consists of four core products (figure 2): CARMA Platform, CARMA 

Messenger, CARMA Streets, and CARMA Cloud. 

CARMA Platform is an automated driving system (ADS). In its third iteration, the current 

CARMA Platform achieves conditional driving automation (at SAE International Level 3) and 

enables ADS functionality to be used for cooperative automation strategies. 

CARMA Messenger represents the capability of moving nonautomated entities (e.g., 

first-responder vehicles, pedestrians, buses) to communicate with the infrastructure and with 

vehicles equipped with CARMA Platform to improve transportation system performance. 
 

3 

CARMA Streets represents the infrastructure piece of CDA at conflict areas (e.g., intersections). 

It provides an interface to roadside units, supports two-way communication between vehicles 

and infrastructure, and supports CDA by using edge computing to optimize travel through 

conflict areas. A part of CARMA Streets is the V2X Hub, a set of software that facilitates data 

exchange needed in V2X communications by translating data elements into various standard 

protocols. 

CARMA Cloud further supports regional transportation systems management and operations 

(TSMO) through cloud-based management of transportation systems, data exchange, and 

multiple simultaneous remote services. CARMA Cloud also hosts CARMA Analytics, which 

supports the fusion, analysis, and management of cooperative automated vehicles (AVs) and 

traditional transportation data. CARMA Platform, CARMA Messenger, CARMA Streets, and 

CARMA Cloud are all OSS built to benefit CDA research.

Source: FHWA.

(1)

ITS = intelligent transportation system; RSU = roadside unit. 

Figure 2. Illustration. CARMA products. 
 

4 

Project Background

This project extends current efforts within the CARMA Program by enhancing the CARMA

Ecosystem to enable CP capabilities. For this project, CP is defined as the sharing of a locally 

perceived driving environment—in particular, locally perceived road objects—by an equipped 

road entity through V2X communications. Such road entities could be a vehicle equipped with 

C–ADS or RSE with detection and perception capabilities. In the high-level ConOps, the project 

team has reviewed the CP state of the art and state of the practice, identified opportunities to 

incorporate CP into the CARMA Ecosystem, examined high-level system operational needs and 

functional requirements, and discussed 14 potential use case scenarios that belong to four 

application categories.(1)

AUDIENCE

The intended audience for this ConOps includes the following: 

• U.S. Department of Transportation and CDA and arterial transportation stakeholders, 

including program managers, assistant managers, research engineers, and transportation 

technology specialists. 

• Academia stakeholders, including faculty, researchers, and students. 

• Private sector stakeholders, including consultant companies and original equipment 

manufacturers. 

• System developers who will create and support CDA algorithms based on the system 

concepts described in this ConOps. 

• Analysts, researchers, and CDA application developers. 

DOCUMENT STRUCTURE

This document is organized as follows. 

Chapter 1 defines the scope of this ConOps. 

Chapter 2 summarizes key information from the high-level CP ConOps, including CP technical 

considerations, CP use cases, and high-level operational needs and functional requirements.(1)

Chapter 3 describes the three situations that this low-level ConOps will focus on, as well as their 

relationship with each other.

Chapter 4 details the following information for Situation 1: user-oriented operational description, 

associated entities and stakeholders, operational user needs, system functional requirements, and 

performance metrics.

Chapters 5 and 6 provide the same details for Situations 2 and 3. 
 

5 

The appendix includes the operational needs and functional requirements developed in the 

high-level CP ConOps.(1)

References provide a list of reference documents.

7 

CHAPTER 2. CP OVERVIEW

Sharing “what I see” is the concept of CP in its most intuitive sense. Standards developing 

organizations, such as SAE International and the European Telecommunication Standards 

Institute, and the research community have reached a consensus on the concept of CP.(4,5,6,7)

More specifically, CP is the sharing of a locally perceived driving environment—in particular, 

locally perceived road objects—by an equipped road entity through V2X communications. Such 

road entities could be a vehicle equipped with C–ADS or an RSE with detection and perception 

capabilities.

CP could be a valuable feature of CDA. In addition to enhancing situational awareness when 

some road users and road objects are not capable of machine-to-machine communications, CP 

could also supplement basic safety messages or personal safety messages defined in SAE J2735, 

in the case where the range and quality of V2X communication are limited.(8)

 Even when the 

shared CP information is redundant (but not complete duplication), for example, perceived 

objects in the mutual field of view of two C–ADS-equipped vehicles, such redundancy could 

reduce uncertainty in both vehicles’ local perception. The enhanced situational awareness is 

expected not only to improve safety performance in immediate collision avoidance scenarios but 

also to enable safer motion planning. Moreover, enhanced performances of connected and 

automated vehicles’ (CAVs’) perception systems could also support path and trajectory planning 

for improved mobility and energy performances.

CP IN CARMA ECOSYSTEM

The CP feature can be integrated into all four core products in the CARMA Ecosystem. As 

illustrated in figure 3, CARMA Platform is a candidate to incorporate CP. Vehicles equipped 

with CARMA Platform are expected to have advanced sensing and perception systems and can 

initiate the sharing of CP information. Although CARMA Messenger currently does not have 

perception capabilities and is not able to generate original CP information (as indicated by the 

one-way arrows pointing toward Messenger in figure 3), it is able to receive CP information, 

process it for human driver consumption, and relay CP information to other entities with 

communication capabilities. Additionally, applications could be developed to further process the 

CP information received for consumption by human drivers (e.g., advisory warning). CARMA 

Streets could use CP information received directly from road objects or relayed through 

CARMA Cloud to obtain a more comprehensive picture of the driving environment and possibly 

improve solutions to relevant TSMO use cases. RSEs equipped with CARMA Streets could also 

serve as a relay for CP information. Moreover, if an RSE equipped with CARMA Streets can

access existing or newly installed infrastructure-based sensors (e.g., cameras and light detection 

and ranging (LiDAR)), it could provide original CP information to connected road entities. 

CARMA Cloud could be a hub where all CP information is consolidated into a global map of 

road objects. 
8 

Source: FHWA.(1)

Figure 3. Illustration. CP in the CARMA Ecosystem.

CP TECHNICAL CONSIDERATIONS

Extensive research has been performed in the past decade on various technical aspects of CP. 

Five categories of technical considerations have been identified in the high-level CP ConOps.(1)

They are: enhanced object detection and perception (ODP), communication issues, cyber 

security (CS) issues, data fusion (DF) algorithms, and the effective application of information 

obtained through CP. This section briefly provides an overview of these technical considerations. 

Interested readers are referred to the high-level CP ConOps, and the references cited therein, for 

details.(1)

Enhanced ODP primarily deals with extracting a perceived object’s center and dimensions, 

which is often relevant to CP applications. Once the objects are detected and perceived, CP 

messages will be generated and disseminated through V2X communications. A large body of 

literature exists on CP communication issues, such as CP message content, as well as CP 

message generation and dissemination rules. CS issues are intrinsic to V2X communications. In 

addition to known security threats to general V2X communications, falsifying perception data is 

a CS threat specific to CP.(9) Once a vehicle has received CP information, DF algorithms are 

needed to combine peer data with locally perceived data. Finally, the effective use of CP 

information to improve safety and mobility, or CP applications (CPA) is an issue that should not 

be overlooked. 
9 

CP USE CASES

In the literature, use cases of CP experiments include advanced pedestrian warning using 

infrastructure-based perception, advisory warning of opposing traffic for permissive left-turn 

vehicles, enhanced awareness of obstructed objects in various scenarios (e.g., along a horizontal 

curve, in overtaking scenarios, and around an intersection, and AV path planning using CP 

information. (See references 7, 10, 11, 12, 13, and 14.) 

The high-level CP ConOps identified 14 CP use case scenarios (see table 1). The scenarios are 

bracketed into four application groups.(1)

 The first application involves VRUs. The second 

application focuses on safety, namely collision avoidance. The third application extends beyond 

safety into increased mobility. The fourth application introduces scenarios in which CP provides 

a general increase in situational awareness.

This low-level ConOps focuses on the system framework and requirements of the CP feature in 

the CARMA Ecosystem for Scenario 2 as defined in the high-level ConOps: VRUs crossing in

controlled conflict areas.(1)

Table 1. Summary of CP operational scenarios.(1)

Application Scenario Description

VRUs Basic road 

segment

Vehicles on the same side of the road should be 

aware of VRUs, anticipate the VRUs’ movements, 

and adjust trajectories accordingly.

VRUs Controlled 

crossing areas

Various vehicle-pedestrian conflicts at controlled 

intersections. 

VRUs Nondesignated 

crossing areas

(i.e., midblock) 

Vehicles unable to detect VRUs at nondesignated 

midblock crossing. 

VRUs Boarding and 

alighting transit

Pedestrians cross the road to board transit or after 

disembarking from a transit vehicle. Pedestrians step 

in front of a transit vehicle to load/unload a bicycle 

from a bike rack. CP improves perception 

performance of other vehicles in the vicinity of the 

stopped transit vehicle. 

Collision avoidance Car-following Vehicles need to act (e.g., braking) automatically 

when an imminent collision is perceived and 

communicate upstream to relevant following 

vehicles.

Collision avoidance Wrong-way 

driving 

Wrong-way vehicle entering a highway from a 

right-way off-ramp. 

Conflict avoidance 

and cooperative 

driving 

Intersections Vehicle turning left at signalized intersection with 

opposing left-turning and through-moving vehicle.

Conflict avoidance 

and cooperative 

driving 

Around business 

access areas

Vehicles coming out of a business driveway have 

potential conflict with oncoming traffic.
10 

Application Scenario Description

Conflict avoidance 

and cooperative 

driving 

Two-lane, 

two-way roads

Vehicle is trying to pass a slow-moving vehicle in 

front on a two-lane, two-way road with oncoming 

traffic in the opposite direction. 

Conflict avoidance 

and cooperative 

driving 

Lane changing Vehicles upstream of an abrupt lane-changing event 

could adjust their trajectories preemptively.

General enhanced 

situational awareness

Behind large 

vehicles

Vehicles traveling behind large vehicles have limited 

line of sight. 

General enhanced 

situational awareness

Horizontal or 

vertical curves

Vehicle’s line of sight could be limited due to 

roadway geometry, particularly horizontal and 

vertical curves.

General enhanced 

situational awareness

Adverse weather Vehicle’s line of sight is limited in adverse weather, 

such as fog, snow, and rain, which negatively affects 

driver visibility, situational awareness, and 

performance.

General enhanced 

situational awareness

Work zone Vehicles approaching a work zone with a closed lane 

segment, overlaid scheduled lanes, and stop lines. 
11 

CHAPTER 3. CP USE CASE: VRU CROSSING IN CONTROLLED CONFLICT AREAS 

This low-level ConOps focuses on the system framework and requirements of the CP feature in 

the CARMA Ecosystem for a particular scenario. The scenario is the second scenario in the VRU 

application group as defined in the high-level ConOps: VRUs crossing in controlled conflict 

areas.(1)

In controlled conflict areas, such as pedestrian crossings, intersections, roundabouts, and ramps, 

VRUs should have higher priority when crossing the road. When traffic volume is relatively 

high, or when the number of conflict points is large, human drivers could easily miss VRUs. 

Autonomous vehicles could also have limited line of sight and may be unable to detect VRUs 

sufficiently early. CP supported by both infrastructure- and vehicle-based sensors, as well as 

V2X communications, could significantly increase road vehicles’ awareness of VRUs and thus 

improve VRU safety. Additionally, with proper design of CAV path-planning algorithms and 

infrastructure-based intersection management algorithms that fully take advantage of CP 

information, mobility and energy consumption improvements could also be possible in

controlled conflict areas.

Several representative situations that fall into the use case of VRUs crossing in controlled 

conflict areas are discussed in the high-level CP ConOps.(1)

 The representative situations include 

multiple examples of turning vehicles conflicting with crossing VRUs, as well as an edge case in 

which vehicles that have the right-of-way conflict with pedestrians who have not cleared the 

intersection (e.g., due to the pedestrian’s slow-moving speed). 

Figure 4 depicts this edge case, in which a westbound pedestrian is clearing the intersection out 

of the designated signal phase. A heavy (or large) vehicle is the first vehicle stopped at the 

intersection on its northbound approach with a clear line of sight of the pedestrian. The vehicle 

remains stopped to allow the pedestrian more time to cross. A passenger vehicle (the bottom 

vehicle in figure 4) is approaching northbound behind the heavy (or large) vehicle. The 

approaching vehicle may be unable to detect the pedestrian due to the vehicle’s obstructed front 

view. The approaching vehicle could have a collision with the pedestrian if the vehicle tries to 

change lanes and drive through the intersection in the adjacent lane. Through CP, the vehicle can 

potentially avoid this collision. Figure 4 illustrates the case in which the heavy vehicle waiting at 

the intersection is equipped with C–ADS and shares its perception with surrounding vehicles 

through V2V communications. Additionally, infrastructure-based sensing, detection, and 

communications could be an integral part of CP in controlled conflict areas. 
12 

Source: FHWA.

(1)

Figure 4. Illustration. CP through V2V communications to improve situational awareness: 

VRUs clearing intersection outside of allocated phase.

This low-level ConOps expands the edge case depicted in figure 4 into three related situations.

All three situations involve a large vehicle (which can be a heavy vehicle, a transit vehicle, or an 

emergency response vehicle), a passenger vehicle equipped with cooperative ADS (C–ADS), a 

pedestrian, and roadside sensing, computation, and communications infrastructure. The three 

situations are the following: 

• Situation 1. Both vehicles are stopped; CP is enabled by infrastructure technologies. 

• Situation 2. Both vehicles are stopped; CP is enabled by both vehicle-based and 

infrastructure-based technologies, as well as DF. 

• Situation 3. The heavy vehicle is stopped, and the passenger vehicle is approaching; CP is 

enabled by both vehicle-based and infrastructure-based technologies, as well as DF; the 

passenger vehicle incorporates CP information in its trajectory planning. 

In Situation 1 (see figure 5), the two vehicles are stopped in the same lane behind the stop line at 

a signalized intersection when the light has just turned green for their approach. The pedestrian is 

crossing the road in front of the two vehicles outside of the designated pedestrian phase (e.g., due 

to the pedestrian’s slow-moving speed). The heavy vehicle is the first vehicle behind the stop 

line and remains stopped to allow the pedestrian to cross the intersection safely. The passenger 

vehicle does not have direct line of sight of the pedestrian, as the large vehicle blocks its view. A 

set of RSE detects and perceives the pedestrian and sends an object-based CP message to the 

passenger vehicle through vehicle-to-infrastructure communications (represented by a dashed 

arrow). The passenger vehicle receives the CP message, processes it, and adds the pedestrian to 

its own object list. With the CP information, the passenger vehicle stays in place and does not 

use the adjacent lane to drive around the heavy vehicle. 
13 

Source: FHWA. 

Figure 5. Illustration. Situation 1. 

Situation 2 (figure 6) adds some complexity to Situation 1 by highlighting DF, one of the five CP 

technical considerations. If the large vehicle is also equipped with C–ADS that supports CP, it 

could detect and perceive the pedestrian and send a CP message to the passenger vehicle through 

V2V communications. The passenger vehicle receives CP messages about the same object (the 

pedestrian) from both the RSE and the large vehicle and needs to fuse data from both CP 

messages before adding the pedestrian to its own object list. 

Source: FHWA. 

Figure 6. Illustration. Situation 2. 

Situation 3 (figure 7) explores improvements to CDA features that effectively use CP 

information. In addition to ODP and DF, CPA is an essential consideration in Situation 3. Unlike 
14 

Situations 1 and 2, the passenger vehicle in Situation 3 is approaching the intersection, unaware 

of the pedestrian due to its obstructed front view. Without CP, the passenger vehicle could 

decide to drive around the stopped heavy vehicle as it approaches the intersection during the 

traffic signal’s green phase. Such a maneuver could lead to a collision between the passenger 

vehicle and the pedestrian. Through CP, the passenger vehicle receives information about the 

pedestrian from both the RSE and the large vehicle, becomes aware of the pedestrian and their 

status after fusing perception data shared by multiple sources, and adjusts its own trajectory to 

avoid conflict with the pedestrian. For example, the passenger vehicle may do one of the 

following: 

• Come to a full stop behind the large vehicle. 

• Slow down sufficiently behind the heavy vehicle in anticipation that the heavy vehicle 

will start to move after the pedestrian clears the lane that the two vehicles are in (traffic 

laws permitting). 

• Change lanes and slow down to allow the pedestrian to safely cross before speeding up 

again (traffic laws permitting). 

Source: FHWA. 

Figure 7. Illustration. Situation 3. 

The three situations have increasing complexities. In Situation 1, two of the five CP technical 

considerations, ODP and communication issues, are relevant to system functions. DF becomes 

relevant in Situation 2, in addition to the two technical considerations in Situation 1. Finally, in 

Situation 3, the effective use of CP information becomes more relevant as the passenger vehicle 

is moving. Note that although CS considerations are critical to the viability of the CP feature in 

actual deployment, they are beyond the scope of the functional requirements of a PoC system. 

Therefore, this low-level ConOps will not include CS requirements. 
15 

The next three chapters will detail operational user needs and system functional requirements for 

the three situations. Note that this low-level ConOps and its associated high-level ConOps are 

both focused on CP in the CARMA Ecosystem.(1) Therefore, the system requirements discussed 

in the next three chapters are specific to CARMA products. This low-level ConOps serves as a 

reference document for algorithm development and implementation.

17 

CHAPTER 4. SITUATION 1

This chapter analyzes Situation 1, described in chapter 3. In Situation 1, both vehicles are 

stopped behind the stop line while a pedestrian clears the intersection out of the designated 

pedestrian phase. CP in Situation 1 is enabled by infrastructure sensing, computing, and 

communication technologies. The large vehicle in Situation 1 is assumed to be a manually driven 

vehicle that does not support V2X communications. The passenger vehicle in Situation 1 is 

assumed to be capable of V2X communications at a minimum. The pedestrian in Situation 1 is 

assumed to be nonconnected. Situation 1 exhibits two of the five CP technical considerations, 

namely ODP and communication issues.

USER-ORIENTED OPERATIONAL DESCRIPTION

This section describes Situation 1 (figure 5) from the perspectives of the road users involved. 

Driver Perspective (connected but nonautomated vehicle)

At a signalized intersection, a passenger vehicle driver is stopped at a red light on the northbound 

intersection approach. The northbound intersection approach has two lanes. The driver’s vehicle 

is second in the median-lane queue, behind a large vehicle. The curbside lane has no visible 

queued vehicles or arriving vehicles.

On the vehicle’s dashboard, the driver notices an alert of a pedestrian in a “conflicting 

crosswalk” (i.e., a crosswalk where a pedestrian could conflict with the car). The alert could be 

in audio, visual, or haptic format, or a combination of those formats. The dashboard could also 

provide a countdown clock, which would provide real-time updates of the northbound signal 

phase. For example, the dashboard countdown clock could show that the northbound signal will 

turn green after a certain amount of time (e.g., 15 s). The driver may not yet see the conflicting 

pedestrian with their own eyes due to the blocked line of sight. However, the dashboard 

continues to warn of a conflicting pedestrian, and the countdown clock (to the next green phase) 

continues to display a decreasing number of seconds remaining in the interval. If adaptive 

pedestrian phase is enabled at the intersection, the driver may notice that the countdown clock 

time displays a higher number of remaining seconds, due to extensions of the current (east-west) 

green pedestrian phase.

As the signal phases change, the driver sees the northbound signal turn green as expected. 

However, the dashboard still warns of a conflicting pedestrian. By now, the driver may or may 

not have seen the conflicting pedestrian at the crosswalk. The large vehicle (first in queue) 

continues to remain motionless for an unusually long time (e.g., more than 5 s) after the 

northbound signal turns green. Normally in such a situation, the driver would change lanes to 

drive past the large vehicle. However, because of the conflicting pedestrian warning, the driver 

continues to wait. 

The driver may notice the conflicting pedestrian appear just to the right of the large vehicle, 

within the crosswalk. The driver may then see the pedestrian complete their walking trip past the 

crosswalk and onto the sidewalk. The pedestrian alert then disappears from the dashboard. The 
18 

large vehicle then drives ahead northbound and through the intersection. The passenger vehicle

driver then drives ahead northbound as well.

Vehicle Perspective (CAV) 

The description in this subsection assumes that the passenger vehicle (second in queue) is an 

SAE Level 3 vehicle that supports at least CDA Class A capabilities.

At a signalized intersection, a passenger car waits behind a large vehicle stopped at a red light on 

the northbound intersection approach. The vehicle’s virtual environment indicates that the 

northbound intersection approach has two lanes. The virtual environment indicates that the 

vehicle is second in the median lane queue and that the curbside lane has no queued vehicles or 

incoming vehicles. The passenger car is receiving and processing both CP messages and signal 

phasing and timing (SPaT) messages from the infrastructure.

The CP messages begin to indicate the presence of a pedestrian who may conflict with the 

northbound signal phases and traffic movements. At approximately this same time, the SPaT 

messages could also indicate an expected duration of the current (east-west) signal phase 

(e.g., 15 s). At some point during the east-west signal phase, the vehicle may directly sense the 

same conflicting pedestrian through its own detection capabilities when the vehicle’s line of 

sight of the pedestrian is not blocked. Also, at some point during the east-west signal phase 

(e.g., 10 s), the SPaT messages may indicate that the current (east-west) signal phase will extend 

by an additional few seconds (e.g., 5 s) if the intersection runs adaptive pedestrian phases. 

Some amount of time after the east-west signal phase began (e.g., 20 s), the SPaT messages 

indicate that a new north-south signal phase has begun. However, the CP messages continue to 

indicate the presence of a pedestrian who may conflict with the northbound traffic movements. 

The large vehicle (first in queue) continues to remain motionless for an unusually long time 

(e.g., more than 5 s) after the northbound signal turns green. Normally in such a situation, the 

passenger vehicle would change lanes to drive past the large vehicle. However, because of the 

conflicting pedestrian presence, the vehicle continues to wait. Some amount of time later 

(e.g., 10 s), the CP messages then cease to contain any pedestrian information. At the same time, 

the large vehicle (which was first in queue) then starts to drive ahead northbound and through the 

intersection. The vehicle then drives ahead northbound in the same lane, after assessing that the 

right-of-way of the current lane is cleared. 

VRU Perspective

The pedestrian approaches a signalized intersection, with queued vehicles waiting at multiple 

approaches. The pedestrian pushes a button to request crossing the intersection in the eastbound 

direction. Once the traffic signal turns green in the eastbound direction, the pedestrian enters the 

intersection crosswalk and walks across four northbound lanes of traffic. Due to her slow 

walking speed, the pedestrian is not able to clear the intersection within the allocated pedestrian 

green phase. The pedestrian sees the pedestrian signal turn red (“do not walk”) when she is in the 

middle of the crosswalk. The pedestrian continues to cross the intersection as the northbound 

vehicles wait for her to clear the intersection. The pedestrian completes her crossing, exits the 

eastbound crosswalk, and enters a sidewalk on the far side of the intersection.
19 

ENTITIES AND STAKEHOLDERS

The following entities and their associated minimum configurations should be considered when 

executing the operational situation for research and development purposes: 

• The pedestrian crossing the road could be a real human because the safety risk in this 

situation is low since neither vehicle is moving. Alternatively, a programmable 

articulation pedestrian dummy could be used. Depending on the infrastructure-sensing 

technologies used, the pedestrian dummy may need to be outfitted with additional 

equipment. For example, if infrastructure sensors are based on thermal technologies, 

heating pads could be mounted on the pedestrian dummy. 

• The first vehicle behind the stop line could be any large vehicle if it is able to block the 

line of sight of the passenger vehicle behind it. 

• The passenger vehicle behind the large vehicle should have machine-to-machine 

communication capabilities, at a minimum. It does not have to have any driving 

automation (SAE Level 0), but it should have onboard computing capabilities that can 

process CP information and convert it for human driver consumption. Alternatively, a 

vehicle with SAE Level 3, or above, driving automation could be used. 

• Infrastructure sensing, computing, and communication technologies are necessary to 

execute this operational situation. 

Stakeholders of this operational situation include the following: 

• VRUs, including pedestrians, bicyclists, motorcyclists, and micromobility users. 

• Drivers of connected but nonautomated passenger vehicles. 

• Passenger vehicles equipped with C–ADS. 

• Researchers and developers. 

• Original equipment manufacturers. 

• Infrastructure owners and operators.

OPERATIONAL USER NEEDS

Table 2 summarizes the operational user needs specific to CP in Situation 1.
20 

Table 2. Operational user needs for Situation 1. 

Mode/Vehicle 

Type Automation 

Connectivity/

CDA

User Characteristics 

and Needs ID Number

Passenger 

vehicle driver 

Human driving Connected Receive real-time 

updates from the 

connected vehicle about 

VRUs within the 

controlled conflict area 

(e.g., a warning message 

designed for human 

driver consumption) at a 

reasonable frequency.

CP-UN-S1-01 

Passenger 

vehicle

Automated 

driving 

Vehicles 

equipped with 

C–ADS

Receive real-time 

updates from the 

infrastructure about 

VRU locations, 

headings, speeds, etc. 

CP-UN-S1-02 

VRU Nonmotorized/

human driving 

Nonconnected Need continuous 

attention from other 

users on the road. 

CP-UN-S1-03 

SYSTEM FUNCTIONAL REQUIREMENTS

In correspondence with the high-level CP ConOps, this low-level ConOps uses CARMA 

Ecosystem as an example CDA system to explore incorporating the CP feature.

(1) Table 3

summarizes the system functional requirements of relevant CARMA products for Situation 1. 

These system requirements support the user needs discussed in table 2. It should be noted that 

the system functional requirements in this low-level ConOps are developed based on the 

assumption that infrastructure-based sensors have onboard computation capabilities to detect 

and perceive pedestrians. If infrastructure-based sensors do not have detection and perception 

capability, such capabilities should be required to reside in CARMA Streets. The high-level 

CP ConOps includes discussions on system functional requirements for both cases.(1) The last 

column of table 3 traces these system requirements to the high-level system operational needs 

and functional requirements defined in the high-level CP ConOps.(1)

 The high-level system 

operational needs and functional requirements are also provided in the appendix of this 

document. 
21 

Table 3. System functional requirements for Situation 1. 

ID Number

Relevant 

Component Functional Requirements Statement Traces To

CP-S1-SR01 Infrastructure-based

smart sensors 

Infrastructure-based smart sensors 

(sensors with onboard computation 

capability) installed at an intersection 

detect and classify pedestrians within 

predefined detection zones (e.g., 

crosswalks). A smart sensor perceives 

the following minimal attributes of a 

detected pedestrian: location, speed, 

and heading.

CP-SR-09;

CP-N-ODP03a

CP-S1-SR02 Infrastructure-based 

smart sensors 

Infrastructure-based smart sensors

(sensors with onboard computation 

capability) installed at an intersection 

transmit processed object-based 

perception data to CARMA Streets. 

Processed object-based perception 

data should be continuously 

transmitted at a consistent frequency 

while a pedestrian is in a predefined 

detection zone. 

A typical transmission frequency is 10 

Hz. Accounting for fluctuation in the 

communication network, the average 

transmission frequency during a 

continuous detection session should be 

10 Hz ± 1 Hz.

CP-SR10;

CP-N-ODP03b 

CP-S1-SR03 CARMA Streets An infrastructure computer with 

CARMA Streets installed wirelessly 

transmits processed object-based 

perception data as a CP message at a 

frequency between 10 and 1 Hz 

according to a ruleset that specifies 

conditions to determine transmission 

frequency and object inclusion.

CP-SR12;

CP-NCOMM02; 

CP-NCOMM05
22 

ID Number

Relevant 

Component Functional Requirements Statement Traces To

CP-S1-SR04 CARMA Platform A CDA vehicle equipped with 

CARMA Platform receives and 

processes CP messages sent by 

CARMA Streets. Each CP message 

should be processed before the next 

message is received. Objects that are 

not currently in the CDA vehicle’s 

world model will be added to the 

object list. Attributes of existing 

objects created from previous CP 

messages should be updated according 

to received perception data.

CP-SR14; 

CP-NCOMM03

CP-S1-SR05 CARMA 

Messenger

CARMA Messenger installed in a 

display system for connected non-AV 

receives and processes object-based 

perception data sent by CARMA 

Streets. Each CP message should be 

processed before the next message is 

received. Objects that are not currently 

in the vehicle’s world model will be 

added to the object list. Attributes of 

existing objects created from previous 

CP messages should be updated 

according to received perception data.

CP-SR17; 

CP-NCOMM03

CP-S1-SR06 CARMA 

Messenger

CARMA Messenger installed in a

connected non-AV notifies the human 

driver (e.g., through visual and/or 

audio alerts) about conflicting VRUs 

derived from object-based perception 

data at a reasonable frequency.

CP-SR19; 

CP-N-CPA02

COMM = communication.
23 

PERFORMANCE METRICS

Key performance metrics for monitoring and evaluating operations during execution of this 

situation should include the following: 

• Object detection and perception data frequency is the frequency at which the 

infrastructure-based smart sensor transmits object detection and perception data to 

CARMA Streets.

• Object detection and perception accuracy is the accuracy of the infrastructure-based 

smart sensor in detecting, perceiving, and locating the VRU. 

• CP message latency is the time difference between origination of the CP message from 

CARMA Streets and the receipt by the vehicle. Total end-to-end latency could include 

the time to compose, transmit, and decompose the message. 

• CP message drop rate is the number of CP messages not received divided by the total 

number of CP messages sent.

25 

CHAPTER 5. SITUATION 2

This chapters analyzes Situation 2, described in chapter 3. In Situation 2, both vehicles are 

stopped behind the stop line while a pedestrian clears the intersection out of the designated 

pedestrian phase. CP in Situation 2 is enabled by both vehicle- and infrastructure-based sensing, 

computing, and communication technologies. The large vehicle in Situation 2 is assumed to be a 

vehicle equipped with detection, perception, and V2X communication capabilities. The 

passenger vehicle in Situation 2 is assumed to be capable of V2X communications, at a 

minimum. The pedestrian in Situation 2 is assumed to be nonconnected. Situation 2 exhibits 

three of the five CP technical considerations. In addition to ODP and communication issues 

discussed in Situation 1 (see chapter 4), DF is essential in Situation 2. 

USER-ORIENTED OPERATIONAL DESCRIPTION

This section describes Situation 2 (figure 6) from the perspectives of the road users involved. 

Compared with Situation 1 (figure 5), DF is now an additional system functionality. In 

Situation 2, the passenger vehicle fuses CP data from two sources (both the large vehicle and the 

infrastructure).

Driver Perspective (connected but nonautomated vehicle)

From the perspective of the driver of the passenger vehicle (second in queue), Situation 2 is not 

significantly different from Situation 1 as described in chapter 4. The passenger vehicle receives 

CP messages from both the large vehicle (first in queue) and the infrastructure and fuses the data 

to synthesize information. This process runs within the passenger vehicle’s software and is not 

visible to the driver. 

If the large vehicle detects the pedestrian before the infrastructure does, the passenger vehicle 

may receive CP information about the pedestrian earlier than it would have in Situation 1. The 

passenger vehicle’s dashboard pedestrian warning (alert) may appear earlier as a result. 

Vehicle Perspective (CAV) 

The description in this subsection assumes that the passenger vehicle (second in queue) is an 

SAE Level 3 vehicle that supports at least CDA Class A capabilities.

At a signalized intersection, a passenger vehicle waits behind a large vehicle at a red light on the 

northbound intersection approach. The vehicle’s CDA software indicates that the northbound 

intersection approach has two lanes. The CDA software indicates that the vehicle is second in the 

median lane queue and that the curbside lane has no queued vehicles or incoming vehicles. The 

passenger vehicle is receiving and processing both CP messages and SPaT messages from the 

infrastructure. The SPaT messages indicate that all northbound signal phases are currently red. 

The CP messages from the infrastructure begin to indicate the presence of a pedestrian who may 

conflict with the northbound signal phases and traffic movements. Also, at approximately the 

same time, the passenger vehicle (second in queue) starts to receive CP messages from the large 

vehicle (first in queue) about a pedestrian who may conflict with the northbound signal phases 
26 

and traffic movements. The passenger vehicle executes internal logic to determine and confirm 

that the CP messages from both the infrastructure and the large vehicle are related to the same 

pedestrian. Once confirmed, the passenger vehicle’s internal logic reconciles any discrepancy in 

object attributes (e.g., location, speed, heading) in the CP messages from both sources and 

registers the pedestrian and her attributes in the vehicle’s world model. 

At approximately this same time, the SPaT messages could also indicate an expected duration of 

the current (east-west) signal phase (e.g., 15 s). At some point during the east-west signal phase, 

the vehicle may directly sense the same conflicting pedestrian through its own detection 

capabilities when the vehicle’s line of sight of the pedestrian is not blocked. Also, at some point 

during the east-west signal phase (e.g., 10 s), the SPaT messages may indicate that the current 

(east-west) signal phase will extend by a few seconds (e.g., 5 s) if the intersection runs adaptive 

pedestrian phases.

Some amount of time after the east-west signal phase began (e.g., 20 s), the SPaT messages 

indicate that a new north-south signal phase has begun. However, the CP messages continue to 

indicate the presence of a pedestrian who may conflict with the northbound traffic movements. 

The large vehicle (first in queue) continues to remain motionless for an unusually long time 

(e.g., more than 5 s) after the northbound signal turns green. Normally in such a situation, the 

passenger vehicle would change lanes to drive past the large vehicle. However, because of the 

conflicting pedestrian presence, the vehicle continues to wait. Some amount of time later 

(e.g., 10 s), the CP messages then cease to contain any pedestrian information. At the same time, 

the large vehicle (which was first in queue) then starts to drive ahead northbound and through the 

intersection. The passenger vehicle then drives ahead northbound in the same lane after assessing 

that the right-of-way of the current lane is cleared.

VRU Perspective

From the pedestrian’s perspective, Situation 2 is identical to Situation 1. The pedestrian remains 

unaware of how other road users are sensing their movements or about what measures the other 

road users are taking to avoid a potential conflict. 

ENTITIES AND STAKEHOLDERS

When executing this operational situation (Situation 2) for research and development purposes, 

the entities and their associated minimum configurations are mostly identical to those in 

Situation 1 (as described in chapter 4). The following minimum configurations required for the 

large vehicle and the passenger vehicle in Situation 2 are slightly different from those in 

Situation 1: 

• As in Situation 1, the large vehicle used in executing Situation 2 needs to be able to block 

the line of sight of the passenger vehicle behind it. Additionally, the large vehicle should 

have sensing, perception, and machine-to-machine communication capabilities, at a 

minimum. It does not have to have any driving automation (SAE Level 0), but it needs to 

be able to detect and perceive the pedestrian and generate and broadcast CP messages. 

Alternatively, a vehicle with SAE Level 3, or above, driving automation could be used. 
27 

• In addition to the minimum requirements discussed in Situation 1, the passenger vehicle 

needs new computation capabilities to fuse CP messages from multiple entities. Such 

computation capabilities may include object localization, object association, and state 

(attribute) estimation. 

The stakeholders for Situation 2 are identical to those for Situation 1, which were described in 

chapter 4.

OPERATIONAL NEEDS

Table 4 summarizes the operational user needs specific to CP in Situation 2. Note that the 

operational needs of the passenger vehicle driver (when the passenger vehicle is connected but 

not automated) and those of the pedestrian in table 4 are identical to CP-UN-S1-01 and 

CP-UN-S1-03 in table 2. The operational user needs of the passenger vehicle (when the 

passenger vehicle is connected and automated) in table 4 are slightly different from 

CP-UN-S1-02 in table 2. 

Table 4. Operational user needs for Situation 2. 

Mode/Vehicle 

Type Automation 

Connectivity/

CDA

User Characteristics and 

Needs ID Number

Passenger 

vehicle driver 

Human driving Connected See CP-UN-S1-01 in table 2. CP-UN-S1-01 

Passenger 

vehicle

Automated 

driving 

Vehicles 

equipped with 

C–ADS

Receive real-time updates 

from both the infrastructure 

and other road vehicles 

equipped with C–ADS about 

VRU locations, headings, 

speeds, etc.

CP-UN-S2-01 

VRU Nonmotorized/

human driving 

Nonconnected See CP-UN-S1-03 in table 2. CP-UN-S1-03 

SYSTEM FUNCTIONAL REQUIREMENTS

In correspondence with the high-level CP ConOps, this low-level ConOps uses CARMA 

Ecosystem as an example CDA system to explore incorporating the CP feature.(1) The system 

functional requirements of relevant CARMA products for Situation 1 (table 3) are still relevant 

for Situation 2. It should be noted that the system functional requirements in this low-level 

ConOps are developed based on the assumption that infrastructure-based sensors have onboard 

computation capabilities to detect and perceive pedestrians. If infrastructure-based sensors do not 

have detection and perception capability, such capabilities should be required to reside in 

CARMA Streets. The high-level CP ConOps includes discussions on system functional 

requirements for both cases.(1)

 Additional system functional requirements specific to Situation 2 

are detailed in table 5. These system requirements support the user needs discussed in table 4. 

The last column of table 5 traces these system requirements to the high-level system operational 
28 

needs and functional requirements defined in the high-level CP ConOps.(1)

 The high-level 

system operational needs and functional requirements are also provided in the appendix of 

this document. 

Table 5. System functional requirements for Situation 2. 

ID Number

Relevant 

Component Functional Requirements Statement Traces To

CP-S1-SR01 Infrastructure-based 

smart sensors 

See CP-S1-SR01 in table 3. CP-SR-09; 

CP-N-ODP03a

CP-S1-SR02 Infrastructure-based 

smart sensors 

See CP-S1-SR02 in table 3. CP-SR10; 

CP-N-ODP03b

CP-S1-SR03 CARMA Streets See CP-S1-SR03 in table 3. CP-SR12; 

CP-N-COMM02; 

CP-N-COMM05

CP-S2-SR01 CARMA Platform A CDA vehicle equipped with 

CARMA Platform detects and 

classifies pedestrians within its field of 

view and detection range and 

perceives the following minimal 

attributes of a detected pedestrian: 

location, speed, and heading. 

CP-SR02; 

CP-N-ODP01

CP-S2-SR02 CARMA Platform A CDA vehicle equipped with 

CARMA Platform wirelessly 

transmits locally perceived object data 

as a CP message at a frequency 

between 10 and 1 Hz according to a 

ruleset that specifies conditions to 

determine transmission frequency and 

object inclusion. 

CP-SR11; 

CP-N-COMM01; 

CP-N-COMM05

CP-S2-SR03 CARMA Platform A CDA vehicle equipped with 

CARMA Platform receives and 

processes CP messages sent by 

CARMA Streets and other CARMA 

Platform instances. Each CP message 

should be processed before the next 

message is received. 

CP-SR14; 

CP-N-COMM03
29 

ID Number

Relevant 

Component Functional Requirements Statement Traces To

CP-S2-SR04 CARMA Platform A CDA vehicle equipped with 

CARMA Platform, in realtime, fuses 

object-based perception data received 

from CARMA Streets and other 

CARMA Platform instances and 

produces a merged world model. 

Objects that are not currently in the 

CDA vehicle’s world model will be 

added to the object list. Attributes of 

existing objects created from previous 

CP messages will be updated 

according to newly received and fused 

perception data.

CP-SR15; 

CP-N-DF01

CP-S2-SR05 CARMA 

Messenger

CARMA Messenger installed in a 

connected non-AV receives and 

processes object-based perception data 

sent by CARMA Streets and other 

CARMA Platform instances. Each CP 

message should be processed before 

the next message is received. 

CP-SR17; 

CP-N-COMM03

CP-S2-SR06 CARMA 

Messenger

CARMA Messenger installed in a 

connected non-AV, in realtime, fuses 

object-based perception data received 

from CARMA Streets and other 

CARMA Platform instances and 

produces a merged world model. 

Objects that are not currently in the 

vehicle’s world model will be added 

to the object list. Attributes of existing 

objects created from previous CP 

messages will be updated according to 

newly received and fused perception 

data.

CP-SR18; 

CP-N-DF01

CP-S1-SR06 CARMA 

Messenger

See CP-S1-SR06 in table 3. CP-SR19; 

CP-N-CPA02
30 

PERFORMANCE METRICS

All performance metrics for Situation 1 discussed in chapter 4 are still relevant in Situation 2. 

Additional performance metrics should be considered to assess the effectiveness of the 

object-level data fusion required in Situation 2. These additional performance metrics could 

include the following: 

• Accuracy of object association is the accuracy of the data fusion algorithms in matching 

objects detected and perceived by multiple entities. 

• Accuracy of the fused object detection and perception is the accuracy of the fused data in 

VRU detection and attributes perception. 

• Computational time of data fusion algorithms is the time it takes to fuse CP data from 

multiple entities into one set of object-based perception data.
31 

CHAPTER 6. SITUATION 3

This chapters analyzes Situation 3 described in chapter 3. In Situation 3, a large vehicle is 

stopped behind the stop line (first in queue) with a passenger vehicle approaching the 

intersection behind the large vehicle, while a pedestrian clears the intersection out of the 

designated pedestrian phase. CP in Situation 3 is enabled by both vehicle- and 

infrastructure-based sensing, computing, and communication technologies. The large vehicle in 

Situation 3 is assumed to be equipped with detection, perception, and V2X communication 

capabilities. The passenger vehicle in Situation 3 is assumed to be capable of V2X 

communications at a minimum. The pedestrian in Situation 3 is assumed to be nonconnected. 

Situation 3 exhibits four of the five CP technical considerations. In addition to ODP, 

communication issues, and DF required in Situation 2 (see chapter 5), the effective use of CP 

information in vehicle trajectory planning and control is more relevant in Situation 3 as the 

passenger vehicle equipped with C–ADS approaches the intersection. 

USER-ORIENTED OPERATIONAL DESCRIPTION

This section describes Situation 3 (figure 7) from the perspectives of the road users involved. 

Compared with Situation 2 (figure 6), CPA is now an additional system functionality. In 

Situation 3, the passenger vehicle uses the fused CP data from two sources (both the large 

vehicle and the infrastructure) in its trajectory planning and control algorithms. 

Driver Perspective (connected but nonautomated vehicle)

At a signalized intersection, a passenger vehicle driver approaches a green light on the 

northbound intersection approach. The northbound intersection approach has two lanes. A large 

vehicle remains motionless at the northbound intersection stop bar in the median lane. The 

curbside lane has no visible queued vehicles or incoming vehicles. 

As the vehicle gets closer to the intersection (but is still relatively far from the large vehicle), the 

driver notices, on the vehicle’s dashboard, an alert of a pedestrian in a “conflicting crosswalk” 

(i.e., a crosswalk where a pedestrian could conflict with the vehicle’s path). The driver may not 

yet see the conflicting pedestrian with their own eyes. The large vehicle remains motionless for 

an unusually long time (e.g., more than 5 s) during the northbound green phase as the passenger 

approaches the green light. Normally in such a situation, the driver would maintain speed and 

change lanes to drive past the large vehicle. However, because of the conflicting pedestrian 

warning, the driver slows down to wait behind the large vehicle. Alternatively, the driver may 

change lanes and slow down at the same time when the vehicle is still relatively far from the stop 

bar (at a sufficient distance to make a full stop at the speed of travel).

As the passenger vehicle stops behind the large vehicle, or as the passenger vehicle changes to 

the curbside lane, the driver may notice the conflicting pedestrian appear just to the right of the 

large vehicle within the crosswalk. If the vehicle has changed lanes and is in the curbside lane 

approaching the intersection, the driver further slows down and stops at the stop bar to wait for 

the pedestrian to clear the intersection. The driver may then see the pedestrian complete their 

walking trip past the crosswalk and onto the sidewalk. The pedestrian alert then disappears from 

the dashboard. The large vehicle then drives ahead northbound and through the intersection. The 
32 

passenger vehicle driver drives ahead northbound as well, following the large vehicle (if the 

passenger vehicle has stopped behind the large vehicle) or at the same time as the large vehicle 

(if the passenger vehicle has changed lanes and stopped behind the stop bar in the curbside lane). 

Vehicle Perspective (CAV) 

At a signalized intersection, a passenger vehicle approaches a green light on the northbound 

intersection approach. The vehicle’s CDA software indicates that the northbound intersection 

approach has two lanes. The virtual environment indicates that a nearby vehicle remains 

motionless at the northbound intersection stop bar, in the median lane, and that the curbside lane 

has no queued vehicles or incoming vehicles. The passenger vehicle is receiving and processing 

both CP messages and SPaT messages from the infrastructure. The SPaT messages indicate that 

all northbound signal phases are currently green. The SPaT messages may indicate an expected 

duration of the current (north-south) signal phase (e.g., 90 s). 

The CP messages from the infrastructure begin to indicate the presence of a pedestrian who may 

conflict with the northbound signal phases and traffic movements. At approximately the same 

time, the passenger vehicle (second in queue) starts to receive CP messages from the large 

vehicle (first in queue) about a pedestrian who may conflict with the northbound signal phases 

and traffic movements. The passenger vehicle executes internal logic to determine and confirm 

that the CP messages from both the infrastructure and the large vehicle are related to the same 

pedestrian. Once confirmed, the passenger vehicle’s internal logic reconciles any discrepancy in 

object attributes (e.g., location, speed, heading) in the CP messages from both sources and 

registers the pedestrian and her attributes in the vehicle’s world model. 

The vehicle’s CDA software indicates that the large vehicle (at the stop bar) has remained 

motionless for an unusually long time (e.g., more than 5 s) during the northbound green signal. 

Normally in such a situation, the passenger car would maintain speed and change lanes to drive 

past the large vehicle. However, because CP messages from at least one of the data sources 

indicate that a pedestrian remains within the conflict area, the passenger vehicle exercises its 

internal maneuver and trajectory planning logic to determine the best course of action. It could 

slow down to wait behind the large vehicle or change lanes and come to a full stop in the 

curbside lane. Some amount of time later (e.g., 10 s), the CP messages then cease to contain any 

pedestrian information. If the passenger vehicle has changed lanes and is the first vehicle stopped 

behind the stop bar in the curbside lane, the vehicle’s own sensors may have also observed the 

pedestrian clearing the intersection and confirmed that the pedestrian is no longer present in the 

conflict area. At approximately the same time, the large vehicle (which was first in queue) starts 

to drive northbound and through the intersection. The passenger vehicle drives ahead northbound 

as well, following the large vehicle (if the passenger vehicle has stopped behind the large 

vehicle) or at the same time as the large vehicle (if the passenger vehicle has changed lanes and 

stopped behind the stop bar in the curbside lane). 

VRU Perspective

From the pedestrian’s perspective, Situation 3 is identical to Situations 1 and 2. The pedestrian 

remains unaware of how other road users are sensing them or about what measures the other road 

users are taking to avoid a potential conflict. 
33 

ENTITIES AND STAKEHOLDERS

When executing this operational situation (Situation 3) for research and development purposes, 

the entities and their associated minimum configurations are mostly identical to those in 

Situations 1 and 2 (as described in chapter 4), with the following differences: 

• Because Situation 3 presents more potential safety risks to the pedestrian during testing, a 

pedestrian dummy should be used instead of a human. The use of a pedestrian dummy 

would allow for safe experimentation with the passenger vehicle’s safety/mobility 

application that uses CP information, whether the application is a driver warning system 

(for connected but nonautomated vehicles) or maneuver and trajectory planning logic (for 

CAVs). 

• For the passenger vehicle, in addition to the minimum requirements discussed in 

Situations 1 and 2, the vehicle should have a safety/mobility application that uses CP 

information to improve safety when approaching controlled VRU crossing areas. The 

warning system (for connected but nonautomated vehicles) should provide alert 

information in the form and frequency that are appropriate for human consumption and 

allow sufficient time for the human driver to react. If the passenger vehicle is connected 

and automated, the vehicle’s maneuver and trajectory planning logic that uses CP 

information should compute a smooth trajectory that ensures pedestrian safety.

The stakeholders for Situation 3 are identical to those for Situation 1, which were described in 

chapter 4.

OPERATIONAL NEEDS

The operational needs for Situation 3 are identical to those for Situation 2, which were 

summarized in table 4. 

SYSTEM FUNCTIONAL REQUIREMENTS

In correspondence with the high-level CP ConOps, this low-level ConOps uses CARMA 

Ecosystem as an example CDA system to explore incorporating the CP feature.(1) The system 

functional requirements of relevant CARMA products for Situation 2 (table 5) are still relevant 

for Situation 3. It should be noted that the system functional requirements in this low-level 

ConOps are developed based on the assumption that infrastructure-based sensors have onboard 

computation capabilities to detect and perceive pedestrians. If infrastructure-based sensors do not 

have detection and perception capability, such capabilities should be required to reside in 

CARMA Streets. The high-level CP ConOps includes discussions on system functional 

requirements for both cases.(1) Additional system functional requirements specific to Situation 3 

are detailed in table 6. These system requirements support the user needs discussed in table 4. 

The last column of table 6 traces these system requirements to the high-level system operational 

needs and functional requirements defined in the high-level CP ConOps.(1) The high-level system 

operational needs and functional requirements are also provided in the appendix of this 

document. 
34 

Table 6. System functional requirements for Situation 3. 

ID Number

Relevant 

Component Functional Requirements Statement Traces To

CP-S1-SR01 Infrastructure-based 

smart sensors

See CP-S1-SR01 in table 3. CP-SR-09;

CP-N-ODP03a

CP-S1-SR02 Infrastructure-based 

smart sensors

See CP-S1-SR02 in table 3. CP-SR10;

CP-N-ODP03b

CP-S1-SR03 CARMA Streets See CP-S1-SR03 in table 3. CP-SR12;

CP-N-COMM02; 

CP-N-COMM05

CP-S2-SR01 CARMA Platform See CP-S2-SR01 in table 5. CP-SR02;

CP-N-ODP01

CP-S2-SR02 CARMA Platform See CP-S2-SR02 in table 5. CP-SR11;

CP-N-COMM01; 

CP-N-COMM05

CP-S2-SR03 CARMA Platform See CP-S2-SR03 in table 5. CP-SR14;

CP-N-COMM03

CP-S2-SR04 CARMA Platform See CP-S2-SR04 in table 5. CP-SR15;

CP-N-DF01

CP-S2-SR05 CARMA 

Messenger

See CP-S2-SR05 in table 5. CP-SR17;

CP-N-COMM03

CP-S2-SR06 CARMA 

Messenger

See CP-S2-SR06 in table 5. CP-SR18;

CP-N-DF01

CP-S3-SR01 CARMA Platform A CDA vehicle equipped with 

CARMA Platform uses fused 

perception data from multiple sources, 

as well as static data such as maps and 

driving rules, to plan and control a 

smooth trajectory that avoids conflict 

with pedestrians clearing the 

intersection outside of their designated 

phase.

CP-SR16;

CP-N-CPA01

CP-S3-SR02 CARMA 

Messenger

CARMA Messenger installed in a 

connected non-AV notifies the human 

driver (e.g., through visual or audio 

alerts or both) about conflicting VRUs 

derived from object-based perception 

data at a reasonable frequency. The 

notification should be given well 

before the passenger vehicle gets too 

close to the intersection (within the 

stopping distance at the vehicle’s 

current speed) to allow for sufficient 

time for the human driver to react.

CP-SR19;

CP-N-CPA02
35 

PERFORMANCE METRICS

All performance metrics for Situations 1 and 2 are still relevant in Situation 3. Additional 

performance metrics that should be considered in Situation 3 to assess the effectiveness of the 

passenger vehicle’s safety/mobility application that uses CP information could include the 

following: 

• Travel speeds driven are the speeds a vehicle drives during the tests, which will be used 

to evaluate the driving smoothness within the control area. 

• Acceleration profile is the acceleration of a vehicle at different time steps during the tests. 

The magnitude of deceleration could be used as a surrogate for safety-critical encounters.

• Timeliness of CP messages refers to whether the approaching passenger vehicle has 

sufficient distance to make a full stop when it first receives CP messages from other 

entities and registers the conflicting pedestrian. 

• Timeliness of relevant safety/mobility applications that use CP information refers to 

whether the approaching passenger vehicle has sufficient distance to make a full stop 

when its safety/mobility applications first alert the driver or first start to replan its 

trajectory by using CP information. 

• Reaction time of human driver refers to the time it takes for a human driver to react and 

reduce speed after receiving the first in-vehicle warning about a conflicting pedestrian. 

This measure could be used as a surrogate for the effectiveness of the in-vehicle warning. 

37 

CHAPTER 7. CONCLUSION

CDA technologies enable mobility and safety applications that individual ADS-operated vehicles

cannot achieve. Such CDA applications are achieved by roadway entities communicating and 

working with each other. CP further enhances CDA by extending the perception range and 

performance of relevant CDA entities, such as roadside infrastructure and vehicles equipped with 

C–ADS. Such increased perception performance is expected to improve situational awareness, 

safety, mobility, and reliability of the transportation system. 

This low-level ConOps discusses the system framework and requirements of three situations that 

fall into a particular CP scenario identified in the high-level ConOps: VRUs crossing in 

controlled conflict areas.(1) All three situations involve a large vehicle (which can be a heavy 

vehicle, a transit vehicle, or an emergency response vehicle), a passenger vehicle equipped with 

C–ADS, a VRU, and roadside sensing, computation, and communication infrastructure. 

In these situations, autonomous vehicles could easily miss VRUs due to limited line of sight. CP 

supported by both infrastructure- and vehicle-based sensors, as well as V2X communications, 

could significantly increase road vehicles’ awareness of VRUs and thus improve VRU safety. 

This ConOps defines the stakeholders, operational needs, system functional requirements, and 

performance metrics for each of the three situations. 

Although CP provides great potential to improve safety and mobility of transportation systems, 

there are a few technical challenges that need to be further addressed before deploying CP 

applications. One of the most important requirements of a safe and effective CP application is the 

timeliness and accuracy of the information shared with different components of the system. The 

latency of VRU detection and perception, as well as the communication latency, must be 

sufficiently small to mitigate or eliminate possible conflicts. In addition, false or erroneous CP 

data may cause safety-critical concerns or lead to diminished trust among transportation users. 

Cybersecurity is another vital challenge that needs further attention in implementing and 

deploying CP applications. Loopholes in CP systems could cause severe safety and mobility 

issues in transportation networks. 

The system functional requirements defined in this ConOps will guide the development of a PoC 

CP feature in the CARMA Ecosystem. To verify and validate the PoC system, a set of field tests 

can be conducted on a closed test track. As a PoC, the testing criteria should be first limited to 

the communication pipeline for VRU detection through CP. The purpose of the testing will be to 

verify the software, collect data for defined performance metrics, and validate that the 

implemented software meets the defined operational needs and functional requirements. Because

many factors contribute to CP data accuracy, the testing will not focus on verifying or validating 

the accuracy aspect of the PoC CP feature in the CARMA Ecosystem. However, the data 

collected during testing may provide some insights that could help further development of CP 

applications in future studies. 

39 

APPENDIX. HIGH-LEVEL SYSTEM REQUIREMENTS

This appendix summarizes the high-level operational needs (table 7) and the functional 

requirements (table 8) of CARMA CP features, based on the generic use cases discussed in the 

high-level ConOps.(1) Based on the five CP technical considerations (see the CP Technical 

Considerations section), the functional requirements and operational needs are classified into five 

categories: ODP, COMM, CS, DF, and CPA. Infrastructure-based ODP could be performed by 

CARMA Streets (CP-N-ODP02a and CP-N-ODP02b) or by smart sensors that also have 

computation capabilities (CP-N-ODP03a and CP-N-ODP03b). These operational needs and 

functional requirements will inform future development of the system requirements of the 

CARMA CP features.

Table 7. CARMA CP operational needs.

Category ID

Relevant 

Component Operational Needs Statement

ODP CP-N-ODP01 CARMA Platform Need to process and fuse calibrated 

raw data received from different local 

onboard extrospective sensors 

(e.g., LiDAR and cameras) and 

produce object-based perception 

information in realtime. The process 

should detect external objects and 

perceive their status, such as location, 

speed, heading, dimensions, 

acceleration, and yaw rate. 

ODP CP-N-ODP02a Infrastructure-based 

roadside sensors–

CARMA Streets

Need to transmit raw sensor data from 

infrastructure-based roadside sensors to 

CARMA Streets in realtime.

ODP CP-N-ODP02b CARMA Streets Need to process calibrated raw sensor 

data from infrastructure-based roadside 

sensors in realtime to detect road 

objects and produce object-based 

perception information. 

ODP CP-N-ODP03a Infrastructure-based 

roadside smart 

sensors 

Need to process calibrated raw sensor 

data from infrastructure-based roadside 

sensors in realtime to detect road 

objects and produce object-based 

perception information. 

ODP CP-N-ODP03b Camera 

infrastructure-based 

roadside smart 

sensors–CARMA 

Streets

Need to transmit object-based 

perception data produced by 

infrastructure-based roadside smart 

sensors to CARMA Streets in realtime.
40 

Category ID

Relevant 

Component Operational Needs Statement

COMM CP-N-COMM01 CARMA Platform Need to temporarily store and 

broadcast processed perception data 

from local onboard extrospective 

sensors.

COMM CP-N-COMM02 CARMA Streets Need to temporarily store and broadcast 

processed perception information 

generated from infrastructure-based 

roadside sensor data. 

COMM CP-N-COMM03 CARMA Platform–

CARMA 

Messenger–

CARMA Streets

Need to receive and temporarily store 

processed perception information 

generated by other entities. 

COMM CP-N-COMM04 CARMA Platform–

CARMA 

Messenger–

CARMA Streets

Need to rebroadcast perception 

information received from other 

entities.

COMM CP-N-COMM05 CARMA Platform–

CARMA 

Messenger–

CARMA Streets

Need to employ communication 

management strategies to reduce 

congestion in the communication 

channels. These strategies could 

include dynamic generation and 

dissemination rules.

CS CP-N-CS01 All Need to have proper CS platforms and 

strategies to protect and recover from 

cyber threats.

DF CP-N-DF01 CARMA Platform–

CARMA 

Messenger–

CARMA Streets

Need to combine perception 

information from multiple sources and 

produce a merged world view for local 

applications. Needed DF algorithms 

include localization, track-to-track 

association, and attributes update. 

CPA CP-N-CPA01 CARMA Platform Need to update relevant ADS and 

C–ADS features to effectively use CP 

to improve safety and efficiency. 

CPA CP-N-CPA02 CARMA 

Messenger

Need to have applications that convert 

CP data to information appropriate for 

human consumption. 

CPA CP-N-CPA03 CARMA Streets Need to update relevant CDA 

applications to effectively use CP to 

improve safety and efficiency.
41 

Table 8. CARMA CP functional requirements.

ID

Relevant 

Component Functional Requirements Statement Traces To

CP-SR01 CARMA 

Platform

A CDA vehicle processes and fuses

calibrated raw data received from local 

onboard extrospective sensors, including 

LiDAR, visible spectrum camera, and 

radar.

CP-N-ODP01

CP-SR02 CARMA 

Platform

A CDA vehicle detects external objects

such as vehicles, motorcycles, cyclists, 

and pedestrians. A CDA vehicle 

perceives the following attributes of 

detected external objects: absolute 

location, location relative to the subject

vehicle, speed, heading, and size (length, 

width, height).

CP-N-ODP01

CP-SR03 Infrastructure Infrastructure-based sensors, including 

LIDAR, visible spectrum cameras, and 

radar installed at static locations, such as 

an intersection, transmit calibrated raw

sensor data to infrastructure computers, 

including CARMA Streets, at a 

frequency of at least 10 Hz.

CP-N-ODP02a

CP-SR04 CARMA Streets An infrastructure computer provides

physical interfaces for connecting to 

LiDAR sensors.

CP-N-ODP02a

CP-SR05 CARMA Streets An infrastructure computer provides 

physical interfaces for connecting to 

radar sensors.

CP-N-ODP02a

CP-SR06 CARMA Streets An infrastructure computer provides

physical interfaces for connecting to 

visible spectrum camera sensors.

CP-N-ODP02a

CP-SR07 CARMA Streets An infrastructure computer consumes

and processes calibrated raw sensor data 

from infrastructure-based roadside 

sensors at a frequency greater than or 

equal to the transmission frequency of 

the infrastructure sensors.

CP-N-ODP02b
42 

ID

Relevant 

Component Functional Requirements Statement Traces To

CP-SR08 CARMA Streets From calibrated raw data from

infrastructure sensors, an infrastructure 

computer detects and classifies objects 

such as vehicles, motorcycles, cyclists, 

and pedestrians. An infrastructure 

computer perceives the following 

attributes of detected external objects: 

absolute location, speed, heading, and 

size (length, width, height). 

CP-N-ODP02b 

CP-SR09 Infrastructure Infrastructure-based smart sensors (that 

also have computation capability), 

including LiDAR, visible spectrum 

cameras, and radar installed at static 

locations, such as an intersection, detect 

and classify detected objects such as

vehicles, motorcycles, cyclists, and 

pedestrians. A smart sensor perceives the 

following attributes of detected external 

objects: absolute location, speed, heading, 

and size (length, width, height). 

CP-N-ODP03a

CP-SR10 Infrastructure Smart sensors (sensors with computation 

capability), including LiDAR, visible 

spectrum cameras, and radar installed at 

static locations, such as an intersection, 

transmit processed object-based 

perception data to infrastructure 

computers, including CARMA Streets at 

a frequency of at least 10 Hz.

CP-N-ODP03b

CP-SR11 CARMA 

Platform

A CDA vehicle wirelessly transmits 

processed object-based perception data 

from local sensors at a frequency 

between 10 and 1 Hz according to a 

ruleset that specifies conditions to 

determine transmission frequency and 

object inclusion. 

CP-N-COMM01; 

CP-N-COMM05

CP-SR12 CARMA Streets An infrastructure computer wirelessly 

transmits processed object-based 

perception data at a frequency between

10 and 1 Hz according to a ruleset that 

specifies conditions to determine 

transmission frequency and object 

inclusion. 

CP-N-COMM02; 

CP-N-COMM05
43 

ID

Relevant 

Component Functional Requirements Statement Traces To

CP-SR13 CARMA Streets An infrastructure computer transmits 

processed object-based perception data to 

wired clients such as CARMA Cloud or 

other instances of CARMA Streets at a 

frequency between 10 and 1 Hz.

CP-N-COMM02

CP-SR14 CARMA 

Platform

A CDA vehicle consumes object-based 

perception data received from other 

entities at a frequency greater than or 

equal to the transmission frequency. 

CP-N-COMM03

CP-SR15 CARMA 

Platform

A CDA vehicle fuses local and received 

object-based perception data at a 

frequency greater than or equal to the 

transmission frequency of CP messages.

CP-N-DF01

CP-SR16 CARMA 

Platform

A CDA vehicle plans and controls its 

trajectory based on fused local and 

received perception data and static data 

such as maps and driving rules. 

CP-N-CPA01

CP-SR17 CARMA 

Messenger

A display system for connected, 

nonautomated vehicles consumes 

object-based perception data received 

from other entities at a frequency greater 

than or equal to the transmission 

frequency of CP messages. 

CP-N-COMM03

CP-SR18 CARMA 

Messenger

A display system for connected, 

nonautomated vehicle fuses received 

object-based perception data at a 

frequency greater than or equal to the 

transmission frequency of CP messages.

CP-N-DF01

CP-SR19 CARMA 

Messenger

A display system for connected, 

nonautomated vehicles displays relevant 

information derived from object-based 

perception data for human consumption 

at a reasonable frequency.

CP-N-CPA02

CP-SR20 CARMA Streets An infrastructure computer consumes 

object-based perception data received 

from other entities at a frequency greater 

than or equal to the transmission 

frequency.

CP-N-COMM03
44 

ID

Relevant 

Component Functional Requirements Statement Traces To

CP-SR21 CARMA Streets An infrastructure computer fuses 

object-based perception data received 

from other entities to produce at least the 

following functions: localization of 

entities within the operational domain, 

and assignment and update of attributes 

of detected entities. 

CP-N-DF01

CP-SR22 CARMA 

Platform

A CDA vehicle rebroadcasts 

object-based perception information 

received from other entities according to 

a ruleset that specifies rebroadcasting 

frequency and conditions for choosing 

whether to rebroadcast or not. 

CP-N-COMM04; 

CP-N-COMM05

CP-SR23 CARMA 

Messenger

A display system for connected, 

nonautomated vehicles rebroadcasts 

object-based perception information 

received from other entities according to 

a ruleset that specifies rebroadcasting 

frequency and conditions for choosing 

whether to rebroadcast or not. 

CP-N-COMM04; 

CP-N-COMM05

CP-SR24 CARMA Streets An infrastructure computer rebroadcasts 

object-based perception information 

received from other entities according to 

a ruleset that specifies rebroadcasting 

frequency and conditions for choosing 

whether to rebroadcast or not. 

CP-N-COMM04; 

CP-N-COMM05

CP-SR25 CARMA 

Platform

A CDA vehicle monitors the quantity of 

data being broadcast and received 

wirelessly and dynamically reduces the 

broadcasting frequency of perception 

messages to reduce radio interference.

CP-N-COMM05

CP-SR26 CARMA 

Messenger

A display system for connected, 

nonautomated vehicles monitors the 

quantity of data being broadcast and 

received wirelessly and dynamically 

reduces the broadcasting frequency of 

perception messages to reduce radio 

interference.

CP-N-COMM05

CP-SR27 CARMA Streets An infrastructure computer monitors the 

quantity of data being broadcast and 

received wirelessly and dynamically 

reduces the broadcasting frequency of 

perception messages to reduce radio 

interference.

CP-N-COMM05
45 

ID

Relevant 

Component Functional Requirements Statement Traces To

CP-SR28 CARMA 

Platform

A CDA vehicle satisfies CS requirements 

set forth in National Institute of

Standards and Technology (NIST) 

800-series publications.(15)

CP-N-CS01 

CP-SR29 CARMA 

Messenger

A display system for connected, 

nonautomated vehicles satisfies CS

requirements set forth in NIST 800-series 

publications.(15)

CP-N-CS01 

CP-SR30 CARMA Streets An infrastructure computer satisfies CS

requirements set forth in NIST 800-series 

publications.(15)

CP-N-CS01 

CP-SR31 Infrastructure Infrastructure-based smart sensors that 

include computational platforms, such as 

infrastructure-based sensors that can 

detect and classify objects, satisfies CS

requirements set forth in NIST 800-series 

publications.(15)

CP-N-CS01 

radar = radio detection and ranging.

47 

REFERENCES

1. Lou, Y., A. Ghiasi, M. Jannat, S. Racha, D. Hale, W. Goforth, and P. Bujanovic. 2022. 

Cooperative Automation Research: CARMA Proof-of-Concept TSMO Use Case Testing: 

CARMA Cooperative Perception Concept of Operations. FHWA-HRT-22-062. 

Washington, DC: Federal Highway Administration.

https://www.fhwa.dot.gov/publications/research/operations/22062/22062.pdf, last

accessed August 5, 2022. 

2. SAE International. 2021. Taxonomy and Definitions for Terms Related to Driving 

Automation Systems for On-Road Motor Vehicles. SAE J3016_202104. Warrendale, PA: 

SAE International. 

3. SAE International. 2020. Taxonomy and Definitions for Terms Related to Cooperative 

Driving Automation for On-Road Motor Vehicles. SAE J3216_202005. Warrendale, PA: 

SAE International. 

4. SAE International. 2018. Work in Progress: Cooperative Perception System. SAE 

J2945/8. Warrendale, PA: SAE International.

https://www.sae.org/standards/content/j2945/8/, last accessed April 27, 2021. 

5. SAE International. 2019. Work in Progress: V2X Sensor-Sharing for Cooperative & 

Automated Driving. SAE J3224. Warrendale, PA: SAE International.

https://www.sae.org/standards/content/j3224/, last accessed April 27, 2021. 

6. European Telecommunication Standards Institute (ETSI). 2019. Intelligent Transport 

Systems; Vehicular Communications; Basic Set of Applications; Analysis of the 

Collective Perception Service; Release 2. Technical report No. 103 562. Sophia 

Antipolis, France: ETSI. 

7. Shan, M., K. Narula, Y.F. Wong, S. Worrall, M. Khan, P. Alexander, and E. Nebot. 2020. 

“Demonstrations of Cooperative Perception: Safety and Robustness in Connected and 

Automated Vehicle Operations.” Sensors 21, no. 1: 1–31. 

8. SAE International. 2020. V2X Communications Message Set Dictionary. SAE 

J2735_202007. Warrendale, PA: SAE International. 

9. Bian, K., G. Zhang, and L. Song. 2018. “Toward Secure Crowd Sensing in 

Vehicle-to-Everything Networks.” IEEE Network 32, no. 2: 126–131. 

https://ieeexplore.ieee.org/document/8121865, last accessed August 5, 2022. 

10. Günther, H. J., B. Mennenga, O. Trauer, R. Riebl, and L. Wolf. 2016. “Realizing 

Collective Perception in a Vehicle.” In Proceedings of the IEEE Vehicular Networking 

Conference. Columbus, OH: IEEE. 
48 

11. Seeliger, F., G. Weidl, D. Petrich, F. Naujoks, G. Breuel, A. Neukum, and K. Dietmayer. 

2014. “Advisory Warnings Based on Cooperative Perception.” In Proceedings of the 

2014 IEEE Intelligent Vehicles Symposium: 246–252. Columbus, OH: IEEE. 

12. Deng, R., B. Di, and L. Song. 2018. “Cooperative Collision Avoidance Scheme Design 

and Analysis in V2X-based Driving Systems.” In Proceedings of the IEEE Global 

Communications Conference. Columbus, OH: IEEE. 

13. Kitazato, T., M. Tsukada, H. Ochiai, and H. Esaki. 2016. “Proxy Cooperative Awareness 

Message: An Infrastructure-Assisted V2V Messaging.” In Proceedings of the Ninth 

International Conference on Mobile Computing and Ubiquitous Networking. Columbus, 

OH: IEEE. 

14. Kim, S. W., Z. J. Chong, B. Qin, X. Shen, Z. Cheng, W. Liu, and M. H. An, Jr. 2013. 

“Cooperative Perception for Autonomous Vehicle Control on the Road: Motivation and 

Experimental Results.” In Proceedings of the IEEE/RSJ International Conference on 

Intelligent Robots and Systems. Columbus, OH: IEEE. 5059–5066. 

15. National Institute of Standards and Technology. 1998–2022. Computer Security 

Resource Center Special Publication (SP) 800 Series. Gaithersburg, MD: National 

Institute of Standards and Technology. https://csrc.nist.gov/publications/sp800, last 

accessed August 9, 2021. 

HRSO-50/11-22(WEB)E Recycled

Recyclable

Recommended citation: Federal Highway Administration,

FHWA Cooperative Automation Research: CARMA Proof-of-Concept TSMO 

Use Case Testing: CARMA Cooperative Perception Low-Level Concept of Operations 

(Washington, DC: 2022) https://doi.org/10.21949/1521946.