Vehicle event fusion method and system based on cooperation of mq message and buffer state

Abstract

This invention relates to the field of data fusion processing technology, and discloses a vehicle event fusion method and system based on the collaboration of MQ messages and cached states. The method includes: constructing a set of input parameters for events to be fused; performing time window repetition filtering; extracting the current state transition judgment parameter set; generating a target fusion event result set; and generating event fusion processing results. Compared to existing technologies that rely solely on single vehicle state reporting information for event recording, especially under conditions where intermediate states exist during vehicle lifting and message arrival times are unstable, this method addresses the technical problem of failing to accurately distinguish between vehicle lifting events and lowering events. By collaboratively verifying the current state field in the MQ message with the previous state field in the Redis cache, and combining this with event reporting time window filtering, this application achieves accurate fusion and identification of vehicle events, improving the accuracy of vehicle event processing.

Description

Technical Field

[0001] This invention relates to the field of data fusion processing technology, and in particular to a vehicle event fusion method and system based on the coordination of MQ messages and cache status. Background Technology

[0002] Currently, in vehicle operation management and dispatching systems, operation events are typically generated by triggering event recording at the dispatch terminal or directly based on the status information reported by the vehicles, such as recording lifting events or bucket lowering events based on changes in vehicle status. However, this type of processing generally relies on a single data source and lacks a collaborative verification mechanism for the consistency between multiple data sources, resulting in significant identification biases and duplicate write problems in complex operating environments.

[0003] For example, during vehicle lifting operations, vehicle status reporting may involve intermediate states, discontinuous state transitions, and short-term fluctuations in status values. Simultaneously, the arrival order of MQ messages may be delayed or out of order, and historical status updates in the Redis cache may lag behind the latest messages. Under these conditions, if event generation is based solely on a single status report or simple time-based judgment, intermediate states may be misclassified as valid events, or the same operation process may be repeatedly recorded due to multiple triggers. This leads to redundancy in event data, inaccurate event type identification, and inconsistencies between cached states and event records.

[0004] Existing technologies cannot fully meet the requirements for accurate identification, effective deduplication, and maintenance of state consistency of vehicle operation events in scenarios with coexisting multi-source data, unstable status reporting, and frequent short-term repetitive triggering. Therefore, there is an urgent need for a vehicle event fusion method that can still accurately determine vehicle lifting and lowering events, effectively filter duplicate events, and maintain consistency between event records and cached states, even when there is a time difference between MQ messages and cached states, intermediate processes in state transitions, and frequent event triggering. This method aims to improve the accuracy, timing consistency, and system stability of vehicle event processing. Summary of the Invention

[0005] To address the aforementioned technical shortcomings, the purpose of this invention is to propose a vehicle event fusion method based on the coordination of MQ messages and cached states. This method aims to solve the technical problem that existing technologies rely solely on single vehicle status reporting information for event recording, particularly when there are intermediate states during the vehicle lifting process and the message arrival time is unstable, making it impossible to accurately distinguish between vehicle lifting events and bucket lowering events.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: The present invention provides a vehicle event fusion method based on the coordination of MQ messages and cache status.

[0007] The vehicle event fusion method based on MQ message and cache state coordination includes: Step S10: Obtain vehicle dispatch trigger information, MQ message data, Redis cache status data, and fusion event table data. Based on the vehicle dispatch trigger information, MQ message data, and Redis cache status data, execute the event input parameter construction task using a multi-source parameter normalization construction mechanism, and output the event input parameter set to be fused. Step S20: Based on the input parameter set of events to be fused, a time window repeated filtering mechanism is used to perform a historical event screening task, and a candidate executable event parameter set is output; Step S30: Based on the candidate executable event parameter set, a message timeliness and state integrity verification mechanism is used to perform a preprocessing task and output a state transition determination parameter set; Step S40: Based on the state transition determination parameter set, a state switching recognition mechanism is used to perform the target event recognition task, and the target fusion event result set is output; Step S50: Generate event unique keys, write fusion events, and update Redis cache status based on the target fusion event result set, and output the event fusion processing result.

