In the third part of our NDS.Live blog series, we covered how the sharing of map data is organized: NDS.Live lays the foundation for a scalable, flexible, reliable, and decentralized network of map services and other network nodes such as vehicles or infrastructure. This “Internet of automotive map data” enables the automotive eco-system partners to offer and consume a greater variety of sources of information and types of content to cater to ADAS, embedded navigation, and automated driving use cases. This flexibility stems from the employment of Modules, Service Registries and SmartLayers in NDS.Live. Let’s take a closer look at all three of them.
The data in NDS.Live is defined as separate modules. This allows developers to speed up the evolution of modules for selected, developing use case areas whilst leaving other, mature parts untouched. It also means that it is possible to selectively implement only the needed parts of the standard. Therefore, it is not necessary to support all modules in one implementation. Every NDS.Live user can move at their own pace and select the modules catering to their use case, as ADAS, embedded navigation, and automated driving all require a different set of map data services. NDS.Live modules will be versioned independently and can then be configured individually for development projects. In addition to this, a set of interoperability and backward compatibility rules are established to keep code maintenance low.
In NDS.Live, there are five categories of modules, based on the data definitions they hold: Common, Feature, Attribute, Reference and Service.
In general, NDS.Live strives to keep dependencies between modules minimal. One measure to do this is to define reference modules for feature and attribute modules (blue lines in the image above) which can be used to keep the dependencies stable.
Registry nodes are the gateways to NDS.Live. They bring together consumers and providers of map data and basically organize the information flow.
A service node (a provider of map data) uses a registry to announce its operational readiness, and a consumer (e.g. a navigation system in the car) uses a registry to discover nodes that are able to deliver specific required data. From a technical perspective, a registry is a network node which receives and distributes metadata about other nodes.
Registries allow the network to be scalable, because nodes offering different services can be added to or removed from the network on-demand. It also relieves nodes from the responsibility of maintaining the ecosystem itself: If a node crashes, another node that offers the same service can simply register in the network. A single unstable service does not threaten the ecosystems’ structural guarantees.
The registry concept also makes the NDS.Live ecosystem more robust in other ways:
Finally, the registry concept makes it very easy for a new vendor to enter the ecosystem by simply registering a new service node within an existing, impartial registry.
NDS.Live services require a reliable interface that is stable even when the map data layers are evolving. For this purpose, an intermediate container layer called SmartLayer is defined. SmartLayers allow service nodes to combine arbitrary binary components, or data layers, into a single packaged response frame without depending on the modules that provide the data layers.
This kind of pre-packaging of data on the server side reduces time-consuming and cost-intensive on-demand data packaging. The SmartLayer provider will deliver a near-to-optimal configuration that matches its client’s needs best, even if some clients will receive some more data than necessary. NDS.Live does not limit the configuration possibilities for pre-packaged data. This means that SmartLayer providers are able to freely pre-package data into sets that are most efficient for them, based on their users’ needs.
NDS.Live contains three types of SmartLayers: SmartLayerTiles, SmartLayerObjects and SmartLayerPaths. They have a similar structure but differ with regard to the entity they cover: a single map tile, a specific object that is not bound to any predefined spatial extent, or around a referenced path.
A SmartLayer service node serves two types of data:
Of course, SmartLayers are relevant for static data as well as dynamic and live data. Information such as data recency and lifetime, which allow the vehicle to assess the credibility of the data, are provided through the SmartLayer Definition metadata.
Through concepts like Modules, Service Registries and SmartLayers, NDS.Live outlines an ecosystem for distributed map standardization that fulfills the network objectives defined in our last blog post: scalability, reliability, mutability and the facilitation of vendor collaboration. Through its modular nature, the architecture can flexibly adapt to future challenges and increasingly heterogeneous map use-cases.
NDS.Live is on track to being released in 2020, with the first release focusing on HD map content necessary to provide next-generation electronic horizon services. Thank you for reading the four NDS.Live blog articles. Stay tuned for news about the next generation of map data and services for the automated and connected vehicles of the future!
Back to news →