Vehicle panoramic portrait construction method and device and server

Abstract

The invention provides a vehicle panoramic portrait construction method and device and a server, and relates to the technical field of vehicle supervision, and the method comprises the steps: obtaining multi-source vehicle data which comprises vehicle static attribute data, vehicle dynamic GPS data, vehicle real-time CAN bus data and vehicle key module state data; performing data association fusion processing on the multi-source vehicle data by taking the vehicle ID and the timestamp as a unified association key to obtain target vehicle data; and on the basis of the target vehicle data, a vehicle panoramic portrait of a three-layer structure for real-time supervision is generated, a unified supervision view is constructed by using the vehicle panoramic portrait, vehicle-road collaborative visual display is carried out, and the vehicle panoramic portrait comprises an attribute layer, a dynamic layer and a state layer. According to the invention, the accuracy and efficiency of vehicle supervision can be significantly improved.

Description

Technical Field

[0001] This invention relates to the technical field of vehicle monitoring, and in particular to a method, apparatus, and server for constructing a panoramic vehicle image. Background Technology

[0002] Currently, the relevant technologies suggest that existing vehicle monitoring methods mainly use independent equipment channels and separate data transmission to collect vehicle data, and rely on manual comparison of coordinates and manual data splicing to passively respond to faults. However, the vehicle data in the above schemes is fragmented, lacking unified integration and correlation analysis capabilities, and the monitoring view is fragmented, failing to achieve visualization of the collaborative status between vehicles and roadside services, resulting in low accuracy and efficiency of vehicle monitoring. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a method, apparatus and server for constructing a panoramic image of a vehicle, which can significantly improve the accuracy and efficiency of vehicle monitoring.

[0004] In a first aspect, embodiments of the present invention provide a method for constructing a vehicle panoramic profile. The method includes: acquiring multi-source vehicle data, wherein the multi-source vehicle data includes: vehicle static attribute data, vehicle dynamic GPS data, vehicle real-time CAN bus data, and vehicle key module status data; performing data association and fusion processing on the multi-source vehicle data using vehicle ID and timestamp as unified association keys to obtain target vehicle data; and generating a three-layer vehicle panoramic profile for real-time monitoring based on the target vehicle data, so as to construct a unified monitoring view and perform vehicle-road cooperative visualization using the vehicle panoramic profile, wherein the vehicle panoramic profile includes: an attribute layer, a dynamic layer, and a status layer.

[0005] In one implementation, the step of performing data association and fusion processing on multi-source vehicle data using vehicle ID and timestamp as unified association keys to obtain target vehicle data includes: associating data with the same vehicle ID and timestamp from the multi-source vehicle data, and performing time-series alignment processing, anomaly cleaning processing, and health calculation processing on the associated data to achieve data association and fusion and obtain target vehicle data.

[0006] In one implementation, the steps of performing time-series alignment, anomaly cleaning, and health calculation on the associated data to obtain target vehicle data include: aligning the timestamps of the associated data, removing invalid data through anomaly cleaning, and filling in missing data through forward padding and backward validation to obtain valid data; performing health calculation on the valid data to obtain health scores at each time point, and generating a health trend curve using the health scores; and determining the target vehicle data based on the valid data and the health trend curve.

[0007] In one implementation, after the step of generating a three-layer vehicle panoramic image for real-time monitoring based on target vehicle data, the process includes: performing real-time incremental update processing and periodic full update processing on the vehicle panoramic image to perform vehicle monitoring processing based on the updated vehicle panoramic image.

[0008] In one implementation, the steps of performing real-time incremental update processing and timed full update processing on the vehicle panoramic image include: when new vehicle dynamic GPS data, vehicle real-time CAN bus data or vehicle key module status data are received, the dynamic layer and status layer of the vehicle panoramic image are updated in real-time using the newly received data, and at preset time intervals, the vehicle panoramic image is fully updated by comparing the consistency of static attribute data with the basic database and the integrity of dynamic data with the original collected data.

[0009] In one implementation, the steps of constructing a unified regulatory view using a vehicle panoramic image and visualizing vehicle-road cooperation include: generating an image information panel and a health trend chart using the vehicle panoramic image and the health trend curve in the target vehicle data, and setting a dynamic trajectory map of the vehicle between the image information panel and the health trend chart to construct a unified regulatory view.

[0010] In one implementation, after the step of constructing a unified regulatory view, the method includes: marking the road test service range based on the unified regulatory view, and setting a label corresponding to the spatial relationship at the vehicle icon according to the spatial relationship between the vehicle's latitude and longitude and the road test service range, so as to perform a visual display of vehicle-road cooperation.

[0011] Secondly, embodiments of the present invention also provide a vehicle panoramic image construction apparatus, the apparatus comprising: a data acquisition module for acquiring multi-source vehicle data, wherein the multi-source vehicle data includes: vehicle static attribute data, vehicle dynamic GPS data, vehicle real-time CAN bus data, and vehicle key module status data; a data fusion module for performing data association and fusion processing on the multi-source vehicle data using vehicle ID and timestamp as unified association keys to obtain target vehicle data; and an image generation module for generating a three-layer vehicle panoramic image for real-time monitoring based on the target vehicle data, so as to construct a unified monitoring view and perform vehicle-road cooperative visualization using the vehicle panoramic image, wherein the vehicle panoramic image includes: an attribute layer, a dynamic layer, and a status layer.

[0012] Thirdly, embodiments of the present invention also provide a server, including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement any of the methods provided in the first aspect.

[0013] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement any of the methods provided in the first aspect.

[0014] The embodiments of the present invention bring the following beneficial effects: This invention provides a method, apparatus, and server for constructing a panoramic vehicle image. After acquiring multi-source vehicle data, the method performs data association and fusion processing on the multi-source vehicle data using vehicle ID and timestamp as unified association keys to obtain target vehicle data. Based on the target vehicle data, a three-layer panoramic vehicle image for real-time monitoring is generated. This panoramic vehicle image is used to construct a unified monitoring view and perform vehicle-road cooperative visualization. This invention can significantly improve the accuracy and efficiency of vehicle monitoring.

[0015] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] 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.

[0018] Figure 1 A schematic diagram of an existing vehicle monitoring method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a method for constructing a panoramic image of a vehicle provided in an embodiment of the present invention; Figure 3 A schematic diagram illustrating the specific process of a method for constructing a panoramic image of a vehicle provided in an embodiment of the present invention; Figure 4 A schematic diagram of a device for constructing a panoramic image of a vehicle provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a server provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. 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.

