Fault event identification method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a fault event identification method and device, electronic equipment and storage medium. The method comprises: adopting a sliding time window, analyzing time series data associated with a vehicle to obtain events associated with the vehicle; matching the events, and identifying a fault event of the vehicle according to the matching result. Embodiments of the present application can improve the real-time identification of fault events of the vehicle.

Description

Technical Field

[0001] This application relates to the field of fault event identification technology, and in particular to a fault event identification method, apparatus, electronic device and storage medium. Background Technology

[0002] During vehicle use, initial warnings are typically issued after a malfunction occurs by analyzing signal data from the vehicle at a specific moment (such as DTCs (Diagnostic Trouble Codes) or instantaneous values ​​from a single sensor), or through manual reporting. However, this method results in information lag and low real-time performance in fault identification. Summary of the Invention

[0003] The technical problem to be solved by the embodiments of this application is to provide a fault event identification method, device, electronic device and storage medium to improve the real-time identification of fault events in vehicles.

[0004] In a first aspect, embodiments of this application provide a fault event identification method, including:

[0005] By using a sliding time window approach, the time series data associated with the means of transportation are parsed to obtain the events associated with the means of transportation;

[0006] The events are matched, and the malfunction events of the vehicle are identified based on the matching results.

[0007] Secondly, embodiments of this application provide a fault event identification device, comprising:

[0008] The event acquisition module is used to parse the time series data associated with the vehicle using a sliding time window method to obtain the events associated with the vehicle.

[0009] The fault identification module is used to match the events and identify the fault events of the vehicle based on the matching results.

[0010] Thirdly, embodiments of this application provide an electronic device, including:

[0011] A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the fault event identification method described above.

[0012] Fourthly, embodiments of this application provide a computer-readable storage medium that, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform any of the fault event identification methods described above.

[0013] Compared with the prior art, the embodiments of this application have the following advantages:

[0014] In this embodiment, a sliding time window approach is used to parse the time-series data associated with vehicles to obtain the events associated with the vehicles. These events are then matched, and vehicle malfunction events are identified based on the matching results. This embodiment, by using a sliding time window to analyze the time-series data of vehicles, can complete malfunction identification as soon as a malfunction event occurs, improving the real-time performance of vehicle malfunction event identification.

[0015] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0016] Figure 1 A flowchart illustrating the steps of a fault event identification method provided in this application embodiment;

[0017] Figure 2 A flowchart illustrating the steps of another fault event identification method provided in this application embodiment;

[0018] Figure 3 This is a schematic diagram of the structure of a fault event identification device provided in an embodiment of this application;

[0019] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0022] Example 1

[0023] Reference Figure 1 The flowchart illustrates the steps of a fault event identification method provided in an embodiment of this application, as follows: Figure 1 As shown, the fault event identification method may include steps 101 and 102.

[0024] Step 101: Using a sliding time window method, parse the time series data associated with the transportation vehicle to obtain the events associated with the transportation vehicle.

[0025] In this embodiment, a sliding time window is a commonly used technique in time series data processing. It refers to a method that uses a fixed window length and sliding step size to sequentially extract continuous or overlapping time intervals on the time axis, and performs real-time or batch processing on the data within each interval. Its core feature is that it achieves block analysis of the data stream through a "sliding" operation, making it suitable for scenarios that require capturing the real-time nature or local features of the data.

[0026] A means of transportation refers to a device used for human transportation or for transporting goods. In this example, a means of transportation can be, but is not limited to, a vehicle.

[0027] In practical implementation, a sliding time window approach can be used to obtain time-series data associated with vehicles. For example, the window length is 20 seconds, the step size is 10 seconds, the first window covers seconds 1 to 20, the second window covers seconds 11 to 30, and so on. In this example, the time-series data can be vehicle trajectory data, driver behavior data, sensor data, vehicle status data, external environment data, etc.

[0028] In one specific implementation of this application, the time series data can be time series data of a vehicle in a stationary state. For example, taking a vehicle as an example, when the vehicle is stationary, if an external fire source causes the vehicle to catch fire, it will trigger the vehicle's power supply. At this time, external environmental data can be acquired for subsequent identification of fault events, etc.

