Abnormality alarm method, device, equipment and storage medium

Abstract

The application discloses an abnormality alarm method and device, equipment and storage medium, and relates to the technical field of vehicle abnormality alarm, and comprises the following steps: when a triggering condition signal of a vehicle is detected, starting a timer to start timing; when the timing duration of the timer reaches a determination duration, obtaining the current state of the vehicle-mounted communication module in the current timing period; if the current state determines that the vehicle-mounted communication module is in a disconnected state, obtaining an abnormality confirmation signal corresponding to the triggering condition signal, and performing abnormality alarm according to the abnormality confirmation signal. By confirming whether the abnormal state signal continuously exists in the timing period and is actively eliminated by the user before triggering the alarm, the real abnormal state of the vehicle and the false alarm situation caused by the communication transient fluctuation or the user intervention in the middle are effectively distinguished, and the accuracy and reliability of the alarm are significantly improved.

Description

Technical Field

[0001] This application relates to the field of vehicle abnormal alarm diagnosis technology, and in particular to an abnormal alarm method, device, equipment and storage medium. Background Technology

[0002] Currently, vehicle anomaly alarm systems typically employ a state detection mechanism based on time thresholds, relying solely on whether a logout message has been received as the alarm trigger criterion, without verifying the continuity and authenticity of the abnormal state signal before and after the logout time.

[0003] When a vehicle is in a special state, the vehicle communication module may trigger a false logout due to a momentary communication anomaly, or the abnormal state signal may have been actively eliminated by the user during the timing period but the system failed to recognize it in time, causing the vehicle that has returned to normal to be misjudged as being in an abnormal state and generating an alarm, which seriously affects the accuracy of the alarm and the user's trust. Summary of the Invention

[0004] The main purpose of this application is to provide an abnormal alarm method, device, equipment and storage medium, which aims to solve the technical problem that existing vehicles are prone to misjudging a vehicle that has returned to normal as an abnormal state and generating an alarm under special conditions.

[0005] To achieve the above objectives, this application proposes an anomaly alarm method, the method comprising: When a trigger condition signal is detected that the vehicle has generated a trigger condition signal, a timer is started to count. The trigger condition signal includes a high-voltage status signal and an abnormal status signal. When the timer reaches the determination duration, the current status of the vehicle communication module within the current timing period is obtained; If the current state determines that the vehicle communication module is disconnected, an abnormal confirmation signal corresponding to the trigger condition signal is obtained, and an abnormal alarm is issued based on the abnormal confirmation signal.

[0006] Optionally, after obtaining the current state of the vehicle communication module within the current timing period when the timer's timing duration reaches the determination duration, the method further includes: If the current state determines that the vehicle communication module is in an undisconnected state, then the first timestamp of the state data corresponding to the trigger condition signal is obtained, and the state data includes high voltage state data and abnormal state data; Obtain the second timestamp of the heartbeat data of the vehicle communication module; Determine the time difference between the current time and the first and second timestamps; When the time difference is less than the determination duration, the abnormal state signal is determined to be reliable within the current timing period, and an abnormal alarm is issued based on the abnormal state signal.

[0007] Optionally, determining the time difference between the current time and the first timestamp and the second timestamp includes: Construct an effective time window based on the second timestamp and the current timing period; If the first timestamp is within the valid time window, then the status data corresponding to the first timestamp is determined to be reliable data, and the first timestamp is determined to be a reliable timestamp. Calculate the difference between the current time and the trusted timestamp to obtain the time difference.

[0008] Optionally, when the timer's duration reaches the determination duration, obtaining the current state of the vehicle communication module within the current timing period includes: When the timer reaches the determination duration, it is determined whether the vehicle communication module has exited the network connection within the current timing period, and the determination result is obtained. The current state of the vehicle communication module is determined based on the judgment result.

[0009] Optionally, determining the current state of the vehicle communication module based on the judgment result includes: If the message type identifier sent by the vehicle communication module is a logout message identifier, then the current state of the vehicle communication module is determined to be disconnected. If the message type identifier sent by the vehicle communication module is a non-logout message identifier, and the vehicle communication module switches from online to offline state, then the current state of the vehicle communication module is determined to be the disconnected state. If the message type identifier sent by the vehicle communication module is a non-logout message identifier, and the vehicle communication module remains online, then the current state of the vehicle communication module is determined to be an undisconnected state.

[0010] Optionally, before obtaining the current state of the vehicle communication module within the current timing period when the timer's timing duration reaches the determination duration, the method further includes: Get the current vehicle status data refresh time and maximum communication latency; The state stability observation time for each state data is determined based on the state data refresh time. The determination duration of the current timing cycle is determined based on the maximum communication delay time and the state stabilization observation time.

[0011] Optionally, after starting the timer when the vehicle generates a trigger condition signal, the method further includes: If a change in the state of the high-voltage state signal in the trigger condition signal is detected within the current timing period, the trigger condition signal is determined to be invalid, the timing of the timer is terminated, and the timer is reset to its initial state. If the current state determines that the vehicle communication module is disconnected within the current timing period, and there is no abnormal confirmation signal corresponding to the trigger condition signal, then no abnormal alarm will be issued. If the current state determines that the vehicle communication module is not disconnected within the current timing period, and the time difference corresponding to the abnormal state signal is greater than or equal to the determination duration, then no abnormal alarm will be issued.

[0012] Furthermore, to achieve the above objectives, this application also proposes an anomaly alarm device, which includes: The timing module is used to start a timer when a trigger condition signal is detected generated by the vehicle. The trigger condition signal includes a high-voltage status signal and an abnormal status signal. The acquisition module is used to acquire the current status of the vehicle communication module within the current timing period when the timing duration of the timer reaches the determination duration. The alarm module is used to obtain an abnormal confirmation signal corresponding to the trigger condition signal if the current state determines that the vehicle communication module is in a disconnected state, and to issue an abnormal alarm based on the abnormal confirmation signal.

[0013] In addition, to achieve the above objectives, this application also proposes an anomaly alarm device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the anomaly alarm method as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the abnormal alarm method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the exception alarm method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: By obtaining the current status of the vehicle communication module after the judgment time has elapsed, and further obtaining the abnormal confirmation signal as the final basis for alarm when the disconnection is confirmed, it is possible to confirm whether the abnormal status signal has been present for a period of time and has not been actively eliminated by the user before the alarm is triggered. This effectively distinguishes between the real abnormal status of the vehicle and false alarms caused by instantaneous communication fluctuations or user intervention, significantly improving the accuracy and reliability of alarms. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the abnormal alarm method of this application; Figure 2 This is a flowchart illustrating the second embodiment of the abnormal alarm method of this application; Figure 3 This is a flowchart illustrating the third embodiment of the abnormal alarm method of this application; Figure 4 This is a schematic diagram of the module structure of the abnormal alarm device according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the abnormal alarm method in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] Based on this, the embodiments of this application provide an anomaly alarm method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the abnormal alarm method of this application.