[0008] Preferably, the set of input parameters for the events to be fused includes at least vehicle identifiers. Event type identifier Operation Description Time of reporting this incident Storage time Current status field in MQ message MQ message timestamp The previous state field in the Redis cache and Redis cache timestamps .

[0009] Preferably, the set of input parameters for the events to be fused includes at least vehicle identifiers. Event type identifier Operation Description Time of reporting this incident Storage time Current status field in MQ message MQ message timestamp The previous state field in the Redis cache and Redis cache timestamps .

[0010] Preferably, in step S20, a historical event screening task is performed based on the set of input parameters for the events to be fused, using a time window repeat filtering mechanism, to output a set of candidate executable event parameters, specifically including: Step S201: Based on the current event reporting time in the set of input parameters for the events to be fused Construct the starting point of the query time window ,in: ; Preset query duration; Then according to the vehicle identification Event type identifier and the start point of the query time window Perform a historical event query on the merged event table data in reverse chronological order of event reporting time, and output a set of candidate historical events. ; Step S202: Based on the candidate historical event set Extract the reporting time of the most recent historical event record. And calculate the reporting time of this incident. The reporting time of the most recent historical event record Time difference , ; Step S203: Then, the time difference With preset duplicate filtering threshold The comparison is performed, and a set of candidate executable event parameters is output.

[0011] Preferably, in step S203, the time difference is then... With preset duplicate filtering threshold The steps of comparing and outputting a set of candidate executable event parameters specifically include: when the set of candidate historical events... Or the time difference When the current event meets the conditions for continuing execution, the input parameter set of the current event is retained as a candidate executable event parameter set; when and If the current event is determined to be a duplicate event, the current processing flow will be terminated.

[0012] Preferably, step S30, which involves performing a preprocessing task based on the candidate executable event parameter set using a message timeliness and state integrity verification mechanism, and outputting a state transition determination parameter set, specifically includes: Step S301: Extract the current state field based on the candidate executable event parameter set. MQ message timestamp Previous state field and Redis cache timestamps And calculate the MQ message timestamp Redis cache timestamps Time difference between ,in: ; Step S302: When the current state field It is an empty value or the previous state field. When the current state field is empty, the candidate executable event parameter set is determined to be incomplete and the current processing flow is terminated; when the current state field is empty... With the previous state field If none of the fields are empty, retain and merge the current state fields. MQ message timestamp Previous state field Redis cache timestamps and time difference Output the complete set of parameters for the state; Step S303: Calculate the time difference Compared with the preset time threshold When comparing, At that time, generate a valid state marker. ;when At that time, generate a valid state marker. ; Step S304: Finally, based on the complete set of state parameters and the valid state flags... Output the set of state transition decision parameters.

[0013] Preferably, step S40, which involves performing the target event identification task based on the state transition determination parameter set using a state switching identification mechanism and outputting a target fusion event result set, specifically includes: Step S401: Read the valid state flag based on the state transition determination parameter set. Current status field and the previous state field When the state is valid, it is marked. When, retain the current state field. With the previous state field And execute step S402; when the state is validly marked If this occurs, the current processing procedure will be terminated. Step S402: Determine the current state field Is it an intermediate state value of 3? When the current state field... When the current state does not meet the target event identification conditions, the target fusion event result set is not output, and steps S301 to S303 are re-executed after a new MQ message is subsequently obtained; when the current state field At that time, retain vehicle identification. Current status field Previous state field Operation Description Incident reporting time and storage time Construct an effective state-switching input group; Step S403: Based on the valid state input group, according to the current state field With the previous state field Identify the state transition relationship between the target and the event type. And according to vehicle identification Target fusion event types Operation Description Incident reporting time Storage time and the current status field Construct and output the target fusion event result set.

[0014] Preferably, in step S40, based on the current state field Compared to the previous status field Combination relationship identification target fusion event type Specifically:

[0015] in, Indicates the type of vehicle lifting event. Indicates the type of vehicle falling into the truck bed. Indicates an invalid event type; when When, a vehicle lifting event is generated; when When, a vehicle falling into the truck bed event is generated; when If no valid state transition is found, the current processing flow is terminated.