[0029] In another specific implementation of this application, the time series data can be time series data of a vehicle in operation. For example, taking a vehicle as an example, when a vehicle is in motion, vehicle status data, sensor data, and driver behavior data can be monitored in real time through equipment inside the vehicle (such as sensors, cameras, etc.).

[0030] It is understood that the above examples are merely examples listed to better understand the technical solutions of the embodiments of this application, and are not intended to be the only limitation on the embodiments.

[0031] After obtaining the time-series data associated with the vehicle, the data can be parsed to obtain the events associated with the vehicle. In this example, the events associated with the vehicle may include: vehicle acceleration events, deceleration events, braking events, driver exiting the vehicle, getting into the vehicle, opening a window, system thermal runaway events, etc.

[0032] After parsing the time series data associated with the vehicles using a sliding time window method to obtain the events associated with the vehicles, step 102 is executed.

[0033] Step 102: Match the events and identify the malfunction events of the vehicle based on the matching results.

[0034] After parsing the time-series data associated with vehicles using a sliding time window approach to obtain the associated events, these events can be matched, and vehicle malfunction events can be identified based on the matching results. Specifically, the parsed events can be cached in a list in ascending order of timestamps, and each event in the list can be matched one by one using a reverse interval matching method to obtain matching results. Then, vehicle malfunction events (such as fire events (e.g., spontaneous combustion of a vehicle while stationary, secondary fires caused by external fire sources (e.g., road fires, building fires), structural fires caused by traffic collisions, thermal runaway or abnormal fires of energy systems during driving, etc.), collision events, etc.) can be identified based on the matching results. During this process, the occurrence of a malfunction event is determined by comprehensively considering trajectory characteristics such as abnormal vehicle status, sudden changes in driving behavior, and system thermal runaway, and the event is quickly reported to the backend system. Compared to traditional mechanisms that rely on post-event DTC statistics or manual reporting, this embodiment can complete the identification of malfunction events in their early stages, greatly improving the timeliness of enterprise intervention in event handling. Meanwhile, in vehicle malfunction incidents, the public is highly sensitive to response speed and corporate attitude. This implementation can provide companies with timely, system-level fire assessment and handling suggestions, avoiding secondary spread and negative impacts caused by information delays. By intervening in public opinion control and incident response processes through technical means, this implementation can effectively protect brand reputation while ensuring user safety.

[0035] The fault event identification method provided in this application uses a sliding time window approach to parse the time-series data associated with vehicles to obtain the events associated with the vehicles. These events are then matched, and the vehicle fault events are identified based on the matching results. By using a sliding time window approach to analyze the time-series data of vehicles, this application embodiment can complete fault identification as soon as a fault event occurs, improving the real-time performance of fault event identification when a vehicle fault event occurs.

[0036] Example 2

[0037] Reference Figure 2 The flowchart illustrates another fault event identification method provided in an embodiment of this application, as follows: Figure 2 As shown, the fault event identification method may include steps 201, 202, 203, 204 and 205.

[0038] Step 201: Use a sliding time window method to obtain multi-source time series data associated with the vehicle.

[0039] In this embodiment, multi-source time series data refers to time series data from different sources for a vehicle. Taking a vehicle as an example, the multi-source time series data can include at least two of the following: vehicle status data (such as vehicle speed, RPM, fuel consumption, battery charge, engine temperature, tire pressure, etc.), driver behavior data (accelerator / brake pedal travel, steering wheel angle, shift frequency, number of rapid accelerations / brakes, etc.), and sensor signal data (millimeter-wave radar obstacle detection distance / speed, lidar point cloud data, etc.).

[0040] In practical implementation, a sliding time window approach can be used to acquire multi-source time-series data associated with transportation vehicles. Taking vehicles as an example, for vehicle status data, the vehicle's electronic control unit (ECU) can be connected via the Controller Area Network Bus (CAN) to parse the bus protocol and obtain the vehicle status data. For driver behavior data, driver behavior can be monitored through pedal position sensors (installed at the accelerator / brake pedal position, monitoring the travel in real time via potentiometers or Hall effect elements), steering wheel angle sensors (integrated into the steering column, outputting CAN signals or analog voltage signals), and onboard cameras. For sensor signal data, sensor signal data can be acquired in real time through onboard millimeter-wave radar, lidar, and other onboard sensors.