[0024] It should be noted that the executing entity in this embodiment can be the vehicle itself, or it can be an anomaly alarm device installed in the vehicle to control the vehicle. The anomaly alarm device can be a controller installed in the vehicle, such as an ECU controller, or other devices that can achieve the same or similar functions. This embodiment does not limit this. In this embodiment and the following embodiments, the anomaly alarm device is used as an example to describe the anomaly alarm method of this embodiment.

[0025] In this embodiment, the abnormal alarm method includes: Step S10: When a trigger condition signal is detected generated by the vehicle, a timer is started to begin counting. The trigger condition signal includes a high-voltage status signal and an abnormal status signal.

[0026] It should be noted that the trigger condition signal is a composite judgment signal composed of the vehicle's high-voltage power supply status and the abnormal status of vehicle components. It is used to characterize abnormal situations that may have been overlooked by the user when the vehicle is unattended. The high-voltage status signal indicates whether the vehicle's high-voltage electrical system is in a closed state. When the high-voltage status signal indicates that the high-voltage system is closed, it means that the vehicle's power system has stopped working and the vehicle is in a non-driving state. The abnormal status signal triggers the abnormality detection logic to indicate whether any vehicle components are not in their normal closed or locked positions, including but not limited to at least one of the following: doors not closed, windows not locked, hood not closed, trunk not closed.

[0027] It is understood that in this embodiment, the trigger condition signal includes a high-voltage status signal and an abnormal status signal. The high-voltage status signal indicates that the high voltage is OFF, and the abnormal status signal indicates that an abnormality has occurred in various components of the vehicle. It should be understood that when the vehicle generates a trigger condition signal, it also means that the corresponding vehicle status data has been acquired. The generation of a trigger condition signal by the vehicle indicates that the vehicle has simultaneously acquired both high-voltage data and abnormal status data.

[0028] It should be noted that the timer is started only when a trigger condition signal is detected, rather than immediately when a single signal appears. This is because the combination of a high-voltage state signal being off and an abnormal state signal being present simultaneously can initially filter out special candidate scenarios where "the vehicle is powered off but there are residual abnormalities." This filters out signal fluctuations caused by brief operations during normal vehicle operation, thus avoiding unnecessary alarm interference in normal usage scenarios.

[0029] Understandably, starting the timer does not immediately trigger an alarm, but rather initiates a preset observation and waiting period. Within this period, the system allows a certain time window for the user to actively return to the vehicle to resolve the abnormal state, or for the communication module to complete the normal logout process. By setting a timer delay for judgment, a balance can be struck between the duration of the abnormal state and the timeliness of the alarm response. This avoids frequent false alarms for users who return immediately after a brief absence, while ensuring a timely response to genuine forgetfulness anomalies.

[0030] Understandably, in the specific implementation process, to further enhance the ability to distinguish between scenarios of "user temporarily leaving" and "vehicle being forgotten," the trigger condition signal can also incorporate at least one of the following as auxiliary judgment elements: power-related signals, user behavior signals, and environmental signals. Power-related signals include low-voltage battery voltage signals and DC-DC operating status signals. Whether the low-voltage battery voltage continuously decreases reflects whether the vehicle continues to consume power after the high-voltage power is cut off. If the low-voltage battery voltage shows a continuous downward trend, it indicates that the vehicle's electrical load has not been properly dormant, proving that the vehicle is in an abnormal abandoned state rather than a normal temporary stop. User behavior signals include key position signals and mobile phone Bluetooth connection status signals. A key inside the vehicle or a mobile phone maintaining a Bluetooth connection usually indicates that the user is still near the vehicle and may return. Conversely, a key outside the vehicle and a disconnected Bluetooth connection indicate that the user has left the vehicle, and the vehicle is more likely to be forgotten. Environmental signals include occupant detection signals and air conditioning operating status signals. Occupant detection signals can be obtained through sensors such as vital sign radar to directly determine whether there are occupants inside the vehicle. The air conditioning operating status can indirectly reflect whether the vehicle is in use.

[0031] Optionally, the generation logic of the trigger condition signal can adopt a hierarchical combination approach. At the first level, the high-voltage state signal being off and the presence of an abnormal state signal are used as the basic trigger conditions. At the second level, at least one of the following is introduced as an auxiliary confirmation condition: a power-related signal, a user behavior signal, and an environmental signal. Only when the auxiliary confirmation condition simultaneously indicates that the vehicle is in an unattended state is the trigger condition signal finally confirmed and the timer started. This effectively filters out special usage scenarios where users are still present, such as temporary stops, short rests, and display vehicles, while ensuring that no genuine anomalies are missed, thus reducing the probability of false triggers at the source.

[0032] Step S20: When the timer reaches the determination duration, obtain the current status of the vehicle communication module within the current timing period.

[0033] It should be noted that the determination duration is a predetermined timing threshold, used to provide the system with a sufficient observation window after the trigger condition signal is detected. This ensures that the communication link data has been fully updated while providing sufficient time margin for the continuous verification of abnormal states. In this embodiment, the vehicle communication module (i.e., TCU) can be used to provide vehicle communication status information.

[0034] Understandably, when the trigger condition signal is first generated, the vehicle communication module (TCU) may be in the process of logging out, or the communication link may be in a transition phase of state switching. If the communication module status is obtained immediately at this time, it may capture an intermediate state that has not yet completed the state transition, leading to a misjudgment of the true state of the communication module. Therefore, by waiting for the determination period before obtaining the status, it can be ensured that the communication module has completed the possible state switching process, so that the obtained current status can accurately reflect whether the vehicle has entered low-power offline mode.

[0035] It should be understood that obtaining the current status of the vehicle communication module can determine whether the vehicle has completed the normal communication logout process during the period of abnormal status. When the vehicle communication module is disconnected, it indicates that the vehicle has completed network logout according to the preset process and actively entered low power or offline mode, or the current status of the vehicle's vehicle communication module has changed from online to offline. When the vehicle communication module is not disconnected, it indicates that the vehicle communication link is still online. It is necessary to further determine whether the vehicle status data obtained at this time is true and valid, in order to distinguish whether the vehicle is indeed in an abnormal state or the data has been invalidated due to communication interruption, thereby providing an accurate decision-making basis for whether to trigger an alarm.

