Method and apparatus for diagnosing vehicle data reporting exception

Abstract

This application proposes a method for diagnosing vehicle data reporting anomalies. The method includes the following steps: acquiring real-time monitoring data collected and reported by the vehicle through a first vehicle-side data link; acquiring remote service data collected and reported by the vehicle through a second vehicle-side data link, wherein the first and second vehicle-side data links are at least partially independent; comparing the real-time monitoring data and the remote service data that meet predetermined comparison conditions; and, based on the comparison result, diagnosing at least the reporting anomaly of the real-time monitoring data. This application also proposes an apparatus, a backend server, and a computer program product for diagnosing vehicle data reporting anomalies. By introducing remote service data as a reference and comparing the two data streams, the problem of accurately judging real-time monitoring data reporting anomalies by relying on a single data source can be effectively solved.

Description

Technical Field

[0001] This application relates to a method for diagnosing vehicle data reporting anomalies, and also to an apparatus for diagnosing vehicle data reporting anomalies, a backend server, and a computer program product. Background Technology

[0002] In recent years, to meet the regulatory requirements for new energy vehicles and improve safety, real-time monitoring (RTM) systems have emerged. However, in actual vehicle operation, due to communication failures, vehicle-side equipment malfunctions, and other reasons, abnormal real-time monitoring data reporting sometimes occurs, manifesting as data loss, data freezing, or reporting interruption. Existing technologies have proposed detecting reporting anomalies by comparing real-time monitoring data packets reported sequentially in time; however, these methods rely on only a single data source, limiting the reliability of the judgment results. For example, in some cases, it is difficult to effectively distinguish between reporting anomalies and the normal state of the vehicle.

[0003] Therefore, the current real-time monitoring data reporting and anomaly diagnosis mechanism is not perfect. Summary of the Invention

[0004] The purpose of this application is to provide a method for diagnosing abnormal vehicle data reporting, an apparatus for diagnosing abnormal vehicle data reporting, a backend server, and a computer program product, so as to at least solve some of the problems in the prior art.

[0005] According to a first aspect of this application, a method for diagnosing vehicle data reporting anomalies is provided, the method comprising the following steps: Acquire real-time monitoring data collected and reported by the vehicle through the first vehicle-side data link; The vehicle acquires remote service data collected and reported by the vehicle through a second vehicle-side data link, wherein the first vehicle-side data link and the second vehicle-side data link are at least partially independent. The real-time monitoring data that meets the predetermined comparison criteria is compared with the remote service data; and Based on the comparison results, at least the abnormality in the reporting of the real-time monitoring data can be diagnosed.

[0006] This application specifically includes the following technical concept: by introducing remote service data as a reference data source and comparing the two data streams, the problem of accurately judging anomalies in real-time monitoring data reporting cannot be solved by relying on a single data source. This solution is particularly effective in distinguishing between reported anomalies and the normal state of the vehicle, avoiding misjudgments caused by specific vehicle conditions. Furthermore, the remote service data and real-time monitoring data are collected and reported using at least partially independent vehicle-side data links, preventing synchronization failures due to sharing the same node and ensuring that the reference source has independent verification capabilities, thereby significantly improving the accuracy and reliability of real-time monitoring data verification.

[0007] In one exemplary embodiment, the first vehicle-side data link and the second vehicle-side data link are at least partially independent, including: the real-time monitoring data and the remote service data are collected through different vehicle-side source nodes. Specifically, the real-time monitoring data is collected through the vehicle's real-time monitoring terminal or T-BOX; the remote service data is collected through network-enabled vehicle components, which include at least one of the following: infotainment head unit (HU), body control module (BCM), door control module (DCM), and / or vehicle control unit (VCU).

[0008] This ensures that the two data streams are independent of each other at the source, preventing both data streams from failing simultaneously due to a failure of the same source node, thus guaranteeing that the reference source has independent verification capabilities.

[0009] In one exemplary embodiment, the first vehicle-side data link and the second vehicle-side data link are at least partially independent, including: the real-time monitoring data and the remote service data are transmitted through different vehicle-side communication nodes. Specifically, the real-time monitoring data is transmitted through the built-in communication unit of the vehicle's real-time monitoring terminal, and the remote service data is transmitted through the built-in communication unit of a network-enabled vehicle component or through a T-BOX; or the real-time monitoring data is transmitted through a T-BOX, and the remote service data is transmitted through the built-in communication unit of a network-enabled vehicle component.

[0010] This can minimize the possibility of two data streams failing simultaneously due to a shared communication node failure, further improving the independence of the data link and ensuring that the reference source has independent verification capabilities.

[0011] In one exemplary embodiment, the remote service data is reported triggered by key business actions of the vehicle, including: unlocking the vehicle, starting the vehicle, turning off the vehicle, locking the vehicle, plugging in the charging gun, unplugging the charging gun, charging in progress, opening the car door and / or closing the car door.

[0012] Therefore, the reporting of remote service data stems from the vehicle's inherent configuration and reporting capabilities for remote control, eliminating the need for additional hardware or modifications to the vehicle's logic to provide reference data. This allows for full utilization of existing vehicle data resources, reducing hardware costs and system complexity during implementation.

[0013] In one exemplary embodiment, comparing real-time monitoring data and remote service data that meet predetermined comparison conditions includes comparing the latest record in the remote service data currently reported by the vehicle with the latest record in the real-time monitoring data currently reported by the vehicle.

[0014] Therefore, the latest records from the two data sources are compared. The latest data best reflects the current actual status of the vehicle. By determining whether the real-time monitoring data lags behind the remote service data, it is possible to identify in real time and effectively whether there are any abnormalities such as reported loss or freezing of real-time monitoring data.

[0015] In one exemplary embodiment, comparing real-time monitoring data and remote service data that meet predetermined comparison conditions includes: triggering the comparison in response to acquiring remote service data reported by a vehicle. Specifically, the acquired remote service data is compared with the last acquired real-time monitoring data up to the time the remote service data was received.

[0016] This enables real-time diagnosis of abnormal data reporting, timely detection of data reporting anomalies, and effective avoidance of missed reports or misjudgments due to diagnostic delays.

[0017] In an exemplary embodiment, comparing real-time monitoring data and remote service data that meet predetermined comparison conditions includes: triggering the comparison when the vehicle reaches the end of its business scenario, wherein the end of the business scenario includes: the end of a driving cycle, and / or the end of a charging cycle.