[0016] This invention also provides a vehicle event fusion system based on MQ message and cache state coordination, including: The parameter construction module is used to obtain vehicle dispatch trigger information, MQ message data, Redis cache status data and fusion event table data. Based on the vehicle dispatch trigger information, MQ message data and Redis cache status data, it uses a multi-source parameter normalization construction mechanism to execute the event input parameter construction task and outputs the set of event input parameters to be fused. The duplicate filtering module is used to perform a historical event screening task based on the input parameter set of events to be fused using a time window duplicate filtering mechanism, and output a candidate executable event parameter set; The preprocessing module is used to perform preprocessing tasks based on the candidate executable event parameter set using a message timeliness and state integrity verification mechanism, and output a state transition determination parameter set. The event recognition module is used to perform the target event recognition task based on the state transition determination parameter set using a state switching recognition mechanism, and output the target fusion event result set; The result writing module is used to generate event unique keys, write fused events, and update Redis cache status based on the target fused event result set, and output the event fusion processing result.

[0017] The present invention also provides a vehicle event fusion device based on MQ message and cache state coordination, comprising: a memory, a processor, and a vehicle event fusion program based on MQ message and cache state coordination stored in the memory and executable on the processor. When the vehicle event fusion program based on MQ message and cache state coordination is executed by the processor, a vehicle event fusion method based on MQ message and cache state coordination is implemented.

[0018] The present invention also provides a computer program product, including a vehicle event fusion program based on MQ message and cache state coordination. When the vehicle event fusion program based on MQ message and cache state coordination is executed by a processor, it implements the vehicle event fusion method based on MQ message and cache state coordination.

[0019] The beneficial effects of this invention are as follows: This invention unifies the construction of vehicle dispatch trigger information, MQ message data, and cached status data, and establishes a query time window based on the event reporting time to screen historical events and compare time intervals, thereby filtering out events that are repeatedly reported in a short period of time; at the same time, in the event identification stage, it combines the correspondence between the current state and the previous state, and generates fused events only when the valid state change conditions are met, thereby avoiding the problem of repeated writing caused by message duplication, frequent reporting, or state jitter, and improving the accuracy and uniqueness of vehicle event identification results.

[0020] This invention compares the consistency of MQ message time with cached state time and performs integrity verification between the current state and the previous state. State transition determination is only performed when the state information is complete and the time is within a valid range. After event identification is completed, the fused event is written and the cached state is updated synchronously to keep the cached state consistent with the event result. This avoids misjudgment of state due to cache delay, missing state, or out-of-order message, thereby improving the timing consistency of event processing and the stability of system operation. Attached Figure Description

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

[0022] Figure 1 This is a flowchart illustrating the first embodiment of the vehicle event fusion method based on the collaboration of MQ messages and cache status according to the present invention.

[0023] Figure 2 This is a schematic diagram of the device for the vehicle event fusion method based on MQ message and cache state coordination according to the present invention. Detailed Implementation

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

[0025] Example 1: As Figure 1 The diagram shown is a flowchart of the first embodiment of the vehicle event fusion method based on the coordination of MQ messages and cache state according to the present invention. The first embodiment of the vehicle event fusion method based on the coordination of MQ messages and cache state according to the present invention is proposed.

[0026] In the first embodiment, the vehicle event fusion method based on MQ message and cache state coordination includes: Step S10: Obtain vehicle dispatch trigger information, MQ message data, Redis cache status data, and fusion event table data. Based on the vehicle dispatch trigger information, MQ message data, and Redis cache status data, execute the event input parameter construction task using a multi-source parameter normalization construction mechanism, and output the event input parameter set to be fused. It should be noted that the vehicle dispatch trigger information refers to the operation request information initiated by the dispatching terminal or collaborative terminal during vehicle operation, used to characterize the operation behavior of the vehicle at the current moment, including but not limited to operation start instructions, operation end instructions, and status change trigger signals; the MQ message data refers to the running status data reported by the vehicle in real time through the message queue, including the current status field, message reporting time, and status identifier information related to vehicle operation; the Redis cached status data refers to the historical vehicle status information maintained in the cache system, including the previous status field and its corresponding time information; the fused event table data refers to the data set used to record the results of historical events, including generated vehicle event records and their corresponding time information and event types. By uniformly acquiring and organizing the above multi-source data, data from different sources are made into a unified input in terms of structure and time dimension.