[0036] In the specific implementation process, the current vehicle status data refresh time and maximum communication latency time can be obtained. The status stabilization observation time can be determined based on the status data refresh time. Then, the judgment duration is determined based on the sum of the maximum communication latency time and the status stabilization observation time. This makes the judgment duration no longer a fixed empirical value, but a dynamic parameter that can be adaptively adjusted according to the vehicle's actual communication environment and data refresh frequency. This ensures both the real-time nature of the judgment and provides a sufficient observation window for whether the abnormal state persists. Before step S20, the following steps are also included: Get the current vehicle status data refresh time and maximum communication latency; The state stability observation time for each state data is determined based on the state data refresh time. The determination duration of the current timing cycle is determined based on the maximum communication delay time and the state stabilization observation time.

[0037] It should be noted that, compared to directly using a fixed empirical value as the judgment duration, the judgment duration in this embodiment is dynamically determined based on the actual communication environment parameters and status data refresh characteristics of the vehicle. This is because the data reporting cycle and network latency of the vehicle communication module vary under different vehicle models and different communication network environments. If a uniform and fixed judgment duration is used, it may lead to judgments being made too early in scenarios with poor communication environments before the data has been updated, or judgments being made too late in scenarios with good communication environments before timely alarm responses.

[0038] The status data refresh time refers to the time interval at which the vehicle communication module reports vehicle status data to the vehicle or cloud at a fixed period. This period is usually determined by the hardware capabilities of the vehicle communication module and the network protocol. The maximum communication latency time refers to the maximum data transmission delay that may occur due to factors such as cellular network signal fluctuations, base station switching, and network congestion during the process of vehicle status data being sent from the vehicle communication module and transmitted through the communication network to the cloud or user terminal.

[0039] Understandably, the state stabilization observation time is determined based on the state data refresh time and serves as an observation window to verify the persistence of abnormal state signals after the timer starts. When the vehicle enters a special mode or the user briefly leaves, the abnormal state signal may change within a short period (e.g., when the user returns and closes the door). Therefore, an observation window covering several data refresh cycles is needed to confirm whether the abnormal state signal is persistent rather than a momentary fluctuation. The state stabilization observation time is typically a preset multiple of the state data refresh time to ensure that at least several data refresh cycles have elapsed before the judgment time arrives, thus obtaining sufficient signal sampling points for continuous judgment.

[0040] In one example, the stable state observation time is dynamically determined based on the state data refresh time, and can be 2 to 3 times the state data refresh time. For example, when the state data refresh time is 10 seconds, the stable state observation time is 30 seconds; when the state data refresh time is 30 seconds, the stable state observation time is 60 seconds. This dynamic correlation mechanism can keep the number of sampling points in the observation window relatively stable, avoiding the problem of inconsistent observation sufficiency under different vehicle models or different communication configurations due to differences in refresh cycles.

[0041] Optionally, the maximum communication delay time can be dynamically adjusted according to the quality of the network environment in which the vehicle is currently located. For example, in a weak network environment where the network signal strength is lower than a preset threshold, the value of the maximum communication delay time can be appropriately extended to adapt to the deterioration of the current communication conditions and ensure the rationality of the judgment duration.

[0042] In one example, the time threshold N is determined by a combination of the system communication cycle T1, communication delay T2, and state stabilization time T3. T1 is the vehicle status data refresh cycle (the vehicle TCU sends data, including door status, to the vehicle or cloud at fixed intervals), typically 10-30 seconds. T2 is the maximum communication delay (vehicle data experiences a certain delay in the communication network, including TCU → network → cloud → user terminal); considering the overall communication environment, the maximum data delay is typically 20-30 seconds. T3 is the state stabilization observation time (when the vehicle enters a special mode, the vehicle status may change rapidly, such as when doors are opened or closed; therefore, a state stabilization observation window is needed to confirm whether the abnormal state persists). This time is typically set to 2-3 data refresh cycles, i.e., T3 is 2-3 times T1. Combining these parameters, the formula for calculating N should be N = T2 + T3, where T2 covers the communication delay, and T3 ensures vehicle state stability. In this embodiment, T1 = 10s, T2 = 30s, T3 = 30s, that is, N = T2 + T3 = 60s.

[0043] Step S30: If the current state determines that the vehicle communication module is in a disconnected state, then obtain the abnormal confirmation signal corresponding to the trigger condition signal, and issue an abnormal alarm based on the abnormal confirmation signal.

[0044] It should be noted that the anomaly confirmation signal is a secondary verification signal used to confirm whether the abnormal state signal persists within the timing period. When the vehicle communication module is determined to be disconnected, it indicates that the vehicle has completed network deregistration according to the preset procedure and actively entered low-power mode or passively entered offline mode. At this time, the vehicle is in an unattended state. However, in special modes (such as temporary parking), the abnormal state signal in the trigger condition signal may have been cleared by the user during the timing period. Therefore, before triggering the alarm, it is necessary to obtain the anomaly confirmation signal again to confirm that the abnormal state signal does indeed persist within the timing period, rather than being cleared during the timing process.

[0045] In one example, a user triggers a timer after leaving the vehicle, then returns and closes the door, just as the vehicle communication module completes its logout process. If an alarm is triggered solely based on the disconnected state, the user's active resolution of the anomaly would be misinterpreted as a persistent anomaly, generating unnecessary and disruptive alarms. By obtaining an anomaly confirmation signal for final verification, a filtering mechanism can be built at the final stage of alarm output, ensuring that an alarm is only triggered if the anomaly has genuinely not been addressed.

[0046] Specifically, as an optional implementation, the method for obtaining the anomaly confirmation signal may include: after determining that the vehicle communication module is in a disconnected state, sending an anomaly status query request to the vehicle status acquisition unit, receiving the actual sampled values ​​of each anomaly status signal at the current time returned by the vehicle status acquisition unit, and using the actual sampled values ​​as the anomaly confirmation signal. If the anomaly confirmation signal still indicates that at least one anomaly status signal remains valid, it is determined that the anomaly status has not been eliminated within the timing period, and an anomaly alarm is triggered; if the anomaly confirmation signal indicates that all anomaly status signals have returned to normal, it is determined that the anomaly status has been processed, the timer is terminated, and the alarm is canceled.

