Data sharing method and device based on vehicle-mounted dynamic distributed file system

Abstract

The invention discloses a data sharing method and device based on a vehicle-mounted dynamic distributed file system. The method is applied to a first vehicle. A vehicle-mounted dynamic distributed file system (VDDFS) with a decentralized architecture is locally deployed on a first vehicle and a second vehicle, so that the first vehicle and the second vehicle in a communication range serve as peer-to-peer isomorphic nodes, and each node stores complete metadata and sensor data. After the first vehicle writes the sensor data into the local VDDFS, the VDDFS packages the write operation into a synchronization instruction, and broadcasts the instruction to other vehicles in a communication range through a V2X communication technology, so that the second vehicle can receive the instruction through the VDDFS deployed by the second vehicle and automatically synchronize the sensor data, and the consistency of the VDDFS data of the two vehicles is ensured. Meanwhile, the first vehicle can obtain sensor data of the second vehicle by accessing the local VDDFS.

Description

Technical Field

[0001] This application relates to the field of vehicle communication technology, and in particular to a data sharing method and device based on an in-vehicle dynamic distributed file system. Background Technology

[0002] With the rapid development of autonomous driving technology, the limitations of single-vehicle sensors, such as detection range and environmental interference resistance, are becoming increasingly apparent. Multi-vehicle collaborative perception has become a key technological direction for improving the safety and environmental perception integrity of autonomous driving. Vehicle-to-Everything (V2X) communication technology enables sensor data sharing between vehicles, which can extend the perception range of a single vehicle. For example, in scenarios where the view is obstructed by a vehicle ahead, sensor data from adjacent vehicles can be used to identify hidden targets, thereby reducing the risk of collision. Therefore, multi-vehicle sensor data sharing has become an important research direction in the field of autonomous driving.

[0003] Currently, multi-vehicle sensor data sharing primarily relies on message-based communication mechanisms. For example, vehicles use Dedicated Short Range Communication (DSRC) or cellular vehicle-to-everything (V2X) protocols to encapsulate sensor data into message messages of a specific format, which are then broadcast or unicasted to neighboring vehicles. Receiving vehicles must parse the message format, verify the data's validity, and then store the data in their local storage. Some solutions also incorporate centralized cloud platforms or edge servers to centrally receive data from multiple vehicles and forward it to the requesting vehicles. Furthermore, vehicles must access shared data through explicit communication request commands; for instance, a first vehicle sends a data acquisition request to a second vehicle, which then receives and processes the data upon its response.

[0004] Vehicles frequently need to handle the details of communication protocols, such as data encapsulation, decapsulation, connection maintenance, and error recovery, increasing the complexity and resource overhead of system development. Furthermore, message-based communication is typically instantaneous, lacking persistent storage mechanisms, making it difficult to support collaborative access and utilization of historical sensor data by multiple vehicles. In related technologies, each vehicle independently manages its local sensor data; heterogeneous data formats and storage methods lead to difficulties in data integration, preventing the formation of a globally consistent perception environment. Vehicles need to explicitly participate in the communication process, making seamless data sharing—that is, data sharing where vehicles only need to store and retrieve data without needing to perceive the communication details—an automatic data sharing process. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a data sharing method and device based on an in-vehicle dynamic distributed file system.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] In a first aspect, embodiments of this application provide a data sharing method based on an in-vehicle dynamic distributed file system, the method comprising:

[0008] The first vehicle writes sensor data to the vehicle dynamic distributed file system VDDFS; wherein, the VDDFS is deployed locally on the first vehicle and the second vehicle, the VDDFS is a decentralized architecture, in the VDDFS the first vehicle as a node is isomorphic to the nodes of the second vehicle within the communication range, and each node stores complete metadata and sensor data;

[0009] The first vehicle's VDDFS encapsulates the sensor data writing operation into a synchronization command. The first vehicle broadcasts the synchronization command to other vehicles within its communication range through vehicle-to-the-outside information exchange (V2X) communication technology, so that the second vehicle can receive the synchronization command through its own deployed VDDFS and automatically synchronize the sensor data, so that the VDDFS of the first vehicle and the second vehicle remain consistent.

[0010] The first vehicle accesses its own deployed VDDFS to obtain sensor data from the second vehicle.

[0011] In one possible implementation, the first vehicle accesses the VDDFS it has deployed, including:

[0012] The first vehicle accesses the data in the VDDFS through a unified data access view; the data access view is a logical mirror of the VDDFS, and the data access view is used to integrate the data scattered in the VDDFS of each vehicle into a globally consistent virtual file system.

[0013] In one possible implementation, the first vehicle writes sensor data to the onboard dynamic distributed file system VDDFS, including:

[0014] When the first vehicle detects a target through its sensors, it searches for the corresponding identifier directory of the target in the VDDFS it has deployed.

[0015] If the first vehicle does not find the identifier directory corresponding to the target in the VDDFS, the first vehicle creates a globally unique identifier directory corresponding to the target in the VDDFS it deploys; the first vehicle updates the target attribute data, target real-time status data and target historical trajectory data in the identifier directory;

[0016] If the first vehicle finds the identifier directory corresponding to the target in the VDDFS, the first vehicle updates the target status data and the target historical trajectory data in the target identifier directory in the VDDFS.

[0017] In one possible implementation, the step of searching for the identifier directory corresponding to the target in the VDDFS deployed within itself includes:

[0018] The first vehicle acquires the real-time 3D position information of the target through sensors, and calculates the absolute position coordinates of the target by combining the global position of the first vehicle;

[0019] The first vehicle extracts the target attribute data of the target;

[0020] The first vehicle traverses the identifier directory of all stored targets in the VDDFS and reads the absolute position coordinates and target attribute data of each stored target;

[0021] The first vehicle calculates the absolute position distance between the target and each of the existing targets based on the absolute position coordinates of the target and the absolute position coordinates of each of the existing targets.

[0022] If the target meets a preset condition with any existing target, it is determined that the identification directory corresponding to the target has been found; the preset condition includes that the absolute positional distance between the target and the existing target is less than a preset threshold, and the matching degree between the target attribute data of the target and the target attribute data of the existing target is greater than a preset ratio;

[0023] If the target does not meet the preset conditions along with any of the existing targets, it is determined that no identifier directory corresponding to the target was found.

[0024] In one possible implementation, the method further includes:

[0025] When a third vehicle enters the communication range of the first vehicle, the first vehicle receives the identifier of the third vehicle broadcast by the third vehicle via V2X. The first vehicle's VDDFS creates an identifier directory corresponding to the third vehicle based on a directory synchronization mechanism and synchronizes the target attribute data of the third vehicle.

[0026] In one possible implementation, the method further includes:

[0027] The first vehicle's VDDFS continuously monitors the heartbeat signals of other vehicles within the first vehicle's communication range;