[0020] See Figure 1 The diagram illustrates an existing vehicle monitoring method. Currently, existing technologies mainly focus on the decentralized collection, independent storage, single processing, and fragmented display of vehicle and roadside equipment data, failing to form a closed loop of data fusion, correlation analysis, and collaborative display. The specific technical logic and limitations are as follows: I. Data Acquisition Layer: Distributed acquisition, lacking a unified standard. Existing technologies for data acquisition from vehicles and roadside equipment employ an independent channel for each device and separate data transmission, failing to establish a unified acquisition system. This presents a significant gap compared to the requirements of dynamic data access or processing, which needs to cover both static and dynamic states of vehicles and the full range of roadside equipment status. 1. Vehicle data collection: Vehicle static data (vehicle model, license plate number, autonomous driving level): These are collected through manual entry or a single interface from the vehicle manufacturer, focusing only on basic attributes and not linked to dynamic data (such as GPS and CAN) with collection identifiers.

[0021] Vehicle dynamic GPS data (latitude and longitude, speed, heading angle): transmitted via an independent TCP protocol through the onboard GPS module, with a collection frequency of only once per second, and no corresponding CAN data (such as brake and accelerator) synchronous collection mechanism.

[0022] Vehicle CAN data (throttle opening, brake status, steering wheel angle): uploaded separately via CAN acquisition card using the SAEJ1939 protocol, recording only the raw data, without timestamps or GPS data alignment.

[0023] Vehicle module status (GPS, camera, radar status): Collected through the vehicle self-test interface, recorded only as normal or abnormal, without any health quantification data such as GPS signal strength or camera frame rate.

[0024] 2. Roadside Equipment Data Acquisition: Roadside equipment data (RSU location, camera online status, radar fault information): is uploaded independently through the equipment's built-in management interface. Only the equipment's own status (such as RSU online or offline) is collected. There is no data on the equipment's service range (such as RSU coverage radius), nor is there any data associated with vehicle location data.

[0025] Therefore, the data collection dimensions of the data acquisition layer are incomplete (lacking health measurement data) and the formats are not uniform (no unified protocol or identifier), which creates obstacles for subsequent data fusion.

[0026] II. Data Storage Layer: Independent Databases, No Association Mechanism. Current technology stores various types of collected data in scattered independent databases without establishing a unified association key, which is inconsistent with the data management center's requirement to integrate vehicle data, roadside video data, and event data. 1. Vehicle-related storage: The vehicle static database only stores basic attributes such as vehicle model and license plate number, and has no vehicle ID field that is associated with the dynamic database.

[0027] GPS track database: only stores location data such as latitude, longitude, and speed, without corresponding timestamps or association with CAN data and module status data.

[0028] CAN data cache library: Stores raw CAN data only in list form, without vehicle ID and timestamp identifiers, and cannot be matched with GPS tracks.

[0029] Module status table: only records the module name and whether it is normal or abnormal, without timestamps or vehicle IDs, and cannot trace the vehicle's location and driving behavior when the abnormality occurred.

[0030] 2. Roadside Equipment Storage: The roadside equipment database only stores the latitude and longitude locations and online status of RSUs and cameras. It does not contain data on the service range of the equipment (such as the coverage radius of the RSU) or index fields associated with vehicle locations.

[0031] Therefore, the data storage layer suffers from data silos and lacks a correlation mechanism, making it impossible to meet the basic requirement of multi-source data correlation queries.

[0032] III. Data Processing Layer: Single Service, No Integrated Analysis. Existing technologies only process stored data of a single type, failing to achieve multi-source data correlation and fusion. This is significantly different from the requirements of dynamic data access or processing, which needs to support real-time processing and intelligent analysis. 1. Vehicle data processing: Static data query service: It only supports searching for vehicle model and autonomous driving level by license plate number, and cannot query the real-time GPS trajectory or historical CAN data of the vehicle at the same time.

[0033] GPS trajectory mapping service: It can only generate historical vehicle trajectories based on GPS data, and cannot display CAN data and module status within the trajectory segment.

[0034] CAN Data List Service: Displays raw CAN data only in chronological order, without timestamps or GPS data alignment, making it impossible to determine the vehicle location corresponding to a specific CAN data.

[0035] Module status alert service: Only generates text alerts when a module is abnormal, without module health metrics and trend analysis.

[0036] 2. Roadside equipment processing: The roadside equipment monitoring service only displays the online rate and failure rate of RSUs and cameras, without calculating the service range of the equipment, and cannot determine whether a vehicle is within the service coverage of the roadside equipment.

[0037] Therefore, the data processing layer has a simplistic processing logic and lacks the ability to perform multi-source data correlation analysis, which fails to support the needs of vehicle status monitoring, trajectory analysis, and intelligent management.

[0038] IV. Regulatory Display Layer: Fragmented View, Lack of Collaborative Presentation. Current regulatory displays primarily rely on independent multi-page presentations, failing to create a unified regulatory view. This is completely incompatible with the monitoring and management center's requirement to provide an overview of the overall situation and the collaborative status between vehicles and roadside facilities. 1. Vehicle-related views: Vehicle Attributes Page: This page needs to be opened separately. It only displays static attributes (vehicle model, license plate number) and does not show dynamic data (GPS, CAN).

[0039] GPS track map page: needs to be opened separately, only displays the vehicle's location trajectory, without overlay display of CAN data or module status.

[0040] CAN data display panel: needs to be opened separately, only lists CAN data, without corresponding GPS track segments, and cannot intuitively determine the driving scenario corresponding to the data.

[0041] Module status alarm bar: Only pop-up text indicates the abnormality, without contextual information such as vehicle location and speed when the abnormality occurred.

[0042] 2. Roadside Equipment View: The roadside equipment distribution map page needs to be opened separately. It only marks the location of RSUs and cameras with icons, without visualizing the service range of the equipment, and it cannot be linked with the vehicle location to display the vehicle-road cooperative status.

[0043] Therefore, the view of the regulatory display layer is fragmented, requiring regulators to frequently switch pages and making it impossible to intuitively grasp the coordination status between vehicles and roadside service areas.