[0047] Optionally, the method of issuing an anomaly alarm based on the anomaly confirmation signal may include generating an anomaly alarm command and sending the anomaly alarm command to the cloud service platform through the last valid communication link established by the vehicle communication module before logout, or sending it to a preset user terminal through a backup communication channel other than the vehicle communication module, to notify the user that there is an unresolved abnormal state of the vehicle. Simultaneously, the trigger time of this alarm event, the type of abnormal state, and the corresponding anomaly confirmation signal sampling data are recorded for subsequent alarm accuracy analysis and system optimization.

[0048] Optionally, when the vehicle enters a "low power / offline state," an anomaly confirmation signal is detected. If the vehicle is already running (high voltage = ON), a logout message is typically not sent. Therefore, the anomaly confirmation signal only contains the anomaly status signal. Thus, to confirm whether the anomaly status persists for N time periods, the anomaly status signal needs to be detected again. If it exists, an alarm is output; otherwise, the process is terminated.

[0049] Understandably, if after determining that the vehicle communication module is disconnected, the acquired abnormal confirmation signal indicates that the abnormal state signal has disappeared, it means that the user has returned to the vehicle and eliminated the abnormality within the timekeeping period. At this time, the timer is terminated and the alarm process is canceled. The system then re-enters the state of listening to the trigger condition signal and waits for the next trigger condition to be met.

[0050] In the specific implementation process, the maintenance status of the trigger condition signal can be continuously monitored during the timing process. Timing can be terminated or maintained under different circumstances, such as a change in the high-voltage status signal, the absence of an anomaly confirmation signal, or a time difference exceeding a judgment threshold. This avoids continuing invalid timing waits even after the user has actively eliminated the anomaly or the high-voltage status has recovered, thus improving the system's real-time responsiveness and resource utilization efficiency. After step S30, the following steps are also included: If a change in the state of the high-voltage state signal in the trigger condition signal is detected within the current timing period, the trigger condition signal is determined to be invalid, the timing of the timer is terminated, and the timer is reset to its initial state. If the current state determines that the vehicle communication module is disconnected within the current timing period, and there is no abnormal confirmation signal corresponding to the trigger condition signal, then no abnormal alarm will be issued. If the current state determines that the vehicle communication module is not disconnected within the current timing period, and the time difference corresponding to the abnormal state signal is greater than or equal to the determination duration, then no abnormal alarm will be issued.

[0051] It should be noted that throughout the entire timer operation, the device continuously monitors the maintenance status of the trigger condition signal and the various preconditions for the judgment result. This is because the vehicle's high-voltage power supply status, abnormal status signals, and communication module status may all change during the timing period. If these changes are not responded to in real time, the alarm logic will become disconnected from the actual vehicle status, resulting in false alarms or missed alarms.

[0052] Understandably, a change in the high-voltage status signal means that after the timer starts, the high-voltage status signal, which was originally in the off state, switches back to the on state. This change in the high-voltage status signal indicates that the vehicle's power system has been reactivated, the driver has returned to the vehicle and is preparing for or has already begun driving. At this point, the fundamental premise of "vehicle power off" upon which the trigger condition signal depends no longer holds. Therefore, the original trigger condition signal should be deemed invalid, and the timer should immediately stop counting and reset to its initial state, awaiting the next fulfillment of the trigger condition.

[0053] Understandably, when the vehicle communication module is determined to be disconnected but no abnormal confirmation signal corresponding to the trigger condition signal exists, it indicates that the abnormal state signal may have been actively eliminated by the user before the communication module logs out within the timer period. For example, if a user leaves the vehicle without closing the door, triggering the timer, but returns and closes the door before the communication module completes the logout process, the disconnected state is still valid, but the abnormal state no longer exists. In this case, not issuing an abnormal alarm avoids repeatedly notifying the user of issues that have already been actively addressed, reducing unnecessary interference.

[0054] Understandably, when the vehicle communication module is determined to be in an active state, but the time difference corresponding to the abnormal state signal is greater than or equal to the judgment duration, it indicates that although the communication module appears online at the protocol level, the data reflecting the vehicle's abnormal state has not been updated for a long time. This situation may arise due to communication network link delays, weak cellular network signals, base station handover failures, network congestion, or abnormal operation of the vehicle communication module, such as freezing or restarting. In such cases, the currently acquired abnormal state data may be cached data remaining from before the communication interruption, and cannot accurately reflect the vehicle's current actual state. Triggering an alarm based on such unreliable data will result in a false alarm. Therefore, when the time difference is greater than or equal to the judgment duration, no abnormal alarm is triggered, and the current timing cycle is terminated, allowing the system to re-enter the listening state for trigger condition signals, waiting for valid data updates after the communication link is restored.

[0055] In an optional implementation, when the time difference is greater than or equal to the judgment duration, resulting in no abnormal alarm being triggered, the system also records the timestamp of this termination event, the communication module status, and the last update time of the vehicle status data for subsequent analysis of the communication link stability. If multiple time-lapse events due to exceeding the time difference limit occur consecutively within a preset time period, the system can determine that the current communication environment is poor or that the vehicle communication module has potential faults, and can selectively send communication abnormality prompts to the user or maintenance platform, but will not trigger an abnormal status alarm for the time being.

[0056] In this embodiment, by obtaining the current status of the vehicle communication module after the determination time has elapsed, and further obtaining the abnormal confirmation signal as the final basis for alarm when the disconnection is confirmed, it is possible to confirm whether the abnormal status signal has been present in the time period and has not been actively eliminated by the user before the alarm is triggered. This effectively distinguishes between the real abnormal status of the vehicle and the false alarm caused by instantaneous communication fluctuations or user intervention, significantly improving the accuracy and reliability of the alarm.

[0057] Based on the first embodiment described above, in the second embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0058] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the abnormal alarm method of this application. After step S20, the method further includes: Step S201: If the current state determines that the vehicle communication module is in an undisconnected state, then obtain the first timestamp of the state data corresponding to the trigger condition signal, wherein the state data includes high voltage state data and abnormal state data.