[0028] If no heartbeat signal from the second vehicle is detected for a preset duration, it is determined that the second vehicle has left the communication range of the first vehicle, and the first vehicle's VDDFS automatically deletes the corresponding identifier directory from the first vehicle.

[0029] In one possible implementation, the root directory of the VDDFS includes multiple identifier directories corresponding to existing targets. Each identifier directory of an existing target includes a static attribute file, a target real-time status data subdirectory, a target historical trajectory data subdirectory, and a metadata file.

[0030] The static attribute file is used to record the globally unique identifier, target type, absolute position coordinates, and target attribute data of the stored target; the target real-time status data subdirectory is used to record the dynamic status information of the stored target; the target historical trajectory data subdirectory is used to persistently record the historical motion sequence information of the stored target.

[0031] The metadata file is an explanatory data file that is bound to the static attribute file, the real-time status data of the target, and the historical trajectory data of the target.

[0032] Secondly, embodiments of this application disclose a data sharing method apparatus based on an in-vehicle dynamic distributed file system, the apparatus comprising:

[0033] The writing module is used to write sensor data to the vehicle dynamic distributed file system VDDFS. The VDDFS is deployed locally on the first vehicle and the second vehicle. The VDDFS is a decentralized architecture. In the VDDFS, the first vehicle is a node and the nodes of the second vehicle within the communication range are isomorphic. Each node stores complete metadata and sensor data.

[0034] The shared module is used to encapsulate sensor data writing operations into synchronization instructions via VDDFS, and broadcast the synchronization instructions to other vehicles within the communication range through vehicle-to-the-outside information exchange (V2X) communication technology, so that the second vehicle can receive the synchronization instructions through its own deployed VDDFS and automatically synchronize the sensor data, so that the VDDFS of the first vehicle and the second vehicle remain consistent.

[0035] The reading module is used to access the VDDFS deployed on itself to obtain sensor data of the second vehicle.

[0036] In one possible implementation, the reading module is specifically used to access data in the VDDFS through a unified data access view; the data access view is a logical mirror of the VDDFS, and the data access view is used to integrate the data scattered in the VDDFS of each vehicle into a globally consistent virtual file system.

[0037] In one possible implementation, the writing module is specifically used to: when the first vehicle detects a target through its sensors, search for the corresponding identifier directory in its deployed VDDFS; if the first vehicle does not find the corresponding identifier directory in the VDDFS, the first vehicle creates a globally unique identifier directory for the target in its deployed VDDFS; the first vehicle updates the target attribute data, the target real-time status data, and the target historical trajectory data in the identifier directory; if the first vehicle finds the corresponding identifier directory in the VDDFS, the first vehicle updates the target status data and the target historical trajectory data in the target-corresponding identifier directory in the VDDFS.

[0038] In one possible implementation, the writing module is specifically used to acquire the real-time 3D position information of the target through sensors, and calculate the absolute position coordinates of the target by combining it with the global position of the first vehicle; the first vehicle extracts the target attribute data of the target; the first vehicle traverses the identifier directories of all stored targets in the VDDFS, and reads the absolute position coordinates and target attribute data of each stored target; the first vehicle calculates the absolute position distance between the target and each stored target based on the absolute position coordinates of the target and the absolute position coordinates of each stored target; if the target meets a preset condition with any stored target, it is determined that the identifier directory corresponding to the target has been found; the preset condition includes that the absolute position distance between the target and the stored target is less than a preset threshold, and the matching degree between the target attribute data of the target and the target attribute data of the stored target is greater than a preset ratio; if the target does not meet the preset condition with any stored target, it is determined that the identifier directory corresponding to the target has not been found.

[0039] In one possible implementation, the device further includes an update module, which is used to receive the identifier of the third vehicle broadcast by the third vehicle via V2X when the third vehicle enters the communication range of the first vehicle. The first vehicle's VDDFS creates an identifier directory corresponding to the third vehicle based on a directory synchronization mechanism and synchronizes the target attribute data of the third vehicle.

[0040] In one possible implementation, the update module is further configured to continuously monitor the heartbeat signals of other vehicles within the communication range of the first vehicle via VDDFS; if the heartbeat signal of the second vehicle is not detected for a preset duration, it is determined that the second vehicle has left the communication range of the first vehicle, and the VDDFS of the first vehicle automatically deletes the identification directory corresponding to the vehicle.

[0041] In one possible implementation, the root directory of the VDDFS includes multiple identifier directories corresponding to existing targets. Each identifier directory of an existing target includes a static attribute file, a target real-time status data subdirectory, a target historical trajectory data subdirectory, and a metadata file.

[0042] The static attribute file is used to record the globally unique identifier, target type, absolute position coordinates, and target attribute data of the stored target; the target real-time status data subdirectory is used to record the dynamic status information of the stored target; the target historical trajectory data subdirectory is used to persistently record the historical motion sequence information of the stored target.

[0043] The metadata file is an explanatory data file that is bound to the static attribute file, the real-time status data of the target, and the historical trajectory data of the target.

[0044] Thirdly, embodiments of this application disclose a control device, including a processor and a memory, wherein the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to complete the data sharing method based on the vehicle-mounted dynamic distributed file system as described in any of the first aspects.

[0045] Fourthly, embodiments of this application disclose a computer-readable storage medium, characterized in that it stores a computer program, which is loaded by a processor to execute the data sharing method based on an in-vehicle dynamic distributed file system as described in any of the first aspects.

[0046] This application provides a data sharing method and device based on an in-vehicle dynamic distributed file system (VDDFS), applied to a first vehicle. By deploying a decentralized architecture VDDFS locally on both the first and second vehicles, the first and second vehicles within communication range act as peer-to-peer isomorphic nodes, each storing complete metadata and sensor data. After the first vehicle writes sensor data to its local VDDFS, the VDDFS encapsulates this write operation into a synchronization command and broadcasts it to other vehicles within communication range via V2X communication technology. This allows the second vehicle to receive the command and automatically synchronize its sensor data through its own deployed VDDFS, ensuring data consistency between the two vehicles' VDDFS. Simultaneously, the first vehicle can access the second vehicle's sensor data by accessing its local VDDFS.

[0047] This application embodiment combines the decentralized architecture of VDDFS with V2X communication technology, enabling the first and second vehicles to share sensor data without relying on a centralized node. This avoids the limitations of traditional centralized file systems in adapting to dynamic vehicle scenarios. The first vehicle only needs to perform a local data write operation, and data synchronization can be achieved through automatic encapsulation of broadcast synchronization instructions, without the need for additional complex communication logic, thus reducing system operational complexity. Simultaneously, each node stores complete data, and the first vehicle can directly access its local VDDFS to obtain data from the second vehicle, significantly improving data access efficiency. Furthermore, the VDDFS automatic synchronization mechanism ensures data consistency between the two vehicles, providing reliable data support for multi-vehicle collaborative perception and effectively compensating for the limitations of single-vehicle perception. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 An architecture diagram for multi-vehicle sensor data sharing provided in an embodiment of this application;