[0044] V. User Operation Layer: Manual interaction, inefficient and prone to errors. Current regulatory decisions rely entirely on manual operation, contradicting the goals of intelligent management and efficient supervision. 1. Data association relies on manual intervention: Supervisory personnel need to manually record the target vehicle ID, open the vehicle attribute page, GPS trajectory map page, and CAN data panel in sequence, and manually compare the timestamps to piece together the vehicle's operating status; 2. Vehicle-road cooperative judgment relies on manual operation: If it is necessary to determine whether a vehicle is within the coverage of the RSU service, it is necessary to manually check the RSU location and coverage radius in the roadside equipment distribution map and then compare it with the vehicle's latitude and longitude in the GPS trajectory map. The operation is cumbersome and prone to errors. 3. Decision-making relies on experience: Module fault analysis requires manual correlation of module status alarm time, CAN data, braking time, and GPS trajectory location. There is no automatic analysis function in the system, resulting in low decision-making efficiency and high error rate.

[0045] Therefore, the manual operation of the user layer cannot meet the technical requirements of the intelligent connected vehicle cloud control platform to support efficient supervision and emergency response.

[0046] In summary, the existing technology has the following drawbacks: 1. Data fragmentation: Vehicle static, dynamic, module status, and roadside equipment data are stored separately without a unified association key, making it impossible to form a complete data chain, which contradicts the data management center's requirement for efficient storage and management of multi-source data; 2. Fragmented view: The monitoring view is independently divided according to data type, without a unified map to integrate vehicle and roadside collaborative status, which contradicts the monitoring management center's requirement to display the overall situation through an overview; 3. Passive analysis: There is no function for multi-source data correlation analysis, module health measurement, or automatic judgment of collaborative status, which contradicts the requirement for dynamic data access or processing to support intelligent analysis and ensure operational safety.

[0047] Specifically, 1. Existing technologies suffer from fragmented vehicle data and a lack of unified integration and correlation analysis capabilities: In existing technologies, vehicle static attributes (vehicle type, autonomous driving level), dynamic GPS data, real-time CAN bus data, and key module status data are scattered across different functional modules, with no interconnected relationships between the data. For example, when viewing a vehicle's dynamic trajectory, it is impossible to simultaneously obtain CAN bus data (such as brake trigger time and throttle opening changes) and module health status (such as whether the radar exhibits abnormalities during trajectory driving). This makes it impossible to comprehensively analyze the correlation between vehicle driving behavior and equipment status from the dimensions of attributes, dynamics, and status, making it difficult to form a complete vehicle operation profile and affecting the accuracy of regulatory decisions.

[0048] Based on this, the method for constructing a panoramic vehicle image provided by this invention adopts full-dimensional data coverage and access, as well as data association storage and linked display: Comprehensive data coverage and access: Integrating vehicle static attributes, dynamic GPS data, real-time CAN bus data, and key module status data to form a complete data acquisition system. Static attributes include vehicle model and autonomous driving level; dynamic GPS data covers latitude and longitude, speed, heading angle, and travel trajectory; real-time CAN bus data includes throttle, brake, steering wheel angle, turn signals, and gear status; and key module status includes the operating status of GPS, cameras, and radar.

[0049] Data association, storage, and linked display: The aforementioned scattered data are uniformly linked to the core module of the vehicle panoramic portrait, enabling linked access between data. For example, when viewing the vehicle's dynamic GPS trajectory (such as a certain driving path), CAN bus data (such as the number of brake triggers and throttle opening changes during the trajectory time period) and the status of key modules (such as whether the radar is in normal working condition during the trajectory driving) can be retrieved simultaneously and displayed on the same interface in the form of trajectory and data panels, forming a complete association analysis dimension of attributes, dynamics, and status, solving the problem of data fragmentation.

[0050] 2. Existing technologies suffer from fragmented regulatory views, failing to visualize the collaborative status of vehicles and roadside services: Current technologies can only display vehicle locations or roadside service ranges (such as RSU coverage areas and roadside equipment distribution) separately, without integrating their collaborative relationship into a unified map view. Supervisory personnel must manually switch between the vehicle monitoring module and the roadside equipment module, comparing the vehicle's latitude and longitude with the roadside service range coordinates to determine whether the vehicle is within roadside service coverage and can receive traffic event information pushed by the roadside equipment. This process is cumbersome, prone to errors, and lacks real-time, intuitive understanding of the collaborative operation of vehicles and roadside facilities, hindering efficient supervision in vehicle-road cooperative scenarios.

[0051] Based on this, the method for constructing a panoramic vehicle image provided by this invention employs roadside service range data access and map annotation, as well as real-time mapping of the collaborative status between vehicles and roadside services: Roadside service range data access and map annotation: Access the deployment location and service coverage data of roadside devices (RSU, roadside cameras, edge computing units), accurately mark the roadside service boundaries such as RSU coverage area and roadside camera monitoring range on the regulatory map, and optimize the visualization of service range by differentiating road levels (national highways, expressways, urban expressways, etc.).

[0052] Real-time mapping of vehicle and roadside service collaboration status: In a unified map view, the real-time location of vehicles (based on GPS data) is matched with the roadside service range using coordinates, and the collaboration relationship is intuitively displayed through color indicators and status labels. For example, when a vehicle is within the RSU coverage area, it is marked with a green highlighted vehicle icon and a roadside service access label, and traffic event information pushed by roadside devices (such as forward congestion alerts) is displayed simultaneously; when a vehicle is outside the service range, it is marked with a gray vehicle icon and a non-access to roadside services label, realizing integrated visualization of vehicle location, roadside service range, and collaboration status. The vehicle-road collaboration situation can be grasped in real time without switching modules, solving the problem of view fragmentation.

[0053] See Figure 2The diagram shows a method for constructing a panoramic image of a vehicle, which mainly includes the following steps S202 to S206: Step S202: Obtain multi-source vehicle data, which includes: vehicle static attribute data, vehicle dynamic GPS data, vehicle real-time CAN bus data, and vehicle key module status data.

[0054] In one implementation, multi-source data access employs a standardized gateway and fixed protocol design: vehicle static attributes are synchronized via an HTTP interface, GPS or CAN data is transmitted via MQTT protocol and 4G or 5G, module status data is accessed via TCP or IP protocol, and the transmission link relies on the public network or a dedicated 4G or 5G network to ensure data real-time performance. Furthermore, for the two core components of the data access protocol and transmission link, the following alternative solutions can be adopted to achieve efficient access and real-time transmission of multi-source data: 1. Data access protocol replacement: Vehicle static attribute data: The HTTP interface has been replaced with the FTP protocol, and the data is synchronized to the platform via timed file transfer. The file format retains the JSON structured design to ensure that the fields are consistent with the original solution. This is suitable for scenarios with low static data update frequency and reduces the pressure on interface calls.

[0055] GPS or CAN data: The MQTT protocol is replaced with the CoAP protocol, and the transmission format is optimized for low bandwidth and high latency scenarios. The CAN data acquisition frequency of 10 times or per second is still maintained. The packet loss rate is ensured to be no more than 0.1% through data fragmentation and retransmission mechanisms, which meets the requirement that the latency of vehicle reporting data is no more than 20ms.