[0041] After obtaining the multi-source time series data associated with the vehicles using the sliding window method, proceed to step 202.

[0042] Step 202: Parse the multi-source time series data to obtain the events associated with the means of transportation and the timestamps of the events.

[0043] Vehicle-related events refer to situations or phenomena of specific significance that occur during the operation of a vehicle. These events can be triggered based on specific patterns or thresholds in multi-source time-series data. For example, an emergency braking event may be triggered by a sharp drop in vehicle speed within a short period of time, abnormal sensor data events, airbag deployment events, etc.

[0044] An event's timestamp is a record of the specific time an event occurred. In multi-source time series data, each data point has a corresponding timestamp. By analyzing the data to determine when an event occurred, the timestamp of the corresponding data point becomes the event's timestamp, used to accurately mark the moment the event occurred.

[0045] After obtaining multi-source time series data associated with transportation vehicles using a sliding window approach, the multi-source time series data can be parsed to obtain the events associated with the transportation vehicles and the timestamps of those events.

[0046] In practical implementation, different events and their triggering rules can be defined based on business needs and the characteristics of vehicle operation. For example, an emergency braking event is triggered when the vehicle speed drops below a certain threshold (e.g., 30 km / h) within a short period (e.g., 2 seconds). An overspeeding event is triggered when the vehicle speed exceeds a preset speed limit (e.g., 120 km / h). An engine failure event is triggered when the engine speed remains above the normal range (e.g., 6000 RPM) for a certain period (e.g., 5 seconds).

[0047] During parsing, rules defined by the event can be used to perform real-time or offline analysis on the preprocessed data, detecting event occurrences and extracting corresponding timestamps. Threshold-based detection can be used: for simple events, such as speeding and emergency braking, data values ​​can be directly compared to preset thresholds; when the condition is met, the event is marked as occurring, and the corresponding timestamp is recorded. Pattern-matching detection can also be used: for complex events, such as engine failure events, it is necessary to analyze the time series patterns of the data and use sliding window techniques to analyze the data's changing trends within a certain time window; when a specific pattern is met, the event is determined to have occurred.

[0048] It is understood that the above examples are merely examples listed to better understand the technical solutions of the embodiments of this application, and are not intended to be the only limitation on the embodiments.

[0049] After parsing the multi-source time series data to obtain the events associated with the vehicles and the timestamps of the events, step 203 is executed.

[0050] Step 203: Cache the event in the timestamp list corresponding to the event type in an incrementing order of timestamps. The event type is the type corresponding to the event.

[0051] After parsing multi-source time series data to obtain the events associated with transportation vehicles and their timestamps, the events can be cached in an ascending order of timestamps in a timestamp list corresponding to each event type. That is, a timestamp list can be created for each event type, and the event index can be cached in ascending order of time. The storage format of the timestamp list can be: Map<event index, List<timestamp>, which records the timestamp sequence of events for each event type.

[0052] In one specific implementation of this application, a TTL (Time To Live) strategy can be set for the data in the timestamp list. Specifically, an expiration time, such as 30 minutes, can be set, and expired data (i.e., event data older than 30 minutes) can be periodically cleaned up to reduce the memory usage of cached data.

[0053] After caching the events in the timestamp list corresponding to the event type in an incrementing manner, proceed to step 204.

[0054] Step 204: Match the events in the timestamp list according to the timestamp to obtain the matching result.

[0055] After caching events in a timestamp list corresponding to the event type in ascending order of timestamps, the events in the timestamp list can be matched according to their timestamps to obtain the matching results. Specifically, the events in the timestamp list can be matched using a reverse interval matching method to obtain the matching results. The matching process will be described in detail in the following embodiments, and will not be repeated here.

[0056] After matching the events in the timestamp list according to the timestamp to obtain the matching results, proceed to step 205.