[0050] Figure 2 A flowchart illustrating a data sharing method based on an in-vehicle dynamic distributed file system provided in this application embodiment;

[0051] Figure 3 A schematic diagram of a VDDFS root directory provided in an embodiment of this application;

[0052] Figure 4 A schematic diagram of a synchronization instruction provided in an embodiment of this application;

[0053] Figure 5 A schematic diagram of a data access view provided in an embodiment of this application;

[0054] Figure 6 A schematic diagram illustrating data sharing between vehicles, provided as an embodiment of this application;

[0055] Figure 7 This application provides a data sharing method and apparatus based on an in-vehicle dynamic distributed file system. Detailed Implementation

[0056] As described earlier, current multi-vehicle sensor data sharing primarily relies on message-based communication mechanisms. For example, vehicles encapsulate sensor data into message packets of a specific format using Dedicated Short Range Communication (DSRC) or cellular vehicle-to-everything (V2X) protocols, and then broadcast or unicast them to neighboring vehicles. Receiving vehicles need to parse the message format, verify the data's validity, and then store the data in their local storage modules. Some solutions also introduce centralized cloud platforms or edge servers to centrally receive data from multiple vehicles and forward it to the requesting vehicles. Furthermore, vehicles must access shared data through explicit communication request commands; for example, the first vehicle sends a data acquisition request to the second vehicle, and the second vehicle receives and processes the data after responding.

[0057] Vehicles frequently need to handle the details of communication protocols, such as data encapsulation, decapsulation, connection maintenance, and error recovery, increasing the complexity and resource overhead of system development. Furthermore, message-based communication is typically instantaneous, lacking persistent storage mechanisms, making it difficult to support collaborative access and utilization of historical sensor data by multiple vehicles. In related technologies, each vehicle independently manages its local sensor data; heterogeneous data formats and storage methods lead to difficulties in data integration, preventing the formation of a globally consistent perception environment. Vehicles need to explicitly participate in the communication process, making seamless data sharing—that is, data sharing where vehicles only need to store and retrieve data without needing to perceive the communication details—an automatic data sharing process.

[0058] To address this technical problem, this application provides a data sharing method and device based on an in-vehicle dynamic distributed file system (VDDFS), applied to a first vehicle. By deploying a decentralized architecture VDDFS locally on both the first and second vehicles, the first and second vehicles within communication range act as peer-to-peer isomorphic nodes, each storing complete metadata and sensor data. After the first vehicle writes sensor data to its local VDDFS, the VDDFS encapsulates this write operation into a synchronization command and broadcasts it to other vehicles within communication range via V2X communication technology. This allows the second vehicle to receive the command and automatically synchronize its sensor data through its own deployed VDDFS, ensuring data consistency between the two vehicles' VDDFS. Simultaneously, the first vehicle can access the second vehicle's sensor data by accessing its local VDDFS.

[0059] This application embodiment combines the decentralized architecture of VDDFS with V2X communication technology, enabling the first and second vehicles to share sensor data without relying on a centralized node. This avoids the limitations of traditional centralized file systems in adapting to dynamic vehicle scenarios. The first vehicle only needs to perform a local data write operation, and data synchronization can be achieved through automatic encapsulation of broadcast synchronization instructions, without the need for additional complex communication logic, thus reducing system operational complexity. Simultaneously, each node stores complete data, and the first vehicle can directly access its local VDDFS to obtain data from the second vehicle, significantly improving data access efficiency. Furthermore, the VDDFS automatic synchronization mechanism ensures data consistency between the two vehicles, providing reliable data support for multi-vehicle collaborative perception and effectively compensating for the limitations of single-vehicle perception.

[0060] like Figure 1 As shown, Figure 1 This is an architecture diagram for multi-vehicle sensor data sharing provided in an embodiment of this application. The system architecture provided in this embodiment uses an autonomous driving application layer, VDDFS, and a V2X communication layer as its core layered structure to achieve decentralized sharing of multi-vehicle sensor data.

[0061] The top layer is the autonomous driving application layer, which is the main user of the data. It is deployed in all participating vehicles and is responsible for calling the VDDFS interface to write and access sensor data. At the same time, the autonomous driving application layer can perform autonomous driving decisions such as environmental perception and path planning based on the global data view provided by VDDFS.

[0062] The middle layer is the Vehicle Dynamic Distributed File System (VDDFS), the core module of the architecture, comprising three subsystems. The first subsystem provides a globally consistent virtual file system view for the autonomous driving application layer, shielding the physical storage location of data and supporting local read / write of all shared data by the application layer. The second subsystem organizes data according to hierarchical rules of target, static, real-time, historical, and metadata, achieving structured storage and self-interpretation of sensor data. The third subsystem encapsulates data operations into synchronization instructions, synchronizing data with the VDDFS of other vehicles via V2X communication to ensure data consistency across multiple vehicles' VDDFS systems.

[0063] The bottom layer is the V2X communication layer, which relies on the V2X communication equipment on each vehicle to realize the broadcast or unicast transmission of synchronization commands between vehicles. It is the underlying communication support for VDDFS data synchronization, ensuring low latency and high reliability transmission of commands.

[0064] The entire architecture, through a layered and decoupled design, achieves both the integration of data storage and communication and ensures the independence of each module, adapting to the dynamic scenarios of in-vehicle ad hoc networks and providing efficient and reliable technical support for multi-vehicle collaborative perception.

[0065] The method provided in this application embodiment can be widely applied to multi-vehicle cooperative autonomous driving scenarios such as urban roads or port terminals. It relies on hardware devices such as the vehicle-mounted communication unit (OBU), LiDAR, camera, and positioning and orientation system (POS) and the locally deployed vehicle dynamic distributed file system (VDDFS).

[0066] In urban intersection scenarios, a first vehicle equipped with LiDAR and high-definition cameras can collect sensor data from targets such as motor vehicles, non-motor vehicles, or other non-vehicle objects in real time. Data is written and synchronization instructions are encapsulated through a locally deployed VDDFS on the first vehicle, which then broadcasts the instructions to a second vehicle within communication range via its OBU. The second vehicle receives the instructions through its own OBU and automatically synchronizes the data using its locally deployed VDDFS. The autonomous driving systems of either the first or second vehicle can directly access the local VDDFS to obtain perception data from other vehicles within communication range without additional communication interaction, quickly identifying targets obscured by buildings or other vehicles, and achieving intersection collision warning.

