Blog by: AECC President and Chairperson Ken-ichi Murata-san, AECC Directors Christer Boberg and Roger Berg

The collaborative work of AECC members is focused on optimizing the network and computer technology that a massively-scaled connected vehicles world will need to enable next-generation connected services. Automotive companies, mobile network operators, cloud providers and other stakeholders in the connected vehicle future are quite excited about this opportunity. But we’re also deeply concerned about ensuring a technological foundation to guarantee the connected vehicle services experience is not just good, but stellar.

The HD mapping application, which we introduced in a prior blog, is one of many apps designed to improve connected vehicle safety and performance. The challenge is that these apps can produce massive amounts of data that must be processed and returned to connected vehicles in real-time. What’s missing is a new mobile internet and data processing architecture (and ultimately, a successful proof-of-concept or business model) to optimize the way these apps and services are supported.

AECC is Exploring New Models for HD Mapping

In its quest for a new, optimized model, the AECC is researching the impacts of three system function blocks for HD mapping and how their placements affect quantities of data flowing through uplinks and downlinks for prescribed latency (See Figure 1).

Figure 1. Expected Process Flow of an HD Map

As described in our recent white paper, Operational Behavior of a High Definition Map Application, system placement of these functions has a dramatic impact on the quantity of data transmitted. The study initially analyzed two options for pattern processing, shown in Figure 2.

Figure 2. Processing Patterns for HD Mapping

Considerations like these patterns are important for stakeholders at this early “policy setting phase” because the technical choices will drive capabilities and potential cost structures of a business model. The model must work for all stakeholders. So, what has the AECC discovered at this early stage?

Architecture Design Is All About the Data

A globally scaled world of connected vehicles will have existential dependence on the architectural model for networking and data processing. For the initial study, AECC looked at a single region to determine application data characteristics. We projected upload and download data frequencies and respective data volumes-per-vehicle for three scenarios in the region. Assumptions included the total deployed connected cars in 2022, 2027 and 2032, which consisted of economy and mid-range model cars. The study assumed system latency of up to 10 seconds, defined as the time from sensor data acquisition to HD map update.

Latency is interesting because depending on the respective app, requirements may vary from sub-second response to sub-minute response, to more relaxed needs. AECC assumes sub-second latency is best suited for a real-time control system contained within the connected vehicle because network latency is hard to guarantee for such a short interval. Our research focuses on the sub-minute latency range where high-speed data transfer and processing is suited for a distributed edge architecture. Apps with non-time-sensitive information are best suited to centralized cloud processing for cost efficiency.

Initial Results, Dramatic Differences

HD maps are supposed to provide early warning of potential temporary obstacles ahead, such as road work, accidents or illegally parked vehicles. This capability is classified as the “reporting of real-time objects.” One conclusion of our study is data upload/download frequencies are minimal with no reporting of real-time objects. When those are included, vehicle data upload and download frequencies rise from 2.3 times/day to 97.9 times/day, an increase of 4,156 percent.

Another conclusion shows a huge difference in the amount of data transmitted by the Pattern A and B models, both of which include reporting of real-time objects. Based on assumptions detailed in the white paper, data upload volume per vehicle system is 24.8 MB/day for Pattern A and 2.2 GB/day for Pattern B – a delta of 8,770 percent!

Data download frequencies and data volume are negligible for Pattern A because only the results are sent to the MSP server via networks. For Pattern B, download frequencies and data volumes per vehicle match uploads for Pattern A.

There are valid reasons why Patterns A or B would be a good choice for implementers. But there are alternative patterns that could take precedence, particularly considering the massive future upswell of data to be generated by hundreds of millions of connected vehicles. AECC plans to address these in future iterations of the HD mapping whitepaper to help stakeholders create an optimum model.

Collaborating Toward a Future of Connected Vehicles

This pair of blogs on HD mapping is meant to whet your appetite for vigorous, ongoing collaboration with the AECC and its members. If you are a stakeholder or a potential stakeholder in the future of connected vehicles, we invite you to get involved. A good place to start is by reading AECC’s General Principle and Vision white paper, and our recently-updated Technical Report, Driving Data to the Edge: The Challenge of Traffic Distribution. We also welcome collaboration by industry stakeholders as members of AECC research projects.