[0056] Module status data: The TCP or IP protocol is replaced by the WebSocket protocol to establish a long connection and push module health data in real time, reducing the connection overhead of TCP three-way handshake, which is especially suitable for high-frequency status interaction scenarios between roadside equipment and the platform.

[0057] 2. Transmission link replacement: The 4G or 5G public network is replaced by a hybrid link of local caching of edge computing units and fiber optic backhaul: vehicle data is first transmitted to the roadside edge computing unit in real time. After local data preprocessing, it is transmitted back to the platform in batches through the fiber optic link, reducing the bandwidth occupation of public network transmission. At the same time, the edge computing unit caches nearly 1 hour of data locally to avoid data loss caused by public network interruption.

[0058] Since both CoAP and WebSocket protocols are industrial-grade standard protocols with mature open-source libraries, those skilled in the art can directly adapt them. The local caching function of the edge computing unit can be implemented based on the data processing and storage capabilities of the edge computing unit without the need for additional hardware. In addition, the data access latency of the above alternative solutions is still no more than 20ms and the packet loss rate is no more than 0.1%. They are also more adaptable to low-bandwidth, high-latency scenarios, while reducing the data processing pressure on the platform and meeting the goal of efficient access to multi-source dynamic data.

[0059] Therefore, by standardizing the access to and integrating multi-source vehicle data in all dimensions, the fragmented data collection problem of existing technologies can be overcome. Through a standardized data access gateway, static vehicle attributes (vehicle type, autonomous driving level), dynamic GPS data (latitude and longitude, speed, heading angle), real-time CAN bus data (accelerator, brake, steering wheel angle, etc.), and key module status data (GPS signal strength, camera frame rate, radar detection accuracy) can be uniformly accessed. It is also compatible with multiple protocols such as HTTP, MQTT, TCP, and IP to ensure data format uniformity and collection integrity. This lays the data foundation for building a panoramic vehicle profile, thereby solving the problems of scattered data storage and lack of linkage. The data integration efficiency is improved by no less than 90%, providing complete data support for subsequent correlation analysis.

[0060] Step S204: Using vehicle ID and timestamp as unified association keys, perform data association and fusion processing on multi-source vehicle data to obtain target vehicle data.

[0061] In one implementation, data association and fusion uses vehicle ID and timestamp as the association key, and is achieved through a three-step logic of time-series alignment, anomaly cleaning, and health calculation to ensure the accuracy of data linkage analysis. Furthermore, for the two core logics of time-series alignment and health calculation, the following alternative solutions can still be used to achieve multi-source data association and fusion and module health measurement: 1. Replacement of timing alignment logic: Alternatively, time window aggregation can be used: A 100ms time window is set, and the GPS data, module status data, and CAN data within this window are automatically aggregated into a single set of associated data. Each set of data is assigned a unique association ID to avoid errors that may be introduced by interpolation calculations. For example, within time windows 10:00:00.000 and 10:00:00.100, the GPS latitude and longitude, module health score, and 10 CAN data entries within that window are automatically associated. When monitoring personnel view any single CAN data entry, they can directly retrieve the GPS and module data from the same window.

[0062] 2. Replacement of health calculation logic: This can be replaced with dynamic weighting: the module health weights are automatically adjusted based on the vehicle's driving scenario, instead of using the fixed weights of 30% for GPS, 30% for camera, and 40% for radar in the original solution. For example: in highway scenarios, the radar module weight is increased to 60%, the GPS weight is reduced to 20%, and the camera weight is reduced to 20%, adapting to the core role of radar in high-speed driving; in urban road scenarios, the camera module weight is increased to 50%, the radar weight is reduced to 30%, and the GPS weight is reduced to 20%, adapting to the complex traffic environment in cities.

[0063] Scene determination criteria: Automatic identification based on the road type field in vehicle GPS data, without the need for manual intervention.

[0064] Since the time window aggregation logic can be implemented through SQL window functions, and the dynamic weights can be preset with scenarios and weight mapping relationships in the configuration file, it can be developed and deployed quickly. In addition, compared with the original solution, the above alternative reduces the data association error by no more than 5%, and the module health score is more in line with the actual scenario requirements, while still achieving the invention purpose of data association analysis and health measurement.

[0065] Therefore, by using the aforementioned data association and fusion technology of vehicle ID and timestamp and health quantification technology, with vehicle ID and timestamp as the unified association key, and through the three-step logic of time sequence alignment, anomaly cleaning, and dynamic health calculation, deep linkage of multi-source data can be achieved. At the same time, a quantitative health model is designed for key modules (GPS, camera, radar) instead of the existing technology of identification, which can realize the association analysis of attribute, dynamic, and status data. The accuracy of module fault prediction is no less than 85%, and potential faults can be warned 1 to 2 hours in advance to avoid passive handling.

[0066] Step S206: Based on the target vehicle data, generate a three-layer vehicle panoramic image for real-time monitoring, so as to build a unified monitoring view and perform vehicle-road cooperative visualization using the vehicle panoramic image. The vehicle panoramic image includes: attribute layer, dynamic layer and state layer.

[0067] In one implementation, vehicle-road cooperative visualization employs map annotation and status labeling: the roadside service area is marked on the map using polygons or sectors, and the cooperative status between the vehicle and the roadside is displayed using text labels, while traffic event information is simultaneously pushed out. Furthermore, for the two core aspects of service area annotation and cooperative status display, the following alternative solutions can still achieve intuitive visualization of the cooperative status between the vehicle and roadside services: 1. Service scope labeling replacement: The fixed polygon or sector shape is replaced with dynamic service area labeling: the size and shape of the service area are dynamically adjusted according to the real-time status of roadside equipment, instead of using fixed radius or angle labels as in the original scheme. For example: RSU device: When the signal strength drops from 70dBm (coverage radius 500m) to 90dBm (coverage radius 300m), the red polygon on the map automatically shrinks and a signal weakening warning is marked simultaneously.

[0068] Camera equipment: When the focal length is adjusted from wide-angle (120°) to telephoto (30°), the blue fan-shaped area automatically shrinks to match the actual monitoring field of view of the camera.

[0069] Equipment status data source: Dynamic adjustment is achieved based on equipment monitoring module and real-time equipment status data.