[0027] Understandably, by employing a multi-source parameter normalization mechanism, data from scheduling trigger information, MQ messages, and cached states are uniformly mapped and integrated. This eliminates differences in field representation, time granularity, and update frequency between different data sources, enabling various types of data to be uniformly represented within the same data structure. This provides a stable data foundation for subsequent steps such as duplicate filtering, state consistency verification, and state transition identification, thereby improving the overall data consistency and processing accuracy. For example, during a vehicle lifting operation, while the dispatcher initiates the operation command, the vehicle continuously reports its current status information via MQ, and Redis retains the previous status record. Through this step, the vehicle identifier and operation description in the scheduling trigger information, the current status field and its reporting time in the MQ message, and the previous status field and its corresponding time in Redis can be uniformly integrated to form a consistent set of input parameters for the event to be fused. This allows subsequent steps to determine whether the vehicle status has changed effectively based on the same data, thus avoiding inaccurate event identification caused by dispersed data sources.

[0028] Step S20: Based on the input parameter set of events to be fused, a time window repeated filtering mechanism is used to perform a historical event screening task, and a candidate executable event parameter set is output; It should be noted that the set of input parameters for events to be merged refers to the set of event input data formed in step S10 after being uniformly constructed based on vehicle scheduling trigger information, MQ message data, and Redis cache state data. It is used to at least characterize the vehicle identifier, event type, event reporting time, and state information related to the current event screening of the event to be processed. The time window duplicate filtering mechanism refers to constructing a query time range of a preset duration based on the time base of the current event, and retrieving historical event records corresponding to the current vehicle identifier and event type in the merged event table to screen events that are repeatedly triggered, repeatedly reported, or repeatedly written within a short period of time. The historical event screening task refers to identifying event records in the historical event table that may have a duplicate relationship with the current event based on the time proximity relationship and event attribute consistency between the current event and historical events. The candidate executable event parameter set refers to the set of event parameters retained after the duplicate screening is completed, which is used to enter the next step to continue executing state integrity verification and state transition identification.

[0029] Understandably, by establishing a temporal correlation between current pending events and historical events, the system can not only focus on the single trigger result at the current moment but also perform joint judgments based on event records already generated within a short timeframe. This allows for the early interception of redundant events caused by continuous triggering, repeated reporting, or high-frequency jitter. In this way, a historical consistency screening can be completed before an event enters the subsequent state determination process. This ensures that events that truly require further processing are retained, while duplicate events that lack further processing value are terminated prematurely. This reduces invalid calculations, improves the processing efficiency of subsequent state verification and event identification stages, and makes the final written fused event result more unique and accurate.

[0030] For example, during a complete vehicle lifting operation, the dispatch terminal might send the same event trigger information multiple times within a few seconds due to network jitter, repeated clicks, or terminal retransmissions. Simultaneously, the vehicle's reported status information during this period might also be received multiple times by the system. Without this historical event screening step, these input messages with the same vehicle identifier and event attributes within a short period could easily be identified as multiple independent events by the system, leading to repeated processing and even repeated writing to the fusion event table in subsequent steps. This step establishes a query time window around the reporting time of the current event, searching the fusion event table for historical records of the same vehicle and event type within that time range. If a historical event with the same attributes and time adjacent to the current event exists, the current event is identified as a duplicate event, and subsequent processing is terminated. If no historical event meets the duplicate criteria, the event is retained as a candidate executable event to proceed to the next step.

[0031] Step S30: Based on the candidate executable event parameter set, a message timeliness and state integrity verification mechanism is used to perform a preprocessing task and output a state transition determination parameter set; It should be noted that the candidate executable event parameter set refers to the set of event parameters retained after the historical event screening in step S20, which is used to characterize that the current event has passed the duplicate filtering and has the basic conditions to enter the state consistency verification stage; the message timeliness and state integrity verification mechanism refers to the processing method of performing validity checks on the data content related to state determination in the candidate executable event parameter set, including extracting the current state field and its corresponding time information in the MQ message, extracting the previous state field and its corresponding time information in the Redis cache, and verifying whether the above state information is complete and whether it is comparable in time; the preprocessing task refers to the screening, verification and regularization of the key parameters involved in the state transition determination before executing the target event identification, so that the data entering the next step all meet the integrity and timing conditions required for state identification; the state transition determination parameter set refers to the set of parameters formed after verification in this step, which can be used to determine whether a valid switch has occurred between the current state and the historical state.