[0057] Step 205: Based on the matching results, identify the malfunction events of the vehicle.

[0058] After matching events in the timestamp list according to their timestamps, the vehicle's malfunction events can be identified based on these results. Specifically, for anomalies in a single data source, such as persistent OBD fault codes, the corresponding malfunction events can be identified, such as thermal runaway or energy system anomalies during driving. For anomalies in multi-source data associations, such as sudden sensor signal changes combined with emergency driver actions and abrupt changes in vehicle status, corresponding malfunction events can be identified, such as collision events.

[0059] The fault event identification method provided in this application realizes continuous tracking of the entire vehicle and driver behavior by performing temporal reconstruction and trajectory extraction of multi-source data such as vehicle status, driving behavior, and sensor signals. Compared with existing methods that rely solely on single-point signals or threshold judgments, it can construct a complete time chain, significantly improving the accuracy of event reconstruction and judgment. Furthermore, it does not require a complex model training process and can be deployed based on rule combinations and trajectory logic. Compared with solutions relying on deep learning or visual recognition, it has lower deployment costs, stronger generalization capabilities, and is suitable for rapid integration and iterative upgrades of large-scale vehicles. Moreover, by jointly modeling the operating status of key vehicle components, environmental factors, and driving behavior, it can effectively capture the spatiotemporal trajectory of fire events under different operating conditions and usage scenarios, exhibiting strong adaptability and accuracy. Compared with traditional strategies relying on DTC fault codes or single-point threshold judgments, it maintains a high recognition rate in diverse scenarios, significantly broadening the applicability of fire warning systems.

[0060] Next, the process of matching events using the reverse interval matching method will be described in detail with reference to specific embodiments.

[0061] In one specific implementation of this application, the step of matching events in a timestamp list according to timestamps to obtain matching results may include: converting the timestamps in the timestamp list into continuous time periods; and using reverse interval matching to match events within the continuous time periods to obtain matching results.

[0062] In this embodiment, the timestamps in the timestamp list can be converted into continuous time periods, that is, discrete timestamps can be merged into continuous time intervals. For example, if the timestamps in the timestamp list are [1000, 1001, 1200], then the resulting continuous time periods are: [[1000, 1001], [1200, 1200]], etc.

[0063] In a practical implementation, a maximum interval threshold (such as 5 seconds) can be set for consecutive intervals. If the interval between adjacent timestamps is less than or equal to the maximum interval threshold, they are merged into the same interval.

[0064] Then, a reverse interval matching method can be used to match events within a continuous time period to obtain the matching results. That is, matching proceeds step by step from the last event backwards. For example, if there are 10 timestamps and event indices corresponding to events in the timestamp list, arranged in ascending order of timestamps: event 1, event 2, ..., event 10, when matching, you can start matching from event 10 and proceed forwards until you match event 1, etc.

[0065] This application's embodiments significantly improve the targeting and efficiency of event matching through a "fault-centric" backtracking mechanism using reverse interval matching, making it particularly suitable for scenarios such as fault tracing and intermittent anomaly capture. Combined with preprocessing that clusters timestamps into continuous time periods, it can effectively address practical problems such as data acquisition interruptions and clock drift.

[0066] In another specific implementation of this application, a dynamic time window can be used for event matching. Specifically, this implementation process may include: Step S1: During event matching using reverse interval matching, obtain the time window of the currently matched first event. Step S2: Obtain the maximum delay time and minimum delay time corresponding to the first event. The maximum delay time is the latest time constraining the second event, and the minimum delay time is the earliest time constraining the second event. The second event is the event preceding the first event in the timestamp list. Step S3: Determine the target time window for the second event based on the start and end times, maximum delay time, and minimum delay time corresponding to the time window. Step S4: Match the second event based on the target time window. Step S5: After all event matching is completed, obtain the matching result.

[0067] In step S1 above, the first event is the event currently being matched in the timestamp list. In this example, when the first event is the last event in the timestamp list, the time window of the first event is the time interval corresponding to the timestamp of the first event. However, when the first event is neither the last event nor the first event, the time window of the first event can be a time window obtained based on the previous matched event.

