{'fraction_non_alphanumeric': 0.03643985811028701, 'fraction_numerical': 0.003762227238525207, 'mean_word_length': 5.092992796332679, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
RTMaps-based Local Dynamic Map for multi-ADAS data fusion

Work on Local Dynamic Maps (LDM) implementation is still in its early stages, as the LDM standards only define how information shall be structured in databases, while the mechanism to fuse or link information across different layers is left undefined. A working LDM component, as a real-time database inside the vehicle is an attractive solution to multi-ADAS systems, which may feed a real-time LDM database that serves as a central point of information inside the vehicle, exposing fused and structured information to other components (e.g., decision-making systems). In this paper we describe our approach implementing a real-time LDM component using the RTMaps middleware, as a database deployed in a vehicle, but also at road-side units (RSU), making use of the three pillars that guide a successful fusion strategy: utilisation of standards (with conversions between domains), middlewares to unify multiple ADAS sources, and linkage of data via semantic concepts.


Introduction
Advanced Driver Assistance Functions (ADAS), such as Forward Collision Warning (FCW), Automated Braking (AB), Lane Departure Warning (LDW) or Blind Spot Detection (BSD) are already operational in our cars. Their utilisation in a vehicle has demonstrated exceptional performance to increase comfort and safety, with reductions of crashes between 27% to 50% 1

. The research and innovation in ADAS and in
Automated Driving (AD) functions is continuously growing and the market expects many new functions in the context of SAE-L3 [1][2] vehicles. Particularly relevant will be the integration and coordinated co-existence of multiple functions, potentially from different vendors, and with possibly overlapping capabilities, input needs and power consumption requirements.
The integration of an ecosystem of ADAS has become a major challenge, since their simple accumulation in a vehicle can produce undesired system conflicts and also decrease user acceptance because of the increased complexity of the vehicle. Car manufacturers are, therefore, keen to research on integrated solutions, which coordinate functions to operate harmonized, balance power and processing consumption, and overall improving driving safety.
One of the main challenges is the ability to fuse data from heterogeneous sources from diverse domains that 1 https://injuryfacts.nsc.org/motor-vehicle/occupant-protection/advanced-driver-assistance-systems/ RTMaps-based Local Dynamic Map for multi-ADAS data fusion 2 have emerged and evolved independently from each other during the last decade: perception (e.g., sensing devices such as cameras or LIDARs with detection capabilities), communication (e.g., V2X systems, with standardized messages [3]), or digital maps (e.g., standard-definition or high-definition road topologies).
The issue is that these domains have establish data formats, standards, and conventions for domain-specific use cases which suddenly clash into the common need to fuse multi-ADAS information real-time in a vehicle to provide the next step of autonomous driving.
Provided each domain is governed by its own inertia, huge alignment efforts are required to interoperate perception, communication and digital map systems. Current approaches focus on creating inter-domain standards (e.g. ISO LDM, ASAM simulation branch), utilise multi-sensor application middlewares (e.g. RTMaps, ROS, ADTF) and apply semantic alignment of concepts [4].
One significant example which have attracted the attention of the automotive industry is the Local Dynamic Map (LDM) concept. Initially defined as an structure of road information categorized in layers (from static to dynamic information), methods to implement the structure itself have started to appear [6][7] [8] as a response to the publication of the LDM-related ETSI/ISO standards. In [9] an interoperable LDM (iLDM) implementation was presented, including a data model aligned with the recently published ASAM OpenLABEL standard [10], to leverage the interconnection of sensor data recording vehicle set-ups with ground truth generation.

Local Dynamic Maps (LDM)
The concept of an LDM has been widely adopted by the automotive sector since its introduction in 2010 with the SAFESPOT [5] project. This project defined the seminal four-layer structure (  The input interface to the iLDM can be used by three possible types of systems: • Map service/files: digital map information received from an online service or as offline (pre-downloaded) files to fill in the lower layer (static data) of the iLDM stack.
• Perception system: local system inside the ego-vehicle that perceives information on the surroundings as a list of objects or a similar representation. Conversion to OpenLABEL format is required prior to its ingestion into the iLDM.
• V2X: communication system that receives messages (e.g., ETSI CAM and CPM messages) from exterior perception systems (e.g., other vehicles). Conversion from CPM to OpenLABEL (using VCD toolkit 2 ) is needed to ingest information into the iLDM.
The output interface from the iLDM shall be used by two possible types of systems: • Archive/data logging: the iLDM component accumulates dynamic information in time. A clear-up policy, set-up during configuration, might establish that information older than a certain threshold is periodically removed. Archiving into local or remote file systems can help prevent loss of information.
• ADAS/AD functions: the second type of application that reads from iLDM is any ADAS/AD function that needs to read synchronised and calibrated information about dynamic objects and their position or relation with the underlying static layers.

LDM Data model
The LDM database is structured as a Graph Database following the principles of the OpenLABEL standard, where a hierarchy of Elements, Streams and Frames allows to define rich and complex static and dynamic properties of a scene, including time-specific information, object geometries and attributes, transforms between coordinate systems, and relations between elements. The LDM database data model follows this schema file, adding certain nodes, attributes and layers to additionally specify LDM levels for injected data. The only structural difference is that the OpenLABEL Relations are expressed in the LDM data model as relationships between nodes of the graph. The proposed data model implements a mechanism to guarantee coexistence of static and dynamic parts of object. For a given object (e.g., lane or vehicle), certain attributes can be permanent (e.g., brand, shape, volume).

Interfaces and formats
The LDM has different interfaces and formats for input and output functions. ETSI CPM messages are supported by LDM, which converts CPM into VCD for internal consistency.

Interface
OSM map data can be loaded into LDM with information about road nodes and ways. Other map formats might be supported in subsequent versions of the LDM (e.g., TomTom's OpenLR 4 ).
Additional information can be retrieved from LDM in the form of list of attributes (e.g., number of objects at a certain frame).

Implementation and Database back-bone
The LDM has been implemented as an Application Programming Interface (API) which makes use of different other packages and resources to serve functions to ADAS/AD applications (see Figure 4).
The LDM API v1.0.0 is a Python library that exposes functions to input and output information from the database. The library manages internally the content according to the established configuration.

Real-time operation -RTMaps
The RTMaps diagram shown in Figure 6 is used to generate ground truth data and upload the information to the DDBB. Its components include: • Simulates the perception and geo-position of the OBUs vehicle (green box) • Visualization: bbox location (blue box) • Data conversion to VCD format (orange box) • External data source: MQTT client (red box) • Upload VCD to Neo4j (LDM API) (yellow box) The LDM operates as a database. As a consequence, different types of queries can be created to retrieve information from the database. As described in previous sections, the content of the database is mostly focused on static (road graphs) and dynamic (perceived objects) elements. All elements are geo-located thanks to the accurate positioning information read from the geo-location systems. Examples of LDM outcomes can then be any type of query result such as: • List of objects closer than a certain distance to the ego-vehicle and dynamic data (Layer 4) from 3 rd Party systems (e.g., map providers or sensing functions).
The utilisation of real-time multi-sensor middlewares such as RTMaps solves the programmatic interconnection between components. Using the middleware, an integrator can easily plug map, communicacionts and sensing data into the LDM component. The LDM is then available as an RTMaps component from which applications can read integrated, synchronized and aligned information. Using standard formats, such as the emergent ASAM OpenLABEL, data stored within the LDM can contain rich descriptions of the scene, including information about the surroundings, the interior of the vehicle (e.g., the driver state), and be forwarded to ground-truth generation processes for evaluation and validation purposes.