[0059] It should be noted that when the vehicle communication module is determined to be in an "online" state, it indicates that the vehicle communication link remains online at the protocol level, and the vehicle has not actively entered a low-power or offline mode. However, the online status of the communication link does not equate to the real-time validity of the vehicle status data. In practical applications, there may be situations where the vehicle communication module appears online but data updates have stopped, resulting in a "false online" scenario. For example, the communication module might be stuck in an infinite loop due to a software malfunction but still maintain a network connection, or congestion at intermediate network nodes might cause data packets to be delayed or dropped. Therefore, in the "online" state, the currently acquired status data cannot be directly used for alarm judgment; it is necessary to further obtain the timestamp corresponding to the status data to verify its timeliness.

[0060] Understandably, status data refers to vehicle status parameters directly associated with trigger condition signals, including high-voltage status data and abnormal status data. High-voltage status data reflects the current operating status (on or off) of the vehicle's high-voltage electrical system, while abnormal status data reflects whether any vehicle components are not in their normal closed or locked positions (e.g., at least one of the following: door status, window status, hood status, trunk status). Timestamps are used to characterize the update time of vehicle status data. The first timestamp is the time stamp corresponding to when the aforementioned status data was recorded or reported locally on the vehicle or in the cloud, indicating the specific moment when the status data was generated.

[0061] Understandably, when the connection is not interrupted, the system needs to distinguish between the following two scenarios: First, the status data is indeed real data collected and reported in real time at the current moment, in which case the abnormal status signal is credible; second, the status data is cached data remaining after the last successful report before the communication interruption, in which case the data is outdated and cannot reflect the current real status of the vehicle.

[0062] Step S202: Obtain the second timestamp of the heartbeat data of the vehicle communication module.

[0063] It should be noted that the heartbeat data of the vehicle communication module refers to the keep-alive messages or status synchronization messages that the vehicle communication module periodically sends to the cloud or vehicle-side network nodes according to a preset heartbeat cycle. This is used to maintain the connection status of the communication link and to announce its own online status. The heartbeat data sending cycle is usually a fixed time interval, determined by the communication protocol stack of the vehicle communication module. This cycle is generally shorter than the status data refresh cycle to ensure real-time monitoring of the communication link status. The second timestamp is the timestamp corresponding to the most recent successful reporting or reception of the heartbeat data by the cloud, used to indicate the most recent valid activity time of the communication link between the vehicle communication module and the cloud.

[0064] Understandably, obtaining the second timestamp of the heartbeat data after acquiring the first timestamp of the status data is necessary because the first timestamp of the business layer status data alone cannot distinguish whether the status data was indeed generated and reported in real time when the communication link was normal, or whether the status data, although bearing a more recent timestamp, actually indicates that the communication link has been interrupted, with the first timestamp merely marking the moment of data generation rather than the moment of successful reporting. By introducing the second timestamp of the heartbeat data as an independent verification basis for the communication layer link status, it is possible to reverse-verify whether the transmission of business layer status data has truly been completed from the maintenance status of the communication link, thereby identifying false online communication scenarios where the vehicle communication module remains online but data updates have stopped.

[0065] Specifically, if the interval between the second timestamp and the current time is within a reasonable deviation range of the heartbeat cycle, it indicates that the communication link is still actively active and the data channel is unobstructed in the near future; if the interval between the second timestamp and the current time has far exceeded the heartbeat cycle, it indicates that the communication link has been substantially interrupted. In this case, even if the first timestamp of the status data is displayed as relatively new, it cannot be confirmed whether the status data has been successfully transmitted to the cloud or effectively recorded.

[0066] Step S203: Determine the time difference between the current time and the first timestamp and the second timestamp.

[0067] It should be noted that the current time is the system time when the timer reaches the determined duration. The first timestamp comes from the status data of the business layer, reflecting the moment when the vehicle's high-voltage status and abnormal status were most recently collected or recorded; the second timestamp comes from the heartbeat data of the communication layer, reflecting the moment when the vehicle communication module most recently successfully sent a heartbeat message or was confirmed to have received it by the cloud.

[0068] Understandably, the purpose of determining the time difference is to establish a quantifiable criterion for data freshness, which can distinguish between two fundamentally different scenarios: First, a small time difference indicates that both the status data and heartbeat data have been effectively updated recently, the communication link is unobstructed, and the vehicle status data is real-time collected data, in which case the abnormal status signal is credible; Second, a large time difference indicates that the status data and heartbeat data have not been updated for a long time. Although the vehicle communication module still shows an online status at the protocol level, the actual data channel has been substantially interrupted or stopped. In this case, the currently acquired status data may be cached data left over from before the communication interruption, which cannot reflect the true status of the vehicle.

[0069] Specifically, as an optional implementation, the time difference is determined as follows: the latest valid timestamp is selected from the first and second timestamps, and then the absolute difference between the current time and the latest valid timestamp is calculated. This absolute difference is then used as the time difference. As long as there are relatively new activity records in either the business layer or the communication layer, the corresponding time difference remains at a small level, thereby avoiding misjudgment of the overall system status due to data lag at a single layer.

[0070] In another optional implementation, the time difference is determined by calculating a first sub-difference between the current time and a first timestamp, and a second sub-difference between the current time and a second timestamp. The smaller of the first and second sub-differences is taken as the time difference, or the weighted average of the two is taken as the time difference. This method can balance the latency at the service layer and the latency at the communication layer, and is suitable for scenarios where there are different weighting requirements for communication reliability and data timeliness.

[0071] In the specific implementation process, an effective time window can be constructed based on the second timestamp of the communication layer heartbeat data and the current timing period. Whether the first timestamp falls within this effective time window is used as a prerequisite for determining the reliability of the business layer status data. This ensures, from a time perspective, that the accepted business layer data is necessarily real-time data generated and successfully reported within the validity period of the communication link. Step S203 includes: Construct an effective time window based on the second timestamp and the current timing period; If the first timestamp is within the valid time window, then the status data corresponding to the first timestamp is determined to be reliable data, and the first timestamp is determined to be a reliable timestamp. Calculate the difference between the current time and the trusted timestamp to obtain the time difference.

[0072] It should be noted that the effective time window is a time validity determination interval constructed with the second timestamp as the baseline boundary. It is used to filter the timeliness of the status data corresponding to the first timestamp from a time dimension. The second timestamp reflects the moment when the heartbeat data of the vehicle communication module was most recently successfully reported, which represents the time node when the communication link still maintains effective activity in the near future.

[0073] It is understandable that in this embodiment, the TCU communication status judgment is combined with the vehicle status data timestamp judgment. The real-time performance of the data is judged by calculating the data time difference ΔT, thereby avoiding false alarms when the TCU is still online but the data has not been updated.