[0067] In port unmanned truck operation scenarios, multiple unmanned trucks equipped with VDDFS and V2X communication hardware can share sensor data such as cargo location and driving status in real time through this method. Combined with the auxiliary communication of roadside communication units (RSU), path coordination and safe obstacle avoidance under mixed-flow operations can be achieved, which can greatly improve port operation efficiency and traffic safety.

[0068] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0069] See Figure 2 , Figure 2 This is a flowchart illustrating a data sharing method based on an in-vehicle dynamic distributed file system, provided in an embodiment of this application. The executing entity of this method can be a vehicle capable of computational functions. The following description uses a first vehicle as the executing entity, and the method includes:

[0070] S201: The first vehicle writes sensor data to VDDFS.

[0071] VDDFS is a decentralized file system designed specifically for vehicular ad hoc networks. Deployed locally on each participating vehicle, it has no centralized metadata node. All vehicle nodes are functionally and structurally identical and are isomorphic, with each node storing all shareable metadata and sensor data. In this embodiment, VDDFS is deployed locally on both the first and second vehicles. Within VDDFS, the first vehicle acts as a node, and its nodes within communication range are isomorphic and equivalent to those of the second vehicle. The VDDFS instances of the first and second vehicles are functionally identical, have the same storage structure, and use the same data processing rules. There is no hierarchy; both can independently perform data write, synchronization, and access operations, and each stores a complete set of shared data.

[0072] Both the first vehicle and the second vehicle are vehicles equipped with sensor data acquisition, storage, and sharing capabilities. The first vehicle and the second vehicle are within the same V2X communication range, and both are equipped with V2X communication modules, onboard sensors, and local VDDFS. The first vehicle is the entity that writes sensor data in this embodiment, and the second vehicle is the object that shares sensor data with the first vehicle, possessing data reception, synchronization, and access capabilities.

[0073] Both the first and second vehicles have VDDFS installed in their local vehicle domain controllers or embedded computing modules. VDDFS does not rely on external cloud platforms or edge servers, only occupying the vehicle's local storage resources (such as solid-state storage modules). During deployment, a unified directory structure and data storage rules are automatically initialized to ensure the isomorphism of VDDFS in both vehicles. Simultaneously, the first vehicle activates its onboard sensors and completes calibration. Devices such as LiDAR and cameras collect real-time data on the surrounding environment, such as the positions of pedestrians on the road, the speed of non-motorized vehicles, or its own position coordinates. The positioning and attitude determination system simultaneously collects the vehicle's own status data, such as speed, acceleration, or heading angle.

[0074] After the first vehicle collects sensor data from the target, it performs a sensor data writing operation. The autonomous driving application layer of the first vehicle can perform structured processing on the collected sensor data. After organizing the sensor data into standardized data, the application layer can call the VDDFS write interface to write the structured sensor data into VDDFS. During the writing process, VDDFS can automatically associate the corresponding metadata of the sensor to ensure that the data and metadata are bound and stored. During this process, the VDDFS of the second vehicle remains in standby mode, with its initialized directory structure completely consistent with that of the first vehicle, waiting to receive synchronization data from the first vehicle.

[0075] In this embodiment, the decentralized architecture of VDDFS eliminates the dependence on centralized nodes, avoiding data loss or access interruptions caused by central node failures or vehicle departures, as is common in traditional distributed file systems. This makes it suitable for scenarios where vehicles dynamically join and leave vehicular ad hoc networks. Furthermore, the first vehicle writes data directly to the local VDDFS, eliminating the need for cross-device transmission and cloud forwarding, simplifying the data storage process, reducing data transmission latency and system resource overhead, and improving the real-time performance of data storage. Simultaneously, the use of homogeneous nodes and standardized write rules removes compatibility obstacles for subsequent synchronization, while the design of each node storing complete data lays the foundation for efficient access. Ultimately, this approach ensures both real-time and reliable data storage while meeting the complex requirements of vehicular scenarios.

[0076] To address the issue of data semantic ambiguity in multi-vehicle collaborative scenarios and to meet the data self-explanation requirements of autonomous driving large language models, this application embodiment further constructs a data self-explanation mechanism through the directory structure and metadata design of VDDFS.

[0077] In one possible implementation, such as Figure 3 As shown, the root directory of VDDFS includes multiple identifier directories corresponding to existing targets. Each identifier directory of an existing target includes a static attribute file, a target real-time status data subdirectory, a target historical trajectory data subdirectory, and a metadata file.

[0078] The static attribute file records the globally unique identifier, target type, absolute position coordinates, and target attribute data of existing targets. The real-time target status data subdirectory records the dynamic status information of existing targets. The historical trajectory data subdirectory persistently records the historical motion sequence information of existing targets.

[0079] Metadata files are explanatory data files that are linked to static attribute files, real-time target status data, and historical target trajectory data.

[0080] In the root directory of VDDFS, the identifier directory for each stored target is organized hierarchically according to static attribute files, real-time target status data, historical target trajectory data, and metadata. Static attribute files record basic information such as the target's globally unique identifier and type. The real-time target status data subdirectory stores dynamic information. The historical trajectory data subdirectory persists motion sequences. Metadata files, serving as interpretive data, are stored in conjunction with the above data. This structure provides a carrier for data self-interpretation, giving the data not only content but also explanation.

[0081] Metadata files can be stored in JSON format and include at least the following fields: basic description field, data generation field, confidence field, timestamp field, and contextual association field. The basic description field records the data type, data format, and natural language description; the data generation field records the sensor ID of the data source, the data processing algorithm, and the input data source; the confidence field records the data confidence value and the unavailability threshold; the timestamp field records the data generation and update times; and the contextual association field records the associated target identifier and association type, enabling data self-explanation and end-to-end traceability.

[0082] To address semantic ambiguities in multi-vehicle data, this application implements self-explanatory data capabilities through metadata. Elements such as decision traceability, semantic interpretation, contextual association, and dynamic adaptability are mapped to metadata fields. These fields record, for example, the data generation algorithm, applicable scenarios, and confidence thresholds, as well as the data's association with current road type, weather, and other scenarios. This allows the data to explain its own value. For instance, when an autonomous driving big data model calls upon data, metadata can clearly indicate that the pedestrian data originated from LiDAR, and its confidence level is lowered due to rain, significantly improving the model's accuracy in understanding the data.

[0083] Meanwhile, this mechanism also helps to solve the black box problem of autonomous driving decision-making. The input data, algorithm rules, and other information recorded in the metadata can be traced back to the basis of the decision. Semantic description fields can explain the decision logic in natural language, while contextual fields explain the adaptability of the decision to the scenario. Dynamic adaptability can also adjust the data usage priority according to changes in the scenario, making autonomous driving decision-making more transparent and more adaptable to complex in-vehicle scenarios.

[0084] After clarifying the directory and metadata structure of VDDFS, in order to achieve unified management of data on the same target by multiple vehicles, this application embodiment also provides a specific process for writing sensor data into VDDFS, ensuring that the data storage and synchronization of data on the same target by multiple vehicles remain consistent.