[0018] Therefore, the endpoint of a business scenario generally corresponds to the moment when either the driving cycle or the charging cycle has ended. At this point, the vehicle status reflected by both data sources has stabilized, avoiding misjudgments caused by asynchronous reporting frequencies and improving the accuracy of diagnostic results and system efficiency.

[0019] In one exemplary embodiment, the real-time monitoring data includes at least a vehicle identification number, cumulative mileage, and a timestamp; the remote service data includes at least a vehicle identification number and cumulative mileage, and also includes a timestamp or a timestamp associated with it.

[0020] This provides the necessary basic information for the correlation and comparison of the two sets of data, ensuring that the comparison operation is feasible and effective.

[0021] In an exemplary embodiment, based on the comparison result, at least the reporting anomaly of the real-time monitoring data is diagnosed, including: if the remote service data and the real-time monitoring data contain the same vehicle identification code, and if the timestamp of the remote service data is later than or equal to the timestamp of the real-time monitoring data, and the cumulative mileage of the remote service data is greater than the cumulative mileage of the real-time monitoring data, then the real-time monitoring data is diagnosed as having a loss error.

[0022] Therefore, if the source data is reported normally and the recorded mileage has increased, but the real-time monitoring data fails to record the newly added mileage, it can be inferred that there is a loss in the reporting of real-time monitoring data.

[0023] In one exemplary embodiment, the method further includes: diagnosing reporting anomalies in remote service data based on the comparison result. Specifically, if the remote service data and the real-time monitoring data contain the same vehicle identification number (VIN), and the timestamp of the remote service data is earlier than the timestamp of the real-time monitoring data, and the cumulative mileage of the remote service data is less than the cumulative mileage of the real-time monitoring data, then a loss error in the remote service data is diagnosed.

[0024] Therefore, if remote service data consistently lags behind real-time monitoring data in both timestamps and mileage, it can be inferred that the remote service data failed to be reported at the appropriate time, potentially indicating data loss. This enables bidirectional diagnostic capabilities for remote service data.

[0025] In one exemplary embodiment, the method further includes: monitoring the vehicle's hibernation state based on the latest and previously acquired remote service data. Specifically, if the two acquired remote service data contain the same vehicle identification number, and if the cumulative mileage of the latest and previously reported remote service data is the same, and the latest reported remote service data is not triggered by a door opening / closing action, then the vehicle is determined to have entered a hibernation state; a timer is started from the moment the hibernation state is determined, and if the vehicle remains in a hibernation state for a period exceeding a preset time threshold, it is determined to be a long-term hibernation vehicle.

[0026] This allows for accurate identification of dormant vehicles, preventing the misclassification of normal dormancy as an RTM reporting anomaly. Furthermore, monitoring dormancy duration and identifying vehicles in long-term dormancy helps optimize backend resource management and provides a reference for assessing the status of vehicles upon re-entry.

[0027] In an exemplary embodiment, both the remote service data and the real-time monitoring data include at least a vehicle identification code and a timestamp, and at least one of the following: SOC (State of Charge), vehicle speed, and / or geographical location. Based on the comparison result, at least the reporting anomaly of the real-time monitoring data is diagnosed, further including: if the remote service data and the real-time monitoring data contain the same vehicle identification code, and for the same time period, if the remote service data records changes in SOC, vehicle speed, and / or geographical location, while the real-time monitoring data does not change in SOC, vehicle speed, and / or geographical location during the corresponding time period, then a freeze error is diagnosed in the real-time monitoring data.

[0028] Therefore, by comparing the trend of the status changes of the two data streams within the same time period, it is possible to diagnose whether there is a freezing anomaly in the real-time monitoring data, and to effectively identify the data stagnation problem.

[0029] According to a second aspect of this application, an apparatus for diagnosing abnormalities in vehicle data reporting is provided. The apparatus includes a memory and a processor. The memory stores computer program instructions, and when the computer program instructions are executed by the processor, the processor is capable of performing the method according to the first aspect of this application.

[0030] According to a third aspect of this application, a backend server is provided, the backend server including the apparatus described in the second aspect of this application.

[0031] According to a fourth aspect of this application, a computer program product is provided, comprising computer program instructions, wherein, when executed by a processor, the computer program instructions enable the processor to perform the method according to a first aspect of this application. Attached Figure Description

[0032] The principles, features, and advantages of this application will be better understood below with reference to the accompanying drawings. The drawings include: Figure 1a and Figure 1b A block diagram of a backend server according to an exemplary embodiment of this application is shown; Figure 2 A block diagram of a backend server according to another exemplary embodiment of this application is shown; Figure 3 A flowchart of a method for diagnosing anomalies in vehicle data reporting according to an exemplary embodiment of this application is shown; Figure 4 It shows Figure 3 The flowcharts for the two method steps shown are as follows; Figure 5 It shows Figure 3 Another flowchart of the two method steps shown; Figure 6 It shows Figure 3 Another flowchart of the two method steps shown; Figure 7 It shows Figure 3 Another flowchart of the two method steps shown; Figure 8 A schematic diagram is shown illustrating the use of the method according to this application in an exemplary application scenario to diagnose errors in the loss of real-time monitoring data; Figure 9 A schematic diagram illustrating the use of the method according to this application to diagnose freezing errors in real-time monitoring data in an exemplary application scenario is shown; and Figure 10 A schematic diagram is shown illustrating the use of the method according to this application in an exemplary application scenario to diagnose anomalies in remote service data reporting. Detailed Implementation

[0033] To make the technical problems to be solved, the technical solutions, and the beneficial technical effects of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and several exemplary embodiments. It should be understood that the specific embodiments described herein are only for explaining this application and are not intended to limit the scope of protection of this application.

[0034] Figure 1a and Figure 1b A block diagram of a backend server according to an exemplary embodiment of this application is shown.

[0035] like Figure 1a and Figure 1b As shown, the backend server 5 can communicate with vehicle 1. Vehicle 1 may in particular be a new energy vehicle, such as a plug-in hybrid electric vehicle (PHEV), a range-extended electric vehicle (EREV), and / or a battery electric vehicle (BEV). However, it should be understood that this application can also be applied to other types of vehicles.