[0070] 2. Alternative to collaborative status display: Replace text labels with color and animation linkage: The coordinated status is intuitively displayed through changes in vehicle icon color and animation effects, eliminating the need for textual explanations. For example: The vehicle is within RSU coverage and receiving traffic events: the vehicle icon is green, indicating that data interaction is in progress.

[0071] The vehicle is within RSU coverage but no events are being received: the vehicle icon is yellow and there is no animation.

[0072] Vehicle outside RSU coverage: The vehicle icon is grayed out, indicating that it is out of service.

[0073] Meanwhile, clicking the vehicle icon will bring up a collaborative details panel, displaying information such as roadside device ID, service type, and event push records, which is consistent with the original solution.

[0074] Since dynamic service range labeling can be implemented through map APIs, and color and animation effects can be achieved through front-end CSS or JS, device status data can directly call existing real-time device monitoring capabilities, eliminating the need for additional data collection steps. Furthermore, compared to the original solution, this alternative improves collaborative status recognition efficiency by at least 20%, and can reflect the impact of roadside device status changes on the service range in real time, avoiding the problem of fixed range labeling not matching actual service capabilities in the original solution, while still achieving the invention's objective of visualizing vehicle-road cooperative status.

[0075] Therefore, by using the aforementioned hierarchical structured generation and real-time update technology for vehicle panoramic images, a hierarchical structured panoramic image with attribute, dynamic, and state layers is constructed, stored in a distributed database, and a real-time incremental update and timed full verification mechanism is designed to ensure the real-time performance and accuracy of the image data. This can break the limitation of existing technologies that only display data in a single way, forming a complete view of vehicle operation, and reducing the time for regulatory personnel to query full-dimensional vehicle information from minutes to seconds.

[0076] Furthermore, through the unified map visualization technology for the collaborative status of vehicles and roadside services, roadside equipment data and real-time vehicle location data are integrated in a unified map view. Through spatial relationship calculation, automatic judgment of collaborative status, and display of color and label or animation linkage, the collaborative relationship between the two is presented intuitively. There is no need to manually switch modules, which can solve the problems of fragmented views and the need for manual judgment of collaborative status in existing technologies. The efficiency of collaborative status judgment is improved by no less than 99%, and the misjudgment rate is no more than 1%, which meets the real-time supervision requirements in vehicle-road cooperative scenarios.

[0077] In summary, the vehicle panoramic portrait construction method provided in this embodiment of the invention has the following advantages: 1. Improved data integration efficiency: Existing technologies require switching 3 to 5 modules to view complete vehicle data. This solution, through unified portrait, reduces data query time from minutes to seconds, improving query efficiency by no less than 90%; 2. Improved vehicle-road cooperative supervision efficiency: Existing technologies require 5 to 10 minutes to manually determine the cooperative status of vehicles and roadside services. This solution automatically labels data in real time, with a response time of no more than 200ms, improving supervision efficiency by no less than 99%; 3. Improved accuracy of module fault prediction: Existing technologies can only passively detect faults. This solution, through health trend analysis, can predict potential faults 1 to 2 hours in advance, with a fault prediction accuracy of no less than 85%, reducing vehicle operation risks.

[0078] See Figure 3 The diagram shows a specific process flow of a method for constructing a panoramic vehicle image. This embodiment of the invention also provides an implementation method for constructing a panoramic vehicle image for vehicle supervision. Through a full-process technical design encompassing integrated access of multi-source data, correlation and fusion processing, panoramic image generation, and vehicle-road cooperative visual supervision, it solves the problems of data fragmentation, view segmentation, and single module status display in existing technologies. Compared with existing technologies that only collect data in a scattered manner and display information separately, the core difference of this solution lies in establishing a technical link that covers all dimensions of data, performs correlation and fusion processing, and presents a unified view. See (1) to (4) below for details: (1) Standardized access and real-time acquisition of multi-source vehicle data (solving the problems of incomplete data acquisition and inconsistent formats in existing technologies), specifically: 1. Data collection scope definition (difference from existing technologies: covering all dimensions of static, dynamic, and module states, rather than a single data type), clearly defining the four core data types and specific fields to be accessed to ensure data integrity, as follows: Vehicle static attribute data: retrieved from the system's basic database, including vehicle model, autonomous driving level, license plate number, vehicle identification number (VIN), and owner information, stored in a structured data format.

[0079] Vehicle dynamic GPS data: collected in real time via the onboard GPS module at a frequency of once per second, including latitude and longitude, speed (km or h), heading angle, altitude (m), and collection timestamp, transmitted in streaming data format to ensure real-time performance.

[0080] Real-time vehicle CAN bus data: Accessed via the on-board CAN acquisition module, with a acquisition frequency of 10 times per second, including throttle status, brake status, steering wheel angle, turn signal status, and gear status (P, R, N, or D). The data format conforms to the SAE J1939 protocol to ensure compatibility with different vehicle models.

[0081] Vehicle key module status data: collected through on-board sensors and module self-test interfaces, at a frequency of once or every 5 seconds, including GPS module, camera module, and radar module, using health quantification values ​​and status code formats.

[0082] 2. Data access implementation method (difference from existing technologies: unified access interface and protocol adaptation, rather than scattered interfaces): Design a standardized data access gateway that supports multi-protocol adaptation. Static attribute data: Synchronized from the database via HTTP interface, with full synchronization performed daily at 1 AM, and incremental synchronization triggered when a vehicle is added or modified.

[0083] GPS and CAN data: Access is made via 4G or 5G network using the MQTT protocol. The vehicle terminal encapsulates the collected data into a specified JSON format and pushes it to the system data access gateway. The gateway verifies the validity of the data, and once the verification is successful, it enters the data processing stage.

[0084] Module status data: Accessed via vehicle Ethernet using TCP or IP protocol. The module self-test program periodically sends health data to the gateway, and the gateway records the data reception timestamp to ensure timing consistency.

[0085] (2) Multi-source data association and fusion processing (solving the problems of data fragmentation and lack of association in existing technologies). In one implementation, data with the same vehicle ID and timestamp from multi-source vehicle data can be associated. The associated data is then subjected to time-series alignment, anomaly cleaning, and health calculation to fuse the data and obtain the target vehicle data. Specifically, after aligning the timestamps of the associated data, invalid data is removed through anomaly cleaning, and missing data is filled in through forward padding and backward verification to obtain valid data. Then, health calculation is performed on the valid data to obtain health scores at each time point. A health trend curve is generated using the health scores, and finally, the target vehicle data is determined based on the valid data and the health trend curve. Specifically: 1. Data Association Key Design (Difference from existing technologies: Using vehicle ID and timestamp as unified association keys to achieve cross-type data binding): Each vehicle is assigned a unique vehicle ID, and a timestamp (accurate to milliseconds) is added to all collected data. Using vehicle ID and timestamp as association keys, a mapping relationship is established for four types of data. For example, GPS data with vehicle ID V001 and timestamp 2025, 10, 0110:00:00.123 (latitude and longitude 116.397, 39.908) can be associated with CAN data, module status data, and static attribute data with the same vehicle ID and timestamp.