[0074] Understandably, the purpose of constructing an effective time window is to identify and eliminate cached data that, while appearing relatively new in terms of data generation time, was actually generated before the communication link was interrupted and failed to be transmitted. When the first timestamp falls within the effective time window, it indicates that the status data was generated within the period when the communication link was confirmed to be valid. This status data has a very high probability of being real data successfully collected and reported in real time under conditions of uninterrupted communication, rather than expired cached data remaining after the communication interruption. When the first timestamp does not fall within the effective time window, it indicates that the status data was generated earlier than the time of the most recent valid activity of the communication link. The data collection and reporting process corresponding to this status data may have been affected by the communication interruption, and the vehicle status it reflects is no longer real-time.

[0075] Specifically, as an optional implementation, the effective time window can be constructed by: using the second timestamp as the center point of the window and a preset communication cycle threshold as the window radius, extending outwards on both sides of the time axis to form a closed time interval. The preset communication cycle threshold can be used to characterize the maximum allowable interval between two adjacent heartbeat reports from the vehicle communication module. If the first timestamp falls within this closed time interval, it is determined that the generation of the status data and the reporting of the heartbeat data are temporally correlated and consistent, indicating that the status data was generated during a period when the communication link is normal, and its reliability is high.

[0076] Understandably, defining the first timestamp within the valid time window as the trusted timestamp and calculating the difference between the current time and the trusted timestamp as the time difference means that the time difference ultimately used for alarm determination is based only on state data generated within the communication link's validity period and verified as trusted. This approach effectively filters out data staleness issues caused by communication interruptions or delays, ensuring that the time difference truly reflects the interval between the current moment and the most recent trusted data update, providing a more accurate and reliable input for subsequent comparisons with the determination time.

[0077] In one example, assume the heartbeat cycle of the vehicle communication module is 30 seconds, and the current timing cycle (i.e., the judgment duration) is 60 seconds. The system obtains the second timestamp of the heartbeat data as 12:00:00, indicating that the communication link is still normal at that moment. Based on this second timestamp and the current timing cycle of 60 seconds, an effective time window is constructed. The upper limit of the window is the moment of the second timestamp, and the lower limit of the window is 60 seconds prior to the second timestamp, i.e., the effective time window is [11:59:00, 12:00:00]. Subsequently, the system obtains the first timestamp of the status data. After querying, the first timestamp is 11:59:30. This timestamp falls within the effective time window, indicating that the status data was generated and collected within 60 seconds of the most recent successful heartbeat data report. This status data overlaps with the normal activity period of the communication link, therefore, the status data is determined to be reliable data, and 11:59:30 is determined as the reliable timestamp. Then, the difference between the current time 12:00:30 and the trusted timestamp 11:59:30 is calculated, and the time difference is found to be 60 seconds.

[0078] In another example, assuming the second timestamp is still 12:00:00, the constructed effective time window is still [11:59:00, 12:00:00], but the obtained first timestamp is 11:55:00. This timestamp does not fall within the effective time window, meaning it is earlier than the lower limit of the window, 11:59:00. This indicates that the latest recorded time of the status data is more than 60 seconds after the most recent successful reporting of the heartbeat data. The status data may be cached data generated before the communication link was interrupted, rather than data collected in real time during the communication validity period. Therefore, this status data is determined to be unreliable and is not used, and the current timing cycle is terminated.

[0079] Step S204: When the time difference is less than the determination duration, the abnormal state signal is determined to be reliable within the current timing period, and an abnormal alarm is issued based on the abnormal state signal.

[0080] It should be noted that when the time difference is less than the judgment duration, it indicates that the interval between the latest timestamp of the status data and the current time is within a reasonable time window allowed by the system. This means that the vehicle status data has been effectively updated recently, both the communication link and the data acquisition link are operating normally, and the currently acquired abnormal status signal can accurately reflect the actual status of the vehicle. Therefore, it can be determined that the abnormal status signal is reliable within the current timing period.

[0081] In one example, assuming a judgment duration of 60 seconds, the time difference between the current time and the trusted timestamp is 30 seconds. This time difference is less than the judgment duration of 60 seconds, indicating that the status data update time is only 30 seconds from the current time, which is well within the range covered by the communication latency tolerance time and the status stability observation time. Therefore, the data possesses sufficient timeliness and reliability. At this point, the system determines that the abnormal status signal is reliable within the current timing period and generates an alarm command based on this signal, pushing an alarm notification to the user's mobile terminal. This alerts the user that there is an abnormal situation such as an open door or window in the vehicle, allowing the user to return and handle it promptly.

[0082] It should be noted that when the time difference is greater than or equal to the judgment duration, it indicates that the data reflecting the vehicle status has not been effectively updated for a long time. At this time, although the vehicle communication module may still show an online status at the protocol level, the interval between the latest timestamp of the business layer status data and the communication layer heartbeat data and the current time has exceeded the maximum tolerance range allowed by the system. The status data corresponding to the abnormal status signal currently obtained is very likely to be cached data left over from before the communication interruption, rather than real-time data reflecting the current true status of the vehicle.

[0083] It is understandable that the reasons for a time difference greater than or equal to the judgment duration may include, but are not limited to, the following: weak cellular network signal causing data packets to be delayed or lost on the transmission link for a long time; base station handover failure causing a brief interruption of the communication link that is not restored in time; network congestion causing data packets to be queued at intermediate nodes; the vehicle communication module freezing or restarting due to software abnormalities, causing data reporting to be interrupted; and the vehicle communication module ceasing to actively report data after entering power-saving mode. In any of the above situations, the actual state of the vehicle may have changed, for example, the user has returned and closed the door that was not properly closed, or the vehicle's high-voltage state has been restored, but due to the data channel interruption, these changes were not perceived and recorded by the system, so the currently retained state data can no longer be used as a reliable basis for alarm judgment.

[0084] Specifically, when the time difference is greater than or equal to the judgment duration, the system does not trigger an abnormal alarm. Instead, it terminates the current timing cycle and resets the timer to its initial state, allowing the system to re-enter the listening for trigger condition signals. This effectively avoids false alarms caused by communication anomalies and prevents the system from sending false alarm information to users based on expired data.

[0085] In this embodiment, by simultaneously acquiring the first timestamp of the status data corresponding to the trigger condition signal and the second timestamp of the heartbeat data of the vehicle communication module, and using the time difference between the current time and the two types of timestamps as a confidence criterion, it is possible to effectively identify the false online communication situation where "the vehicle communication module shows an online status at the protocol level, but the actual data link has been interrupted or the data has stopped updating." This avoids misjudging outdated cached data as the current real vehicle status in such situations, and significantly reduces the probability of false alarms caused by communication delays or data stagnation.