[0032] Understandably, after event filtering, further pre-constraints are imposed on the availability and time consistency of the state data itself. This ensures that subsequent state identification is based not on isolated, missing, or time-mismatched state information, but on valid data that truly reflects the vehicle's state change process. By first determining the completeness of the current state and the previous state, and then determining the time sequence consistency between the message time and the cache time, unreliable inputs caused by factors such as missing state fields, outdated caches, message delays, or state asynchrony can be eliminated before entering target event identification. This ensures that subsequent state transition identification is based on valid and reliable data, improving the stability and accuracy of state determination.

[0033] It should be understood that, compared to the traditional approach of directly identifying events based on the current state value after receiving a vehicle status report, this step not only focuses on the current state itself but also simultaneously incorporates the previous state and its time information from the cache for joint verification. This transforms state identification from "single-point judgment" to "interrelated judgment of preceding and following states." This effectively overcomes the misjudgment problems caused by lost state fields, cache delays, unstable message timing, or missing previous states in traditional processing methods. It also avoids directly sending data that does not meet the judgment criteria into the subsequent identification process, thereby improving the rigor, reliability, and engineering applicability of the entire event fusion process.

[0034] For example, during a vehicle lifting operation, the system has already confirmed in step S20 that the current event is not a repeated triggering event within a short period. At this point, it needs to further determine whether the status information in the current MQ message can be truly used for subsequent state transition identification. If the current message contains the vehicle identifier and event triggering information, but the current status field is empty, or the previous status field for the corresponding vehicle is not saved in the Redis cache, it indicates that a complete "previous state - current state" relationship cannot be constructed. In this case, this step will directly terminate the processing to avoid continuing identification without basis. Similarly, if the status information in the current MQ message exists, and the previous state also exists in Redis, but the time difference between the two is too large, it indicates that the cached state and the current message state are not in the same continuous operation process. Continuing to determine the state transition in this case could easily misidentify unrelated states as the preceding and following states of the same event. Therefore, this step will intercept them. Only when the current state, the previous state, and the corresponding time relationship all meet the preset conditions will the state transition determination parameter set be output for step S40 to continue performing target event identification, thereby ensuring that the data entering the next step has sufficient basis for determination.

[0035] Step S40: Based on the state transition determination parameter set, a state switching recognition mechanism is used to perform the target event recognition task, and the target fusion event result set is output; It should be noted that the state transition determination parameter set refers to the set of parameters retained after the message timeliness and state integrity verification is completed in step S30, which is used to characterize at least the current state, the previous state, and the event context information corresponding to the two; the state switching identification mechanism refers to the processing method of identifying whether a valid state switching has been formed based on the change relationship between the current state and the previous state of the vehicle, including judging whether the state is in an identifiable state, intercepting intermediate states, and distinguishing the direction of change of valid states; the target event identification task refers to classifying the current event to be identified into a specific target fusion event type based on the state switching relationship, so as to determine whether a vehicle lifting event, a vehicle lowering event, or a valid event should be generated; the target fusion event result set refers to the event result parameter set formed after identification in this step, which is used to characterize the target event type corresponding to the current event and the event information required for subsequent writing.

[0036] It should be understood that, compared to traditional methods that only statically judge the current state value or generate events based on a single trigger signal, this step introduces a correspondence between the previous and current states, giving the event recognition process a clear characteristic of continuous judgment. Especially when the vehicle's operating state has intermediate states, state fluctuations, or short pauses, traditional methods easily misidentify temporary changes during state transitions as valid events. This step, however, by first determining whether the state meets the recognition criteria and then determining the event type based on the direction of state transition, can effectively suppress misjudgments caused by state instability, making the final generated event results more consistent with the actual vehicle operation process.