[0085] In one possible implementation, when the first vehicle detects a target through its sensors, it looks up the corresponding identifier directory for the target in its own deployed VDDFS.

[0086] If the first vehicle does not find the target's corresponding identifier directory in VDDFS, the first vehicle creates a globally unique identifier directory for the target in its own deployed VDDFS; the first vehicle then updates the target attribute data, the target's real-time status data, and the target's historical trajectory data in the identifier directory.

[0087] If the first vehicle finds the target's corresponding identifier directory in VDDFS, the first vehicle updates the target's status data and historical trajectory data in the target's corresponding identifier directory in VDDFS.

[0088] When the sensors of the first vehicle detect a new target, it first traverses the existing identification directories in the local VDDFS and matches whether a corresponding directory exists by using the target's absolute location and type.

[0089] If no corresponding identifier directory is found, the first vehicle will create a globally unique identifier directory for the target, write the target attribute data and real-time status data to the directory, and initialize the historical trajectory data. If a corresponding directory is found, the real-time status data and historical trajectory data will be updated directly in that directory, such as supplementing the target's latest location and extending the motion trajectory sequence.

[0090] This process ensures that new targets can quickly establish independent storage directories, and also ensures that data for the same target is continuously updated to the same directory, avoiding the problem of scattered data storage. When other vehicles subsequently detect the target, they can also match the same identifier directory through the same search logic, laying the foundation for the synchronization of target data across multiple vehicles, and ultimately achieving collaborative management of the same target data by multiple vehicles.

[0091] To accurately match the identifier directory corresponding to the same target and avoid duplicate creation or mismatch, this application embodiment achieves accurate association of targets through dual matching rules of location and attributes.

[0092] In one possible implementation, the first vehicle acquires the target's real-time 3D position information through sensors, and calculates the target's absolute position coordinates by combining the first vehicle's global position.

[0093] The first vehicle extracts the target's attribute data and iterates through the identifier directory of all stored targets in VDDFS, reading the absolute position coordinates and target attribute data of each stored target. Based on the target's absolute position coordinates and the absolute position coordinates of each stored target, the first vehicle calculates the absolute position distance between the target and each stored target.

[0094] If the target meets the preset conditions with any existing target, it is determined that the target's corresponding identifier directory has been found; if the target does not meet the preset conditions with any existing target, it is determined that the target's corresponding identifier directory has not been found. The preset conditions include that the absolute positional distance between the target and any existing target is less than a preset threshold, and that the matching degree between the target's target attribute data and the target attribute data of any existing target is greater than a preset ratio.

[0095] Once the first vehicle detects a target, it acquires the target's real-time 3D position information through sensors. Combined with the first vehicle's global position (which can be determined by the positioning and attitude determination system), the target's absolute position coordinates are calculated. Simultaneously, the first vehicle extracts the target's attribute data, such as target type or size parameters.

[0096] Subsequently, the first vehicle traverses all existing target identifier directories in the local VDDFS, reads the absolute position coordinates and target attribute data from each identifier directory, calculates the absolute position distance between the current target and each existing target, and compares the matching degree of the target attribute data. If the distance between the absolute position coordinates of an existing target and the absolute position coordinates of the target is less than a preset threshold, and the matching degree of the target attribute data of the existing target and the target exceeds a preset ratio, then the two are determined to be the same target, and the corresponding identifier directory is found. If none of the existing targets meet this condition, then it is determined to be a new target.

[0097] This application's embodiments significantly improve the accuracy of target matching through dual verification of spatial location and attribute features. This avoids duplicate directory creation caused by minor target movements and prevents mismatches between different targets due to similar attributes. Subsequently, when multiple vehicles detect the same target, they can be associated with the same identifier directory using the same matching rules, ensuring consistent data storage paths for the same target across multiple vehicles and providing a precise foundation for data synchronization and collaborative management.

[0098] S202: The VDDFS of the first vehicle encapsulates the sensor data writing operation into a synchronization command, and the first vehicle broadcasts the synchronization command to other vehicles within the communication range through vehicle-to-the-outside information exchange (V2X) communication technology.

[0099] After completing the local writing of sensor data, the VDDFS of the first vehicle automatically triggers the synchronization command generation logic without additional intervention from the autonomous driving application layer. The VDDFS extracts the target globally unique identifier, the directory path of the data update, the data generation timestamp, and the data integrity check value for this write operation, and encapsulates these parameters into a synchronization command according to a preset command format, ensuring that the command content is concise and contains all the key information required for data synchronization.

[0100] Subsequently, the first vehicle's VDDFS calls the interface of the onboard V2X communication module to broadcast the synchronization command to all vehicles within communication range. The second vehicle receives the synchronization command through its own deployed VDDFS and automatically synchronizes sensor data, ensuring data consistency between the VDDFS of the first and second vehicles.

[0101] During the broadcast process, the V2X communication module will automatically select the optimal communication protocol and transmission power according to the channel status of the vehicle ad hoc network to ensure effective transmission of instructions in complex scenarios such as high-speed vehicle movement and obstruction. At the same time, the synchronization instruction will carry the node identifier of the first vehicle and the instruction generation timestamp, which will facilitate the VDDFS of the receiving vehicle to verify the validity of the instruction.

[0102] Existing distributed file systems (DFS) typically deploy metadata on a centralized metadata node, while data is distributed across specific data nodes. Client applications first request metadata from the centralized metadata node, and then access the data through the specific data nodes.

[0103] As an example, such as Figure 4 As shown, the synchronization command can be the FS_Sync command. The FS_Sync command will be automatically generated after the VDDFS of the first vehicle completes the sensor data writing.

[0104] The instruction header explicitly identifies the instruction type as FS_Sync, the source node as the first vehicle (e.g., VIDx), and the target as all vehicles within the communication range (e.g., VIDx / ALL). It also indicates the data type (static / dynamic / historical) and the communication type (broadcast). The metadata section includes information such as the target identifier directory and data update path for this write; the data section carries a data digest.

[0105] VDDFS transparently translates the FS_Sync command into a V2X broadcast message, which is then sent to all vehicles within range via the onboard V2X communication module. This process requires no intervention from the autonomous driving application layer and is completed collaboratively by VDDFS and the onboard V2X communication module, ensuring real-time command transmission.

[0106] When the second vehicle receives the FS_Sync command, its local VDDFS will first verify the source node identifier and timestamp of the command. After confirming that the command is valid, it will locate the corresponding target identifier directory based on the metadata in the command, and then update the corresponding data synchronously according to the summary of the data part to achieve data synchronization.

[0107] S203: The first vehicle accesses its own deployed VDDFS to obtain sensor data from the second vehicle.