[0068] In step S2 above, the maximum delay time is the latest time constraining the second event (i.e., the maximum time interval between the first and second events when a fault occurs), and the minimum delay time is the earliest time constraining the second event (i.e., the minimum time interval between the first and second events when a fault occurs). The second event is the event preceding the first event in the timestamp list. After matching the first event, the maximum and minimum delay times corresponding to the first event can be obtained, i.e., the maximum and minimum delay times are determined based on the constraint time range of the second event.

[0069] In step S3 above, after obtaining the maximum and minimum delay times, the target time window for the second event can be determined based on the start and end times, maximum and minimum delay times corresponding to the time window. Specifically, the minimum delay time can be expressed as min_delay_seconds, the maximum delay time as max_delay_seconds, and the target time window can be calculated as new_range (target time window) = [current_start - max_delay, current_end - min_delay], where current_start and current_end are the start and end times of the time period of the first event, respectively. For example, if the time window of the first event is [1000s, 1001s], and the constraint time of the second event is 2s (minimum delay) to 5s (maximum delay), then the calculated target time window is [995, 999], etc.

[0070] In steps S4 and S5 above, after obtaining the target time window, the second event can be matched based on the target time window. And after all events have been matched, the matching result is obtained.

[0071] This embodiment employs a dynamic window matching method, which can flexibly adjust the range according to event characteristics, avoiding missed matches caused by improper parameter settings in a fixed window. Simultaneously, it filters out extremely short-interval interference events (such as instantaneous anomalies caused by noise) by using the minimum delay time and excludes irrelevant events with long delays by using the maximum delay time, reducing false matches. For example, in car collision accident analysis, the preceding "collision sensor triggering" of the "airbag deployment" event must occur within 0.1-1 seconds before it; the dynamic window can accurately match this interval, excluding sensor fluctuations in other time periods. Furthermore, this embodiment uses dynamic time window constraints and a reverse interval matching algorithm to achieve efficient time series trajectory matching.

[0072] In another specific implementation of this application, an interval intersection calculation matching method can be used when performing event matching. This matching process can include: Step M1: In the process of event matching using the reverse interval matching method, starting from the current event, calculate the intersection of the time window with the third event. If an intersection exists, the current event is determined to be successfully matched, and the time intersection interval is recorded. The third event is the event preceding the current event in the timestamp list. Step M2: Using the time intersection interval obtained from the current match as a new constraint, continue to repeat the above intersection calculation process with the fourth event until all events are traversed and a matching result is obtained. The fourth event is the event preceding the third event in the timestamp list.

[0073] In this embodiment, a recursive reverse interval intersection matching scheme is adopted. Each event must include the start and end times of the time window (such as the effective time period of the event). In step M1 above, the third event is the event preceding the currently matched event in the timestamp list. During the event matching process using the reverse interval matching method, starting from the current event, the intersection of the time windows with the third event is calculated. If an intersection exists, the current event is considered to be successfully matched, and the time intersection interval is recorded. For example, for two events A and B, where event B is the event preceding event A, A = [[1,3],[5,7]], B = [[2,6]], then the calculated time intersection interval can be: [[2,3],[5,6]]. In step M2 above, the time intersection interval obtained by the current match can be used as a new constraint condition to continue repeating the above intersection calculation process with the fourth event until all events are traversed and a matching result is obtained. The fourth event is the event preceding the third event in the timestamp list.

[0074] This application embodiment can construct the temporal dependency relationship of the event chain through recursive intersection calculation. The temporal intersection of each link represents the time range of the effective causal relationship, thereby accurately identifying fault events.

[0075] In this embodiment of the application, if any of the following conditions exist during the event matching process, a matching failure result will be returned:

[0076] 1. If any necessary event fails to match within a continuous time period, the result of event matching failure is obtained. The necessary event is the necessary event that triggers the failure event.

[0077] In this embodiment, a necessary condition refers to the condition that must be met to trigger a fault event in a logical relationship, that is, "without this condition, the result will definitely not occur, and with this condition, the result may occur (and other conditions need to be met)".