[0037] Step S50: Generate event unique keys, write fusion events, and update Redis cache status based on the target fusion event result set, and output the event fusion processing result.

[0038] It should be noted that the target fusion event result set refers to the set of target event parameters identified in step S40, which is at least used to characterize the vehicle identifier, target event type, event description, event time, and current status of the current event; the event unique key generation refers to constructing a data identifier that can uniquely identify the current event based on the key fields in the target fusion event result, which is used to distinguish the event records corresponding to different vehicles, different event types, and different time points; the fusion event writing refers to writing the currently identified target event into the fusion event table according to the preset field structure to form a formal event record that can be used for subsequent querying, deduplication, and tracing; the Redis cache status update refers to writing back the latest status information and related time information corresponding to the current identification to the Redis cache after the event writing is completed, as a historical reference for subsequent vehicle status determination; the event fusion processing result refers to the processing output formed after the table writing and cache update are completed in this step, which is used to characterize that the current event has been finally stored in the database and the status is synchronized.

[0039] Understandably, the purpose of this step is to transform the target events identified in the previous steps from "judgment results" into formal system records that are "manageable, traceable, and reusable," while simultaneously maintaining the cached state foundation upon which subsequent identification relies. On one hand, generating unique event keys ensures that the current event is clearly identified within the system, facilitating unique event management and accurate retrieval. On the other hand, writing the merged event to the event table and synchronously updating the state information in Redis after writing ensures that historical event records remain consistent with the cached state, providing a reliable historical basis for the next round of event duplication filtering and state transition identification. Thus, this step not only completes the final processing of the current event but also establishes a continuous data foundation for subsequent event processing flows.

[0040] It should be understood that, compared to traditional methods that only generate event results without simultaneously maintaining the cache state, or that update the cache before writing to the event table, this step coordinates the formal writing of events with the update of the cache state, creating a consistent closed-loop relationship between event results and the underlying state. This effectively avoids two common problems in traditional methods: firstly, events are judged but not formally recorded, leading to a lack of queryable basis for subsequent duplicate filtering; secondly, the cache state is overwritten before the event record is written to the table, causing a misalignment between the cache and event history relied upon in subsequent state recognition processes. This step ensures that event records, state caches, and subsequent recognition logic remain continuous and consistent, thereby improving the stability and consistency of the entire vehicle event fusion processing process.

[0041] For example, when step S40 has identified that the current vehicle has completed a valid lifting event, this step first constructs a unique identifier for the current event based on the vehicle's identifier, event type, and event time, ensuring that the lifting event has a unique record entry in the fused event table. Then, the relevant fields of this event are written to the fused event table, enabling the system to accurately retrieve the event's historical records during subsequent duplicate filtering. After writing, the current state and corresponding time are updated in Redis, ensuring that the state stored in Redis matches the most recently confirmed event. Therefore, when the vehicle reports a new state and triggers event processing again, the system can determine whether the same event has recently occurred based on the fused event table, and also determine whether a new valid transition has occurred between the current and previous states based on the latest state in Redis. This ensures the continuity of the entire processing chain and avoids issues such as duplicate event writing, distorted state references, and inconsistent subsequent identification bases.

[0042] Example 2: Furthermore, the vehicle event fusion system based on MQ message and cache state coordination provided by the present invention, employing the vehicle event fusion method based on MQ message and cache state coordination in the above embodiments, can solve the technical problem of vehicle event fusion based on MQ message and cache state coordination. The beneficial effects of the vehicle event fusion system based on MQ message and cache state coordination provided by the present invention are the same as those of the vehicle event fusion method based on MQ message and cache state coordination provided in the above embodiments, and other technical features of the vehicle event fusion system based on MQ message and cache state coordination are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0043] Example 3: This invention provides a vehicle event fusion device based on MQ message and cache state coordination. Please refer to... Figure 2The vehicle event fusion device based on MQ message and cache state coordination 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, which are executed by the at least one processor to enable the at least one processor to execute the vehicle event fusion method based on MQ message and cache state coordination in Embodiment 1 above. The vehicle event fusion device based on MQ message and cache state coordination in this embodiment of the invention may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio 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. The vehicle event fusion device based on MQ message and cache state coordination is merely an example and should not impose any limitations on the functionality and scope of use of this embodiment of the invention. The vehicle event fusion device based on MQ message and cache state coordination 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 read-only memory 1002 or a program loaded from storage device 1003 into random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the vehicle event fusion device based on MQ message and cache state coordination. The processing unit 1001, read-only memory 1002, and random access memory 1004 are interconnected via bus 1005. I / O interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touch screens, 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 vehicle event fusion device based on MQ message and cache state coordination to communicate wirelessly or wiredly with other devices to exchange data. While the figures show vehicle event fusion devices based on MQ message and cache state coordination 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.

