The California Connected Vehicle Test Bed is located in the heart of the Silicon Valley in Palo Alto, California. The Test Bed spans 16 consecutive intersections along a three-mile stretch of State Route 82 (El Camino Real) and is in the process of adding 15 more intersections that bring its length to 7 miles. It provides an operational environment where intersections and vehicles can communicate through wireless connectivity.

• 1. What are connected vehicles and How do they work?
• 2. Where is the California Connected Vehicle Test Bed located?
• 3. Which connected vehicle standards are being used in the Test Bed?
• 4. What messages are transmitted on which DSRC channel, at what frequency?
• 5. Which version of DSRC RSU Specifications is deployed in the Test Bed?
• 6. Does the Test Bed have a backhaul connection?
• 7. How MAP and SPaT are generated at roadside?
• 8. Where to get sample encoded MAP and SPaT data payload?
• 9. Can I use MAP payload encoded by other tools?
• 10. How to check Test Bed status before driving a test vehicle to the Test Bed?
• 11. Where to get the documentation regarding the design and implementation of the Test Bed?
• 12. Is the source code for deployed connected vehicle applications open source?

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. It consists of 16 consecutive intersections between Medical Foundation Dr and Dinah's Ct in Palo Alto. The Test Bed exchanges live data with a Caltrans 2070 traffic controller at each intersection for populating the SPaT messages and commanding adaptive signal and priority timing. Traffic signals are operated and maintained by Caltrans District 4. The Test Bed is maintained and managed by the California PATH program.

The Test Bed is undeway of adding 15 more intersections. The expanded Test Bed consists of 31 consecutive intersections between Medical Foundation Dr in Palo Alto and Grant Rd in Mountain View.

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.

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

The Test Bed utilizes version 4.1 RSU hardware and software.

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) in the near future. Caltrans and PATH do not archive Test Bed data.

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

At a connected vehicle 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 planed to add the capability to interface with NTCIP controllers.

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 estimates the phase remaining time, encodes SAE J2735 SPaT message payload and sends RSU the payload for broadcasting over-the-air. The Roadside Processor also stores the encoded SAE J2735 MAP payload which describes the geographic road information of the intersection and sends RSU the MAP payload for broadccasting over-the-air.

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

Please see Data Sample page for encoded MAP payload and sample encoded SPaT payload by intersection.

9. Can I use MAP payload encoded by other tools?

We support the use of MAP payload encoded by other tools, for example, the USDOT MAP Tool.

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

Please see Test Bed Status page for real-time status of the Test Bed.

11. 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:

• MMITSS Concept of Operations
• Detailed System Design for California MMITSS

12. 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).