[0078] When matching events within a continuous time period, if any necessary event fails to match, the matching process ends, and the result of event mismatch is returned. For example, in reverse matching (from back to front): first match event C, then look back for the previous event (event A). There is a time overlap (assuming a time window allows a 5-second delay), and the two match successfully. Continue traversing forward; no earlier events are found. Result determination: If necessary event B fails to match, the matching is directly determined to be a failure (even if events A and C match successfully, the lack of necessary condition B will prevent the fault event from being triggered), etc.

[0079] 2. If the number of successfully matched events is less than the threshold, the result of event matching failure is obtained.

[0080] If all events in the timestamp list have been matched, and all necessary events have been successfully matched, then the number of successfully matched events can be obtained. If the number of successfully matched events is less than a threshold, then the result is "event matching failed." For example, if the number of matched events is less than the total number of events multiplied by the threshold, an empty matching result is returned directly.

[0081] This application embodiment avoids false alarms caused by mismatches of non-critical events by mandating verification of necessary events. At the same time, it combines quantity threshold constraints to prevent logical loopholes caused by missing a single necessary event or incorrect threshold settings, ensuring that the matching results only reflect real faults where the complete triggering conditions are met, thereby reducing maintenance misjudgments and resource waste.

[0082] After completing the above matching process, the vehicle malfunction events can be comprehensively analyzed based on the successfully matched events.

[0083] In another specific implementation of this application, the matching frequency corresponding to an event can be determined based on the number of events within the sliding time window. Events are then matched according to timestamps based on the matching frequency, and vehicle malfunction events are identified based on the matching results.

[0084] In this embodiment, the matching frequency refers to the frequency of event matching. During the process of acquiring multi-source time series data and matching events using a sliding time window, the matching frequency can be calculated based on the number of events within the current sliding time window, and the event matching process can be performed according to the matching frequency. That is, the more events within the sliding time window, the lower the matching frequency; conversely, the fewer events within the sliding time window, the higher the matching frequency.

[0085] This application adjusts the calculation interval (i.e., matching frequency, such as 10s to 30s) according to the trajectory length (i.e., the number of events within the sliding time window). When the trajectory is long, extending the calculation interval can reduce redundant calculations, and when the trajectory is short, shortening the interval can ensure real-time performance.

[0086] Taking a vehicle fire as an example, this application embodiment can assess the integrity of the trajectory: based on the event coverage (e.g., number of hit events / total number of events) and the continuity of the time interval in the matching results, it determines whether a complete "fire risk trajectory" is constituted. It can also be adapted to various scenarios: for different scenarios such as spontaneous combustion, external fire source impact, collision-induced fire, and thermal runaway, it matches the trajectory model using preset event sequences (e.g., "abnormal battery temperature → smoke signal → voltage drop" corresponding to the thermal runaway scenario). If the match is successful and the coverage exceeds a threshold, a real-time warning is triggered, and risk points are located by combining spatiotemporal information (e.g., vehicle location, event occurrence time chain), providing a basis for fire rescue or vehicle control.

[0087] The solution provided in this application does not rely on a complex model training process and can be deployed based on rule combination and trajectory logic. Compared with solutions that rely on deep learning or visual recognition, it has low deployment cost, strong generalization ability, and is suitable for rapid integration and iterative upgrades of large-scale vehicles. This embodiment can be applied to the after-sales stage, safety monitoring stage, and OTA (Over-The-Air Technology) data analysis process of the whole vehicle. It can be embedded as an important component of the intelligent risk control system of car companies, building a closed-loop fire monitoring system integrating vehicle and cloud, and providing a technical foundation for large-scale intelligent operation. Since it does not rely on deep learning training or image recognition modules, this embodiment can run in computing-limited environments, is suitable for compatible deployment of multiple vehicle models, multiple platforms, and different signal sampling rates, and has good stability and scalability.

[0088] Example 3

[0089] Reference Figure 3 The diagram shows a structural schematic of a fault event identification device provided in an embodiment of this application. Figure 3 As shown, the fault event identification device 300 may include the following modules:

[0090] The event acquisition module 310 is used to parse the time series data associated with the vehicle using a sliding time window method to obtain the events associated with the vehicle.

[0091] The fault identification module 320 is used to match the events and identify the fault events of the vehicle based on the matching results.

[0092] Optionally, the event acquisition module includes:

[0093] The multi-source data acquisition submodule is used to acquire multi-source time series data associated with the vehicle.

[0094] The event acquisition submodule is used to parse the multi-source time series data to obtain the events associated with the means of transportation and the timestamps of the events.

[0095] Optionally, the fault identification module includes:

[0096] The event caching submodule is used to cache the event in an incrementing timestamp list corresponding to the event type, where the event type is the type corresponding to the event.

[0097] The matching result acquisition submodule is used to match events in the timestamp list according to the timestamp to obtain the matching result;

[0098] The fault identification submodule is used to identify fault events of the vehicle based on the matching results.

[0099] Optionally, the matching result acquisition submodule includes:

[0100] A timestamp conversion unit is used to convert timestamps in the timestamp list into consecutive time periods;

[0101] The matching result acquisition unit is used to match events in a continuous time period using a reverse interval matching method to obtain the matching result.

[0102] Optionally, the matching result acquisition unit includes:

[0103] The time window acquisition sub-unit is used to acquire the time window of the first matched event during the event matching process using the reverse interval matching method.

[0104] The delay time acquisition subunit is used to acquire the maximum delay time and the minimum delay time corresponding to the first event. The maximum delay time is the latest time that constrains the second event, and the minimum delay time is the earliest time that constrains the second event. The second event is the event preceding the first event in the timestamp list.

[0105] The target window determination subunit is used to determine the target time window of the second event based on the start and end times corresponding to the time window, the maximum delay time, and the minimum delay time.

[0106] An event matching subunit is used to match the second event based on the target time window;

[0107] The first result acquisition subunit is used to obtain the matching result after all event matching is completed.

[0108] Optionally, the matching result acquisition unit includes:

[0109] The intersection calculation subunit is used to calculate the intersection of the time window with the third event starting from the current event during the event matching process using the reverse interval matching method. If there is an intersection, the current event is determined to be successfully matched, and the time intersection interval is recorded. The third event is the event preceding the current event in the timestamp list.

[0110] The second result acquisition subunit is used to continue repeating the above intersection calculation process with the fourth event, using the currently matched time intersection interval as a new constraint, until all events are traversed to obtain the matching result. The fourth event is the event preceding the third event in the timestamp list.

[0111] Optionally, the matching result acquisition unit includes:

[0112] The third result acquisition subunit is used to obtain the result of event matching failure if any necessary event in the events within the continuous time period fails to match. The necessary event is the necessary event that triggers the fault event.

[0113] The fourth result acquisition subunit is used to obtain the result of event matching failure when the number of successfully matched events is less than the number threshold.

[0114] Optionally, the fault identification module includes:

[0115] The frequency determination submodule is used to determine the matching frequency corresponding to the event based on the number of events within the sliding time window;

[0116] The fault event identification submodule is used to match the events according to the timestamp based on the matching frequency, and identify the fault events of the vehicle based on the matching results.

[0117] This application embodiment provides a method for parsing time-series data associated with vehicles using a sliding time window approach to obtain events associated with the vehicles. These events are then matched, and vehicle malfunction events are identified based on the matching results. By employing a sliding time window approach to analyze the time-series data of vehicles, this application embodiment can complete malfunction identification as soon as a malfunction event occurs, improving the real-time performance of vehicle malfunction event identification.

[0118] Example 4

[0119] This application also provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the above-described fault event identification method.

[0120] Figure 4 A schematic diagram of the structure of an electronic device 400 according to an embodiment of the present invention is shown. Figure 4 As shown, the electronic device 400 includes a central processing unit (CPU) 401, which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) 402 or loaded from storage unit 408 into random access memory (RAM) 403. The RAM 403 may also store various programs and data required for the operation of the electronic device 400. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0121] Multiple components in electronic device 400 are connected to I / O interface 405, including: input unit 406, such as keyboard, mouse, microphone, etc.; output unit 407, such as various types of monitors, speakers, etc.; storage unit 408, such as disk, optical disk, etc.; and communication unit 409, such as network card, modem, wireless transceiver, etc. Communication unit 409 allows electronic device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0122] The various processes and handling described above can be executed by processing unit 401. For example, the methods of any of the above embodiments can be implemented as computer software programs tangibly contained in a computer-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 400 via ROM 402 and / or communication unit 409. When the computer program is loaded into RAM 403 and executed by CPU 401, one or more actions of the methods described above can be performed.