[0044] Example 4: This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the vehicle event fusion method based on MQ message and cache state coordination as described above. The computer program product provided by this invention can solve the technical problem of vehicle event fusion based on MQ message and cache state coordination. Compared with the prior art, the beneficial effects of the computer program product provided by this invention are the same as those of the vehicle event fusion method based on MQ message and cache state coordination provided in the above embodiments, and will not be repeated here.

[0045] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this invention 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 invention.

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

[0047] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A vehicle event fusion method based on MQ message and cache state coordination, characterized in that, The methods include: Step S10: Obtain vehicle dispatch trigger information, MQ message data, Redis cache status data, and fusion event table data. Based on the vehicle dispatch trigger information, MQ message data, and Redis cache status data, execute the event input parameter construction task using a multi-source parameter normalization construction mechanism, and output the event input parameter set to be fused. Step S20: Based on the input parameter set of events to be fused, a time window repeated filtering mechanism is used to perform a historical event screening task, and a candidate executable event parameter set is output; Step S30: Based on the candidate executable event parameter set, a message timeliness and state integrity verification mechanism is used to perform a preprocessing task and output a state transition determination parameter set; Step S40: Based on the state transition determination parameter set, a state switching recognition mechanism is used to perform the target event recognition task, and the target fusion event result set is output; Step S50: Generate event unique keys, write fusion events, and update Redis cache status based on the target fusion event result set, and output the event fusion processing result.

2. The vehicle event fusion method based on MQ message and cache state coordination as described in claim 1, characterized in that, The set of input parameters for the events to be merged includes at least vehicle identifiers. Event type identifier Operation Description Time of reporting this incident Storage time Current status field in MQ message MQ message timestamp The previous state field in the Redis cache and Redis cache timestamps .

3. The vehicle event fusion method based on MQ message and cache state coordination as described in claim 1, characterized in that, In step S20, a historical event screening task is performed based on the input parameter set of events to be fused, using a time window repeat filtering mechanism, to output a candidate executable event parameter set, specifically including: Step S201: Based on the current event reporting time in the set of input parameters for the events to be fused Construct the starting point of the query time window ,in: ; Preset query duration; Then according to the vehicle identification Event type identifier and the start point of the query time window Perform a historical event query on the merged event table data in reverse chronological order of event reporting time, and output a set of candidate historical events. ; Step S202: Based on the candidate historical event set Extract the reporting time of the most recent historical event record. And calculate the reporting time of this incident. The reporting time of the most recent historical event record Time difference , ; Step S203: Then, the time difference With preset duplicate filtering threshold The comparison is performed, and a set of candidate executable event parameters is output.

4. The vehicle event fusion method based on MQ message and cache state coordination as described in claim 3, characterized in that, In step S203, the time difference is then... With preset duplicate filtering threshold The steps of comparing and outputting a set of candidate executable event parameters specifically include: when the set of candidate historical events... Or the time difference When the current event meets the conditions for continuing execution, the input parameter set of the current event is retained as a candidate executable event parameter set; when and If the current event is determined to be a duplicate event, the current processing flow will be terminated.

