Skip to main content

Connected Vehicle Blueprint


The Connected Vehicle Blueprint (CVB) focuses on establishing an open source MEC platform, which is the backbone for V2X application. CVB has been tested and validated on BareMetal, virtual machine, as well as container environments.

The following use cases have been tested within the community, with additional use casse to come:

  • Accurate Location: Accuracy of location improves by over 10 times that of today’s GPS system. Today’s GPS system is around 5-10 meters away from your reallocation, <1 meter is possible with the help of Connected Vehicle Blueprint
  • Smarter Navigation: Real-time traffic information updates; reduces the latency from minutes to seconds; figures out the most efficient route for drivers
  • Safe Drive Improvement: Figures out potential risks which cannot be seen by the driver.
  • Reduces traffic violations: Conveys traffic rules of some specific area. For instance, change the lane prior to a narrow street, avoid opposite way driving on a one-way road, avoiding the carpool lane when single driver, etc.

From a technology architecture perspective, the blueprint consists of four major layers:

  • Hardware Layer: Connected Vehicle Blueprint runs on top of community hardware. Both Arm and x86 servers are well supported.
  • IaaS Layer: Connected Vehicle Blueprint can be deployed in a virtual environment as well. Virtual Machine, Containers, as well as other IaaS mainstream software like OpenStack, Kubernates et al) are supported.
  • PaaS Layer: Tars is the microservice framework of Connected Vehicle Blueprint. Tars can provide high performance RPC calls, deploys microservices in larger scale-out scenarios efficiently, and provides easy-to-understand service monitor features.
  • SaaS Layer: The latest v2x application is depicted in the previously mentioned use case examples.

From a network architecture perspective, the blueprint can be deployed in both 4G and 5G networks. Two key points to note: 1) Offloading data to edge MEC platform. The policy of data offload is configurable based on different applications. 2) The ability for the edge to talk to other edges as well as the remote data center. In some use cases, date process in one edge cannot address the application’s requirements. We need to collect the data from different edges and figure out a “conclusion” for the application.

Key features added in R2:
  • High Performance RPC Call
  • Service Discovery
  • Service Management
  • Web Config/Monitor Platform
  • Multi Program Languages
  • Slightly Optimization for Edge Deployment
  • Orchestration between Edge Nodes
  • Orchestration between Edge Node and Data Center

For more information: