A multi-source data processing system and method based on an electronic horizon reconstruction module

Abstract

The present application relates to the field of vehicle-mounted electronics, and discloses a multi-source data processing system and method based on an electronic horizon reconstruction module, wherein the system designed by the present application comprises a data access layer, a standardized processing layer, a data service layer and an application interface layer which are decoupled through standardized interfaces between adjacent layers; the data access layer acquires multi-source data and performs plug-in adaptation to process the data, outputting standardized raw data; the standardized processing layer performs data purification processing, multi-source data fusion and compression processing on the standardized raw data, outputting standardized compressed data; the data service layer determines the scheduling priority of each functional module according to the currently activated functional modules of ADAS, to output the on-demand scheduling data corresponding to each functional module; and the application interface layer converts the on-demand scheduling data corresponding to each functional module into a recognizable data format and pushes the data to the corresponding functional modules respectively, thereby realizing efficient interfacing with vehicle-mounted multi-source data sources and ADAS functional modules.

Description

Technical Field

[0001] This invention relates to the field of vehicle electronics technology, and more specifically to a multi-source data processing system and method based on an electronic horizon reconstruction module. Background Technology

[0002] As the automotive industry rapidly evolves towards intelligence and connectivity, more and more vehicles are upgrading to Advanced Driver Assistance Systems (ADAS), iterating from basic Level 2 assistance functions to advanced Level 3 (L3-L4) autonomous driving. The Electronic Horizon Reconstructor (EHR) module, as the core data support for ADAS perception, planning, and decision-making functions, directly affects the reliability, scalability, and real-time performance of the ADAS system due to the rationality of its architecture design. Currently, most in-vehicle EHR modules adopt a traditional monolithic integrated architecture, with all in-vehicle data sources such as LiDAR, high-precision maps, and cameras connected to a single EHR module. This module adopts a single physical resource sharing and centralized processing method without layering and modularization, resulting in high coupling of data access, processing, and transmission links, and a lack of effective isolation and decoupling mechanisms. Summary of the Invention

[0003] This invention provides a multi-source data processing system and method based on an electronic horizon reconstruction module to solve the problem that traditional monolithic integrated architectures do not perform layered and modular division, resulting in high coupling of data access, processing and transmission links and a lack of effective isolation and decoupling mechanisms.

[0004] In a first aspect, the present invention provides a multi-source data processing system based on an electronic horizon reconstruction module. The system is deployed within an advanced driver assistance system (ADAS) domain controller and includes an independent data access layer, a standardization processing layer, a data service layer, and an application interface layer, all decoupled from each other via standardized interfaces. The data access layer establishes connections with in-vehicle multi-source data sources, adapts multi-source data to plugins, processes the data using the adapted plugins, and outputs standardized raw data. The standardization processing layer receives the standardized raw data output from the data access layer and performs data purification, multi-source data fusion, and dynamic compression processing on the standardized raw data, outputting standardized compressed data. The data service layer receives the standardized compressed data output from the standardization processing layer, manages its storage, and determines the on-demand scheduling data and scheduling priority for each functional module based on the currently activated functional modules of the ADAS, outputting the on-demand scheduling data corresponding to each functional module according to the scheduling priority. The application interface layer receives the on-demand scheduling data output from the data service layer, converts the on-demand scheduling data corresponding to each functional module into a recognizable data format, and pushes it to the corresponding functional modules.

[0005] This invention provides a multi-source data processing system based on an electronic horizon reconstruction module. This system can be directly deployed within the domain controller of an advanced driver assistance system (ADAS) without modifying the vehicle's hardware architecture. It includes independent layers—a data access layer, a standardization processing layer, a data service layer, and an application interface layer—decoupled from each other via standardized interfaces. The data access layer establishes connections with the vehicle's multi-source data, performs plug-in adaptation for the multi-source data, processes the data, and outputs standardized raw data. The standardization processing layer performs data purification, multi-source data fusion, and compression on the standardized raw data, outputting standardized compressed data. The data service layer stores the standardized compressed data and applies it to the advanced driver assistance system. The system unifies the currently active functional modules, determines the on-demand scheduling data and scheduling priority for each module, and outputs the on-demand scheduling data for each module. The application interface layer converts the on-demand scheduling data for each module into a recognizable data format and pushes it to the corresponding functional modules. This enables efficient integration with multi-source vehicle data sources and ADAS functional modules. Through plug-in access, layered processing, on-demand scheduling, and independent interface output, it can adapt to new multi-source data sources without modifying the core code, resulting in stronger adaptability and scalability. At the same time, it achieves layered fault isolation, prevents the spread of single-point anomalies, effectively improves the real-time performance and stability of the electronic horizon reconstruction module, and meets the operational requirements of high-level autonomous driving.

[0006] In one optional implementation, the data access layer includes a plugin management center and a data verification unit. The plugin management center integrates a plugin registry for recording the mapping relationship between each data source and the adaptation plugin. The plugin management center is used to receive multi-source data and search the plugin registry based on the currently accessed data source type to determine whether the current data source has a matching first plugin set. The first plugin set includes at least a protocol parsing plugin and a data source adaptation plugin. If a matching first set of plugins exists in the plugin registry, each plugin is invoked to perform protocol parsing and format conversion on the data output from the current data source to obtain data in a unified format; the data verification unit is used to verify the validity of the unified format data and push the standardized raw data that passes the verification to the standardization processing layer.

[0007] This invention constructs a plug-in multi-source data access system, which relies on a plug-in management center and registry to achieve precise data source adaptation, uniformly complete protocol parsing and format conversion, and at the same time, uses a data verification unit to filter valid data and block abnormal data, thereby achieving unified collection of heterogeneous data and filtering of invalid data, forming a full-process access system of "plug-in adaptation-protocol parsing-data verification", which greatly improves the flexibility and efficiency of data source adaptation.

[0008] In one optional implementation, the data access layer further includes a plugin development unit, wherein the plugin development unit is used to obtain the protocol information of the new data source and develop a second plugin set corresponding to the new data source based on a preset plugin standard template; the plugin development unit is used to package the metadata corresponding to the developed second plugin set and submit it to the plugin management center for registration; the plugin management center is used to verify the second plugin set, and after the verification is passed, load the code and dependencies of the second plugin set and update it in the plugin registry, wherein the verification includes at least plugin version verification and plugin integrity verification.

[0009] This invention develops a set of plugins for adding new data sources through a plugin development unit, and the plugin management center realizes dynamic registration and loading of plugins. The adaptation of new data sources can be completed without modifying the core code of the electronic horizon reconstruction module, shortening the adaptation cycle, greatly improving the system scalability, adapting to the multi-sensor iteration requirements of advanced driver assistance systems, and effectively solving the technical pain points of difficult and long-cycle adaptation of new data sources in traditional electronic horizon reconstruction modules.

[0010] In one optional implementation, the standardization processing layer includes a data processing module, an anomaly repair module, a multi-source data fusion engine, and a dynamic compression module. The data processing module performs spatiotemporal and sampling frequency synchronization processing and semantic standardization on the standardized raw data, outputting standardized data. The anomaly repair module detects anomalies in the standardized data, and upon detection, employs a corresponding anomaly repair strategy to repair the anomaly data, verifies the repair results, and outputs multi-source valid data. The multi-source data fusion engine performs multi-source data fusion processing on the multi-source valid data, outputting fused data. The dynamic compression module evaluates the accuracy of the fused data, selects an appropriate compression strategy based on the accuracy evaluation results, and outputs standardized compressed data.

[0011] This invention designs a spatiotemporal synchronization, semantic standardization, anomaly detection and repair, fusion and dynamic compression process to reduce the accuracy loss of dynamic compression, ensure high precision and high consistency of output data, and provide stable and reliable data support for ADAS functional modules.

[0012] In one optional implementation, the multi-source data fusion engine is specifically used to acquire multi-source valid data output by the anomaly repair module, calculate the confidence level of each data source for the valid data from each data source, and combine the confidence level of each data source, driving environment parameters, and the operating conditions of the advanced driver assistance system. A corresponding data fusion strategy is matched; the matched data fusion strategy is used to perform multi-source data fusion processing on the multi-source valid data to obtain preliminary fused data; the preliminary fused data is optimized using a Kalman filter algorithm, and the accuracy of the optimized fused data is verified to obtain the data accuracy results of each fused data set; the fused data whose data accuracy results meet the preset accuracy requirements is output to the dynamic compression module.

[0013] In one optional implementation, the data service layer includes a backup service module and a resource scheduling center. The backup service module receives standardized compressed data output from the standardized processing layer, stores standardized compressed data with access frequencies exceeding a preset frequency threshold in a local cache, and synchronizes all standardized compressed data to the cloud for backup. The resource scheduling center identifies the current operating scenario and activated functional modules of the advanced driver assistance system, determines the on-demand scheduling data corresponding to each functional module, and allocates scheduling priorities according to the needs of each functional module. The resource scheduling center also extracts the on-demand scheduling data corresponding to each functional module from the local cache, and pushes the on-demand scheduling data corresponding to each functional module to the application interface layer according to the corresponding scheduling priority and a preset update strategy. The preset update strategy is to select a real-time update strategy or an incremental update strategy based on the scheduling priority.

[0014] In one optional implementation, the application interface layer includes an application programming interface gateway, a protocol adapter, and a permission management module. The application programming interface gateway is used to adapt and convert the interface protocol of the on-demand scheduling data corresponding to each functional module, converting it into a data format recognizable by each functional module, and pushing it to the corresponding functional module through the adapted standardized interface. The protocol adapter is used to accept the interface protocol and data format of the newly added functional module, and to perform protocol parsing, format adaptation, and interface conversion on the on-demand scheduling data of the newly added functional module, so as to push the on-demand scheduling data to the newly added functional module. The permission management module is used to control the data access permissions of each functional module, so as to control each functional module's access to the on-demand scheduling data within its authorized scope.

[0015] In one optional implementation, the data access layer, standardization processing layer, data service layer, and application interface layer are each deployed with an independent fault monitoring module. Each fault monitoring module monitors the operational status of its own layer and the data transmission status of the inter-layer data processing links in real time. When any fault monitoring module detects an anomaly in its corresponding layer, it performs fault location processing to determine the fault type. Based on the fault type, it executes a corresponding fault handling strategy. The fault handling strategy includes, if the fault type is a plugin fault, uninstalling the faulty plugin and loading a backup plugin; if the detected fault type is a functional module fault within the layer, replacing the faulty functional module with a backup functional module; if the detected fault type is a preset alarm fault type, triggering an alarm signal and maintaining data push from the functional modules used for vehicle driving safety.

[0016] Secondly, this invention provides a multi-source data processing method based on an electronic horizon reconstruction module, applied to a multi-source data processing system based on an electronic horizon reconstruction module in the first aspect or any corresponding embodiment. The system is deployed within an advanced driver assistance system domain controller and includes an independent data access layer, a standardized processing layer, a data service layer, and an application interface layer, all decoupled from each other through standardized interfaces. The method includes: acquiring multi-source data; adapting the multi-source data to plugins; processing the data using the adapted plugins; and outputting standardized raw data; performing data purification, multi-source data fusion, and dynamic compression processing on the standardized raw data; outputting standardized compressed data; managing the storage of the standardized compressed data; determining the on-demand scheduling data and scheduling priority corresponding to each functional module based on the currently activated functional modules of the advanced driver assistance system; outputting the on-demand scheduling data corresponding to each functional module according to the scheduling priority; and converting the on-demand scheduling data corresponding to each functional module into a recognizable data format and pushing it to the corresponding functional module.

[0017] In one alternative embodiment, the present invention provides a vehicle including a multi-source data processing system based on an electronic horizon reconstruction module according to the first aspect described above or any corresponding embodiment thereof.

[0018] Thirdly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the multi-source data processing method based on the electronic horizon reconstruction module described in the first aspect or any corresponding embodiment thereof.

[0019] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the multi-source data processing method based on the electronic horizon reconstruction module described in the first aspect or any corresponding embodiment thereof.

[0020] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the multi-source data processing method based on the electronic horizon reconstruction module described in the first aspect or any corresponding embodiment thereof.

[0021] The present invention has the following technical effects: This invention provides a multi-source data processing system based on an electronic horizon reconstruction module. This system can be directly deployed within the domain controller of an advanced driver assistance system (ADAS) without modifying the vehicle's hardware architecture. It includes independent layers—a data access layer, a standardization processing layer, a data service layer, and an application interface layer—decoupled from each other via standardized interfaces. The data access layer establishes connections with the vehicle's multi-source data, performs plug-in adaptation for the multi-source data, processes the data, and outputs standardized raw data. The standardization processing layer performs data purification, multi-source data fusion, and compression on the standardized raw data, outputting standardized compressed data. The data service layer stores the standardized compressed data and applies it to the advanced driver assistance system. The system unifies the currently active functional modules, determines the on-demand scheduling data and scheduling priority for each module, and outputs the on-demand scheduling data for each module. The application interface layer converts the on-demand scheduling data for each module into a recognizable data format and pushes it to the corresponding functional modules. This enables efficient integration with multi-source vehicle data sources and ADAS functional modules. Through plug-in access, layered processing, on-demand scheduling, and independent interface output, it can adapt to new multi-source data sources without modifying the core code, resulting in stronger adaptability and scalability. At the same time, it achieves layered fault isolation, prevents the spread of single-point anomalies, effectively improves the real-time performance and stability of the electronic horizon reconstruction module, and meets the operational requirements of high-level autonomous driving. Attached Figure Description

[0022] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is an example diagram of a data processing scheme for a conventional vehicle-mounted electronic horizon reconstruction module according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a multi-source data processing system based on an electronic horizon reconstruction module according to an embodiment of the present invention; Figure 3 This is a structural example diagram of a multi-source data processing system based on an electronic horizon reconstruction module according to an embodiment of the present invention; Figure 4 This is an overall example diagram of a high-level decoupled modular scalable architecture based on an electronic horizon reconfiguration module according to an embodiment of the present invention; Figure 5 This is an example diagram of the data access layer plug-in management and multi-source data adaptation process according to an embodiment of the present invention; Figure 6 This is an example diagram illustrating the implementation process of plug-in adaptation for adding new data sources according to an embodiment of the present invention; Figure 7 This is an example diagram of the data fusion and anomaly repair process in the standardized processing layer according to an embodiment of the present invention; Figure 8 This is an example diagram of the multi-source data spatiotemporal synchronization and high-precision fusion process according to an embodiment of the present invention; Figure 9 This is a flowchart illustrating the data caching, backup, and scenario-based scheduling of the data service layer according to an embodiment of the present invention. Figure 10 This is an example diagram illustrating the interface between the application interface layer and various functional modules according to an embodiment of the present invention; Figure 11 This is an example diagram of the fault isolation and anomaly handling process of the EHR module according to an embodiment of the present invention; Figure 12 This is a diagram illustrating a practical application deployment example in an L3 passenger vehicle ADAS system according to an embodiment of the present invention; Figure 13 This is a schematic diagram of a multi-source data processing method based on an electronic horizon reconstruction module according to an embodiment of the present invention; Figure 14 This is a structural block diagram of a vehicle according to an embodiment of the present invention; Figure 15This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0026] Traditional data processing solutions for electronic horizon reconstructors (EHR) in vehicles include... Figure 1 As shown, a monolithic integrated architecture design is adopted, with all vehicle data sources such as LiDAR, high-precision maps, and cameras directly connected to a single EHR module. This module integrates all functions such as data access, processing, services, and interfaces, without any layering or modularization. This traditional approach, which uses a single physical resource sharing and centralized processing method, results in a high degree of coupling between data access, processing, and transmission, lacking effective isolation and decoupling mechanisms. On the one hand, when adding new data sources (such as vehicle-to-everything (V2X) roadside units), the EHR core code needs to be modified, leading to a long adaptation period and a high risk of system failure. On the other hand, once an anomaly occurs in a certain data processing stage, the fault will quickly spread to the entire EHR module, and may even affect the normal operation of Advanced Driver Assistance Systems (ADAS) functional modules (Navigation on Autopilot (NOA), Adaptive Cruise Control (ACC), Lane Keeping Assist (LKA), etc.), severely reducing the reliability and safety of the ADAS system and failing to meet the high-precision and high-scalability requirements of Level 3 (L3) and above autonomous driving for multi-source data processing.

[0027] This embodiment provides a multi-source data processing system based on an electronic horizon reconstruction module. This system is deployed within an ADAS domain controller, such as... Figure 2 As shown, the system comprises an independent data access layer 201, a standardized processing layer 202, a data service layer 203, and an application interface layer 204, which are decoupled from each other through standardized interfaces. This ensures the efficiency and scalability of EHR data processing while also considering the real-time requirements and hardware adaptation needs of in-vehicle scenarios. Specifically, the data access layer establishes connections with multi-source data sources in the vehicle, adapts multi-source data to plugins, processes the data using the adapted plugins, and outputs standardized raw data. The standardized processing layer receives the standardized raw data output from the data access layer and performs data purification, multi-source data fusion, and dynamic compression processing on the standardized raw data, outputting standardized compressed data. The data service layer receives the standardized compressed data output from the standardized processing layer, manages its storage, and determines the on-demand scheduling data and scheduling priority for each functional module based on the currently activated functional modules of the advanced driver assistance system. It then outputs the on-demand scheduling data for each functional module according to the scheduling priority. The application interface layer receives the on-demand scheduling data output from the data service layer, converts the on-demand scheduling data for each functional module into a recognizable data format, and pushes it to the corresponding functional modules.

[0028] Specifically, such as Figure 3As shown, the multi-source data processing system based on the Electronic Horizon Reconstruction (EHR) module designed in this embodiment of the invention, through a layered decoupling design, divides the EHR module into four independent functional layers: a data access layer, a standardization processing layer, a data service layer, and an application interface layer. All functional layers are deployed within the ADAS domain controller, achieving efficient integration with vehicle-mounted multi-source data and ADAS functional modules. Vehicle-mounted multi-source data sources (including but not limited to LiDAR, high-precision maps, Vehicle to Everything (V2X) communication, cameras, millimeter-wave radar, ultrasonic radar, and Inertial Measurement Unit (IMU) / Global Navigation Satellite System (GNSS)) serve as data input terminals, establishing connections with the data access layer. The data access layer pre-develops a registry of plugins adapted to various vehicle-mounted data sources, including V2X roadside unit adaptation plugins, high-precision map offline data package adaptation plugins, and vehicle controller area network (Controller Area Network) plugins. Network (CAN) bus vehicle speed / attitude data plugins, LiDAR road contour data plugins, etc. The data access layer serves as the core interface between the EHR module and the vehicle's multi-source data sources. It mainly realizes the plug-in adaptation of multi-source data for data processing. During application, the data access layer automatically identifies the current vehicle hardware mounting status and data source activation status, and performs plug-in adaptation for multi-source data respectively. Then, each adapted plugin processes its data independently, such as data parsing, protocol conversion, and invalid data filtering. After all plugins have completed processing, standardized raw data is uniformly output and transmitted to the standardization processing layer.

[0029] The standardized processing layer designed in this embodiment of the invention is the core of achieving high-precision processing of multi-source data. It is mainly responsible for data purification processing of the standardized raw data output from the data access layer, high-precision fusion of multi-source data, and dynamic compression processing to ensure the accuracy, consistency, and reliability of the output data. It outputs standardized compressed data to the data service layer. Among them, data purification processing includes, but is not limited to, spatiotemporal synchronization operation, semantic standardization processing, and interpolation and completion of lost data. The standardized processing layer can then fuse the purified data (including static data such as road topology and slope of high-precision map and V2X real-time traffic data, obstacle data, etc.) to reconstruct complete and accurate electronic horizon scene data, making up for the limitations of a single data source. Then, it can dynamically adjust the compression ratio according to the current vehicle operating status. For example, it retains high-precision road curvature and lane boundary data in high-speed driving conditions and simplifies redundant terrain data in low-speed driving conditions, outputting lightweight and standardized compressed data, which not only ensures the accuracy required by ADAS functions, but also reduces bus transmission and chip computing power consumption.

[0030] The data service layer designed in this embodiment of the invention is mainly responsible for storing, backing up, and scheduling the standardized compressed data output by the standardized processing layer in a scenario-based manner, ensuring the security, availability, and real-time performance of the data, and providing efficient data support for the application interface layer. Specifically, the data service layer can manage the storage of standardized compressed data. Among these, high-frequency standardized compressed data (such as real-time traffic conditions and vehicle attitude data) can be cached at high speed, while low-frequency standardized compressed data (such as static traffic condition data) can be stored at low speed. This is just an example. Then, the data service layer can monitor the activation status of ADAS functions in real time and dynamically match the data requirements and scheduling priorities of each functional module. For example, the priority of emergency execution of AEB function is higher than that of ACC adaptive cruise control function. According to the scheduling priority of each functional module, the data on demand for each functional module can be output to the application interface layer.

[0031] The application interface layer designed in this embodiment of the invention serves as a bridge between the EHR module and the ADAS functional modules. It is mainly responsible for standardizing data output and interface adaptation, ensuring seamless integration and flexible expansion between the EHR module and various functional modules. Specifically, the application interface layer has pre-set standardized output interfaces for various ADAS functional modules. After receiving the on-demand scheduling data output by the data service layer, it performs targeted format conversion based on the data parsing protocol and format requirements of different functional modules, converting the on-demand scheduling data into a data format that the functional module can recognize. After the format conversion is completed, the data can be accurately pushed to the corresponding ADAS functional module, supporting the stable and accurate operation of each function and fully meeting the core requirements of L3 and above autonomous driving.

[0032] This invention proposes a modular EHR architecture based on layered decoupling. By constructing four independent functional layers, it achieves complete decoupling between the EHR system and the ADAS core module and multiple data sources. Unlike the traditional monolithic integrated architecture, this solution assigns independent responsibilities and standardized interfaces to each layer. It replaces core architecture modifications with plug-in adaptation, solving the drawback of the traditional architecture's "change in one part affects the whole" problem from the bottom up. This ensures the real-time performance and stability of EHR data processing while reserving flexibility for subsequent function upgrades and data source expansion, thus resolving the contradiction between the scalability and stability of the vehicle EHR system.

[0033] This invention provides a multi-source data processing system based on an electronic horizon reconstruction module. This system can be directly deployed within the domain controller of an advanced driver assistance system (ADAS) without modifying the vehicle's hardware architecture. It includes independent layers—a data access layer, a standardization processing layer, a data service layer, and an application interface layer—decoupled from each other via standardized interfaces. The data access layer establishes connections with the vehicle's multi-source data, performs plug-in adaptation for the multi-source data, processes the data, and outputs standardized raw data. The standardization processing layer performs data purification, multi-source data fusion, and compression on the standardized raw data, outputting standardized compressed data. The data service layer stores the standardized compressed data and applies it to the advanced driver assistance system. The system unifies the currently active functional modules, determines the on-demand scheduling data and scheduling priority for each module, and outputs the on-demand scheduling data for each module. The application interface layer converts the on-demand scheduling data for each module into a recognizable data format and pushes it to the corresponding functional modules. This enables efficient integration with multi-source vehicle data sources and ADAS functional modules. Through plug-in access, layered processing, on-demand scheduling, and independent interface output, it can adapt to new multi-source data sources without modifying the core code, resulting in stronger adaptability and scalability. At the same time, it achieves layered fault isolation, prevents the spread of single-point anomalies, effectively improves the real-time performance and stability of the electronic horizon reconstruction module, and meets the operational requirements of high-level autonomous driving.

[0034] Furthermore, the data access layer includes a plugin management center and a data verification unit. The plugin management center integrates a plugin registry to record the mapping relationship between each data source and the corresponding plugin. The plugin management center receives multi-source data and searches the plugin registry based on the currently accessed data source type to determine if the current data source has a matching first plugin set. The first plugin set includes at least a protocol parsing plugin and a data source adaptation plugin. If a matching first plugin set exists in the plugin registry, each plugin is invoked to perform protocol parsing and format conversion on the data output by the current data source to obtain data in a unified format. The data verification unit is used to verify the validity of the unified format data and pushes the standardized raw data that passes the verification to the standardization processing layer.

[0035] like Figure 4 As shown, the data access layer designed in this embodiment of the invention includes a plug-in management center and a data verification unit, such as... Figure 5As shown, when the vehicle-mounted multi-source data sources (LiDAR, high-precision maps, etc.) start outputting data, all multi-source data first access the plug-in management center of the data access layer. After receiving the multi-source data, the plug-in management center can search the internally integrated plug-in registry, which records the mapping relationship between each data source and the corresponding plug-in. It determines whether the current data source has a corresponding first plug-in set. The first plug-in set includes at least a data source adaptation plug-in, a protocol parsing plug-in, a data format conversion plug-in, and a data verification plug-in. If a matching first plug-in set exists in the plug-in registry, each plug-in can be called to perform protocol parsing and format conversion on the data output from each data source, converting heterogeneous data into data of a unified format. If the plug-in registry does not contain the plug-in set corresponding to the current data source, the system will not perform protocol parsing and format conversion. This system can directly intercept incompatible data sources, preventing them from entering the core data link, and simultaneously report alarms. If it is a critical data source, it can automatically activate backup devices / plugins as a backup, relying on a layered isolation mechanism to ensure the normal operation of the vehicle's ADAS. Subsequently, developers can develop corresponding data source adaptation plugins and protocol parsing plugins according to the plugin standardization specifications. After development, they can connect to the plugin management center and then perform subsequent protocol parsing operations. After data parsing is completed, the data verification unit of the data access layer can perform validity verification on the unified formatted data, filtering invalid data (such as data with missing key fields or incorrect data format), and then push the standardized raw data that has passed the verification to the standardization processing layer, laying the foundation for subsequent data processing.

[0036] This invention constructs a plug-in multi-source data access system, which relies on a plug-in management center and registry to achieve precise data source adaptation, uniformly complete protocol parsing and format conversion, and at the same time, uses a data verification unit to filter valid data and block abnormal data, thereby achieving unified collection of heterogeneous data and filtering of invalid data, forming a full-process access system of "plug-in adaptation-protocol parsing-data verification", which greatly improves the flexibility and efficiency of data source adaptation.

[0037] Furthermore, the data access layer also includes a plugin development unit. This unit is used to obtain the protocol information of the new data source and develop a second plugin set corresponding to the new data source based on a preset plugin standard template. The plugin development unit is also used to package the metadata corresponding to the developed second plugin set and submit it to the plugin management center for registration. The plugin management center is used to verify the second plugin set and, after successful verification, load the code and dependencies of the second plugin set and update it in the plugin registry. The verification includes at least plugin version verification and plugin integrity verification.

[0038] like Figure 6As shown, the data access layer designed in this embodiment of the invention also includes a plugin development unit, which supports non-intrusive iterative adaptation of new data source plugins. When a vehicle accesses a new type of in-vehicle data source and there is no matching plugin set in the plugin registry, the plugin development unit obtains the protocol information and parameters of the new data source and then, strictly following the plugin standard specifications and templates of the EHR module, quickly develops a second plugin set (including but not limited to data source adaptation plugins and protocol parsing plugins) to adapt to the data source, ensuring that the plugins are compatible with the core module of the data access layer. Then, the plugin development unit packages the version information, functional source data, and dependencies of the developed second plugin set and submits it to the plugin management center to complete the registration application. After receiving the plugin package, the plugin management center calls the plugin discovery service to identify the plugin type, such as... Figure 5 As shown, the plugin metadata is registered in the plugin repository. The plugin dependency management submodule of the plugin management center checks whether the plugin dependencies are complete and whether the versions are compatible. The plugin version control submodule verifies whether the plugin version conflicts with existing plugins. The plugin configuration management submodule loads the plugin's configuration parameters. The integrity verification confirms that the plugin package is not damaged and conforms to the standardization specifications. After the verification is passed, the hot-swap engine sends a plugin loading request to the plugin execution engine. The plugin execution engine dynamically loads the plugin code without restarting the entire EHR core system. The dependency management submodule synchronously loads all the plugin's dependencies to ensure the integrity of the runtime environment. After loading is completed, the plugin matching query module updates the plugin registry and binds the plugin to the corresponding data source type. The newly added adaptation plugin is incorporated into the data processing pipeline so that the plugin can be used to process the data in a corresponding way, including but not limited to protocol adaptation, data parsing, format conversion and data verification. This is just an example.

[0039] This invention develops a set of plugins for adding new data sources through a plugin development unit, and the plugin management center realizes dynamic registration and loading of plugins. The adaptation of new data sources can be completed without modifying the EHR core code, shortening the adaptation cycle, greatly improving the system scalability, adapting to the multi-sensor iteration requirements of ADAS systems, and effectively solving the technical pain points of difficult and long-cycle adaptation of new data sources in traditional EHR modules.

[0040] In one optional implementation, the standardization processing layer includes a data processing module, an anomaly repair module, a multi-source data fusion engine, and a dynamic compression module. The data processing module performs spatiotemporal and sampling frequency synchronization processing and semantic standardization on the standardized raw data, outputting standardized data. The anomaly repair module detects anomalies in the standardized data, and upon detection, employs appropriate anomaly repair strategies to repair the anomaly data, verifies the repair results, and outputs multi-source valid data. The multi-source data fusion engine performs multi-source data fusion processing on the multi-source valid data, outputting fused data. The dynamic compression module evaluates the accuracy of the fused data, selects an appropriate compression strategy based on the accuracy evaluation results, and outputs standardized compressed data.

[0041] like Figure 4 As shown, the standardized processing layer designed in this embodiment of the invention includes a data processing module, an anomaly repair module, a multi-source data fusion engine, and a dynamic compression module, such as... Figure 7 As shown, specifically, the data processing module can perform spatiotemporal synchronization and semantic standardization on standardized raw data. First, the data processing module aligns the time reference of all standardized raw data to GPS time or a unified system time to eliminate time discrepancies between different data sources. Simultaneously, it aligns the spatial reference to the vehicle coordinate system or world coordinate system to ensure that data collected by different sensors (such as LiDAR and cameras) are in the same spatial dimension. Then, it uses interpolation synchronization methods to unify the sampling frequency of all data, avoiding data misalignment caused by differences in sampling frequency. For example, combining the ADAS operating scenario and device computing power, a global standard sampling frequency and fixed sampling period are set to generate unified, equally spaced time-series sampling nodes. All data sources share this time axis, employing a scenario-specific interpolation strategy: linear interpolation is used for conventional data such as radar, cameras, and V2X to ensure real-time performance; cubic spline interpolation is used for high-precision position and attitude data such as IMU, GNSS, and high-precision maps to reduce fitting errors. For each standard time-series node, the corresponding interpolation algorithm is called to calculate the equivalent data value, unifying the sampling frequency of all heterogeneous data sources. Simultaneously, boundary fallback processing and preliminary anomaly correction are performed to avoid frame breaks and boundary failures, verify the time sequence consistency of all data, completely eliminate data misalignment issues, and finally output standardized data with completely unified time sequence, spatial domain, and sampling frequency to support subsequent high-precision data fusion. This is just an example.

[0042] This invention embodiment can perform unified and standardized processing on spatiotemporally synchronized data, specifically including four aspects: format unification (converting heterogeneous formats from different data sources into a unified JSON or Protobuf format), unit unification (unifying parameters such as distance, speed, and angle into units of m, km / h, and rad, respectively), field mapping (mapping all data fields according to a unified naming convention to eliminate differences in field naming), and value range normalization (normalizing the value range of all data to the range of 0-1 to improve the efficiency and accuracy of subsequent fusion processing). This is just an example.

[0043] The anomaly repair module of this invention can perform anomaly detection on data and achieve multi-dimensional anomaly identification through four detection methods: missing value detection (based on timestamp continuity, detecting whether the data is missing), range anomaly detection (based on physical limits, determining whether the data exceeds a reasonable range), jump anomaly detection (based on rate of change threshold, identifying whether the data has abrupt changes), and consistency detection (through multi-sensor cross-validation, determining whether the data is contradictory). These are just examples. When data anomalies occur, corresponding anomaly repair strategies can be adopted to repair the detected abnormal data, such as missing value imputation (using linear interpolation or spline interpolation methods to supplement missing data), anomaly correction (using median filtering or mean replacement methods to correct data exceeding a reasonable range or with abrupt changes), and consistency repair (based on the vehicle's physical model, correcting contradictory data in multi-sensor cross-validation). These are just examples. Then, the repair results can be verified, such as performing secondary verification on the repaired data to ensure that the repair effect meets the requirements. Finally, after successful verification of the repair results, multi-source valid data is output.

[0044] The multi-source data fusion engine designed in this embodiment of the invention can perform multi-source data fusion processing on valid data from multiple sources to output fused data. The fusion methods for multi-source data include, but are not limited to, weighted average fusion and Bayesian fusion. The dynamic compression module can evaluate the accuracy of the fused data, calculate the potential accuracy loss caused by the current data compression, and obtain the accuracy evaluation result. For example, it can extract statistical feature parameters of the fused data, including data variance, signal-to-noise ratio, and numerical distribution range. Based on the statistical feature parameters, it can calculate the theoretical accuracy loss curves corresponding to different compression ratios and determine the expected accuracy loss of the current data under different compression strategies. Then, it can be used to... Based on the accuracy assessment results, an adaptive selection of lossy or lossless compression strategies is made to ensure that the accuracy loss during compression is ≤0.5%. For example, if the expected accuracy loss is no greater than 0.5%, a lossy compression strategy can be selected; if the expected accuracy loss is greater than 0.5%, a lossless compression strategy can be selected to compress the fused data. This is just an example. After compression, the compression effect can be verified by comparing the decompressed data with the effective data from multiple sources to confirm that the compression accuracy meets the requirements. Finally, high-precision standardized compressed data is output to the data service layer. In an optional implementation, the multi-source data can also be fused first, and the fused data can be anomaly repaired. This is not limited.

[0045] This invention designs a spatiotemporal synchronization, semantic standardization, anomaly detection and repair, fusion and dynamic compression process to reduce the accuracy loss of dynamic compression, ensure high precision and high consistency of output data, and provide stable and reliable data support for ADAS functional modules.

[0046] Furthermore, the multi-source data fusion engine is specifically used to acquire multi-source valid data output by the anomaly repair module. For valid data from each data source, it calculates the confidence level of each data source; combining the confidence levels of each data source, driving environment parameters, and the operating conditions of the advanced driver assistance system, it matches the corresponding data fusion strategy; using the matched data fusion strategy, it performs multi-source data fusion processing on the valid data from multiple sources to obtain preliminary fused data; it optimizes the preliminary fused data using a Kalman filter algorithm, and performs accuracy verification on the optimized fused data to obtain the data accuracy results of each fused data; finally, it outputs the fused data whose accuracy results meet the preset accuracy requirements to the dynamic compression module.

[0047] like Figure 8As shown, the multi-source data fusion engine of this invention can first acquire effective data from various sources such as LiDAR, cameras, millimeter-wave radar, high-precision maps, and V2X roadside units, calculate the dynamic confidence level of each data source, and quantify the reliability of the current data by combining historical errors, real-time data fluctuations, and historical reliability data of the data source. At the same time, it can simultaneously collect vehicle driving environment parameters and the actual operating conditions of the ADAS system, and match the corresponding data fusion strategy. For example, there are two built-in fusion strategies and applicable scenarios: 1. Weighted average fusion applicable scenario: all sensors are working normally, the external environment is good, there is no obvious interference, the vehicle is running in normal road conditions, and the ADAS is performing ordinary auxiliary functions such as ACC and LKA. Working logic: weights are assigned according to the real-time confidence level of each data source. The higher the confidence level, the greater the weight. The weighted average calculation is performed on the multi-source data to integrate the effective information of each source; 2. Bayesian fusion applicable scenario: complex environments such as rain, fog, strong light, and obstruction, or some sensors have small noise and high data uncertainty; it can also be used in tunnels, congested road sections, and other operating conditions. Working Logic: Based on a probabilistic inference model, combined with historical errors and current reliability of the data source, the uncertainty of the data is quantified, and probabilistic fusion of multi-source information is performed to weaken the impact of interfering data and improve the stability of the results. As an example, a matching data fusion strategy can then be used to perform multi-source data fusion processing on the effective multi-source data to obtain preliminary fused data. Then, a Kalman filter algorithm can be introduced to perform state estimation and short-term prediction on the preliminary fused data, achieving complementary fusion of multi-source data and further suppressing noise. For example, the distance accuracy of LiDAR and the image accuracy of a camera are complementary. Specifically, the introduction of the Kalman filter algorithm can include Kalman... The filtering process assigns weights to the sensor observations in the initial fused data according to their noise covariance. That is, the lower the noise and the higher the confidence level, the greater the weight. For the state vector of the same target, the distance measurement noise of the LiDAR is small, so it gets a high weight in the distance dimension; the pixel observation of the camera is more accurate in lateral position and edge recognition, so it gets a high weight in the corresponding state dimension. During the filtering process, the sensor observations are optimally weighted according to their respective noise covariance. The overall noise of the fused data after the complementarity is suppressed to the minimum. This is just an example. After the fusion is completed, the reliability of the fusion result is evaluated to ensure the accuracy of the fused data (e.g., ensuring that the noise is ≤0.01).

[0048] This invention improves scenario adaptability by dynamically calculating the confidence levels of each data source and combining a smart matching and fusion strategy of driving environment and ADAS conditions. Then, relying on multiple fusion strategies and Kalman filtering optimization, it effectively suppresses data noise, compensates for the defects of a single data source, stabilizes the accuracy of fused data, and improves the accuracy and environmental robustness of road reconstruction data.

[0049] In one optional implementation, the data service layer includes a backup service module and a resource scheduling center. The backup service module receives standardized compressed data output from the standardized processing layer, stores standardized compressed data with access frequencies exceeding a preset frequency threshold in a local cache, and synchronizes all standardized compressed data to the cloud for backup. The resource scheduling center identifies the current operating scenario of the advanced driver assistance system and the activated functional modules, determines the on-demand scheduling data corresponding to each functional module, and allocates scheduling priorities according to the needs of each functional module. The resource scheduling center also extracts the on-demand scheduling data corresponding to each functional module from the local cache, and pushes the on-demand scheduling data corresponding to each functional module to the application interface layer according to the corresponding scheduling priority and a preset update strategy. The preset update strategy is to select a real-time update strategy or an incremental update strategy based on the scheduling priority.

[0050] After receiving the standardized compressed data output by the standardized processing layer, the backup service module in the data service layer of this invention can store the standardized compressed data with an access frequency higher than a preset frequency threshold (such as real-time traffic conditions, vehicle attitude data, etc.) in a local cache to ensure a fast response when ADAS function modules are called and reduce data access latency. Simultaneously, it can synchronize all standardized compressed data to a cloud server for backup, achieving data security redundancy and preventing local data loss. It also supports cloud data backtracking and analysis. Through a dual storage strategy, it achieves secure data storage and efficient data retrieval. The resource scheduling center can identify the current operating scenario of the ADAS system and determine the currently activated ADAS function modules (such as NOA function in highway scenarios, urban scenarios, etc.). The system first identifies the AEB (Autonomous Emergency Braking) function in a road scenario, and then determines the data requirements of each functional module. Based on the scenario recognition results, the resource scheduling center performs scenario-based priority scheduling. It can allocate data priorities according to the importance and real-time requirements of each functional module. For example, the data priority of the emergency braking AEB function is higher than that of the ACC (Adaptive Cruise Control) function. Then, according to the scheduling priority, the corresponding update strategy can be selected. For example, a real-time update strategy is used for high priority, an incremental update strategy is used for medium priority, and a batch update strategy is used for low priority. Then, according to the update strategy, the on-demand scheduling data corresponding to each functional module can be pushed to the application interface layer through each interface to ensure the real-time and targeted data transmission, and achieve a scheduling delay of ≤3ms and a data update delay of ≤3s.

[0051] This invention designs a standardized data processing and dynamic scheduling scheme for the entire process. It innovatively adopts a data processing mechanism of "spatiotemporal synchronization + multi-strategy fusion," combining dynamic confidence calculation and Kalman filtering algorithms to achieve high-precision fusion of multi-source data, with post-fusion data noise ≤0.01. Simultaneously, it designs a categorized data compression strategy and a scenario-based scheduling mechanism, dynamically adjusting data processing priority and compression rate according to ADAS functional requirements. While ensuring data accuracy (compression accuracy loss ≤0.5%), it reduces computing power and bandwidth consumption, solving the problem of balancing EHR data accuracy and real-time performance in automotive scenarios.

[0052] The data service layer of this embodiment also integrates a version control module. This module manages the versions of all processed data, recording key information such as update events and processing methods to facilitate data backtracking and troubleshooting. Simultaneously, through cloud synchronization services, it achieves real-time synchronization between local and cloud data, ensuring data consistency and availability. Examples of the data caching, backup, and scenario-based scheduling processes in the data service layer can be found in [link to relevant documentation]. Figure 9 As shown.

[0053] This invention utilizes scene recognition combined with a refined priority scheduling mechanism to dynamically allocate scheduling priorities based on functional safety levels. Coupled with real-time and incremental update push methods, it achieves precise on-demand data distribution, effectively reducing computing power and bandwidth losses caused by invalid data transmission, while also reducing scheduling latency and improving the real-time performance and relevance of EHR data distribution.

[0054] In one optional implementation, the application interface layer includes an application programming interface gateway, a protocol adapter, and a permission management module. The application programming interface gateway adapts and converts the on-demand scheduling data corresponding to each functional module using interface protocols, transforming it into a data format recognizable by each functional module, and pushes it to the corresponding functional modules through adapted standardized interfaces. The protocol adapter, when a new functional module is added, accepts the interface protocol and data format of the new functional module, performs protocol parsing, format adaptation, and interface conversion on the on-demand scheduling data of the new functional module, and pushes the on-demand scheduling data to the new functional module. The permission management module controls the data access permissions of each functional module to control each functional module's access to on-demand scheduling data within its authorized scope.

[0055] The application interface layer designed in this embodiment of the invention includes an Application Programming Interface (API) gateway, a protocol adapter, and a permission management module. Specifically, after receiving the on-demand scheduling data corresponding to each functional module pushed by the data service layer, the API gateway performs interface protocol adaptation and format conversion on the on-demand scheduling data, converting the on-demand scheduling data into a data format recognizable by the corresponding functional module. Simultaneously, the permission management module controls data access permissions to ensure that each ADAS functional module can only access the data it needs, guaranteeing data security. After interface adaptation is complete, the application interface layer pushes the format-converted on-demand scheduling data to the corresponding ADAS functional modules through the adapted standardized interface. Examples include: NOA (Highway Navigation), ACC (Adaptive Cruise Control), LKA (Lane Keeping Assist), Autonomous Emergency Braking (AEB), Automatic Parking Assist (APA), Blind Spot Detection (BSD), and other ADAS functional modules. This provides high-precision, real-time data support for the normal operation of each functional module. An example of the interface between the application interface layer and each functional module can be found in [link to example]. Figure 10 As shown.

[0056] This invention adopts scenario-based priority scheduling and standardized API interface, with data scheduling latency ≤3ms. It can seamlessly connect with various ADAS functional modules, support the addition and iteration of functional modules, and achieve efficient data transmission and access control.

[0057] The application interface layer of this invention also includes a protocol adapter, specifically adapted to the iterative expansion scenarios of newly added ADAS function modules. When the vehicle ADAS system iterates and adds new function modules, such as automatic lane change assist and intersection passage assist, the protocol adapter can independently handle the communication interface protocol, data field definition, and data format specifications specific to the new function module. For the on-demand scheduling data output by the data service layer, the protocol adapter automatically completes targeted protocol parsing, field mapping, data format adaptation, and interface conversion processing, converting standardized general on-demand scheduling data into business data that the new function module can recognize and directly call. There is no need to modify the core architecture of the EHR module; it only needs to adapt to the interface requirements of the new function module through the protocol adapter to achieve seamless connection between the EHR module and the new function module, greatly improving the scalability of the EHR module and adapting to the needs of ADAS system function iteration and upgrade. The application interface layer also includes a monitoring and logging function module, which is used to record key information during the data transmission process in real time (such as data transmission time, data volume, and interface status), facilitating subsequent fault diagnosis and system optimization.

[0058] This invention achieves unified data format adaptation and accurate push for existing ADAS functions by integrating an application programming interface gateway. It leverages a protocol adapter for non-intrusive adaptation of new functional modules without altering the core EHR architecture, significantly enhancing the system's iterative expansion capabilities. Simultaneously, a permission management module implements hierarchical control over data access, preventing unauthorized data access and effectively improving the security, standardization, and compatibility of EHR data interaction.

[0059] In one optional implementation, the data access layer, standardization processing layer, data service layer, and application interface layer each have an independent fault monitoring module. Each layer's fault monitoring module monitors the operational status of its own layer and the data transmission status of the inter-layer data processing links in real time. When any fault monitoring module detects an anomaly in its corresponding layer, it performs fault location processing to determine the fault type. Based on the fault type, it executes a corresponding fault handling strategy. This strategy includes, if the fault type is a plugin fault, uninstalling the faulty plugin and loading a backup plugin; if the detected fault type is a functional module fault within the layer, replacing the faulty functional module with a backup functional module; and if the detected fault type is a preset alarm fault type, triggering an alarm signal and maintaining data push from the functional modules used for vehicle driving safety.

[0060] This invention employs independent fault monitoring modules deployed at each functional layer to monitor the operational status of each module and the integrity of the data processing link in real time. When the current fault monitoring module detects an anomaly in the corresponding layer, fault location analysis can be initiated to determine the fault type. The overall execution process includes: the monitoring module capturing the anomaly, collecting basic information such as time, link, and operating conditions, and reporting it; checking layer by layer along the data flow link to quickly determine the functional layer where the fault is located and achieve initial isolation; for the target layer, checking internal sub-modules, plug-ins, interfaces, and computing units to pinpoint the specific fault location; distinguishing between four types: plug-in faults, intra-layer functional module faults, cross-layer transmission faults, and critical core faults; log retention: isolating the fault link, saving fault logs to prevent fault propagation; and sending the location information to the processing module to execute the corresponding fault self-healing or emergency plan. In other words, through layered isolation design, the layer or module where the fault is located (such as plug-in faults, intra-layer functional module faults, and cross-layer data transmission faults) is accurately located, preventing the fault from spreading from a certain layer to the entire EHR module, while also preventing the impact on the normal operation of the ADAS functional module. This is just an example.

[0061] Based on different fault types, the fault monitoring module of this invention adopts corresponding processing strategies. If the fault type is a plug-in fault, the faulty plug-in can be immediately identified, safely uninstalled, and a backup plug-in can be automatically loaded to verify the plug-in's functionality. The entire process does not require restarting the EHR core system, and the core architecture remains unaffected, ensuring the continuity of the data processing chain. If the fault type is an intra-layer functional module fault (such as an anomaly in the multi-source data fusion engine of the standardized processing layer), an intra-layer anomaly self-healing mechanism can be activated to isolate the faulty module. Through module redundancy switching, the faulty module can be quickly replaced, and normal data processing can be restored after self-healing. If the fault type is a serious fault (such as a core module crash or data transmission interruption), an alarm signal is immediately triggered, and a fault log (recording the fault time, fault type, fault location, etc.) is retained to facilitate subsequent investigation by developers. At the same time, the data supply for core ADAS safety functions (such as AEB) is guaranteed to avoid security risks. After the fault is handled, the system automatically resumes normal operation. If it is a serious fault, the system resumes normal data processing after manual intervention and repair. This fault isolation and anomaly handling mechanism effectively improves the reliability and robustness of the EHR module, ensuring its long-term stable operation and adapting to the stringent operating requirements of in-vehicle ADAS systems. For an example of the EHR module's fault isolation and anomaly handling process, please refer to [link to example]. Figure 11 As shown.

[0062] This invention deploys independent fault monitoring and self-healing modules at each functional layer, enabling precise fault location and rapid recovery. Plugin and intra-layer faults do not require a core system restart, while critical faults ensure core functionality, improving system high availability. It also features a layered fault isolation and anomaly self-healing mechanism. Each functional layer has an independent fault monitoring module for precise fault location and isolation. Differentiated handling strategies are employed for plugin, intra-layer, and critical faults. Plugin and intra-layer faults can quickly self-heal without restarting the core system, ensuring stable operation of the EHR module and adapting to stringent automotive requirements.

[0063] This invention deploys independent fault monitoring modules in a four-layer architecture to achieve layered real-time status monitoring and link monitoring. It can accurately locate fault types at each layer and match differentiated fault tolerance strategies. For plug-in faults, intra-layer functional module faults, and alarm-type faults, it executes plug-in replacement, module redundancy fallback, and security keep-alive push mechanisms to achieve local fault isolation and prevent the cross-layer propagation of single-point faults. This effectively improves the fault tolerance and operational stability of the system, ensures the continuous availability of core functions under fault scenarios, and meets the safety operation requirements of high-level autonomous driving.

[0064] In a specific embodiment, the multi-source data processing system based on the electronic horizon reconstruction module designed in this invention can be directly deployed in the ADAS domain controller of an L3-level passenger vehicle ADAS system. Its practical application deployment diagram is shown below. Figure 12 As shown, no new dedicated hardware is required, and it can be adapted to existing vehicle hardware architectures, reducing deployment costs. The specific deployment method is as follows: Inside an L3-level passenger vehicle, the ADAS domain controller serves as the core carrier, deploying the layered decoupled architecture of the EHR module of this invention (data access layer, standardized processing layer, data service layer, and application interface layer); vehicle hardware (LiDAR, cameras, millimeter-wave radar, IMU / GNSS, V2X communication module, high-precision map module, etc.) serves as a multi-source data source, establishing connections with the data access layer of the EHR module to achieve real-time acquisition of multi-source data; the EHR module works collaboratively through each layer... After adapting, standardizing, integrating, and scheduling multi-source data, the system interfaces with the core ADAS functional modules (NOA highway navigation, automatic lane change, ACC adaptive cruise control, etc.) through the application interface layer, providing high-precision, real-time data support for each functional module. Based on the data output by the EHR module, the core ADAS functional modules send control commands to the vehicle actuators (steering, braking, and acceleration systems) to achieve Level 3 autonomous driving functionality. At the same time, the EHR module's data service layer establishes a connection with the cloud server to achieve cloud backup, remote monitoring, and data analysis, facilitating vehicle maintenance and functional optimization.

[0065] The advantages of this deployment scheme are: First, it has strong compatibility, allowing direct deployment on existing ADAS domain controllers (such as the TDA4VH platform) without requiring modifications to the vehicle hardware architecture; second, it has good scalability, supporting rapid adaptation to new data sources and ADAS functional modules, meeting the needs of ADAS system function iteration and upgrades; third, it has high reliability, ensuring long-term stable operation of the EHR module and guaranteeing the safety of autonomous driving functions through layered fault isolation and anomaly handling mechanisms; and fourth, it has high accuracy, with output data noise ≤0.01 and scheduling latency ≤3ms through a multi-source data high-precision fusion mechanism, meeting the stringent data processing requirements of L3 autonomous driving. Practical application verification shows that the multi-source data processing method and apparatus of this invention can effectively solve the technical pain points of traditional EHR modules, improve the reliability, safety, and scalability of ADAS systems, and has high engineering application value. For detailed explanations, please refer to the above embodiments, which will not be repeated here.

[0066] According to an embodiment of the present invention, a multi-source data processing method based on an electronic horizon reconstruction module is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0067] This embodiment provides a multi-source data processing method based on an electronic horizon reconstruction module, applied to the multi-source data processing system based on the electronic horizon reconstruction module described above. This system is deployed within the domain controller of an advanced driver assistance system and includes independent data access layers, a standardized processing layer, a data service layer, and an application interface layer, all decoupled from each other through standardized interfaces. Figure 13 This is a flowchart of a multi-source data processing method based on an electronic horizon reconstruction module according to an embodiment of the present invention, such as... Figure 13 As shown, the process includes the following steps: Step S1301: Obtain multi-source data, adapt the multi-source data to the plugin, process the data using the adapted plugin, and output standardized raw data.

[0068] Step S1302 involves performing data purification, multi-source data fusion, and dynamic compression on the standardized raw data to output standardized compressed data.

[0069] Step S1303: Store and manage the standardized compressed data, and determine the on-demand scheduling data and scheduling priority corresponding to each functional module according to the currently activated functional module of the advanced driver assistance system, and output the on-demand scheduling data corresponding to each functional module according to the scheduling priority.

[0070] Step S1304: Convert the on-demand scheduling data corresponding to each functional module into a recognizable data format and push it to the corresponding functional module respectively.

[0071] This invention acquires multi-source data and, based on a pre-adapted registry of plugins for various vehicle data sources, adapts the multi-source data to plugins. The adapted plugins process the data, outputting standardized raw data. This standardized raw data then undergoes data purification (including but not limited to spatiotemporal synchronization and semantic standardization), multi-source data fusion, and dynamic adjustment of the compression ratio based on the current vehicle operating status to obtain lightweight, standardized compressed data. The standardized compressed data is then stored and managed. High-frequency standardized compressed data (such as real-time traffic conditions and vehicle attitude data) can be cached, while low-frequency standardized compressed data (such as static traffic data) can be stored separately. (e.g., low-speed storage, as an example only); then, the activation status of ADAS functions can be monitored in real time, dynamically matching the data requirements and scheduling priorities of each functional module. For example, the priority of emergency AEB function is higher than that of ACC adaptive cruise control function. According to the scheduling priority of each functional module, the on-demand scheduling data corresponding to each functional module can be output. Finally, targeted format conversion is performed according to the data parsing protocol and format requirements of different functional modules, converting the on-demand scheduling data into a data format that the functional module can recognize. After the format conversion is completed, the data can be accurately pushed to the corresponding ADAS functional module, supporting the stable and accurate operation of each function, and fully meeting the core requirements of L3 and above autonomous driving. For detailed explanation, please refer to the above embodiment, which will not be repeated here.