5. The vehicle event fusion method based on MQ message and cache state coordination as described in claim 1, characterized in that, Step S30, which involves performing a preprocessing task based on the candidate executable event parameter set using a message timeliness and state integrity verification mechanism, and outputting a state transition determination parameter set, specifically includes: Step S301: Extract the current state field based on the candidate executable event parameter set. MQ message timestamp Previous state field and Redis cache timestamps And calculate the MQ message timestamp. Redis cache timestamps Time difference between ,in: ; Step S302: When the current state field It is an empty value or the previous state field. When the current state field is empty, the candidate executable event parameter set is determined to be incomplete and the current processing flow is terminated; when the current state field is empty... With the previous state field If none of the fields are empty, retain and merge the current state fields. MQ message timestamp Previous state field Redis cache timestamps and time difference Output the complete set of parameters for the state; Step S303: The time difference Compared with the preset time threshold When comparing, At that time, generate a valid state marker. ;when At that time, generate a valid state marker. ; Step S304: Finally, based on the complete set of state parameters and the valid state flags... Output the set of state transition decision parameters.

6. The vehicle event fusion method based on MQ message and cache state coordination as described in claim 5, characterized in that, Step S40, which involves executing the target event identification task based on the state transition determination parameter set using a state switching identification mechanism and outputting a target fusion event result set, specifically includes: Step S401: Read the valid state flag based on the state transition determination parameter set. Current status field and the previous state field When the state is valid, it is marked. When, retain the current state field. With the previous state field And execute step S402; when the state is validly marked If this occurs, the current processing procedure will be terminated. Step S402: Determine the current state field Is it an intermediate state value of 3? When the current state field... When the current state does not meet the target event identification conditions, the target fusion event result set is not output, and steps S301 to S303 are re-executed after a new MQ message is subsequently obtained; when the current state field At that time, retain vehicle identification. Current status field Previous state field Operation Description Incident reporting time and storage time Construct an effective state-switching input group; Step S403: Based on the valid state input group, according to the current state field With the previous state field Identify the state transition relationship between the target and the event type. And according to vehicle identification Target fusion event types Operation Description Incident reporting time Storage time and the current status field Construct and output the target fusion event result set.

7. The vehicle event fusion method based on MQ message and cache state coordination as described in claim 6, characterized in that, In step S40, based on the current state field Compared to the previous status field Combination relationship identification target fusion event type Specifically: in, Indicates the type of vehicle lifting event. Indicates the type of vehicle falling into the truck bed. Indicates an invalid event type; when When, a vehicle lifting event is generated; when When, a vehicle falling into the truck bed event is generated; when If no valid state transition is found, the current processing flow is terminated.

8. A vehicle event fusion system based on MQ message and cache state coordination, applied to the vehicle event fusion method based on MQ message and cache state coordination as described in any one of claims 1 to 7, characterized in that, The vehicle event fusion system based on MQ message and cache state coordination includes: The parameter construction module is used to obtain vehicle dispatch trigger information, MQ message data, Redis cache status data and fusion event table data. Based on the vehicle dispatch trigger information, MQ message data and Redis cache status data, it uses a multi-source parameter normalization construction mechanism to execute the event input parameter construction task and outputs the set of event input parameters to be fused. The duplicate filtering module is used to perform a historical event screening task based on the input parameter set of events to be fused using a time window duplicate filtering mechanism, and output a candidate executable event parameter set; The preprocessing module is used to perform preprocessing tasks based on the candidate executable event parameter set using a message timeliness and state integrity verification mechanism, and output a state transition determination parameter set. The event recognition module is used to perform the target event recognition task based on the state transition determination parameter set using a state switching recognition mechanism, and output the target fusion event result set; The result writing module is used to generate event unique keys, write fused events, and update Redis cache status based on the target fused event result set, and output the event fusion processing result.

9. A vehicle event fusion device based on MQ message and cached state coordination, characterized in that, The vehicle event fusion device based on MQ message and cache state coordination includes: a memory, a processor, and a vehicle event fusion program based on MQ message and cache state coordination stored in the memory and executable on the processor. When the vehicle event fusion program based on MQ message and cache state coordination is executed by the processor, it implements the vehicle event fusion method based on MQ message and cache state coordination as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a vehicle event fusion program based on MQ message and cache state coordination. When the vehicle event fusion program based on MQ message and cache state coordination is executed by the processor, it implements the vehicle event fusion method based on MQ message and cache state coordination as described in any one of claims 1 to 7.

Images