The California Connected Vehicle Test Bed is located in the heart of the Silicon Valley in Palo Alto, California. The Test Bed spans 11 consecutive intersections along a two-mile stretch of State Route 82 (El Camino Real). It provides an operational environment where intersections and vehicles can communicate through wireless connectivity.

1. What are connected vehicles and How do they work?

USDOT provides a website on Connected Vehicle Basic as well as Knowledge Resources.

2. Where is the California Connected Vehicle Test Bed located?

The Test Bed currently runs along El Camino Real in Palo Alto. Testbed Map It consists of 11 consecutive intersections between Stanford Ave at the north end and W Charleston Ave at the south end. The Test Bed exchanges live data with a Caltrans 2070 traffic controller at each intersection. Traffic signals are operated and maintained by Caltrans District 4. The Test Bed is maintained and managed by the California PATH program.

3. Which connected vehicle standards are being used in the Test Bed?

Connected Vehicle Standards are rules that provide the software programming codes, definitions, and formats needed to create interoperable, consistent, and seamless communications exchange among shared information systems and devices. The Test Bed is using the latest version of SAE J2735 standard published March 30, 2016.

4. What messages are transmitted on which DSRC channel, at what frequency?

The connected vehicle system comprised of two parts:

  • On-Board Uint (OBU) that is installed on the connected vehicles; and
  • Roadside Unit (RSU) that is installed at the roadside and integrated with existing traffic equipment, such as traffic signal controller and backhaul connections to Traffic Management Centers (TMCs).

OBUs communicate between themselves (V2V or Vehicle-to-Vehicle) and with RSUs (V2I or Vehicle-to-Infrastructure) using DSRC. The DSRC message sets transmitted between OBU and RSU, and their channel configurations are summarized in the table below.

MessageAbbreviationFromFrequencyToChannelPSIDDSRC Message ID
MAP/GIDMAPRSU1 HzOBU1720p80-02 (0x82)18
Signal Phase and TimingSPaTRSU10 HzOBU1720p80-02 (0x82)19
Signal Status MessageSSMRSU1 HzOBU1720p80-02 (0x82)30
Basic Safety MessageBSMOBU10 HzRSU1720p20 (0x20)20
Signal Request MessageSRMOBUAsynchronousRSU1720p80-02 (0x82)29
RTCM Corrections MessageRTCMRSU Type 1004 5 HzOBU1820p80-01 (0x81)28
Type 1006 2 Hz
Type 1008 2 Hz

5. Which version of DSRC RSU Specifications is deployed in the Test Bed?

The Test Bed currently utilizes version 3.0 RSU hardware and software. It will be upgraded to RSU v4.1 in Spring 2018.

6. Does the Test Bed have a backhaul connection?

Each connected intersection has a 4G/LTE backhaul. The backhaul connection is currently used for PATH researchers to maintain and manage the Test Bed. It will be utilized to communicate with the Security Credential Management System (SCMS), and transmit real-time intersection data to the nation's connected vehicle data warehouse. Caltrans and PATH do not archive Test Bed data. Test Bed data can be accessed through the nation's data warehouse.

7. How MAP and SPaT messages are generated at roadside?

At a connected vehicle intersection, CV Intersection the RSU is usually mounted on upright above the mast arm with DSRC radio antenna mounted on the mast arm. The RSU is connected to the Roadside Processor through Power-over-Ethernet cable. The Roadside Processor, installed inside the traffic cabinet, is a Linux-based industrial PC which runs the roadside connected vehicle applications and communicates with the traffic signal controller through a wired connection. The Test Bed utilizes AB3418 protocol over RS232 for communications between the Roadside Processor and the controller. we plan to have the capability to interface with NTCIP controllers in the future.

The traffic controller pushes out signal status, vehicle call, and pedestrian call data to the Roadside Processor, at a rate of 10 Hz. The Roadside Processor then encodes SAE J2735 SPaT message payload and sends RSU the payload for broadcasting over-the-air. The Roadside Processor also stores an intersection description text file which contains necessary data attributes to describe the geometric intersection design. It reads the intersection description file, encodes SAE J2735 MAP payload, and sends RSU the payload for broadccasting over-the-air. For more information about the intersection description files, please see an example.

8. Where to get sample encoded MAP and SPaT data payload?

Please see our Data Sample section for intersection description file, encoded MAP payload, and sample encoded SPaT payload by intersection.

9. How to check Test Bed status before driving a test vehicle to the Test Bed?

Please see our Test Bed Status section for the status of the Test Bed.

10. Where to get the documentation regarding the design and implementation of the Test Bed?

Documentation is available at the Connected Vehicle Pooled Fund Study web site. In particular, the following documents from that web site are relevant to the California CV Testbed:

11. Is the source code for deployed connected vehicle applications open source?

The source code is open source under the ECL-2.0 open source license and is available through USDOT Open Source Application Development Portal (OSADP).