[0036] Vehicle 1 is capable of collecting and reporting real-time monitoring data 32, and will report the collected real-time monitoring data 32 to the backend server 5. According to relevant national standards, new energy vehicles are required to install on-board terminals and periodically report vehicle operating status data (including vehicle data, drive motor data, battery data, location data, and alarm data) to the enterprise platform according to the prescribed communication protocols and data formats. This standard aims to fully realize real-time monitoring of the operation of new energy vehicles to strengthen the safety supervision of new energy vehicles.

[0037] The backend server 5 can be a cloud-based server, for example, it can be deployed and operated by the original equipment manufacturer (OEM). The backend server 5 is used to receive real-time monitoring data 32 reported by vehicle 1, store, analyze and process the received data, and perform operations such as vehicle status monitoring, safety alarms and fault diagnosis based on the analysis results.

[0038] In addition, the backend server 5 can also communicate with a public platform server (not explicitly shown for simplicity), thereby enabling the transmission of real-time monitoring data 32 to the public platform server. The public platform server can be a national new energy vehicle regulatory platform server, used to support the monitoring and management of the operation of new energy vehicles.

[0039] The device 50 for diagnosing vehicle data reporting anomalies can be deployed in the backend server 5. The device 50 may include a processor and a memory (not shown for simplicity). The memory may include computer-readable storage media such as hard disks, RAM, and flash memory, and stores computer program instructions. The processor may be a central processing unit (CPU), microcontroller unit (MCU), graphics processing unit (GPU), neural network processing unit (NPU), digital signal processor (DSP), or other general-purpose or special-purpose processor. When the processor executes the computer program instructions stored in the memory, it can perform the aforementioned method for diagnosing vehicle data reporting anomalies.

[0040] As shown in the figure, the device 50 acquires real-time monitoring data 32 reported by vehicle 1 on the one hand, and remote service data 31 reported by vehicle on the other hand, and analyzes and diagnoses the reporting anomalies of real-time monitoring data 32 based on the comparison results of the two.

[0041] After a vehicle reports its data, remote service data 31 can be stored in the first database 51, and real-time monitoring data 32 can be stored in the second database 52. The first database 51 and the second database 52 can both be deployed on the backend server 5, or they can be deployed in different locations. The device 50 can obtain the required data by reading databases 51 and 52.

[0042] In one embodiment, the device can directly read all data from the corresponding databases 51 and 52, or it can read only the filtered data. For example, instead of using all remote service data for comparison, only remote service data in the case of a stationary vehicle is retrieved. Another example is that the remote service data may contain other irrelevant content such as window status, which can be filtered out, and only records containing specific data content (such as mileage, timestamps, door status, etc.) are retrieved for comparison.

[0043] In vehicle 1, real-time monitoring data 32 is collected and reported through the first vehicle-side data link, and remote service data 31 is collected and reported through the second vehicle-side data link, and the first vehicle-side data link and the second vehicle-side data link are at least partially independent.

[0044] exist Figure 1a In the illustrated embodiment, the difference between the first and second vehicle-side data links lies in the use of different vehicle-side source nodes 12 and 13 for data collection. Specifically, real-time monitoring data 32 is collected by the real-time monitoring terminal 12 (also known as the RTM terminal). The real-time monitoring terminal 12 is connected to multiple functional components 21, 22, 23, and 24 of the vehicle via an in-vehicle communication network (such as CAN bus, Ethernet, or FlexRay), thereby enabling the collection of vehicle operating status data. The functional components 21, 22, 23, and 24 include, but are not limited to: battery management system (BMS), environmental sensors, odometer, speed sensor, accelerometer, and Global Navigation Satellite System (GNSS) positioning device, etc.

[0045] Unlike the source node for collecting real-time monitoring data 32, remote service data 31 is collected by network-enabled vehicle components 13. These network-enabled vehicle components 13 include, but are not limited to, the infotainment head unit (HU), body control module (BCM), door control module (DCM), and vehicle control unit (VCU). Here, "network-enabled" means that the vehicle component has the ability to interact with external networks directly or indirectly (e.g., via vehicle-side communication nodes).

[0046] The two data streams are collected by their respective vehicle-side source nodes 12 and 13, and then transmitted to the vehicle-side communication node 11 (e.g., T-BOX, Telematics BOX, also known as vehicle-mounted communication terminal), and finally sent to the backend server 5 through the communication network (not shown for simplicity) via the vehicle-side communication node 11.

[0047] In an embodiment not shown, the vehicle-side source node responsible for collecting real-time monitoring data 32 can also be directly T-BOX 11, that is, the real-time monitoring terminal 12 and T-BOX 11 are integrated into one unit, and the same hardware device simultaneously undertakes the functions of collecting, processing and reporting real-time monitoring data 32.

[0048] exist Figure 1b In the illustrated embodiment, the difference between the first vehicle-side data link and the second vehicle-side data link lies in the use of different vehicle-side communication nodes to transmit data. Specifically, real-time monitoring data 32 is transmitted by the built-in communication unit of the real-time monitoring terminal 12, and remote service data 31 is transmitted by the built-in communication unit of the network-connected vehicle component 13.

[0049] In an embodiment not shown, real-time monitoring data 32 can also be sent through T-BOX 11, while remote service data 31 is still sent through the built-in communication unit of the network-enabled vehicle component 13. This is also a case where two data streams are sent through different vehicle-side communication nodes, maintaining a certain degree of independence at the communication node level.

[0050] It should be noted that Figure 1a This illustration only demonstrates a scenario where the two data source nodes are different but share a communication node. In other implementations, the two data links may be different at both the source node and the communication node, and the specific type of node used is not limited to that shown in the figure.

[0051] It should also be noted that Figure 1b The example shown is only exemplified when both the real-time monitoring terminal 12 and the network-enabled vehicle component 13 have their own communication units. However, in other cases, the network-enabled vehicle component 13 may not have its own or built-in communication unit, but instead use a different vehicle-side communication node than the T-BOX to transmit data.

[0052] Figure 2 A block diagram of a backend server according to another exemplary embodiment of this application is shown.

[0053] and Figure 1a and Figure 1b The embodiments shown are different, in Figure 2 In this embodiment, the real-time monitoring data 32 and the remote service data 31 are not reported to the same backend server, but are reported to different backend servers 5 and 6 respectively.

[0054] Specifically, remote service data 31 is reported to the first backend server 6, and real-time monitoring data 32 is reported to the second backend server 5. The first backend server 6 and the second backend server 5 can be deployed on the same cloud platform or on different cloud platforms.