[0072] This solution achieves decoupling of the data processing link through layered decoupling and modular design (such as plug-in data access layer, independent functional division of each layer, and standardized interface design). Combined with multi-source data high-precision fusion, fault isolation, and dynamic scheduling mechanisms, it comprehensively improves the scalability, reliability, and robustness of the EHR module while ensuring the real-time performance (scheduling delay ≤3ms) and accuracy (fused data noise ≤0.01). It can be directly deployed on existing ADAS domain controllers without adding new dedicated hardware, and is suitable for the actual application needs of L3 and above passenger vehicle ADAS systems.

[0073] This embodiment also provides a vehicle, such as Figure 14 As shown, the vehicle includes a multi-source data processing system based on an electronic horizon reconstruction module.

[0074] Figure 15 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0075] The following is a detailed reference. Figure 15This diagram illustrates a suitable structural schematic for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1502 or a program loaded from memory 1508 into random access memory (RAM) 1503. The RAM 1503 also stores various programs and data required for the operation of the electronic device. The processor 1501, ROM 1502, and RAM 1503 are interconnected via a bus 1504. An input / output (I / O) interface 1505 is also connected to the bus 1504.

[0076] Typically, the following devices can be connected to I / O interface 1505: input devices 1506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1509. Communication device 1509 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 15 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0077] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 1509, or installed from a memory 1508, or installed from a ROM 1502. When the computer program is executed by the processor 1501, it performs the functions defined in the multi-source data processing method based on the electronic horizon reconstruction module of the embodiments of the present invention.