[0086] Reference Figure 3 , Figure 3 This is a flowchart illustrating the third embodiment of the abnormal alarm method of this application. Based on the above embodiments, the third embodiment of the abnormal alarm method of this application is proposed. In the third embodiment, step S20 includes: Step S21: When the timer reaches the determination duration, determine whether the vehicle communication module has exited the network connection within the current timing period, and obtain the determination result.

[0087] It should be noted that the vehicle communication module exiting the network connection refers to the disconnection of the communication link between the module and the vehicle-side network node or cloud server, causing the module to no longer be in a communicable online state. Unlike methods that rely solely on whether a logout message is received, this embodiment directly uses the actual change in the network connection status as the judgment object, thereby capturing all situations of the vehicle communication module exiting the network, including active exit (sending a logout message) and passive exit (module disconnection). The judgment result is used to indicate whether the network connection status of the vehicle communication module has changed from connected to disconnected within the current timing period.

[0088] Understandably, when an in-vehicle communication module actively disconnects from the network, it will send a feedback message. This feedback message is a communication protocol message sent by the in-vehicle communication module to the vehicle system or cloud service during operation, indicating its network connection status and service processing status. Types of feedback messages include, but are not limited to, logout messages (used to notify the communication link that it is about to be disconnected and to execute the deregistration process); and deregistration messages (used to notify the network side to deregister the current device's registration information). When the in-vehicle communication module normally executes the logout process or the network status changes, the corresponding feedback message will be captured by the vehicle system within the current time period. Conversely, when the in-vehicle communication module passively disconnects from the network (e.g., when the vehicle enters a tunnel), the in-vehicle communication module's status will change from online to offline.

[0089] Understandably, when the timer starts, the trigger condition signal has just been generated, and the vehicle communication module may be in the process of normal business processing, not yet performing a logout operation. By waiting for the judgment period before making the judgment, sufficient time can be provided for the vehicle communication module to execute the logout process. This ensures that if the vehicle communication module should indeed log out at the judgment time, it has already completed the relevant operations and sent the corresponding feedback message, thus avoiding the misjudgment of a communication module that has not yet started the logout process as being in an abnormal disconnected state due to premature judgment.

[0090] Specifically, if a feedback message is received within the current timing period, it indicates that the vehicle communication module has undergone a clear state change in its communication interaction with the vehicle system. The system can further extract the message type identifier or determine the network status of the vehicle communication module from the feedback message to accurately identify the specific state of the communication module. If no feedback message is received within the current timing period, and the vehicle communication module remains connected, it indicates that the vehicle communication module has not actively notified the vehicle system of any state change within the timing period. Further determination is needed to determine whether the obtained abnormal state data is real-time data.

[0091] Step S22: Determine the current state of the vehicle communication module based on the judgment result.

[0092] Understandably, the current state of the vehicle communication module is divided into two types: disconnected and not disconnected. A disconnected state means the vehicle communication module has completed the normal logout process by actively sending a logout message, or the network connection has switched from online to offline, the vehicle communication link has been substantially disconnected, and the vehicle has entered low-power or offline mode. A not disconnected state means the vehicle communication module has neither sent a logout message nor has the network connection remained online; the vehicle communication link maintains a connection at the protocol level.

[0093] In the specific implementation process, cross-verification based on message type and network status can cover all possible manifestations of the vehicle communication module's logout behavior, avoiding missed or incorrect judgments caused by relying on only a single criterion, and improving the accuracy and robustness of communication module status identification. Step S23 includes: If the message type identifier sent by the vehicle communication module is a logout message identifier, then the current state of the vehicle communication module is determined to be disconnected. If the message type identifier sent by the vehicle communication module is a non-logout message identifier, and the vehicle communication module switches from online to offline state, then the current state of the vehicle communication module is determined to be the disconnected state. If the message type identifier sent by the vehicle communication module is a non-logout message identifier, and the vehicle communication module remains online, then the current state of the vehicle communication module is determined to be an undisconnected state.

[0094] It should be noted that if the message type identifier is a logout message identifier or a deregistration message identifier, then regardless of the network status identifier, the current status of the vehicle communication module is directly determined to be disconnected, because the sending of a logout or deregistration message itself indicates that the vehicle communication module has actively executed the logout process. In this case, the device will subsequently enter the abnormal confirmation signal acquisition and verification stage to confirm whether the abnormal state of the vehicle persisted before it officially went offline.

[0095] If the message type identifier is not a logout message identifier (such as a heartbeat message identifier or a status synchronization message identifier), but the network status indicates that the vehicle communication module has switched from an online state to an offline state, then the current state of the vehicle communication module is determined to be disconnected. This situation corresponds to scenarios where the communication module is passively offline due to network anomalies, signal loss, or other reasons. In such scenarios, the network connection switching from online to offline indicates that the communication link has been interrupted, and the vehicle has actually entered an offline state. Determining this situation as a disconnected state can avoid misjudging the true offline state as an active state due to a lack of criteria, thus incorrectly entering the data real-time verification branch. In this scenario, it can be determined whether the data is historical cached data.

[0096] If the message type identifier is not a logout message identifier, and the network status indicates that the vehicle communication module remains online, then the current status of the vehicle communication module is determined to be an undisconnected state. This scenario corresponds to a situation where the communication link is still connected and the vehicle has not yet entered low-power or offline mode. The device needs to further obtain the timestamps of the status data and heartbeat data, and verify the real-time performance and reliability of the data by comparing the time difference with the judgment duration, in order to distinguish whether the vehicle is indeed in an abnormal state or the data has not been updated due to a communication failure.

[0097] In this embodiment, by monitoring whether a feedback message is received within the current timing period when the timer starts counting, and extracting the message type identifier and network status identifier from the message for dual identification when a feedback message is received, it is possible to accurately distinguish whether the vehicle communication module is in a disconnected state where it actively sends a logout message and is normally offline, a passively disconnected state where it switches from online to offline, or a non-disconnected state where it remains online but there are abnormalities.

[0098] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the abnormal alarm method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0099] This application also provides an abnormal alarm device, please refer to... Figure 4 The abnormal alarm device includes: The timing module 10 is used to start a timer when a trigger condition signal is detected generated by the vehicle, wherein the trigger condition signal includes a high voltage status signal and an abnormal status signal. The acquisition module 20 is used to acquire the current status of the vehicle communication module within the current timing period when the timing duration of the timer reaches the determination duration. The alarm module 30 is used to obtain an abnormal confirmation signal corresponding to the trigger condition signal if the current state determines that the vehicle communication module is in a disconnected state, and to issue an abnormal alarm based on the abnormal confirmation signal.