[0055] The first backend server 6 may include a first database 51 for storing remote service data 31 reported by vehicle 1. The purpose of collecting this remote service data 31 is, for example, to support the remote control functions of vehicle 1, such as allowing users to remotely open and close car doors or remotely start the air conditioning via a mobile app. The first backend server 6 may be, for example, a backend server deployed by the original equipment manufacturer specifically for supporting remote function operation and maintenance.

[0056] The second backend server 5 may include a second database 52 for storing real-time monitoring data 32, and a device 50 for diagnosing data reporting anomalies from vehicle 1. The second backend server 5 may be, for example, a backend server deployed by an original equipment manufacturer (OEM) specifically for supporting the collection and diagnosis of real-time monitoring data 32. The device 50 may, for example, access the first database 51 of the first backend server 6 via an API call. When a comparison is required, the device 50 retrieves remote service data 31 from the first database 51 via the API, and simultaneously retrieves the corresponding real-time monitoring data 32 that meets preset comparison conditions from the second database 52, thereby performing data comparison and reporting anomaly diagnosis.

[0057] Figure 3 A flowchart of a method for diagnosing vehicle data reporting anomalies according to an exemplary embodiment of this application is shown. Figure 3 The method shown includes steps S1 to S4, for example, it can be achieved by using... Figure 1a , Figure 1b or Figure 2 The background server or device shown is used for execution.

[0058] In step S1, real-time monitoring data collected and reported by the vehicle through the first vehicle-side data link is acquired.

[0059] As mentioned above, real-time monitoring data can be collected from the vehicle network by a separate real-time monitoring terminal or by the vehicle's T-BOX. For example, real-time monitoring data may include vehicle identification number (VIN), vehicle data (such as vehicle speed, cumulative mileage, SOC, gear position, charging status), drive motor data, battery data (such as voltage, current, temperature), vehicle location data (longitude, latitude), alarm data, etc.

[0060] In addition, real-time monitoring data is also required to include a time field to record the time when vehicle data was collected (this time can also be approximately equal to the reporting time). For example, a timestamp of a real-time monitoring data point is "2025-04-20 14:30:25", which means that the vehicle status corresponding to this data point was collected and reported at 14:30:25 on April 20, 2025.

[0061] In step S2, remote service data collected and reported by the vehicle through the second vehicle-side data link is obtained, wherein the first vehicle-side data link and the second vehicle-side data link are at least partially independent.

[0062] In one embodiment, remote service data is reported triggered by key business actions of the vehicle, i.e., event-triggered. Each report signifies a change in vehicle status or the arrival of a certain business node. Key business actions include, for example: unlocking the vehicle, starting the vehicle, turning off the vehicle, locking the vehicle, plugging in the charging gun, unplugging the charging gun, charging in progress, opening the car door, and / or closing the car door. Whenever any of the above actions occurs, the network-connected vehicle component triggers the reporting of the corresponding remote service data.

[0063] In some cases, the remote service data described in this article may refer only to the data reported by the vehicle when it is stationary and parked. For example, actions such as unlocking, locking, opening and closing doors, and plugging and unplugging the charging gun that occur when the vehicle is parked can trigger remote service data that reflects the stable cumulative mileage of the vehicle when it is stationary.

[0064] In one embodiment, remote service data originates from the vehicle's inherent configuration and is actively reported by network-enabled vehicle components to support remote control functions. Such remote control functions include: remote door opening / closing, remote air conditioning control, remote window / sunroof / sunshade control, remote charging management, remote diagnostics, and OTA (Over-The-Air) upgrades. The purpose of reporting this data is to provide the latest vehicle status foundation for subsequent potential remote control scenarios. For example, when a user locks the vehicle at 9:01 AM, the vehicle reports the locking event and its locking status, which can be synchronized to the user's mobile app for real-time vehicle status viewing.

[0065] In another embodiment, the remote service data may not rely entirely on the vehicle's inherent configuration, but may be specially configured to collect and report specific types of remote service data to meet the data comparison requirements of this solution.

[0066] In one embodiment, remote service data is collected and reported by network-enabled vehicle components. These network-enabled vehicle components include, for example, an infotainment head unit (HU), a body control module (BCM), a door control module (DCM), and a vehicle control unit (VCU).

[0067] For example, remote service data includes: Vehicle Identification Number (VIN), timestamp, mileage, door open / close status, unlock status, ignition status, charging status, window status, sunroof status, air conditioning status, horn status, and / or headlight status. This data reflects the real-time status of the vehicle when critical business operations occur, providing necessary reference information for comparison with real-time monitoring data.