[0086] 2. Data fusion processing logic (difference from existing technologies: time-series alignment and anomaly detection, rather than simple concatenation), employing a three-step fusion logic of time-series alignment, anomaly cleaning, and health calculation: Time alignment: Timestamp interpolation is performed on GPS data, CAN data, and module status data for the same vehicle ID to align the timestamps of GPS and module status data to the 10-times or second frequency of CAN data, ensuring that data can be analyzed in a linked manner under the same time dimension.

[0087] Anomaly cleaning: Invalid data is removed based on a preset threshold, and missing data is filled in using forward filling and backward verification methods.

[0088] Health Calculation: The module status data is quantitatively scored, with a total health score of 100 points. The module health score is automatically calculated every 5 seconds based on GPS signal strength, camera frame rate, and radar detection distance, generating a health trend curve.

[0089] (3) Generation and storage of vehicle panoramic images (solving the problem of existing technologies lacking complete images and only displaying single data). In one implementation, real-time incremental updates and timed full updates are performed on the vehicle panoramic images to execute vehicle monitoring processing based on the updated images. That is, when new vehicle dynamic GPS data, real-time vehicle CAN bus data, or vehicle key module status data are received, the dynamic and status layers of the vehicle panoramic images are updated in real-time using the newly received data. At preset time intervals, the vehicle panoramic images are fully updated by comparing the consistency of static attribute data with the basic database and the integrity of dynamic data with the original collected data. Specifically: 1. Panoramic Image Structure Definition (Difference from existing technologies: layered structured design, including attribute layer, dynamic layer, and state layer), generating a three-layered panoramic vehicle image, stored in a distributed database for easy querying and display: Attribute layer: Stores static attribute data, with fields including vehicle ID, vehicle model, autonomous driving level, license plate number, and affiliated company. This data is read-only and is only updated when vehicle information is modified.

[0090] Dynamic layer: Stores dynamic data after real-time association, partitioned by vehicle ID and date. Fields include timestamp, latitude and longitude, speed, heading angle, throttle opening, braking status, steering wheel angle, turn signal, gear position, and retains historical data for the past year.

[0091] Status layer: Stores module health data, with fields including timestamp, GPS signal strength, GPS health score, camera frame rate, camera health score, radar detection distance, radar health score, and total health score, and synchronously generates health anomaly markers.

[0092] 2. Profile update mechanism (difference from existing technologies: real-time incremental updates and timed full verification, rather than static storage): Real-time incremental updates: When new GPS, CAN or module status data is accessed and fused, the system automatically updates the dynamic layer and status layer of the panoramic image, with an update delay of no more than 200ms.

[0093] Scheduled full verification: At 2:00 AM every day, a full verification of the panoramic images of all vehicles is performed to compare the consistency of static attribute data with the basic database and the integrity of dynamic data with the original collected data, so as to ensure that the image data is accurate.

[0094] (4) Unified regulatory view and vehicle-road cooperative visualization (solving the problems of fragmented views and lack of collaborative display in existing technologies). In one implementation, a profile information panel and a health trend chart are generated using a panoramic vehicle profile and health trend chart data. A dynamic trajectory map of the vehicle is set between the profile information panel and the health trend chart to construct a unified regulatory view. Then, the road test service area is marked on the basis of the unified regulatory view, and a label corresponding to the spatial relationship is set at the vehicle icon according to the spatial relationship between the vehicle's latitude and longitude and the road test service area to perform vehicle-road cooperative visualization. Specifically: 1. Unified monitoring view construction (difference from existing technologies: a single interface integrating profile information, dynamic trajectory, and health status, rather than switching between multiple modules). A unified monitoring interface is designed on the system's web platform, comprising three core areas: Profile information panel (left side): Displays vehicle static attributes, real-time dynamic data, and module health status; data is updated in real time.

[0095] Dynamic trajectory map (middle): Using Baidu Maps as the base map, the real-time location of the vehicle is marked, and the driving trajectory of the past 1 hour is drawn. Clicking on any point on the trajectory allows you to view the CAN data and module status at that moment.

[0096] Health Trend Chart (right side): Displays the module's health trend curve over the past 24 hours, marking outliers. Hovering the mouse over the outlier will show the cause of the outlier.

[0097] 2. Visualization of vehicle-road cooperative status (difference from existing technologies: real-time labeling of vehicle and roadside service area cooperative relationships on the map, rather than displaying them separately), integrating roadside device data to display cooperative status on the monitoring map: Roadside service area marking: The coverage area of ​​RSU and the monitoring range of roadside cameras are marked on the map using polygons of different colors. The marking information includes device ID, service type and online status.

[0098] Collaborative status judgment and display: The system calculates the spatial relationship between the vehicle's latitude and longitude and the roadside service area in real time. If the vehicle is within the RSU coverage area, an RSU connected tag will be displayed next to the vehicle icon, and roadside traffic events will be pushed simultaneously. If the vehicle is outside the coverage area, the tag will show that the RSU is not connected, and the camera monitoring range icon will turn gray, intuitively presenting the vehicle-road cooperative status. The whole situation can be grasped without switching modules.

[0099] In summary, compared with the problems of data fragmentation, view segmentation and single module status display in the existing technology, the present invention can achieve the following key technical effects based on the integrated access of multi-source data, correlation and fusion processing, panoramic image generation and vehicle-road cooperative visual supervision, as detailed in (1) to (3): (1) It can realize the full-dimensional integration and correlation analysis of vehicle data, and improve the accuracy and efficiency of regulatory decision-making. The technical effect is as follows: In the existing technology, the static attributes, dynamic GPS, CAN bus and module status data of vehicles are stored in different modules and cannot be linked for analysis, making it difficult for regulatory personnel to judge the rationality of vehicle driving behavior from the dimensions of attributes, dynamics and status. Through the data correlation and fusion design, deep linkage of multi-source data can be realized, so that regulatory decision-making is upgraded from single data dependence to panoramic data support, the decision accuracy is improved by no less than 85%, and the data query and analysis efficiency is improved by no less than 90%.