[0100] The anomaly alarm device provided in this application, employing the anomaly alarm method in the above embodiments, can solve the technical problem that existing vehicles are prone to misjudging a vehicle that has recovered to normal as being in an abnormal state and generating an alarm under special conditions. Compared with the prior art, the beneficial effects of the anomaly alarm device provided in this application are the same as those of the anomaly alarm method provided in the above embodiments, and other technical features in the anomaly alarm device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0101] This application provides an anomaly alarm device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the anomaly alarm method in Embodiment 1 above.

[0102] The following is for reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing an anomaly alarm device according to embodiments of this application. The anomaly alarm device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The abnormal alarm device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0103] like Figure 5As shown, the anomaly alarm device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the anomaly alarm device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the alarm device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show alarm devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0104] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0105] The anomaly alarm device provided in this application, employing the anomaly alarm method in the above embodiments, can solve the technical problem that existing vehicles are prone to misjudging a vehicle that has recovered to normal as being in an abnormal state and generating alarms under special conditions. Compared with the prior art, the beneficial effects of the anomaly alarm device provided in this application are the same as those of the anomaly alarm method provided in the above embodiments, and other technical features in this anomaly alarm device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0106] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0107] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0108] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the exception alarm method in the above embodiments.

[0109] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0110] The aforementioned computer-readable storage medium may be included in the anomaly alarm device; or it may exist independently and not be assembled into the anomaly alarm device.

[0111] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the abnormal alarm device, cause the abnormal alarm device to perform the abnormal alarm method described above.

[0112] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0113] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0114] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0115] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described anomaly alarm method. This solves the technical problem that existing vehicles, under special conditions, easily misjudge a vehicle that has recovered to normal as being in an abnormal state and generate an alarm. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the anomaly alarm method provided in the above embodiments, and will not be repeated here.

[0116] The above description is only a part of the embodiments of this application and does not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. An anomaly alarm method, characterized in that, The abnormal alarm method includes: When a trigger condition signal is detected that the vehicle has generated a trigger condition signal, a timer is started to count. The trigger condition signal includes a high-voltage status signal and an abnormal status signal. When the timer reaches the determination duration, the current status of the vehicle communication module within the current timing period is obtained; If the current state determines that the vehicle communication module is disconnected, an abnormal confirmation signal corresponding to the trigger condition signal is obtained, and an abnormal alarm is issued based on the abnormal confirmation signal.

2. The anomaly alarm method as described in claim 1, characterized in that, After obtaining the current state of the vehicle communication module within the current timing period when the timer reaches the determination duration, the method further includes: If the current state determines that the vehicle communication module is in an undisconnected state, then the first timestamp of the state data corresponding to the trigger condition signal is obtained, and the state data includes high voltage state data and abnormal state data; Obtain the second timestamp of the heartbeat data of the vehicle communication module; Determine the time difference between the current time and the first and second timestamps; When the time difference is less than the determination duration, the abnormal state signal is determined to be reliable within the current timing period, and an abnormal alarm is issued based on the abnormal state signal.

3. The anomaly alarm method as described in claim 2, characterized in that, Determining the time difference between the current time and the first and second timestamps includes: Construct an effective time window based on the second timestamp and the current timing period; If the first timestamp is within the valid time window, then the status data corresponding to the first timestamp is determined to be reliable data, and the first timestamp is determined to be a reliable timestamp. Calculate the difference between the current time and the trusted timestamp to obtain the time difference.

4. The anomaly alarm method as described in claim 1, characterized in that, When the timer reaches the determined duration, the current state of the vehicle communication module within the current timing period is obtained, including: When the timer reaches the determination duration, it is determined whether the vehicle communication module has exited the network connection within the current timing period, and the determination result is obtained. The current state of the vehicle communication module is determined based on the judgment result.

5. The anomaly alarm method as described in claim 4, characterized in that, Determining the current state of the vehicle communication module based on the judgment result includes: If the message type identifier sent by the vehicle communication module is a logout message identifier, then the current state of the vehicle communication module is determined to be disconnected. If the message type identifier sent by the vehicle communication module is a non-logout message identifier, and the vehicle communication module switches from online to offline state, then the current state of the vehicle communication module is determined to be the disconnected state. If the message type identifier sent by the vehicle communication module is a non-logout message identifier, and the vehicle communication module remains online, then the current state of the vehicle communication module is determined to be an undisconnected state.

6. The anomaly alarm method as described in claim 1, characterized in that, Before obtaining the current state of the vehicle communication module within the current timing period when the timer reaches the determination duration, the method further includes: Get the current vehicle status data refresh time and maximum communication latency; The state stability observation time for each state data is determined based on the state data refresh time. The determination duration of the current timing cycle is determined based on the maximum communication delay time and the state stabilization observation time.

7. The anomaly alarm method as described in any one of claims 1 to 6, characterized in that, After the timer starts counting when the vehicle generates a trigger condition signal, the process further includes: If a change in the state of the high-voltage state signal in the trigger condition signal is detected within the current timing period, the trigger condition signal is determined to be invalid, the timing of the timer is terminated, and the timer is reset to its initial state. If the current state determines that the vehicle communication module is disconnected within the current timing period, and there is no abnormal confirmation signal corresponding to the trigger condition signal, then no abnormal alarm will be issued. If the current state determines that the vehicle communication module is not disconnected within the current timing period, and the time difference corresponding to the abnormal state signal is greater than or equal to the determination duration, then no abnormal alarm will be issued.

8. An abnormal alarm device, characterized in that, The device includes: The timing module is used to start a timer when a trigger condition signal is detected generated by the vehicle. The trigger condition signal includes a high-voltage status signal and an abnormal status signal. The acquisition module is used to acquire the current status of the vehicle communication module within the current timing period when the timing duration of the timer reaches the determination duration. The alarm module is used to obtain an abnormal confirmation signal corresponding to the trigger condition signal if the current state determines that the vehicle communication module is in a disconnected state, and to issue an abnormal alarm based on the abnormal confirmation signal.

9. An abnormal alarm device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the anomaly alarm method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the abnormal alarm method as described in any one of claims 1 to 7.

Images