[0108] When the autonomous driving application layer of the first vehicle needs to obtain sensor data from other vehicles, for example, if its own sensors are blocked, it needs to call the target perception data of the second vehicle. It can directly initiate a data access request to the locally deployed VDDFS without sending additional communication commands to the second vehicle.

[0109] Because VDDFS adopts a decentralized peer-to-peer homogeneous architecture, and vehicles within the communication range have already completed data synchronization via the FS_Sync command, the sensor data of the second vehicle has been synchronized and stored in the local VDDFS of the first vehicle. At this time, the VDDFS of the first vehicle will directly read the contents of the corresponding static attribute file, real-time status data subdirectory, or historical trajectory data subdirectory from the local storage according to the request from the application layer, and return the corresponding metadata to the application layer.

[0110] For example, when the first vehicle needs to obtain the pedestrian PID1 data detected by the second vehicle, the application layer only needs to specify the PID1 directory and real-time status data. VDDFS can then directly retrieve the synchronized real-time location, movement speed, and other information of the pedestrian from the local machine, and return the data's credibility, source sensor, and other descriptions in the metadata.

[0111] In this embodiment, the first vehicle can directly access the local VDDFS to obtain synchronized data from other vehicles without needing to communicate and interact with other vehicles in real time. This completely avoids the latency and network fluctuation risks associated with cross-vehicle communication, significantly improving the real-time performance of data access. Simultaneously, since the data is stored locally through a strong consistency synchronization mechanism, the access process is unaffected by the status of other vehicles, ensuring the reliability of data access. Furthermore, local access combined with the self-explanatory capabilities of metadata allows the application layer to quickly obtain data and corresponding explanatory information, improving the efficiency and accuracy of autonomous driving decisions.

[0112] In this embodiment of the application, a unified data access view can be used to present data stored in multiple vehicles in a globally consistent virtual file system, which simplifies the data access process at the application layer.

[0113] In one possible implementation, the first vehicle can access data in VDDFS through a unified data access view. The data access view is a logical mirror of VDDFS, used to integrate data scattered across the VDDFS locations of each vehicle into a globally consistent virtual file system.

[0114] like Figure 5 As shown, Figure 5 This is a schematic diagram of a data access view provided in an embodiment of this application.

[0115] The data access view uses globally unique identifiers and target types as its core classification logic, including all vehicle data (such as VID1, VID2) and pedestrian data (such as PID1) within the communication range, with each data item corresponding to an independent identifier directory.

[0116] The view content of all vehicles within the communication range is completely synchronized, ensuring that the autonomous driving systems of each vehicle see the same data structure. For the autonomous driving application layer, accessing this view does not require concern about the physical storage location of the data; data can be written to or read from the nearest location simply through the local VDDFS view interface.

[0117] For example, if the application layer needs to obtain the status data of a neighboring vehicle's VID2, it can directly access the directory corresponding to VID2 in the view without sending a communication request to VID2. This design frees the application layer from dependence on data location, greatly simplifies data retrieval logic, and ensures the reliability of multi-vehicle collaborative decision-making by relying on the global consistency of the view.

[0118] A unified data access view masks the physical storage differences of data from multiple vehicles, allowing the application layer to access global data through a local single file system, significantly reducing the development complexity of the application layer. At the same time, the globally consistent structure of the virtual file system ensures that the data access logic of the multi-vehicle application layer is completely unified, avoiding data retrieval errors caused by differences in path rules, and providing convenient and reliable access support for the large-scale application of multi-vehicle collaborative autonomous driving.

[0119] In multi-vehicle dynamic networking scenarios, the vehicles within the communication range of the first vehicle frequently change, such as a vehicle leaving or entering the first vehicle's communication range. To address this scenario, this application embodiment also provides a data synchronization process when a vehicle leaves or enters the first vehicle's communication range, ensuring the integrity of the VDDFS data view.

[0120] In one possible implementation, when a third vehicle enters the communication range of the first vehicle, the first vehicle receives the identifier of the third vehicle broadcast by the third vehicle via V2X. The first vehicle's VDDFS creates an identifier directory corresponding to the third vehicle based on a directory synchronization mechanism and synchronizes the target attribute data of the third vehicle.

[0121] When a third vehicle enters the V2X communication range of the first vehicle, the third vehicle will broadcast its own identification information (such as a unique vehicle ID) via V2X. Upon receiving this broadcast, the first vehicle's VDDFS will trigger a directory synchronization mechanism. First, a globally unique identification directory corresponding to the third vehicle's identifier is created in the root directory of the first vehicle's local VDDFS, ensuring that the directory structure remains consistent with other vehicles. Then, based on the synchronization logic of the FS_Sync instruction, the target attribute data broadcast by the third vehicle is received, and this data is written to a static attribute file in the newly created identification directory.

[0122] In this embodiment, the third vehicle only needs to broadcast its own identifier and basic data, allowing the first vehicle to quickly complete directory creation and data synchronization. The technical advantage lies in the fact that after a new vehicle joins the communication range, the first vehicle's VDDFS can expand its data access view in real time, incorporating the new vehicle's data into the global virtual file system. This ensures that the autonomous driving application layer can directly obtain the third vehicle's information through a unified data access view without additional communication requests or data adaptation operations. This perfectly adapts to scenarios where vehicles dynamically join in vehicular ad hoc networks, guaranteeing the real-time performance and data integrity of multi-vehicle collaborative perception.

[0123] In one possible implementation, the VDDFS of the first vehicle continuously monitors the heartbeat signals of other vehicles within the communication range of the first vehicle. If no heartbeat signal of the second vehicle is detected for a preset period of time, it is determined that the second vehicle has left the communication range of the first vehicle, and the VDDFS of the first vehicle automatically deletes the corresponding identifier directory of that vehicle.

[0124] The first vehicle's VDDFS continuously monitors the heartbeat signals of all vehicles within its communication range at a preset frequency. These heartbeat signals are periodically broadcast by each vehicle to determine whether it is within the communication range. During the monitoring process, VDDFS maintains a heartbeat timing window for each vehicle with an established identification directory. Each time a heartbeat signal from the corresponding vehicle is received, the timing window resets to zero. If a vehicle's heartbeat signal is interrupted, the timing window begins to accumulate time.

[0125] When the accumulated duration of the timer window reaches the preset duration, the VDDFS of the first vehicle will determine that the second vehicle has left the communication range, and then trigger the automatic directory deletion process. The first vehicle cleans up the identification directory corresponding to the second vehicle in the VDDFS and all data files under it, and at the same time updates the unified data access view, removing the data items related to the vehicle from the virtual file system.

[0126] This application embodiment ensures that the autonomous driving application layer always accesses valid vehicle data within the current communication range by updating VDDFS in real time, thus eliminating decision-making errors caused by calling outdated data of vehicles that have already left, and further improving the reliability and scenario adaptability of multi-vehicle collaborative perception.