[0100] Specifically: 1. Data Integration Level: Standardized access to multi-source vehicle data clearly covers four core data categories: static attributes, dynamic GPS, CAN bus, and module status. Unified access is achieved through a standardized gateway, resolving the issues of incomplete data collection and inconsistent formats in existing technologies. For example, CAN data is accessed according to the SAE J1939 protocol, ensuring compatibility with different vehicle models and avoiding the problems of CAN data loss or unresolved issues caused by protocol inconsistencies in existing technologies.

[0101] 2. Correlation Analysis Level: Multi-source data correlation and fusion processing uses vehicle ID and timestamp as unified association keys, achieving data linkage through time-series alignment, anomaly cleaning, and health calculation logic. For example, GPS data is interpolated and aligned to CAN data frequencies, allowing regulatory personnel to simultaneously obtain the GPS location and radar module status at a given moment, forming a complete analysis chain of behavior, location, and status. Compared to existing technologies that require manually splicing data by switching 3 to 5 modules, this solution reduces data query time from minutes to seconds, provides more comprehensive analysis dimensions, and significantly improves decision-making accuracy.

[0102] (2) Visualize the collaborative status of vehicles and roadside services, improving the real-time and intuitive nature of vehicle-road cooperative supervision. The technical effect is as follows: Existing technologies can only display the vehicle location or roadside service range separately, requiring manual comparison of coordinates to determine the collaborative status. This operation is cumbersome and prone to errors, failing to meet the supervision needs of real-time monitoring of whether vehicles are within the coverage of roadside services and whether they can receive roadside information in vehicle-road cooperative scenarios. By integrating vehicle and roadside service data through a unified map view, the collaborative status can be automatically marked in real time. Supervisors can intuitively grasp the overall situation without manual operation, improving the efficiency of collaborative status judgment by no less than 99% and reducing the misjudgment rate to no more than 1%.

[0103] Specifically: 1. Roadside Data Integration: The vehicle-road cooperative system visualizes and displays data from roadside devices. RSU coverage areas and camera monitoring ranges are marked on a map using different colors, along with device IDs and online status information. This addresses the lack of visualization of roadside service areas in existing technologies. For example, RSU device latitude and longitude data and vehicle GPS data use the same coordinate system, ensuring that the coverage calculation accuracy is no greater than 10 meters.

[0104] 2. Collaborative Status Judgment: By calculating the spatial relationship between the vehicle's latitude and longitude and the roadside service area in real time, a collaborative status tag is automatically generated, and roadside traffic events are pushed synchronously. For example, when a vehicle enters the RSU coverage area, the system triggers the display of the RSU connected tag in real time, and simultaneously displays the traffic light countdown data pushed by the roadside on the profile information panel; if the vehicle leaves the coverage area, the tag automatically switches to RSU not connected, and the camera monitoring range icon turns gray. Compared to the efficiency of existing technologies that require manual coordinate comparison for 5 to 10 minutes or multiple judgments, this solution has a response time of no more than 200ms and requires no manual intervention, significantly improving intuitiveness and real-time performance.

[0105] (3) Achieve quantitative health measurement and trend early warning for key vehicle modules, thereby improving vehicle operation safety and regulatory foresight. The technical effects are as follows: Existing technologies for monitoring and identifying the status of key vehicle modules cannot quantify health or predict faults, and can only be dealt with passively after a module has completely failed, increasing the risk of vehicle operation. Through the design of module health measurement and trend analysis, potential faults can be predicted 1 to 2 hours in advance, the fault handling response time can be shortened by no less than 60%, and the operational risk of vehicles caused by module failures can be reduced by no less than 70%.

[0106] Specifically: 1. Health Measurement Level: A quantitative model with a total score of 100 is used to calculate and convert GPS signal strength, camera frame rate, and radar detection distance into specific scores, solving the problem of the single status display in existing technologies. For example, when the GPS signal strength continuously decreases from 80dBm (24 points) to 100dBm (12 points), the health score decreases simultaneously. Supervisors can intuitively detect the deterioration trend of the module's status, rather than only noticing the fault after the signal is completely lost.

[0107] 2. Trend Early Warning Level: The panoramic image status layer stores historical health data of the module and displays changes through trend curves. When the health score is below 60 points for three consecutive times, the system automatically marks a potential fault risk warning, allowing supervisors to arrange maintenance in advance and prevent the fault from escalating. Compared to the passive handling mode of existing technologies after a fault occurs, this solution can predict risks 1-2 hours in advance, making fault handling more proactive and significantly improving vehicle operation safety.

[0108] Regarding the vehicle panoramic image construction method provided in the foregoing embodiments, this invention provides a vehicle panoramic image construction apparatus, see [link to relevant documentation]. Figure 4 The diagram shows a structural schematic of a device for constructing a panoramic image of a vehicle, which includes the following parts: The data acquisition module 402 acquires multi-source vehicle data, which includes: vehicle static attribute data, vehicle dynamic GPS data, vehicle real-time CAN bus data, and vehicle key module status data. The data fusion module 404 uses vehicle ID and timestamp as unified association keys to perform data association and fusion processing on multi-source vehicle data to obtain target vehicle data. The profile generation module 406 generates a three-layer panoramic profile of the vehicle for real-time monitoring based on the target vehicle data. This allows for the construction of a unified monitoring view and visualization of vehicle-road cooperative systems. The panoramic profile of the vehicle includes an attribute layer, a dynamic layer, and a status layer.

[0109] The vehicle panoramic image construction device provided in this application embodiment can significantly improve the accuracy and efficiency of vehicle supervision.

[0110] In one embodiment, when performing the step of data association and fusion processing of multi-source vehicle data using vehicle ID and timestamp as unified association keys to obtain target vehicle data, the aforementioned data fusion module 404 is further configured to: associate data with the same vehicle ID and timestamp among the multi-source vehicle data, and perform time-series alignment processing, anomaly cleaning processing, and health calculation processing on the associated data, so as to associate and fuse the data to obtain target vehicle data.

[0111] In one embodiment, when performing time-series alignment, anomaly cleaning, and health calculation on the associated data to fuse the data and obtain target vehicle data, the data fusion module 404 is further configured to: align the timestamps of the associated data, remove invalid data through anomaly cleaning, and fill in missing data through forward padding and backward verification to obtain valid data; perform health calculation on the valid data to obtain health scores at each time point, and generate a health trend curve using the health scores; and determine the target vehicle data based on the valid data and the health trend curve.

[0112] In one embodiment, after performing the step of generating a three-layer panoramic vehicle image for real-time monitoring based on target vehicle data, the image generation module 406 is further configured to: perform real-time incremental update processing and timed full update processing on the panoramic vehicle image, so as to perform vehicle monitoring processing based on the updated panoramic vehicle image.

