When we founded NDS in 2009, our goal was clear: jointly develop a common, automotive standard for digital maps used by applications running on embedded devices – and stored in the car. Because, in 2009, there was no cloud to consume data from. In 2009, the iPhone turned two years old (and its RAM was measured in Megabytes). People still surfed the internet with Netscape. There was no Instagram. There was no LTE. There wasn’t even Windows 7. So, it really was a different time.
A key focus of NDS was on how to best structure the format in order to create data files as small and storage-efficient as possible. In the early days of NDS, the map data needed to fit onto a CD-ROM, then a DVD, and later a hard drive. Data size was always an issue. Map data included more and more attributes, and new features that needed support from new data types needed more space. The evolution of NDS addressed this with optimizations of data structures and relations, with the addition of data modules that are called NDS building blocks, and with the flexibility of how NDS Update Regions can be defined. The possibility to add smaller add-ons for selected features like 3D city models, the so-called NDS Update Areas also contributes to a minimal map data file size.
In 2018, the European Union made an eCall system mandatory for new cars. Suddenly, all cars are being equipped with cell phone connections. By now, many car manufacturers are leveraging this technology to offer additional connected services. In terms of navigation, this can be map data updates over the air, downloading additional map coverage as needed, and so on.
2019 saw the beginning of the deployment of 5G, the fifth-generation wireless technology for digital cellular networks. Data speeds are expected to be up to and over 2Gbit/s, many times faster than 4G. In addition, 5G provides very low latencies, reaching less than ten milliseconds. With the future of high-speed data connectivity just around the corner, many automotive companies are rethinking how in-car features should use map data. ADAS, navigation, and HAD systems work best with the freshest possible data. Also, they work better if the relevant data is crunched on a super-high-performance computer system rather than what is usually build into cars.
As we can see, a lot of things have changed since 2009. Now, what does this mean for NDS? With new technology, new use cases for map data, and much more information being stored in maps, the requirements to any map data format have evolved. And so does NDS: To combine the best of our past experience, today’s realities, and tomorrow’s new possibilities, we are defining the next generation of the NDS specification.
We call it NDS.Live.
NDS.Live will continue to ensure the interoperability of applications, maps, and services that is and continues to be one of the key objectives of NDS. At the same time, it offers more flexibility in terms of data management and deployment, supporting the connected and automated cars of today and of the future. NDS.Live will cover the specification for standard and HD map data models and allow a combination of these with services via APIs for ADAS, navigation, and automated driving support.
The principles and objectives for NDS.Live are: It…
Driving assistance features and autonomous driving systems need highly detailed up-to-date information to guide their decision-making processes. Applications utilize online services and vehicles have become nodes in huge connected networks. In order to handle these challenges, NDS.Live is designed as a truly distributed system being able to cover all use cases dealing with map data.
We will explore the intricacies of NDS.Live in a series of blog posts, discovering how the evolved standard handles data management and data deployment and how it allows for modular development and flexible implementation. In the next article, we discuss how map data is categorized and organized in NDS.Live. You can find it here: https://nds-association.org/map-data-structure/
Back to news →