[0068] In one embodiment, remote service data may directly include a timestamp, which, for example, corresponds to the time of occurrence of a critical business action, is generated by the vehicle (e.g., vehicle unlocking at 9:01) and encapsulated in the remote service data for reporting. In another embodiment, remote service data may not have its own timestamp; instead, the backend server may append a timestamp to the remote service data reported by the vehicle upon receipt, recording the time the data arrived at the server (e.g., receiving the vehicle's unlocking action report at 9:01), thus associating it with a timestamp. Therefore, the "timestamp of remote service data" referred to in this application context can be understood as either the event occurrence time generated by the vehicle or the data reception time recorded by the cloud.

[0069] In the context of this application, "vehicle-side data link" refers, for example, to the data transmission path within a vehicle from a vehicle-side source node (such as a real-time monitoring terminal or HU) to a vehicle-side communication node (such as a T-BOX, built-in antenna, etc.), encompassing data acquisition, processing, and transmission via the communication node. The meanings and possible configurations of "first vehicle-side data link" and "second vehicle-side data link," which are at least partially independent, have been discussed above. Figure 1a and Figure 1b This has been explained in detail, so I will not repeat it here.

[0070] In step S3, the real-time monitoring data that meets the predetermined comparison conditions is compared with the remote service data.

[0071] In this context, "meeting predetermined comparison conditions" includes conditions regarding the timing of the comparison operation and conditions regarding the data involved in the comparison. This type of condition filtering aims to ensure high reliability and real-time performance of the comparison. Specifically, predetermined comparison conditions may include: comparison is not triggered every time remote service data is received, but only at specific business nodes or when specific event conditions are met. For example, the real-time monitoring data and remote service data involved in the comparison must meet certain business relevance or time alignment requirements.

[0072] In one embodiment, the comparison operation can be triggered in response to receiving remote service data reported by the vehicle. In other words, the background does not perform the comparison at all times, but is triggered when a specific event occurs, such as when the vehicle reports an action of unplugging the charging gun or locking the vehicle.

[0073] The rationale behind this design is that remote service data is event-triggered, and the reporting timing is not fixed. Using remote service data as the trigger condition for the comparison operation ensures that the reference source (remote service data) is real-time, and that each comparison uses the latest event-triggered data as the reference, avoiding misjudgments caused by a lag in the reference source.

[0074] For example, the acquired remote service data can be compared with the latest real-time monitoring data obtained up to the time the data was received. For instance, if the backend server receives unlock data reported by a vehicle at 9:01, it can retrieve the last recorded real-time monitoring data with a timestamp before 9:01 and compare it with the currently received remote service data as the reference source. Real-time monitoring data generated after 9:01 (e.g., 9:02) is not included in this comparison because there is no new reference source available.

[0075] In one embodiment, the comparison is triggered when the vehicle reaches its business scenario endpoint.

[0076] For example, the endpoint of a business scenario may include the end of a driving cycle, such as closing the car door, locking the car, or turning off the engine. When a vehicle completes a driving cycle and enters a parked state, parameters such as the vehicle's mileage, power consumption, speed, and location have basically stabilized and no longer change significantly. At this point, both remote service data and real-time monitoring data should be recorded to the same final state. Comparing data at this stable point can effectively avoid misjudgments caused by inconsistent data collection times or asynchronous reporting frequencies.

[0077] For example, the endpoint of a business scenario may include the end of a charging cycle, such as unplugging the charging gun or completing charging. When a vehicle completes a charging cycle, its charging state tends to stabilize (e.g., the State of Charge (SOC) reaches the target value, and the charging current drops to zero). At this point, both data sources should record approximately the same charging result (e.g., the final SOC value). Comparing data at this deterministic moment allows for a more reliable determination of whether the real-time monitoring data has completely recorded the charging process.

[0078] By triggering comparison at the end of the business scenario and selecting a deterministic moment when the vehicle status has stabilized for data verification, misjudgments caused by asynchronous reporting frequency or inconsistent data collection time during data changes can be avoided, thereby improving the accuracy of diagnostic results.

[0079] In one embodiment, the latest record in the remote service data currently reported by the vehicle is compared with the latest record in the real-time monitoring data currently reported by the vehicle.

[0080] For example, the latest record can refer to the newest single data record.

[0081] For remote service data, the "latest record" can refer to the last data record corresponding to the most recently reported key business action. For example, in a charging operation, starting from plugging in the charging gun, the vehicle may report charging status data multiple times (such as charging in progress, plugging in the gun, etc.), and the last record of this charging operation (such as fully charged, unplugging the charging gun, or charging interrupted) is the latest record in this business scenario, reflecting the final state when the charging operation ends.

[0082] For real-time monitoring data, "the latest record" can refer to the most recently reported real-time monitoring data. For example, in the entire driving cycle, it can refer to the last reported record within that cycle; in the charging cycle, it can refer to the last data report received before the end of the charging cycle.

[0083] Furthermore, "latest record" is not limited to a single data point; it can also refer to multiple recently reported records or the latest dataset over a period of time. For example, during vehicle charging, multiple SOC records reported by remote service data can be compared with multiple SOC records reported by real-time monitoring data within the same time period to determine whether their trends are consistent throughout the charging process. By comparing multiple records, a more comprehensive diagnosis of any anomalies in the real-time monitoring data can be made.

[0084] In step S4, based on the comparison results, at least the abnormality in the reporting of the real-time monitoring data is diagnosed.

[0085] In the context of this application, abnormal situations reported in real-time monitoring data can include various types, such as: Reporting anomalies may include: data loss errors (data that should have been reported was not reported), data freeze errors (repeatedly reporting duplicate data), and data interruption errors (data resumed after a period of interruption). The causes of these anomalies may stem from data source node failures, transmission node failures, etc.

[0086] Corresponding to genuine anomalies, certain normal vehicle states (such as vehicle hibernation or power failure) can also cause real-time monitoring data reporting to appear abnormal (e.g., sudden cessation of reporting or repetitive reporting). By comparing dual-channel data, it is possible to effectively distinguish between genuine faults and normal states, thereby avoiding misjudgments. This will be discussed further below. Figures 4 to 7 Further description.

[0087] Figure 4 It shows Figure 3 The flowcharts for the two method steps shown are as follows.

[0088] exist Figure 4 In the embodiments, Figure 3 Step S3 includes sub-steps S31 and S32, and step S4 includes sub-steps S41 and S42.

[0089] In this embodiment, both remote service data and real-time monitoring data include at least a vehicle identification number, accumulated mileage, and a timestamp. Before proceeding to sub-step S31, for example, the remote service data and real-time monitoring data to be compared have been filtered according to preset comparison conditions, which may be, for example, the two most recent records up to the present.

[0090] In sub-step S31, it is determined whether the vehicle identification code in the remote service data and the real-time monitoring data are consistent. If they are consistent, it indicates that the two data sources belong to the same vehicle, and subsequent comparisons can continue; if they are inconsistent, the diagnosis is terminated or marked as a data association error.

[0091] In sub-step S32, check whether the following conditions are met: the timestamp of the remote service data is later than or equal to the timestamp of the real-time monitoring data, and the cumulative mileage of the remote service data is greater than the cumulative mileage of the real-time monitoring data.

[0092] If the condition in sub-step S32 is met, then a data loss error in real-time monitoring is diagnosed in sub-step S41. This condition indicates that when remote service data is triggered to report due to critical vehicle operations (such as locking the vehicle or removing the charging port), the recorded cumulative mileage is already the vehicle's latest mileage, while the cumulative mileage in real-time monitoring data remains at an earlier value and has not been updated synchronously. This means that during the period between the two reports, the vehicle actually traveled new mileage, but the real-time monitoring data failed to record and report these mileage increments, i.e., there is a reporting loss.

[0093] For example, when the vehicle is locked, the mileage recorded by the remote service data is 50km, while the latest mileage recorded by the real-time monitoring data is only 40km, a difference of 10km. This indicates that the real-time monitoring data lost the reported data corresponding to 10km in this driving cycle.

[0094] If the condition in sub-step S32 is not met, other determinations can be performed in sub-step S42. For example, if the failure is due to the timestamp condition not being met, earlier real-time monitoring data can be retrieved for comparison again. Furthermore, it can be further determined whether other types of anomalies exist, or whether both data streams are found to be without anomalies.

[0095] For example, the following determination can be performed in the additional diagnostics: if the timestamp of the remote service data is later than or equal to the timestamp of the real-time monitoring data, and the cumulative mileage of the two is equal, it indicates that neither of the two data streams being compared has reported a loss error.

[0096] Figure 5 It shows Figure 3 Another flowchart of the two method steps shown. Figure 5 In the embodiments, Figure 3Step S3 includes sub-steps S301 and S302, and step S4 includes sub-steps S401 and S402, which are used to illustrate that, in addition to diagnosing reporting anomalies in real-time monitoring data, the data comparison operation can also diagnose reporting anomalies in remote service data.

[0097] In this embodiment, both remote service data and real-time monitoring data include at least vehicle identification number, cumulative mileage, and timestamp.

[0098] Before proceeding to sub-step S301, for example, the latest remote service data and real-time monitoring data to be compared have been filtered according to preset comparison conditions.

[0099] In sub-step S301, it is determined whether the vehicle identification code in the remote service data and the real-time monitoring data are consistent. If they are consistent, it indicates that the two data sources belong to the same vehicle, and subsequent comparisons can continue. If they are inconsistent, the diagnosis is terminated or marked as a data association error.

[0100] In sub-step S302, check whether the following conditions are met: the timestamp of the remote service data is earlier than the timestamp of the real-time monitoring data, and the cumulative mileage of the remote service data is less than the cumulative mileage of the real-time monitoring data.

[0101] If the condition in sub-step S302 is met, then in sub-step S401, a report loss error in remote service data is diagnosed. This condition indicates that the remote service data, serving as a reference source, failed to be collected or reported in a timely manner when critical business actions occurred, causing its recorded timestamps and mileage to lag behind real-time monitoring data. Possible causes of this type of failure include: a fault in a networked vehicle component (such as the HU) preventing data collection; a fault in the communication module of the networked vehicle component preventing data reporting; or an interruption of the link between the vehicle and the backend server. In this case, a diagnostic prompt can be generated, such as a suggestion to send the vehicle to a repair shop for inspection.

[0102] If the condition in sub-step S302 is not met, other determinations are performed in sub-step S402. For example, it can further diagnose whether there are any abnormalities in the real-time monitoring data (such as loss errors or freeze errors), or determine that both data reports are normal.

[0103] Figure 6 It shows Figure 3 Another flowchart of the two method steps shown. In this embodiment, step S3 includes additional sub-steps S311 and S312, and step S4 includes additional sub-steps S411 and S412, which are used to explain that in addition to diagnosing abnormalities in the reporting of real-time monitoring data, the vehicle's dormant state and long-term dormant state can also be determined.

[0104] In this embodiment, both remote service data and real-time monitoring data include at least a vehicle identification number, cumulative mileage, and a timestamp. Unlike the previous embodiments, this embodiment does not compare real-time monitoring data and remote service data; instead, it compares and analyzes the two most recent reports of remote service data.

[0105] In sub-step S311, it is determined whether the vehicle identification codes of the two most recently reported remote service data are consistent. If they are consistent, it indicates that the two reports belong to the same vehicle, and subsequent comparisons can continue; if they are inconsistent, the diagnosis is terminated or marked as a data association error.

[0106] In sub-step S312, check whether the following conditions are met: the cumulative mileage of the latest and the previous remote service data are the same, indicating that the vehicle has not been driven during this period; and the latest reported remote service data is not triggered by the door opening and closing action, meaning that the last report is not a door opening or closing event (e.g., it may be a car locking event or a periodic heartbeat).

[0107] If the condition in sub-step S312 is met, it indicates that the vehicle did not move between the two reports, and there is a high probability that no personnel will enter or exit afterward, which meets the characteristics of a vehicle in hibernation. Therefore, in sub-step S411, it is determined that the vehicle has entered hibernation mode. If the condition is not met, monitoring continues in this sub-step until the next remote service data report is submitted before making a judgment.

[0108] In sub-step S412, timing and monitoring begin from the moment the vehicle is determined to enter a hibernation state. If the vehicle remains in a hibernation state for a period exceeding a preset time threshold (e.g., 3 months), it is determined to be a long-term hibernation vehicle.

[0109] Once a vehicle is determined to be in a long-term dormant state, its status can be recorded and filed in the backend server, for example, marked as "long-term dormant". This record can be used to explain to the relevant regulatory platform for new energy vehicles that the vehicle's failure to report data during the long-term dormant period is normal, rather than a failure of the real-time monitoring terminal or loss of data reporting, thereby avoiding misjudging the lack of data reporting due to dormancy as an abnormal reporting situation.

[0110] Figure 7 It shows Figure 3 Another flowchart of the two method steps shown. Figure 7 In the embodiments, Figure 3 Step S3 is shown as including sub-steps S321 and S322, and step S4 is shown as including sub-steps S421 and S422, which are used to illustrate that in addition to diagnosing errors of lost real-time monitoring data, the data comparison operation can also diagnose freezing errors.

[0111] In this context, a freeze error refers to a situation where real-time monitoring data is continuously reported, but the data content remains unchanged for a long time, failing to reflect actual changes in the vehicle's status.

[0112] In this embodiment, both remote service data and real-time monitoring data include at least a vehicle identification number and a timestamp, as well as SOC, vehicle speed, and / or geographic location.

[0113] Before proceeding to sub-step S321, for example, the latest remote service data and real-time monitoring data within the same time period have been filtered out according to preset comparison conditions.

[0114] In sub-step S321, it is determined whether the vehicle identification code in the remote service data and the real-time monitoring data are consistent. If they are consistent, it indicates that the two data sources belong to the same vehicle, and subsequent comparisons can continue. If they are inconsistent, the diagnosis is terminated or marked as a data association error.

[0115] In sub-step S322, check whether the following conditions are met: for the same time period, the remote service data records show that the SOC, vehicle speed and / or geographical location have changed, while the real-time monitoring data shows that the SOC, vehicle speed and / or geographical location have not changed in the corresponding time period.

[0116] If the condition in sub-step S322 is met, it indicates that the actual state of the vehicle has changed (e.g., SOC increases, vehicle speed changes, position moves), but the real-time monitoring data has not been updated synchronously and remains at the value before the change. Based on this, a freeze error in the real-time monitoring data is diagnosed in sub-step S421.

[0117] For example, during the charging process, the vehicle continuously reports multiple remote service data points, showing that the vehicle's SOC has increased from 50% to 80%, but the SOC value in the real-time monitoring data remains at 50%. Or, after the vehicle starts, the speed accelerates from 0 km / h to 60 km / h, but the speed value in the real-time monitoring data always shows 0 km / h.

[0118] If the condition in sub-step S322 is not met, other determinations can be performed in sub-step S422, such as diagnosing other types of abnormalities or performing further verification.

[0119] Figure 8 A schematic diagram is shown illustrating the use of the method according to this application in an exemplary application scenario to diagnose errors caused by the loss of real-time monitoring data.

[0120] like Figure 8 As shown, the data in Table 81 on the left is the remote service data reported by the vehicles, and the data in Table 82 on the right is the real-time monitoring data reported by the vehicles. Both sets of data are stored on the backend server.

[0121] When a vehicle performs a critical business action (such as opening or closing doors, locking or unlocking the vehicle), the vehicle reports remote service data. In this embodiment, a comparison operation between the remote service data and real-time monitoring data is triggered at the end of the business scenario (such as when the vehicle is locked).

[0122] The data blocks marked with shaded areas in Table 81 on the left correspond to remote service data 811 and 812, which are triggered by the critical business action of locking the vehicle at the end of the two driving cycles.

[0123] The data blocks marked with shaded areas in Table 82 on the right correspond to the last real-time monitoring data 821 and 822 obtained at the end of the two driving cycles, up to the time when remote service data 811 and 812 were received.

[0124] As shown in the figure, a total of two data comparisons were performed: The first comparison occurred at 7:05 when the vehicle was locked. Remote service data 811 reported the vehicle locking event at 7:05, with a cumulative mileage of 100.0 kilometers; real-time monitoring data 821 last recorded a cumulative mileage of 100.0 kilometers at 7:04. Since the mileages were equal, it was determined that no real-time monitoring data loss error occurred.

[0125] The second comparison occurred at 14:03 when the vehicle was locked. Remote service data 812 reported the vehicle locking event at 14:03, with a cumulative mileage of 120.0 km; real-time monitoring data 822 last recorded a cumulative mileage of 115.0 km at 13:30. Both the time and mileage recorded by real-time monitoring data 822 lagged behind those recorded by remote service data 812. This indicates that the vehicle traveled a cumulative 20.0 km (from 100.0 km to 120.0 km) between 7:05 and 14:03, but the mileage increment recorded by real-time monitoring data 822 was only 15.0 km (from 100.0 km to 115.0 km), a shortfall of 5.0 km. Therefore, it was determined that there was a reporting error in the real-time monitoring data.

[0126] Figure 9 A schematic diagram is shown illustrating the use of the method according to this application in an exemplary application scenario to diagnose a freezing error in real-time monitoring data.

[0127] As shown in the figure, the data in Table 81 on the left is the remote service data reported by the vehicles, and the data in Table 82 on the right is the real-time monitoring data reported by the vehicles. Both sets of data are stored in the backend server.

[0128] The data blocks marked with shaded areas in Table 81 on the left correspond to remote service data 815, 816, and 817 reported during vehicle charging, such as key business actions like plugging in the charging gun, charging in progress, and unplugging the charging gun. Among them, remote service data 816 records the change in vehicle SOC during charging: gradually increasing from an initial 50% to 80%.

[0129] The data blocks marked with shaded areas in Table 82 on the right represent real-time monitoring data 825 reported by vehicles within the same time period. As can be observed, the vehicle SOC changes recorded in real-time monitoring data 825 are as follows: after rising from an initial 50% to 60%, it remains at 60%. Although there were multiple subsequent reports (with timestamps continuously increasing), the SOC value never changed again.

[0130] Comparing the two sets of data reveals that: remote service data 816 shows the vehicle's SOC normally increasing from 50% to 80% during charging, while real-time monitoring data shows the vehicle's SOC stagnating after reaching 60%, failing to reflect subsequent actual SOC growth. Therefore, real-time monitoring data 825 is determined to have a freeze error; although data is continuously reported, the content is repetitive and fails to update with changes in the vehicle's actual status.

[0131] Figure 10 A schematic diagram is shown illustrating the use of the method according to this application in an exemplary application scenario to diagnose anomalies in remote service data reporting.

[0132] As shown in the figure, the data in Table 81 on the left is the remote service data reported by the vehicles, and the data in Table 82 on the right is the real-time monitoring data reported by the vehicles. Both sets of data are stored in the backend server.

[0133] In this embodiment, a comparison operation is performed, for example, at the end of a driving cycle, to diagnose reporting anomalies in remote service data. For this purpose, the latest record 819 from the remote service data and the latest record 829 from the real-time monitoring data are extracted. The results show that the timestamp of the last reported remote service data 819 is 15:30, with a cumulative mileage of 100.0 km; the timestamp of the last reported real-time monitoring data 829 is 17:00, with a cumulative mileage of 120.0 km. Both the timestamp and cumulative mileage of remote service data 819 are less than those of real-time monitoring data 829.

[0134] This indicates that when data was aggregated at the end of the driving cycle, the vehicle status and time recorded by the latest remote service data lagged behind the latest status recorded by real-time monitoring data 829. The last 20 kilometers of the vehicle's journey before the end were not recorded by the remote service data.

[0135] Therefore, it can be reasonably inferred that at the end of this driving cycle, the remote service data should have been triggered by critical business actions such as closing or locking the car, but in reality, no corresponding reporting record was generated, or the reported data failed to reach the backend server. This indicates an anomaly in the remote service data reporting. Common causes of such anomalies include: failure of connected vehicle components (such as the HU) preventing data collection, communication module failure preventing data reporting, or interruption of the link between the vehicle and the cloud. In this case, a diagnostic prompt can be generated, recommending that the vehicle owner visit a repair shop to have the connected vehicle components inspected.

[0136] It should be noted that Figures 8 to 10 The timestamp resolution in the illustrated embodiment is merely exemplary; higher precision can be used in practical applications. Furthermore, remote service data is not limited to event-triggered types; it can also be configured for periodic reporting, such as reporting at a lower frequency.

[0137] Although specific embodiments of this application are described in detail herein, they are given for illustrative purposes only and should not be construed as limiting the scope of this application. Various substitutions, modifications, and alterations can be conceived without departing from the spirit and scope of this application.

Claims

1. A method for diagnosing abnormal data reporting in vehicles (1), the method comprising the following steps: Obtain real-time monitoring data (32) collected and reported by the vehicle (1) through the first vehicle terminal data link; Obtain remote service data (31) collected and reported by the vehicle (1) through the second vehicle-side data link, wherein the first vehicle-side data link and the second vehicle-side data link are at least partially independent; The real-time monitoring data (32) that meets the predetermined comparison conditions is compared with the remote service data (31); as well as Based on the comparison results, at least the abnormality in the reporting of the real-time monitoring data (32) can be diagnosed.

2. The method according to claim 1, wherein, The first vehicle-side data link and the second vehicle-side data link are at least partially independent, including: The real-time monitoring data (32) and the remote service data (31) are collected through different vehicle-side source nodes; Specifically, the real-time monitoring data (32) is collected through the real-time monitoring terminal (12) or T-BOX of the vehicle (1); the remote service data (31) is collected through a network-enabled vehicle component (13), which includes at least one of the following: an infotainment host, a body control module, a door control module and / or a vehicle controller.

3. The method according to claim 1 or 2, wherein, The first vehicle-side data link and the second vehicle-side data link are at least partially independent, including: The real-time monitoring data (32) and the remote service data (31) are sent through different vehicle-side communication nodes; Specifically, the real-time monitoring data (32) is transmitted via the built-in communication unit of the real-time monitoring terminal (12) of the vehicle (1), and the remote service data (31) is transmitted via the built-in communication unit of the network-enabled vehicle component (13) or via T-BOX, or The real-time monitoring data (32) is sent through the T-BOX, and the remote service data (31) is sent through the built-in communication unit of the network-connected vehicle component (13).

4. The method according to any one of claims 1 to 3, wherein, The remote service data (31) is reported by the vehicle’s key business actions, which include: unlocking the vehicle, starting the vehicle, turning off the vehicle, locking the vehicle, plugging in the charging gun, unplugging the charging gun, charging in progress, opening the car door and / or closing the car door.

5. The method according to any one of claims 1 to 4, wherein, The real-time monitoring data (32) and remote service data (31) that meet the predetermined comparison criteria are compared, including: Compare the latest record in the remote service data (31) currently reported by vehicle (1) with the latest record in the real-time monitoring data (32) currently reported by vehicle (1).

6. The method according to any one of claims 1 to 5, wherein, The real-time monitoring data (32) and remote service data (31) that meet the predetermined comparison criteria are compared, including: In response to receiving remote service data (31) reported by vehicle (1), the comparison is triggered; Specifically, the acquired remote service data (31) is compared with the last acquired real-time monitoring data (32) up to the time when the remote service data (31) is received.

7. The method according to any one of claims 1 to 6, wherein, The real-time monitoring data (32) and remote service data (31) that meet the predetermined comparison criteria are compared, including: The comparison is triggered when the vehicle (1) reaches the end of the business scenario, wherein the end of the business scenario includes: the end of the driving cycle, and / or the end of the charging cycle.

8. The method according to any one of claims 1 to 7, wherein, The real-time monitoring data (32) includes at least the vehicle identification code, cumulative mileage and timestamp; the remote service data (31) includes at least the vehicle identification code and cumulative mileage, and also includes timestamp or associated with a corresponding timestamp.

9. The method according to claim 8, wherein, Based on the comparison results, at least the following abnormalities in the reporting of the real-time monitoring data (32) can be diagnosed: If the remote service data (31) and the real-time monitoring data (32) contain the same vehicle identification number, If the timestamp of the remote service data (31) is later than or equal to the timestamp of the real-time monitoring data (32), and the cumulative mileage of the remote service data (31) is greater than the cumulative mileage of the real-time monitoring data (32), then the real-time monitoring data (32) is diagnosed as having a loss error.

10. The method according to claim 8 or 9, wherein, The method further includes: diagnosing any abnormalities in the reporting of remote service data (31) based on the comparison results. Specifically, if the remote service data (31) and the real-time monitoring data (32) contain the same vehicle identification code, and if the timestamp of the remote service data (31) is earlier than the timestamp of the real-time monitoring data (32), and the cumulative mileage of the remote service data (31) is less than the cumulative mileage of the real-time monitoring data (32), then the remote service data (31) is diagnosed as having a loss error.

11. The method according to any one of claims 8 to 10, wherein, The method further includes: monitoring the sleep state of the vehicle (1) based on the latest and previous remote service data (31). Specifically, if the two remote service data (31) obtained contain the same vehicle identification code, and the cumulative mileage of the latest and the previous reported remote service data (31) is the same, and the latest reported remote service data (31) is not triggered by the door opening and closing action, then the vehicle (1) is determined to enter a dormant state; the timer starts from the moment the dormant state is determined, and if the vehicle (1) remains in a dormant state for a longer period of time than the preset time threshold, then it is determined to be a long-term dormant vehicle.

12. The method according to any one of claims 1 to 11, wherein, The remote service data (31) and the real-time monitoring data (32) both include at least a vehicle identification number and a timestamp, and at least one of the following: SOC, vehicle speed and / or geographical location. Based on the comparison results, at least the reporting anomalies of the real-time monitoring data (32) are diagnosed, and the data also includes: If the remote service data (31) and the real-time monitoring data (32) contain the same vehicle identification code, and for the same time period, if the remote service data (31) records changes in SOC, vehicle speed and / or geographical location, while the real-time monitoring data (32) does not change in SOC, vehicle speed and / or geographical location in the corresponding time period, then the real-time monitoring data (32) is diagnosed as having a freeze error.

13. An apparatus (50) for diagnosing vehicle data reporting anomalies, the apparatus (50) comprising a memory and a processor, the memory storing computer program instructions, wherein when the computer program instructions are executed by the processor, the processor is capable of performing the method according to any one of claims 1 to 12.

14. A backend server (5), the backend server (5) comprising the apparatus (50) according to claim 13.

15. A computer program product comprising computer program instructions, wherein, When executed by a processor, the computer program instructions enable the processor to perform the method according to any one of claims 1 to 12.

Images