[0078] Figure 15 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0079] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the multi-source data processing method based on the electronic horizon reconstruction module shown in the above embodiments is implemented.

[0080] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0081] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined herein.

Claims

1. A multi-source data processing system based on an electronic horizon reconstruction module, characterized in that, The system is deployed within the advanced driver assistance system domain controller and includes independent data access, standardized processing, data service, and application interface layers that are decoupled from each other through standardized interfaces. The data access layer is used to establish connections with multi-source data sources in vehicles, adapt multi-source data to plugins, process the data using the adapted plugins, and output standardized raw data. The standardization processing layer is used to receive the standardized raw data output by the data access layer, and to perform data purification, multi-source data fusion and dynamic compression on the standardized raw data, and output standardized compressed data. The data service layer is used to receive the standardized compressed data output by the standardized processing layer, store and manage the standardized compressed data, and determine the on-demand scheduling data and scheduling priority corresponding to each functional module according to the currently activated functional module of the advanced driver assistance system, and output the on-demand scheduling data corresponding to each functional module according to the scheduling priority. The application interface layer is used to receive the on-demand scheduling data output by the data service layer, convert the on-demand scheduling data corresponding to each functional module into a recognizable data format, and push it to the corresponding functional module respectively.

2. The system of claim 1, wherein, The data access layer includes a plugin management center and a data verification unit. The plugin management center integrates a plugin registry to record the mapping relationship between each data source and the adapted plugins. The plugin management center is used to receive multi-source data and search the plugin registry based on the currently accessed data source type to determine whether the current data source has a matching first plugin set. The first plugin set includes at least a protocol parsing plugin and a data source adaptation plugin. If a matching first set of plugins exists in the plugin registry, each plugin is invoked to perform protocol parsing and format conversion on the data output from the current data source to obtain data in a unified format. The data verification unit is used to verify the validity of the data after it has been formatted in a unified manner, and pushes the standardized raw data that has passed the verification to the standardization processing layer.

3. The system of claim 2, wherein, The data access layer also includes a plugin development unit, wherein, The plugin development unit is used to obtain the protocol information of the new data source and develop a second set of plugins corresponding to the new data source based on the preset plugin standard template. The plugin development unit is used to package the metadata corresponding to the developed second plugin set and submit it to the plugin management center for registration. The plugin management center is used to verify the second plugin set, and after the verification is passed, it loads the code and dependencies of the second plugin set and updates them to the plugin registry. The verification includes at least plugin version verification and plugin integrity verification.

4. The system of claim 1, wherein, The standardized processing layer includes a data processing module, an anomaly repair module, a multi-source data fusion engine, and a dynamic compression module. The data processing module is used to perform spatiotemporal and sampling frequency synchronization processing and semantic standardization processing on the standardized raw data, and output standardized data. The anomaly repair module is used to detect anomalies in the standardized data, and after detecting anomalies, it uses corresponding anomaly repair strategies to repair the anomalies, and outputs multi-source valid data after verifying the repair results. The multi-source data fusion engine is used to perform multi-source data fusion processing on the multi-source effective data and output fused data; The dynamic compression module is used to evaluate the accuracy of the fused data, select an appropriate compression strategy based on the accuracy evaluation results, and output standardized compressed data.

5. The system of claim 4, wherein, The multi-source data fusion engine is specifically used for Obtain valid data from multiple sources output by the anomaly repair module, and calculate the confidence level of each data source for the valid data from each data source. By combining the confidence levels of each data source, driving environment parameters, and the operating conditions of the advanced driver assistance system, a corresponding data fusion strategy is matched. A matching data fusion strategy is used to perform multi-source data fusion processing on effective multi-source data to obtain preliminary fused data; The initial fused data is optimized using the Kalman filter algorithm, and the accuracy of the optimized fused data is verified to obtain the data accuracy results of each fused data. The fused data that meets the preset accuracy requirements is output to the dynamic compression module.

6. The system of claim 1, wherein, The data service layer includes a backup service module and a resource scheduling center, wherein... The backup service module is used to receive standardized compressed data output by the standardized processing layer, store standardized compressed data with access frequency higher than a preset frequency threshold in the local cache, and synchronize all standardized compressed data to the cloud for backup. The resource scheduling center is used to identify the current operating scenario of the advanced driver assistance system and the activated functional modules, determine the on-demand scheduling data corresponding to each functional module, and allocate scheduling priorities according to the needs of each functional module. The resource scheduling center is also used to extract the on-demand scheduling data corresponding to each functional module from the local cache, and push the on-demand scheduling data corresponding to each functional module to the application interface layer according to the corresponding scheduling priority and preset update strategy. The preset update strategy is to select a real-time update strategy or an incremental update strategy according to the scheduling priority.

7. The system of claim 1, wherein, The application interface layer includes an application programming interface gateway, a protocol adapter, and a permission management module, wherein... The application programming interface gateway is used to adapt the interface protocol and convert the format of the on-demand scheduling data corresponding to each functional module, convert it into a data format that each functional module can recognize, and push it to the corresponding functional module through the adapted standardized interface. The protocol adapter is used to accept the interface protocol and data format of the new functional module when a new functional module is added. It performs protocol parsing, format adaptation and interface conversion on the on-demand scheduling data of the new functional module so as to push the on-demand scheduling data to the new functional module. The permission management module is used to control the data access permissions of each functional module, so as to control each functional module to access the on-demand scheduling data within its authorized scope.

8. The system of claim 1, wherein, The data access layer, standardization processing layer, data service layer, and application interface layer each have independent fault monitoring modules deployed, among which, The fault monitoring module of each layer is used to monitor the operating status of its own layer and the data transmission status of the data processing link between layers in real time; When any fault monitoring module detects an anomaly in the corresponding layer, it performs fault location processing to determine the fault type. Based on the fault type, a corresponding fault handling strategy is executed. The fault handling strategy includes: if the fault type is a plug-in fault, uninstalling the faulty plug-in and loading a backup plug-in; if the fault type is an intra-layer functional module fault, replacing the faulty functional module with a backup functional module; if the detected fault type is a preset alarm fault type, triggering an alarm signal and maintaining the data push of the functional module for vehicle driving safety.

9. A multi-source data processing method based on an electronic horizon reconstruction module, characterized in that, The method is applied to the multi-source data processing system based on the electronic horizon reconstruction module as described in any one of claims 1-8, wherein the system is deployed within the domain controller of an advanced driver assistance system, and includes an independent data access layer, a standardized processing layer, a data service layer, and an application interface layer that are decoupled from adjacent layers through standardized interfaces; the method includes: Acquire multi-source data, adapt the multi-source data to plugins, process the data using the adapted plugins, and output standardized raw data. The standardized raw data is subjected to data purification, multi-source data fusion and dynamic compression to output standardized compressed data; The standardized compressed data is stored and managed, and the on-demand scheduling data and scheduling priority corresponding to each functional module are determined according to the currently activated functional modules of the advanced driver assistance system. The on-demand scheduling data corresponding to each functional module is output according to the scheduling priority. The on-demand scheduling data corresponding to each functional module is converted into a recognizable data format and pushed to the corresponding functional module respectively.

10. A vehicle characterized by comprising: The vehicle includes the multi-source data processing system based on the electronic horizon reconstruction module as described in any one of claims 1-8.

11. An electronic device, comprising: include: The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes these computer instructions to perform the multi-source data processing method based on the electronic horizon reconstruction module as described in claim 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the multi-source data processing method based on the electronic horizon reconstruction module as described in claim 9.

13. A computer program product, characterized in that, It includes computer instructions for causing a computer to execute the multi-source data processing method based on the electronic horizon reconstruction module as described in claim 9.

Images