[0127] To facilitate understanding of the methods provided in the embodiments of this application, a schematic diagram of data sharing between vehicles is also provided in the embodiments of this application. The following is in conjunction with... Figure 6 The methods provided in the embodiments of this application will be described.

[0128] Referring to the accompanying drawings, this embodiment of the application utilizes VDDFS and V2X communication technologies to achieve sensor data sharing and unified management in multi-vehicle collaborative perception scenarios. The specific process is as follows:

[0129] like Figure 6 As shown, the first vehicle's sensors were unable to directly detect pedestrians ahead because the second vehicle blocked its view.

[0130] The second vehicle first detects the pedestrian using its own sensors, assigns it a globally unique identifier PID1, and writes the pedestrian's location, status, and other data into its own VDDFS PID1 identifier directory. Subsequently, the second vehicle's VDDFS automatically generates an FS_Sync command, which is broadcast to the communication range via V2X. After receiving the command, the first and third vehicles' VDDFS create PID1 directories locally and synchronize the pedestrian data.

[0131] The third vehicle detects the pedestrian after the second vehicle, and its VDDFS executes a target directory lookup process. The third vehicle acquires the pedestrian's real-time 3D position using sensors, calculates the pedestrian's absolute coordinates using its global position, and extracts the pedestrian's attribute data. The third vehicle traverses the local VDDFS identifier directory, reading the absolute coordinates and target attribute data corresponding to the synchronized PID1 identifier directory. The third vehicle calculates the distance between the absolute coordinates of the currently detected pedestrian and the absolute coordinates in the PID1 identifier directory. If this distance is less than a preset threshold, and the matching degree between the pedestrian's target attribute data and the target attribute data in the PID1 identifier directory exceeds a preset ratio, they are determined to be the same target, and the third vehicle directly associates the pedestrian's sensor data with the existing PID1 identifier directory.

[0132] The third vehicle updates the pedestrian's latest real-time status data in the PID1 identifier directory. The third vehicle's VDDFS then encapsulates a new FS_Sync command and broadcasts it. Upon receiving the command, the first and second vehicles' VDDFS automatically synchronize the latest data in the PID1 identifier directory, ensuring that the data in the PID1 identifier directory is identical across all three vehicles' VDDFS. The data access view is also updated synchronously, maintaining global consistency of the data in the PID1 identifier directory.

[0133] The first vehicle cannot directly detect pedestrians due to obstruction by the vehicle in front. However, by accessing the data access view of the first vehicle's local VDDFS, the latest pedestrian data under the PID1 identifier directory can be directly retrieved. Based on this data, the autonomous driving system identifies collision risks and triggers emergency obstacle avoidance operations, realizing safety decision-making supported by multi-vehicle data collaboration.

[0134] Based on the above method embodiments, this application also provides a data sharing method apparatus based on an in-vehicle dynamic distributed file system, such as... Figure 7 As shown, the device includes:

[0135] The writing module 701 is used to write sensor data to the vehicle dynamic distributed file system VDDFS; wherein, the VDDFS is deployed locally on the first vehicle and the second vehicle, the VDDFS is a decentralized architecture, in the VDDFS the first vehicle as a node is isomorphic to the nodes of the second vehicle within the communication range, and each node stores complete metadata and sensor data.

[0136] The shared module 702 is used to encapsulate the sensor data writing operation into a synchronization command through VDDFS, and broadcast the synchronization command to other vehicles within the communication range through vehicle-to-the-outside information exchange (V2X) communication technology, so that the second vehicle can receive the synchronization command through its own deployed VDDFS and automatically synchronize the sensor data, so that the VDDFS of the first vehicle and the second vehicle remain consistent.

[0137] The reading module 703 is used to access the VDDFS deployed on itself to obtain sensor data of the second vehicle.

[0138] In one possible implementation, the reading module 703 is specifically used to access data in the VDDFS through a unified data access view; the data access view is a logical mirror of the VDDFS, and the data access view is used to integrate the data scattered in the VDDFS of each vehicle into a globally consistent virtual file system.

[0139] In one possible implementation, the writing module 701 is specifically used to: when the first vehicle detects a target through its sensors, search for the identifier directory corresponding to the target in the VDDFS it deploys; if the first vehicle does not find the identifier directory corresponding to the target in the VDDFS, the first vehicle creates a globally unique identifier directory corresponding to the target in the VDDFS it deploys; the first vehicle updates the target attribute data, the target real-time status data, and the target historical trajectory data in the identifier directory; if the first vehicle finds the identifier directory corresponding to the target in the VDDFS, the first vehicle updates the target status data and the target historical trajectory data in the identifier directory corresponding to the target in the VDDFS.

[0140] In one possible implementation, the writing module 701 is specifically used to acquire the real-time 3D position information of the target through a sensor, and calculate the absolute position coordinates of the target by combining it with the global position of the first vehicle; the first vehicle extracts the target attribute data of the target; the first vehicle traverses the identifier directories of all stored targets in the VDDFS, and reads the absolute position coordinates and target attribute data of each stored target; the first vehicle calculates the absolute position distance between the target and each stored target based on the absolute position coordinates of the target and the absolute position coordinates of each stored target; if the target meets a preset condition with any stored target, it is determined that the identifier directory corresponding to the target has been found; the preset condition includes that the absolute position distance between the target and the stored target is less than a preset threshold, and the matching degree between the target attribute data of the target and the target attribute data of the stored target is greater than a preset ratio; if the target does not meet the preset condition with any stored target, it is determined that the identifier directory corresponding to the target has not been found.

[0141] In one possible implementation, the device further includes an update module, which is used to receive the identifier of the third vehicle broadcast by the third vehicle via V2X when the third vehicle enters the communication range of the first vehicle. The first vehicle's VDDFS creates an identifier directory corresponding to the third vehicle based on a directory synchronization mechanism and synchronizes the target attribute data of the third vehicle.

[0142] In one possible implementation, the update module is further configured to continuously monitor the heartbeat signals of other vehicles within the communication range of the first vehicle via VDDFS; if the heartbeat signal of the second vehicle is not detected for a preset duration, it is determined that the second vehicle has left the communication range of the first vehicle, and the VDDFS of the first vehicle automatically deletes the identification directory corresponding to the vehicle.

[0143] In one possible implementation, the root directory of the VDDFS includes multiple identifier directories corresponding to existing targets. Each identifier directory of an existing target includes a static attribute file, a target real-time status data subdirectory, a target historical trajectory data subdirectory, and a metadata file.

[0144] The static attribute file is used to record the globally unique identifier, target type, absolute position coordinates, and target attribute data of the stored target; the target real-time status data subdirectory is used to record the dynamic status information of the stored target; the target historical trajectory data subdirectory is used to persistently record the historical motion sequence information of the stored target.