[0123] Additionally, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned fault event identification method.

[0124] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0125] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0126] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminals (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0127] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0128] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal, causing a series of operational steps to be executed on the computer or other programmable terminal to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0129] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0130] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes said element.

[0131] The above provides a detailed description of a fault event identification method, a fault event identification device, an electronic device, and a computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A fault event identification method, characterized in that, include: By using a sliding time window approach, the time series data associated with the means of transportation are parsed to obtain the events associated with the means of transportation; The events are matched, and the malfunction events of the vehicle are identified based on the matching results.

2. The method according to claim 1, characterized in that, The analysis of time-series data associated with the means of transportation yields the events associated with those means of transportation, including: Obtain multi-source time series data associated with the vehicle; The multi-source time series data is parsed to obtain the events associated with the means of transportation and the timestamps of those events.

3. The method according to any one of claims 1 to 2, characterized in that, The matching of the events and the identification of the vehicle malfunction events based on the matching results include: The events are cached in a timestamp list corresponding to the event type, where the event type is the type corresponding to the event. The events in the timestamp list are matched according to the timestamp to obtain the matching result; Based on the matching results, the malfunction events of the vehicle are identified.

4. The method according to claim 3, characterized in that, The step of matching events in the timestamp list according to the timestamp to obtain the matching result includes: Convert the timestamps in the timestamp list into consecutive time periods; The matching results are obtained by matching events in a continuous time period using a reverse interval matching method.

5. The method according to claim 4, characterized in that, The method of reverse interval matching is used to match events within a continuous time period to obtain the matching results, including: During the event matching process using reverse interval matching, the time window of the first matched event is obtained. Obtain the maximum delay time and minimum delay time corresponding to the first event, wherein the maximum delay time is the latest time constraining the second event, the minimum delay time is the earliest time constraining the second event, and the second event is the event preceding the first event in the timestamp list; The target time window for the second event is determined based on the start and end times corresponding to the time window, the maximum delay time, and the minimum delay time. The second event is matched based on the target time window; The matching results are obtained after all events have been matched.

6. The method according to any one of claims 4 to 5, characterized in that, The method of reverse interval matching is used to match events within a continuous time period to obtain the matching results, including: In the process of event matching using the reverse interval matching method, starting from the current event, the intersection of the time window with the third event is calculated. If there is an intersection, the current event is determined to be successfully matched, and the time intersection interval is recorded. The third event is the event preceding the current event in the timestamp list. Using the time intersection interval obtained from the current match as a new constraint, continue to repeat the above intersection calculation process with the fourth event until all events are traversed to obtain the matching result. The fourth event is the event preceding the third event in the timestamp list.

7. The method according to any one of claims 4 to 6, characterized in that, The matching of events over a continuous time period to obtain the matching result includes: If any necessary event fails to match within the continuous time period, the result of event matching failure is obtained, where the necessary event is the necessary event that triggers the fault event. If the number of successfully matched events is less than the threshold, the result is "event matching failed".

8. The method according to any one of claims 1 to 7, characterized in that, The matching of the events and the identification of the vehicle malfunction events based on the matching results include: The matching frequency corresponding to the event is determined based on the number of events within the sliding time window; According to the matching frequency, the events are matched based on the timestamp, and the malfunction events of the vehicle are identified based on the matching results.

9. A fault event identification device, characterized in that, include: The event acquisition module is used to parse the time series data associated with the vehicle using a sliding time window method to obtain the events associated with the vehicle. The fault identification module is used to match the events and identify the fault events of the vehicle based on the matching results.

10. An electronic device, characterized in that, include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the fault event identification method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the fault event identification method according to any one of claims 1 to 8.

Images