[0113] In one embodiment, when performing the steps of real-time incremental update processing and timed full update processing for the vehicle panoramic image, the image generation module 406 is further configured to: when receiving new vehicle dynamic GPS data, vehicle real-time CAN bus data, or vehicle key module status data, use the newly received data to perform real-time incremental update processing on the dynamic layer and status layer of the vehicle panoramic image, and perform a full update of the vehicle panoramic image at preset time intervals by comparing the consistency of static attribute data with the basic database and the integrity of dynamic data with the original collected data.

[0114] In one embodiment, when performing the step of constructing a unified regulatory view using a vehicle panoramic image and visualizing vehicle-road cooperation, the aforementioned image generation module 406 is further configured to: generate an image information panel and a health trend chart using the vehicle panoramic image and the health trend curve in the target vehicle data, and set a dynamic trajectory map of the vehicle between the image information panel and the health trend chart to construct a unified regulatory view.

[0115] In one embodiment, after performing the step of constructing a unified regulatory view, the above-mentioned profile generation module 406 is further used to: mark the road test service range on the basis of the unified regulatory view, and set a label corresponding to the spatial relationship at the vehicle icon according to the spatial relationship between the vehicle's latitude and longitude and the road test service range, so as to perform vehicle-road cooperative visualization display.

[0116] The device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0117] This invention provides a server, specifically, the server includes a processor and a storage device; the storage device stores a computer program, which, when run by the processor, executes the method described in any of the above embodiments.

[0118] Figure 5 This is a schematic diagram of the structure of a server provided in an embodiment of the present invention. The server 100 includes: a processor 50, a memory 51, a bus 52 and a communication interface 53. The processor 50, the communication interface 53 and the memory 51 are connected through the bus 52. The processor 50 is used to execute executable modules, such as computer programs, stored in the memory 51.

[0119] The memory 51 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 53 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0120] Bus 52 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0121] The memory 51 is used to store programs. After receiving an execution instruction, the processor 50 executes the programs. The method executed by the device for defining the flow process disclosed in any of the foregoing embodiments of the present invention can be applied to the processor 50 or implemented by the processor 50.

[0122] Processor 50 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 50 or by instructions in software form. Processor 50 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 51. The processor 50 reads the information in memory 51 and, in conjunction with its hardware, completes the steps of the above method.

[0123] The computer program product of the readable storage medium provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the foregoing method embodiments. For specific implementation, please refer to the foregoing method embodiments, which will not be repeated here.

[0124] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0125] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for constructing a panoramic image of a vehicle, characterized in that, The method includes: Acquire multi-source vehicle data, wherein the multi-source vehicle data includes: vehicle static attribute data, vehicle dynamic GPS data, vehicle real-time CAN bus data, and vehicle key module status data; Using vehicle ID and timestamp as unified association keys, the multi-source vehicle data is subjected to data association and fusion processing to obtain the target vehicle data; Based on the target vehicle data, a three-layer vehicle panoramic profile is generated for real-time monitoring, so as to build a unified monitoring view and perform vehicle-road cooperative visualization using the vehicle panoramic profile. The vehicle panoramic profile includes: an attribute layer, a dynamic layer, and a state layer.

2. The method for constructing a panoramic vehicle image according to claim 1, characterized in that, The step of performing data association and fusion processing on the multi-source vehicle data using vehicle ID and timestamp as unified association keys to obtain target vehicle data includes: The data with the same vehicle ID and timestamp from the multi-source vehicle data are associated, and the associated data is then processed by time-series alignment, anomaly cleaning, and health calculation to fuse the data and obtain the target vehicle data.

3. The method for constructing a panoramic vehicle image according to claim 2, characterized in that, The steps of performing time-series alignment, anomaly cleaning, and health calculation on the associated data to fuse the data and obtain the target vehicle data include: After aligning the timestamps of the associated data, invalid data is removed through anomaly cleaning, and missing data is filled in through forward padding and backward validation to obtain valid data. The valid data is processed to calculate the health score at each time point, and the health score is used to generate a health trend curve. Based on the valid data and the health trend curve, the target vehicle data is determined.

4. The method for constructing a panoramic vehicle image according to claim 1, characterized in that, Following the step of generating a three-layered panoramic vehicle image for real-time monitoring based on the target vehicle data, the following steps are included: The vehicle panoramic image is subjected to real-time incremental update processing and timed full update processing to perform vehicle supervision processing based on the updated vehicle panoramic image.

5. The method for constructing a panoramic vehicle image according to claim 4, characterized in that, The steps of performing real-time incremental update processing and timed full update processing on the panoramic image of the vehicle include: When new vehicle dynamic GPS data, vehicle real-time CAN bus data, or vehicle key module status data are received, the dynamic layer and the status layer of the vehicle panoramic image are updated in real time using the newly received data. At preset time intervals, the vehicle panoramic image is fully updated by comparing the consistency of static attribute data with the basic database and the integrity of dynamic data with the original collected data.

6. The method for constructing a panoramic vehicle image according to claim 1, characterized in that, The steps of constructing a unified regulatory view using the vehicle panoramic image and visualizing vehicle-road cooperative interaction include: Using the vehicle panoramic image and the health trend curve in the target vehicle data, an image information panel and a health trend chart are generated, and a dynamic trajectory map of the vehicle is set between the image information panel and the health trend chart to construct the unified monitoring view.

7. The method for constructing a panoramic vehicle image according to claim 6, characterized in that, Following the step of constructing the unified regulatory view, the following is included: Based on the unified regulatory view, the road test service range is marked, and according to the spatial relationship between the vehicle's latitude and longitude and the road test service range, a label corresponding to the spatial relationship is set at the vehicle's icon to perform the vehicle-road cooperative visualization display.

8. A device for constructing a panoramic image of a vehicle, characterized in that, The device includes: The data acquisition module acquires multi-source vehicle data, which includes: vehicle static attribute data, vehicle dynamic GPS data, vehicle real-time CAN bus data, and vehicle key module status data. The data fusion module uses vehicle ID and timestamp as unified association keys to perform data association and fusion processing on the multi-source vehicle data to obtain the target vehicle data. The profile generation module generates a three-layer panoramic profile of the vehicle for real-time monitoring based on the target vehicle data. This panoramic profile is used to construct a unified monitoring view and perform vehicle-road cooperative visualization. The panoramic profile of the vehicle includes an attribute layer, a dynamic layer, and a state layer.

9. A server, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images