[0145] The metadata file is an explanatory data file that is bound to the static attribute file, the real-time status data of the target, and the historical trajectory data of the target.

[0146] This application also provides a control device. The control device may include a memory and a processor. The processor is used to execute the data sharing method based on the vehicle-mounted dynamic distributed file system described in any of the above embodiments. The memory may be random access memory (RAM), flash memory, read-only memory (ROM), non-volatile read-only memory (EPROM), registers, hard disk, removable disk, etc.

[0147] The memory can store computer instructions. When these instructions are executed by the processor, the processor can use them to implement data sharing methods based on an in-vehicle dynamic distributed file system. The memory can also store data.

[0148] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape) or a semiconductor medium (e.g., solid-state disk (SSD)).

[0149] This application also provides a readable storage medium for storing the methods provided in the above embodiments. For example, RAM, flash memory, ROM, EPROM, registers, hard disk, removable disk, or any other form of storage medium in the art.

[0150] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.

[0151] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Regarding the methods disclosed in the embodiments, since they correspond to the product embodiments disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the description of the product embodiments.

[0152] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A data sharing method based on an in-vehicle dynamic distributed file system, characterized in that, Applied to a first vehicle, the method includes: The first vehicle writes sensor data to the vehicle dynamic distributed file system VDDFS; wherein, the VDDFS is deployed locally on the first vehicle and the second vehicle, the VDDFS is a decentralized architecture, in the VDDFS the first vehicle as a node is isomorphic to the nodes of the second vehicle within the communication range, and each node stores complete metadata and sensor data; The first vehicle's VDDFS encapsulates the sensor data writing operation into a synchronization command. The first vehicle broadcasts the synchronization command to other vehicles within its communication range through vehicle-to-the-outside information exchange (V2X) communication technology, so that the second vehicle can receive the synchronization command through its own deployed VDDFS and automatically synchronize the sensor data, so that the VDDFS of the first vehicle and the second vehicle remain consistent. The first vehicle accesses its own deployed VDDFS to obtain sensor data from the second vehicle.

2. The method according to claim 1, characterized in that, The first vehicle accesses the VDDFS it has deployed, including: The first vehicle accesses the data in the VDDFS through a unified data access view; the data access view is a logical mirror of the VDDFS, and the data access view is used to integrate the data scattered in the VDDFS of each vehicle into a globally consistent virtual file system.

3. The method according to claim 1, characterized in that, The first vehicle writes sensor data to the in-vehicle dynamic distributed file system VDDFS, including: When the first vehicle detects a target through its sensors, it searches for the corresponding identifier directory of the target in the VDDFS it has deployed. If the first vehicle does not find the identifier directory corresponding to the target in the VDDFS, the first vehicle creates a globally unique identifier directory corresponding to the target in the VDDFS it deploys; the first vehicle updates the target attribute data, target real-time status data and target historical trajectory data in the identifier directory; If the first vehicle finds the identifier directory corresponding to the target in the VDDFS, the first vehicle updates the target status data and the target historical trajectory data in the target identifier directory in the VDDFS.

4. The method according to claim 3, characterized in that, The step of searching for the identifier directory corresponding to the target in the VDDFS deployed within itself includes: The first vehicle acquires the real-time 3D position information of the target through sensors, and calculates the absolute position coordinates of the target by combining the global position of the first vehicle; The first vehicle extracts the target attribute data of the target; The first vehicle traverses the identifier directory of all stored targets in the VDDFS and reads the absolute position coordinates and target attribute data of each stored target; The first vehicle calculates the absolute position distance between the target and each of the existing targets based on the absolute position coordinates of the target and the absolute position coordinates of each of the existing targets. If the target meets a preset condition with any existing target, it is determined that the identification directory corresponding to the target has been found; the preset condition includes that the absolute positional distance between the target and the existing target is less than a preset threshold, and the matching degree between the target attribute data of the target and the target attribute data of the existing target is greater than a preset ratio; If the target does not meet the preset conditions along with any of the existing targets, it is determined that no identifier directory corresponding to the target was found.

5. The method according to claim 1, characterized in that, The method further includes: When a third vehicle enters the communication range of the first vehicle, the first vehicle receives the identifier of the third vehicle broadcast by the third vehicle via V2X. The first vehicle's VDDFS creates an identifier directory corresponding to the third vehicle based on a directory synchronization mechanism and synchronizes the target attribute data of the third vehicle.

6. The method according to claim 1, characterized in that, The method further includes: The first vehicle's VDDFS continuously monitors the heartbeat signals of other vehicles within the first vehicle's communication range; If no heartbeat signal from the second vehicle is detected for a preset duration, it is determined that the second vehicle has left the communication range of the first vehicle, and the first vehicle's VDDFS automatically deletes the corresponding identifier directory from the first vehicle.

7. The method according to claim 1, characterized in that, The root directory of the VDDFS includes multiple identifier directories corresponding to existing targets. Each identifier directory of an existing target includes a static attribute file, a target real-time status data subdirectory, a target historical trajectory data subdirectory, and a metadata file. The static attribute file is used to record the globally unique identifier, target type, absolute position coordinates, and target attribute data of the stored target; the target real-time status data subdirectory is used to record the dynamic status information of the stored target; the target historical trajectory data subdirectory is used to persistently record the historical motion sequence information of the stored target. The metadata file is an explanatory data file that is bound to the static attribute file, the real-time status data of the target, and the historical trajectory data of the target.

8. A data sharing device based on an in-vehicle dynamic distributed file system, characterized in that, Applied to a first vehicle, the device includes: The writing module is used to write sensor data to the vehicle dynamic distributed file system VDDFS. The VDDFS is deployed locally on the first vehicle and the second vehicle. The VDDFS is a decentralized architecture. In the VDDFS, the first vehicle is a node and the nodes of the second vehicle within the communication range are isomorphic. Each node stores complete metadata and sensor data. The shared module is used to encapsulate sensor data writing operations into synchronization instructions via VDDFS, and broadcast the synchronization instructions to other vehicles within the communication range through vehicle-to-the-outside information exchange (V2X) communication technology, so that the second vehicle can receive the synchronization instructions through its own deployed VDDFS and automatically synchronize the sensor data, so that the VDDFS of the first vehicle and the second vehicle remain consistent. The reading module is used to access the VDDFS deployed on itself to obtain sensor data of the second vehicle.

9. A control device, characterized in that, It includes a processor and a memory, the memory being used to store programs, instructions, or code, and the processor being used to execute the programs, instructions, or code in the memory to complete the data sharing method based on an in-vehicle dynamic distributed file system as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The system contains a computer program that is loaded by a processor to execute the data sharing method based on an in-vehicle dynamic distributed file system as described in any one of claims 1-7.

Images