Alarm information processing method and device, electronic equipment and storage medium

Abstract

This application provides an alarm information processing method, apparatus, electronic device, and storage medium, relating to the field of Internet of Things (IoT) technology. The method is applied to a gateway and includes: acquiring a first message sent by a vehicle; querying at least one of the vehicle's local cache and memory database based on the vehicle identifier to determine whether the vehicle's current state is normal; if the vehicle's current state is abnormal and the first message is an alarm trigger message, determining whether the first alarm information corresponding to the first message is new alarm information; if it is new alarm information, pushing the first alarm information to a downstream system and storing the first alarm information in the server's local cache and memory database; if it is not new alarm information, not pushing the first alarm information to the downstream system; if the vehicle's current state is normal and the first message is an alarm end message, not pushing the alarm recovery information corresponding to the first message to the downstream system. This reduces the alarm information push delay.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to alarm information processing methods, devices, electronic devices, and storage media. Background Technology

[0002] With the continuous maturation and promotion of new energy vehicles and Internet of Things (IoT) technologies, vehicle-to-everything (V2X) technology is becoming increasingly widespread. Currently, many vehicles are connected to intelligent platforms. During vehicle operation, problems inevitably occur, and these problems need to be reported to the Telematics Service Provider (TSP) as alarm messages. In addition to recording relevant data, the TSP platform also needs to push information to the downstream systems of relevant business parties when alarm messages are generated and when alarms are recovered.

[0003] In existing technologies, when the gateway on the platform side receives data packets from a vehicle, it first sends the data packets to the Kafka message middleware. Then, the parsing server retrieves each data packet from the Kafka message middleware, parses out the alarm information, and finally pushes the alarm information to downstream systems. However, this method results in a high delay in alarm information delivery. Summary of the Invention

[0004] This application provides an alarm information processing method, device, electronic equipment, and storage medium to reduce the push delay of alarm information.

[0005] This application provides an alarm information processing method applied to a gateway, comprising the following steps: Obtain the first message sent by the vehicle, wherein the first message is an alarm trigger message or an alarm end message, and the first message includes the vehicle identifier of the vehicle; Based on the vehicle identifier query server local cache and memory database at least one, determine whether the current status of the vehicle is normal; If the current state of the vehicle is abnormal and the first message is an alarm trigger message, determine whether the first alarm information corresponding to the first message is a new alarm information; if it is a new alarm information, push the first alarm information to the downstream system and store the first alarm information in the local cache of the server and the memory database; if it is not a new alarm information, do not push the first alarm information to the downstream system. If the vehicle is currently in a normal state and the first message is an alarm termination message, the alarm recovery information corresponding to the first message will not be pushed to the downstream system.

[0006] According to the alarm information processing method provided in this application, the method further includes: If the vehicle is in a normal state and the first message is an alarm trigger message, the first alarm information corresponding to the first message is pushed to the downstream system, and the first alarm information is stored in the server's local cache and the memory database. If the current state of the vehicle is abnormal and the first message is an alarm end message, the alarm recovery information corresponding to the first message will be pushed to the downstream system.

[0007] According to an alarm information processing method provided in this application, storing the first alarm information in the local cache of the server and the memory database includes: generating a key including the vehicle identifier, an end flag, and the first alarm information in binary representation; and generating a value including the vehicle identifier, start time, end time, alarm level, and the first alarm information. The key and the value are stored in the local cache of the server and the memory database in the form of key-value pairs. The start time is the timestamp of the first message being sent, the end time is a preset initial value, and the end flag is used to indicate whether the first message is an alarm trigger message or an alarm end message. The method further includes: when the current state of the vehicle is abnormal and the first message is an alarm termination message, updating the end time corresponding to the unfinished historical alarm information of the vehicle in the local cache of the server and the memory database.

[0008] According to the alarm information processing method provided in this application, the method further includes: If the first alarm information is a new alarm information, the end time corresponding to the unfinished historical alarm information of the vehicle is updated in the local cache of the server and the memory database.

[0009] According to the alarm information processing method provided in this application, the method further includes: If the current state of the vehicle is normal and the first message is an alarm trigger message, the current state of the vehicle is changed to abnormal in the local cache of the server and the memory database. If the current state of the vehicle is abnormal and the first message is an alarm termination message, the current state of the vehicle will be changed to normal in the local cache of the server and the memory database.

[0010] According to the alarm information processing method provided in this application, the step of querying at least one of the vehicle identifier's local cache and memory database to determine whether the vehicle's current status is normal includes: Generate a fuzzy query key that includes the vehicle identifier; The server's local cache is queried according to the fuzzy query key to determine whether there are any unfinished historical alarm messages in the server's local cache that match the fuzzy query key. If the server's local cache contains unfinished historical alarm information that matches the fuzzy query key, the current state of the vehicle is determined to be abnormal. If the server's local cache does not contain any unfinished historical alarm information matching the fuzzy query key, the memory database is queried according to the fuzzy query key to determine whether the memory database contains any unfinished historical alarm information matching the fuzzy query key. If the memory database contains unfinished historical alarm information that matches the fuzzy query key, the current state of the vehicle is determined to be abnormal. If there are no unfinished historical alarm messages matching the fuzzy query key in the memory database, the current state of the vehicle is determined to be normal.

[0011] According to the alarm information processing method provided in this application, when the current state of the vehicle is abnormal and the first message is an alarm trigger message, determining whether the first alarm information corresponding to the first message is a new alarm information includes: When the current state of the vehicle is abnormal and the first message is an alarm trigger message, the fault code in the first alarm information is obtained to obtain the first fault code, and the fault code in the historical alarm information in the returned data is obtained to obtain the second fault code, wherein the returned data is the unfinished historical alarm information matched by the fuzzy query key; The first fault code is matched with the second fault code. If the first fault code is the same as the second fault code, the first alarm information is determined to be a new alarm information; if the first fault code is different from the second fault code, the first alarm information is determined to be a new alarm information.

[0012] According to the alarm information processing method provided in this application, when the current state of the vehicle is abnormal and the first message is an alarm trigger message, determining whether the first alarm information corresponding to the first message is a new alarm information includes: Generate a precise query key that includes the vehicle identifier and the first alarm information; The server's local cache is queried according to the exact query key to determine whether there are any unfinished historical alarm messages in the server's local cache that match the exact query key. If the server's local cache contains unfinished historical alarm information that matches the exact query key, it is determined that the first alarm information is not a new alarm information; If the server's local cache does not contain any unfinished historical alarm information that matches the exact query key, the memory database is queried according to the fuzzy query key to determine whether the memory database contains any unfinished historical alarm information that matches the exact query key. If the memory database contains unfinished historical alarm information that matches the exact query key, it is determined that the first alarm information is not a new alarm information; If no unfinished historical alarm information matching the exact query key exists in the memory database, the first alarm information is determined to be a new alarm information.

[0013] This application also provides an alarm information processing device, including the following modules: The message acquisition module is used to acquire the first message sent by the vehicle, wherein the first message is an alarm trigger message or an alarm end message, and the first message includes the vehicle identifier of the vehicle. The status determination module is used to query at least one of the local cache and memory database of the server based on the vehicle identifier to determine whether the current status of the vehicle is normal. The first processing module is configured to determine whether the first alarm information corresponding to the first message is a new alarm information when the current state of the vehicle is abnormal and the first message is an alarm trigger message; if it is a new alarm information, the first alarm information is pushed to the downstream system and the first alarm information is stored in the local cache of the server and the memory database; if it is not a new alarm information, the first alarm information is not pushed to the downstream system. The second processing module is used to not push alarm recovery information corresponding to the first message to the downstream system when the current state of the vehicle is normal and the first message is an alarm end message.

[0014] According to the alarm information processing device provided in this application, the device further includes: The third processing module is used to push the first alarm information corresponding to the first message to the downstream system when the current state of the vehicle is normal and the first message is an alarm trigger message, and to store the first alarm information in the local cache of the server and the memory database. The fourth processing module is used to push the alarm recovery information corresponding to the first message to the downstream system when the current state of the vehicle is abnormal and the first message is an alarm end message.

[0015] 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 processor executes the computer program to implement any of the alarm information processing methods described above.

[0016] This application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the alarm information processing method as described above.

[0017] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the alarm information processing method as described above.

[0018] The alarm information processing method, apparatus, electronic device, and storage medium provided in this application directly push alarm information through the gateway, significantly shortening the alarm information transmission link and thus reducing the alarm information push latency. Furthermore, it filters the alarm information and alarm recovery information actually being pushed, reducing the push of useless information and conserving push resources. Especially when the data volume is large, this filtering mechanism can effectively reduce the amount of data pushed, thereby reducing transmission congestion caused by large data volumes and further reducing the alarm information push latency. In addition, the embodiments of this application employ a dual caching mechanism of server local caching + in-memory database, which, while ensuring stability, reduces data read / write time, increases concurrency under the same server hardware resources, and reduces the possibility of losing the vehicle's current state due to fault restarts. Attached Figure Description

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

[0020] Figure 1 This is one of the flowcharts illustrating the alarm information processing method provided in this application; Figure 2 This is the second flowchart of the alarm information processing method provided in this application; Figure 3 This is a schematic diagram of a possible implementation of step S102 in the alarm information processing method provided in this application; Figure 4 This is the third flowchart of the alarm information processing method provided in this application; Figure 5This is a schematic diagram of a possible implementation of step S403 in the alarm information processing method provided in this application; Figure 6 This is one of the structural schematic diagrams of the alarm information processing device provided by the present invention; Figure 7 This is one of the structural schematic diagrams of the alarm information processing device provided by the present invention; Figure 8 This is a schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] In related technologies, alarm information is often transmitted through network interfaces or message middleware. However, transmitting alarm information via network interfaces or message middleware during frequent vehicle information transmission can result in high latency. When the downstream system and the cloud-based Telematics Service Provider (TSP) are not on the same network, the alarm information transmission link is: vehicle - TSP gateway - network interface / message middleware - parsing server - TSP gateway - downstream system network. This transmission link is long, and all alarm information must pass through it. When the data volume is large, link congestion can occur, causing delays in alarm information push. Furthermore, if the system hosting the network interface or message middleware fails during alarm information transmission, alarm information will be lost, making it impossible to trace the vehicle's current state. In the absence of a state, the vehicle's transition from normal to alarm or from alarm to normal cannot trigger the push mechanism. In addition, network interfaces or message middleware can only receive and push alarm information. They cannot statistically analyze the start and end times of alarm information in real time, requiring additional time statistics later. The algorithm logic is complex, the statistical difficulty is high, and the statistical timeliness is poor.

[0023] To address at least one of the aforementioned problems, embodiments of this application provide an alarm information processing method, apparatus, electronic device, and storage medium, which are described below in conjunction with... Figures 1 to 8 Please provide a detailed explanation.

[0024] Figure 1 This is one of the flowcharts illustrating the alarm information processing method provided in this application, applied to a gateway, such as... Figure 1As shown, the method includes the following steps: S101, Obtain the first message sent by the vehicle, wherein the first message is an alarm trigger message or an alarm end message, and the first message includes the vehicle identifier of the vehicle.

[0025] The gateway establishes a communication connection with the vehicle based on a preset communication protocol and receives the first message sent by the vehicle through this connection. The communication protocol can be customized according to actual needs, such as the GB / T 32960 communication protocol or the Message Queuing Telemetry Transport (MQTT) protocol. The first message is an alarm-related message; specifically, it is either an alarm trigger message or an alarm termination message. The alarm trigger message is used to trigger an alarm, and the alarm termination message is used to terminate an alarm. When using the GB / T 32960 communication protocol, the first message can adopt the message format of an event trigger message; when using the MQTT communication protocol, the first message can adopt the message format of a status reporting message. The first message includes the vehicle's identification number, which is used to uniquely identify the vehicle. In one example, the vehicle identification number (VIN) can be used.

[0026] S102, based on the vehicle identifier, query at least one of the local cache and memory database of the server to determine whether the current status of the vehicle is normal.

[0027] The server-side local cache is a primary local cache on the server hosting the gateway. It boasts extremely fast read / write speeds, but the data within it cannot be recovered after a power outage. The in-memory database, on the other hand, is a secondary distributed cache for the gateway. While its read / write speed is slower than the server-side local cache, the data in the in-memory database can be recovered after a power outage. Server-side local caches can be implemented using Caffeine, Guava Cache, Enterprise Cache, etc., while in-memory databases can be Redis, Apache Ignite, MongoDB, etc. This dual caching mechanism of server-side local cache + in-memory database ensures stability while reducing data read / write time, increasing concurrency with the same server hardware resources, and minimizing the loss of vehicle status due to restarts caused by failures. In one example, Redis is used as the in-memory database, leveraging its high-speed read / write capabilities to retrieve and push vehicle alarm information, achieving a low-latency alarm information retrieval and push mechanism.

[0028] In one example, the vehicle identifier can be first queried from the server's local cache. If the vehicle's current state can be determined based on the local cache, there's no need to query the in-memory database. If the vehicle's current state cannot be determined from the local cache, then the in-memory database is queried to determine the vehicle's current state.

[0029] To prevent excessive data from accumulating in the server's local cache, all data in the local cache can be stored in a relational database such as MySQL (MySQL Structured Query Language) at preset intervals. For example, a scheduled task system can be used to read data from Redis and store it in a relational database like MySQL at a fixed time the next day, persisting the data and then clearing the persisted data in Redis, thereby freeing up memory space.

[0030] S103, if the current state of the vehicle is abnormal and the first message is an alarm trigger message, determine whether the first alarm information corresponding to the first message is a new alarm information; if it is a new alarm information, push the first alarm information to the downstream system and store the first alarm information in the local cache of the server and the memory database; if it is not a new alarm information, do not push the first alarm information to the downstream system.

[0031] When the first message is an alarm trigger message, it is used to trigger the alarm. The alarm information represented by the first message is called the first alarm information. The gateway is checked to see if it has previously received an alarm information identical to the first alarm information. If not, the first alarm information is considered new. If it is new, the first alarm information is stored in the server's local cache and memory database, and the gateway also pushes the first alarm information to downstream systems. When the downstream system is a third-party platform different from the TSP platform, the transmission link changes from "vehicle - TSP gateway - network interface / message middleware - parsing server - TSP gateway - downstream system network" to "vehicle - TSP gateway - downstream system network," significantly shortening the transmission link. If the first alarm information is not new, it means that an alarm information with the same content as the first alarm information has already been pushed, and there is no need to push the first alarm information to the downstream system again.

[0032] S104, if the current state of the vehicle is normal and the first message is an alarm end message, the alarm recovery information corresponding to the first message is not pushed to the downstream system.

[0033] When the first message is an alarm termination message, it is used to terminate the alarm. The alarm termination information represented by the first message is called alarm recovery information. If the gateway determines that the vehicle's current status is normal, it means that the vehicle status stored in the downstream system is also normal, therefore there is no need to push alarm recovery information to the downstream system.

[0034] In this embodiment, alarm information is pushed directly by the gateway, significantly shortening the transmission link and reducing push latency. Furthermore, the actual alarm and recovery information being pushed is filtered, reducing the push of useless information and conserving resources. Especially with large data volumes, this filtering mechanism effectively reduces the amount of data pushed, minimizing transmission congestion and further reducing push latency. In addition, this embodiment employs a dual caching mechanism of local server caching and in-memory database. This ensures stability while reducing data read / write time, increasing concurrency with the same server hardware resources, and reducing the risk of vehicle status loss due to fault restarts.

[0035] exist Figure 1 Based on the illustrated embodiments, in one possible manner, see [reference needed]. Figure 2 The method further includes: S105, if the current state of the vehicle is normal and the first message is an alarm trigger message, the first alarm information corresponding to the first message is pushed to the downstream system, and the first alarm information is stored in the local cache of the server and the memory database.

[0036] If the current status of the vehicle in the gateway is normal, it means that there are no unfinished alarm messages for that vehicle in the gateway. Therefore, the first alarm message must be a new alarm message. In this case, we can directly push and store the first alarm message.

[0037] S106, if the current state of the vehicle is abnormal and the first message is an alarm end message, the alarm recovery information corresponding to the first message is pushed to the downstream system.

[0038] The abnormal vehicle status in the gateway indicates that the vehicle status stored in the downstream system is also abnormal. Therefore, it is necessary to push alarm recovery information to the downstream system. In addition, it is also necessary to terminate the unresolved alarm information for this vehicle in the gateway's local server cache and memory database.

[0039] In this embodiment, alarm information is pushed directly by the gateway, which significantly shortens the transmission link of alarm information and thus reduces the push delay of alarm information.

[0040] exist Figure 1 or Figure 2 Based on the illustrated embodiments, in one possible implementation, the method further includes: Step A1: If the first alarm information is a new alarm information, store the start time of the first alarm information in the local cache of the server and the memory database.

[0041] In S103 above, when the first alarm information is determined to be a new alarm information, in addition to storing the first alarm information, the start time of the first alarm information can also be stored. In one example, the start time of the first alarm information can be the timestamp of the first message.

[0042] Step A2: If the vehicle's current state is normal and the first message is an alarm trigger message, store the start time of the first alarm information in the server's local cache and the memory database.

[0043] If the vehicle is currently in a normal state and the first message is an alarm trigger message, in addition to storing the first alarm information in the server's local cache and memory database, the start time of the first alarm information can also be stored.

[0044] Step A3: If the current state of the vehicle is abnormal and the first message is an alarm end message, update the end time of the historical alarm information of the vehicle in the local cache of the server and the memory database.

[0045] When the vehicle's current status changes from abnormal to normal, all alarms for that vehicle should end. Therefore, for alarm information for that vehicle stored in the server's local cache and memory database (that has not yet ended), an end time needs to be set for that alarm information to terminate it. In one example, the end time of the alarm information can be the timestamp of the first message sent.

[0046] In this embodiment, the alarm information transmitted in real time can be statistically analyzed. When the vehicle's state changes, the statistical logic can be directly triggered to calculate the start and end times of the alarm information. This eliminates the need to find the corresponding data from a large amount of data later for statistical analysis, resulting in more real-time statistical results.

[0047] exist Figure 1 and Figure 2Based on the illustrated embodiment, in one possible implementation, storing the first alarm information in the server local cache and the memory database includes: generating a key including the vehicle identifier, an end flag, and the first alarm information in binary representation; and generating a value including the vehicle identifier, start time, end time, alarm level, and the first alarm information. The key and the value are stored in the server local cache and the memory database in key-value pairs. The start time is the timestamp of the first message being sent, the end time is a preset initial value, and the end flag is used to indicate whether the first message is an alarm trigger message or an alarm end message.

[0048] The method further includes: when the current state of the vehicle is abnormal and the first message is an alarm termination message, updating the end time corresponding to the unfinished historical alarm information of the vehicle in the local cache of the server and the memory database.

[0049] The first message may include a vehicle identifier, an end flag, a binary representation of the first alarm information, and the alarm level. The end flag indicates whether an alarm is triggered or terminated. This flag determines whether the first message is an alarm trigger or alarm termination message. For example, when the end flag value is 0, the first message is an alarm trigger; when the end flag value is 1, the first message is an alarm termination message. The preset initial value can be customized according to actual conditions, usually set to 0 or a negative number. When the end time is the preset initial value, it indicates that the corresponding alarm information has not ended. The alarm information includes multiple fault codes, each corresponding to an alarm item. For any alarm item, when the fault code for that alarm item is the first value (e.g., 1), it indicates that the vehicle has an abnormality related to that alarm item; when the fault code for that alarm item is the second value (e.g., 0), it indicates that the vehicle does not have an abnormality related to that alarm item. The alarm level corresponds to the severity of the alarm; each alarm item in the alarm information can correspond to an alarm level.

[0050] The key includes the vehicle identifier, whether it is an end signal, and the first alarm message in binary representation. In one example, these three elements can be concatenated using the colon ":" character to obtain the key. The value includes the vehicle identifier, start time, end time, alarm level, and the first alarm message. In one example, these five elements can be concatenated using the colon ":" character to obtain the value.

[0051] When the vehicle's current status changes from abnormal to normal, all alarms for that vehicle are terminated. For any unfinished alarm information (alarm information with a preset initial end time) stored in the server's local cache and memory database, the end time of the alarm information needs to be updated. The end time in the Value field of the vehicle with the preset initial end time is updated to the sending timestamp of the first message.

[0052] In one possible implementation, the method further includes: if the first alarm information is a new alarm information, updating the end time corresponding to the unfinished historical alarm information of the vehicle in the server local cache and the memory database. If a new alarm information of the vehicle is received, it indicates that the previous unfinished alarm information of the vehicle has expired, so it is necessary to update the end time of the previous unfinished historical alarm information of the vehicle, specifically, it can be updated to the sending timestamp of the first message (the message containing the new alarm information).

[0053] In this embodiment, alarm information transmitted in real time can be statistically analyzed. When the vehicle's state changes, the statistical logic can be directly triggered to calculate the start and end times of the alarm information. This eliminates the need to find the corresponding data from a large amount of data later for statistical analysis, resulting in more real-time statistical results. Furthermore, the alarm information is stored in key-value pairs, which facilitates data matching and improves matching speed.

[0054] The current status of the vehicle can be determined based on alarm information stored in the server's local cache and memory database. Figure 1 or Figure 2 Based on the illustrated embodiments, see also Figure 3 In one possible implementation, step S102, based on the vehicle identifier, queries at least one of the server's local cache and memory database to determine whether the vehicle's current state is normal, including: S1021, Generate a fuzzy query key including the vehicle identifier.

[0055] Alarm information is stored in key-value pairs in the server's local cache and in-memory database. The key includes the vehicle identifier, an end-of-term flag, and the alarm information in binary representation. The value includes the vehicle identifier, start time, end time, alarm level, and alarm information. Fuzzy search keys must include at least the vehicle identifier and may also include an end-of-term flag, but not the alarm information in binary representation. The alarm information in binary representation within the fuzzy search key can be accessed via "..." Replace with the character "".

[0056] S1022, query the server's local cache according to the fuzzy query key, and determine whether there is any unfinished historical alarm information in the server's local cache that matches the fuzzy query key.

[0057] Unfinished historical alarm information refers to alarm information in the corresponding Value whose end time is a preset initial value. Matching with the fuzzy search key means that, excluding " Except for the single character, all other characters are identical. Since the server's local cache is read extremely quickly, matching is performed there first.

[0058] S1023, if there are unfinished historical alarm messages in the local cache of the server that match the fuzzy query key, the current state of the vehicle is determined to be abnormal.

[0059] If there are unresolved historical alarm messages for the vehicle, it indicates that the alarm has not ended, and therefore the current state of the vehicle is determined to be abnormal.

[0060] S1024, if there is no unfinished historical alarm information matching the fuzzy query key in the local cache of the server, query the memory database according to the fuzzy query key to determine whether there is unfinished historical alarm information matching the fuzzy query key in the memory database.

[0061] Data in the in-memory database can be recovered after a power outage and restart, while data in the server's local cache will be lost after a power outage. Therefore, if there is no unfinished historical alarm information for a vehicle in the server's local cache, it is also necessary to query the in-memory database to prevent the vehicle status from being misjudged due to the loss of alarm information caused by a power outage.

[0062] S1025, if there are unfinished historical alarm messages in the memory database that match the fuzzy query key, the current state of the vehicle is determined to be abnormal.

[0063] S1026, if there is no unfinished historical alarm information matching the fuzzy query key in the memory database, the current state of the vehicle is determined to be normal.

[0064] If there are no pending historical alarm messages for the vehicle, it means that there are no ongoing alarms for the vehicle, and therefore the current state of the vehicle is determined to be normal.

[0065] In this embodiment, a dual caching mechanism of server local cache + in-memory database is adopted. First, matching is performed from the server local cache, which can reduce data read and write time and increase concurrency under the same server hardware resources. If matching fails in the server local cache, matching is then performed from the in-memory database, which reduces the possibility of loss of the current vehicle status due to failure restart and improves data stability.

[0066] exist Figure 3In one possible implementation of the illustrated embodiment, when the current state of the vehicle is abnormal and the first message is an alarm trigger message, determining whether the first alarm information corresponding to the first message is a new alarm information includes: Step B1: When the current state of the vehicle is abnormal and the first message is an alarm trigger message, obtain the fault code in the first alarm information to obtain the first fault code, and obtain the fault code in the historical alarm information in the returned data to obtain the second fault code, wherein the returned data is the unfinished historical alarm information matched by the fuzzy query key.

[0067] The returned data is: Figure 3 During the fuzzy query key matching process in the illustrated embodiment, the server's local cache or memory database returns unfinished historical alarm information matched by the fuzzy query key.

[0068] The alarm information includes multiple fault codes, each corresponding to an alarm item. For any alarm item, when the fault code for that alarm item is a first value (e.g., 1), it indicates that the vehicle has an abnormality related to that alarm item; when the fault code for that alarm item is a second value (e.g., 0), it indicates that the vehicle does not have an abnormality related to that alarm item. The fault codes in the first alarm information are referred to as the first fault codes, and the fault codes in the historical alarm information returned in the data are referred to as the second fault codes.

[0069] Step B2: Match the first fault code with the second fault code. If the first fault code and the second fault code are the same, then the first alarm information is determined to be a new alarm information; if the first fault code and the second fault code are different, then the first alarm information is determined to be a new alarm information.

[0070] If the first fault code and the second fault code are the same, it means the alarm content is also the same, therefore the first alarm message is not a new alarm message. If the first fault code and the second fault code are different, it means the alarm content has changed, therefore the first alarm message is a new alarm message.

[0071] In this embodiment, the returned data is used directly to determine whether the first alarm information is a new alarm information. Compared with searching for historical alarm information with the same fault code of the vehicle from the local cache or memory database of the server, the determination speed is faster, thereby reducing the push delay of alarm information.

[0072] The gateway can also maintain a current state for the vehicle in the server's local cache and in-memory database, thus allowing direct access to the vehicle's current state. Figure 1 or Figure 2 Based on the illustrated embodiments, in one possible implementation, the method further includes: Step C1: If the current state of the vehicle is normal and the first message is an alarm trigger message, change the current state of the vehicle to abnormal in the local cache of the server and the memory database.

[0073] Step C2: If the current state of the vehicle is abnormal and the first message is an alarm termination message, the current state of the vehicle is changed to normal in the local cache of the server and the memory database.

[0074] The initial value of the vehicle's current status is normal. For vehicles with a normal current status, the current status is set to abnormal upon receiving an alarm trigger message. For vehicles with an abnormal nitrogen status, the current status is set to normal upon receiving an alarm end message.

[0075] In this embodiment, the current state of the vehicle is maintained in the local cache on the server and in the memory database, which facilitates the determination of the current state of the vehicle. The dual caching mechanism of local cache on the server and memory database can reduce data read and write time while ensuring stability, increase the number of concurrent connections under the same server hardware resources, and reduce the loss of the current state of the vehicle due to failure restart.

[0076] exist Figure 1 or Figure 2 In one possible implementation of the illustrated embodiment, when the current state of the vehicle is abnormal and the first message is an alarm trigger message, determining whether the first alarm information corresponding to the first message is a new alarm information includes: Step D1: Generate a precise query key that includes the vehicle identifier and the first alarm information.

[0077] Alarm information is stored in key-value pairs in the server's local cache and in-memory database. The key includes the vehicle identifier, an end-of-term flag, and the alarm information in binary representation. The value includes the vehicle identifier, start time, end time, alarm level, and alarm information. A precise query key must include at least the vehicle identifier and the first alarm information in binary representation, and may also include an end-of-term flag. If the end-of-term flag is not included in the precise query key, it can be determined using "...". Replace with the character "".

[0078] Step D2: Query the server's local cache according to the exact query key, and determine whether there are any unfinished historical alarm messages in the server's local cache that match the exact query key.

[0079] Step D3: If there are unfinished historical alarm messages in the server's local cache that match the exact query key, it is determined that the first alarm message is not a new alarm message.

[0080] Step D4: If there is no unfinished historical alarm information matching the exact query key in the server's local cache, query the memory database according to the fuzzy query key to determine whether there is unfinished historical alarm information matching the exact query key in the memory database.

[0081] Step D5: If there are unfinished historical alarm messages in the memory database that match the exact query key, determine that the first alarm message is not a new alarm message.

[0082] Step D6: If there is no unfinished historical alarm information matching the exact query key in the memory database, determine that the first alarm information is a new alarm information.

[0083] The precise query key includes the first alarm information. Therefore, for any unfinished historical alarm information that matches the precise query key, its fault code will necessarily be the same as the fault code of the first alarm information. Thus, you can determine whether the first alarm information is a valid alarm by checking if any unfinished historical alarm information is found.

[0084] This application also provides an alarm information processing method applied to a gateway, see [link to relevant documentation]. Figure 4 The method shown includes: S401, Receive the first message sent by the vehicle.

[0085] The gateway can establish a Transmission Control Protocol (TCP) connection with the vehicle based on the GB / T 32960 communication protocol, and obtain the first message sent by the vehicle based on the TCP connection. The first message is an alarm trigger message or an alarm termination message, and the first message includes the vehicle's vehicle identifier.

[0086] S402, parse the first message and determine whether the first message is an alarm trigger message.

[0087] If the first message is an alarm trigger message, execute S403; if the first message is an alarm end message, execute S407. The first message includes an end flag, which indicates whether the first message is an alarm trigger message or an alarm end message. Therefore, the end flag can be used to determine whether the first message is an alarm trigger message. In one example, when the end flag value is 0, the first message is determined to be an alarm trigger message; when the end flag value is 1, the first message is determined to be an alarm end message.

[0088] S403, based on the vehicle identifier, query at least one of the local cache and memory database of the server to determine whether the current status of the vehicle is normal.

[0089] S404 is executed if the current state of the vehicle is normal, and S405 is executed if the current state of the vehicle is abnormal.

[0090] S404, push the first alarm information corresponding to the first message to the downstream system, and store the first alarm information in the server's local cache and the memory database.

[0091] S405, determine whether the first alarm information corresponding to the first message is a new alarm information.

[0092] If the first alarm message is a new alarm message, then execute S406; if the first alarm message is not a new alarm message, then do not push the first alarm message to the downstream system and end the current process.

[0093] S406, push the first alarm information to the downstream system, and store the first alarm information in the server's local cache and the memory database.

[0094] Alarm information can be stored in the server's local cache and in-memory database in key-value pairs. The key includes the vehicle identifier, an end-of-term flag, and the first alarm message in binary representation. In one example, these three elements can be concatenated using a colon (:) to obtain the key. The value includes the vehicle identifier, start time, end time, alarm level, and the first alarm message. Again, these five elements can be concatenated using a colon (:) to obtain the value.

[0095] S407, based on the vehicle identifier, query at least one of the local cache and memory database of the server to determine whether the current status of the vehicle is normal.

[0096] If the current state of the vehicle is abnormal, execute S408; if the current state of the vehicle is normal, do not push the alarm recovery information corresponding to the first message to the downstream system, and end the process.

[0097] S408, push the alarm recovery information corresponding to the first message to the downstream system.

[0098] In addition to pushing the alarm recovery information corresponding to the first message to downstream systems, the gateway can also update the end time of any unresolved historical alarm information for the vehicle in the server's local cache and memory database. The updated end time can be the timestamp of the first message's transmission.

[0099] To prevent excessive data from accumulating in the server's local cache, all data in the local cache can be stored in a relational database such as MySQL (MySQL Structured Query Language) at preset intervals. For example, a scheduled task system can be used to read data from Redis and store it in a relational database like MySQL at a fixed time the next day, persisting the data and then clearing the persisted data in Redis, thereby freeing up memory space.

[0100] In this embodiment, alarm information is pushed directly by the gateway, significantly shortening the transmission link and reducing push latency. Furthermore, the actual alarm and recovery information being pushed is filtered, reducing the push of useless information and conserving resources. Especially with large data volumes, this filtering mechanism effectively reduces the amount of data pushed, minimizing transmission congestion and further reducing push latency. In addition, this embodiment employs a dual caching mechanism of local server caching and in-memory database. This ensures stability while reducing data read / write time, increasing concurrency with the same server hardware resources, and reducing the risk of vehicle status loss due to fault restarts.

[0101] exist Figure 4 Based on the illustrated embodiments, in one possible implementation, see [link to relevant documentation]. Figure 5 Step S403, based on the vehicle identifier, queries at least one of the server's local cache and memory database to determine whether the vehicle's current status is normal, including: S4031, Generate a fuzzy query key including the vehicle identifier.

[0102] S4032, query the server's local cache according to the fuzzy query key to determine whether there is any unfinished historical alarm information in the server's local cache that matches the fuzzy query key. If it does not exist, proceed to step S4033; if it does exist, proceed to step S4035.

[0103] S4033, query the memory database according to the fuzzy query key to determine whether there is any unfinished historical alarm information in the memory database that matches the fuzzy query key. If it does not exist, proceed to step S4034; if it does exist, proceed to step S4035.

[0104] S4034, the returned data is empty, indicating that the current state of the vehicle is normal.

[0105] S4035, return the unfinished historical alarm information matched by the fuzzy query key, and determine that the current state of the vehicle is abnormal.

[0106] In this embodiment, a dual caching mechanism of server local cache + in-memory database is adopted. First, matching is performed from the server local cache, which can reduce data read and write time and increase concurrency under the same server hardware resources. If matching fails in the server local cache, matching is then performed from the in-memory database, which reduces the possibility of loss of the current vehicle status due to failure restart and improves data stability.

[0107] exist Figure 4 Based on the illustrated embodiment, in one possible implementation, step S405, determining whether the first alarm information corresponding to the first message is a new alarm information, includes: obtaining a first fault code from the fault code in the first alarm information, and obtaining a second fault code from the fault codes of historical alarm information in the returned data, wherein the returned data is unfinished historical alarm information matched by the fuzzy query key; matching the first fault code with the second fault code, and if the first fault code and the second fault code are the same, then determining that the first alarm information is not a new alarm information; if the first fault code and the second fault code are different, then determining that the first alarm information is a new alarm information.

[0108] In this embodiment, the returned data is used directly to determine whether the first alarm information is a new alarm information. Compared with searching for historical alarm information with the same fault code of the vehicle from the local cache or memory database of the server, the determination speed is faster, thereby reducing the push delay of alarm information.

[0109] The alarm information processing device provided in this application is described below. The alarm information processing device described below can be referred to in correspondence with the alarm information processing method described above.

[0110] This application provides an alarm information processing device applied to a gateway; see [link to relevant documentation]. Figure 6 The device includes: The message acquisition module 601 is used to acquire a first message sent by the vehicle, wherein the first message is an alarm trigger message or an alarm end message, and the first message includes the vehicle identifier of the vehicle.

[0111] The status judgment module 602 is used to query at least one of the local cache and memory database of the server based on the vehicle identifier to determine whether the current status of the vehicle is normal.

[0112] The first processing module 603 is configured to, when the current state of the vehicle is abnormal and the first message is an alarm trigger message, determine whether the first alarm information corresponding to the first message is a new alarm information; if it is a new alarm information, push the first alarm information to the downstream system and store the first alarm information in the local cache of the server and the memory database; if it is not a new alarm information, do not push the first alarm information to the downstream system.

[0113] The second processing module 604 is used to not push alarm recovery information corresponding to the first message to the downstream system when the current state of the vehicle is normal and the first message is an alarm end message.

[0114] exist Figure 6 Based on the illustrated embodiments, in one possible implementation, see [link to relevant documentation]. Figure 7 The device further includes: The third processing module 605 is used to push the first alarm information corresponding to the first message to the downstream system when the current state of the vehicle is normal and the first message is an alarm trigger message, and to store the first alarm information in the local cache of the server and the memory database.

[0115] The fourth processing module 606 is used to push the alarm recovery information corresponding to the first message to the downstream system when the current state of the vehicle is abnormal and the first message is an alarm end message.

[0116] In one possible implementation, the first processing module 603 is specifically configured to: generate a key including the vehicle identifier, an end flag, and a first alarm information in binary representation; and generate a value including the vehicle identifier, a start time, an end time, an alarm level, and the first alarm information. The key and the value are stored in the server local cache and the memory database in the form of key-value pairs. The start time is the timestamp of the first message being sent, the end time is a preset initial value, and the end flag is used to indicate whether the first message is an alarm trigger message or an alarm end message. The first processing module 603 is further configured to: when the current state of the vehicle is abnormal and the first message is an alarm end message, update the end time corresponding to the unfinished historical alarm information of the vehicle in the local cache of the server and the memory database.

[0117] In one possible implementation, the first processing module 603 is further configured to: if the first alarm information is a new alarm information, update the end time corresponding to the unfinished historical alarm information of the vehicle in the local cache of the server and the memory database.

[0118] In one possible implementation, the third processing module 605 is further configured to change the current state of the vehicle to abnormal in the local cache of the server and the memory database when the current state of the vehicle is normal and the first message is an alarm trigger message. The fourth processing module 606 is further configured to change the current status of the vehicle to normal in the local cache of the server and the memory database when the current status of the vehicle is abnormal and the first message is an alarm end message.

[0119] In one possible implementation, the state determination module 602 is specifically configured to: generate a fuzzy query key including the vehicle identifier; query the server's local cache according to the fuzzy query key to determine whether there is any unfinished historical alarm information matching the fuzzy query key in the server's local cache; if there is any unfinished historical alarm information matching the fuzzy query key in the server's local cache, determine that the current state of the vehicle is abnormal; if there is no unfinished historical alarm information matching the fuzzy query key in the server's local cache, query the memory database according to the fuzzy query key to determine whether there is any unfinished historical alarm information matching the fuzzy query key in the memory database; if there is any unfinished historical alarm information matching the fuzzy query key in the memory database, determine that the current state of the vehicle is abnormal; if there is no unfinished historical alarm information matching the fuzzy query key in the memory database, determine that the current state of the vehicle is normal.

[0120] In one possible implementation, the first processing module 603 is specifically configured to: when the current state of the vehicle is abnormal and the first message is an alarm trigger message, obtain a first fault code from the fault code in the first alarm information, and obtain a second fault code from the fault codes of historical alarm information in the returned data, wherein the returned data is unfinished historical alarm information matched by the fuzzy query key; match the first fault code with the second fault code, and if the first fault code and the second fault code are the same, determine that the first alarm information is not a new alarm information; if the first fault code and the second fault code are different, determine that the first alarm information is a new alarm information.

[0121] In one possible implementation, the first processing module 603 is specifically configured to: generate a precise query key including the vehicle identifier and the first alarm information; query the server's local cache according to the precise query key to determine whether there is any unfinished historical alarm information matching the precise query key in the server's local cache; if there is any unfinished historical alarm information matching the precise query key in the server's local cache, determine that the first alarm information is not a new alarm information; if there is no unfinished historical alarm information matching the precise query key in the server's local cache, query the memory database according to the fuzzy query key to determine whether there is any unfinished historical alarm information matching the precise query key in the memory database; if there is any unfinished historical alarm information matching the precise query key in the memory database, determine that the first alarm information is not a new alarm information; if there is no unfinished historical alarm information matching the precise query key in the memory database, determine that the first alarm information is a new alarm information.

[0122] Figure 8 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 8 As shown, the electronic device may include a processor 810, a communications interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communications interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 can call logical instructions in the memory 830 to execute any of the alarm information processing methods shown in this application.

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

[0124] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute any of the alarm information processing methods shown in this application.

[0125] In another aspect, this application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform any of the alarm information processing methods shown in this application.

[0126] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0127] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0128] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for processing alarm information, characterized in that, Applied to a gateway, the method includes: Obtain the first message sent by the vehicle, wherein the first message is an alarm trigger message or an alarm end message, and the first message includes the vehicle identifier of the vehicle; Based on the vehicle identifier query server local cache and memory database at least one, determine whether the current status of the vehicle is normal; If the current state of the vehicle is abnormal and the first message is an alarm trigger message, determine whether the first alarm information corresponding to the first message is a new alarm information; if it is a new alarm information, push the first alarm information to the downstream system and store the first alarm information in the local cache of the server and the memory database; if it is not a new alarm information, do not push the first alarm information to the downstream system. If the vehicle is currently in a normal state and the first message is an alarm termination message, the alarm recovery information corresponding to the first message will not be pushed to the downstream system.

2. The method according to claim 1, characterized in that, The method further includes: If the vehicle is in a normal state and the first message is an alarm trigger message, the first alarm information corresponding to the first message is pushed to the downstream system, and the first alarm information is stored in the server's local cache and the memory database. If the current state of the vehicle is abnormal and the first message is an alarm end message, the alarm recovery information corresponding to the first message will be pushed to the downstream system.

3. The method according to claim 2, characterized in that, The step of storing the first alarm information in the server local cache and the memory database includes: generating a key including the vehicle identifier, an end flag, and the first alarm information in binary representation; and generating a value including the vehicle identifier, start time, end time, alarm level, and the first alarm information. The key and the value are stored in the server local cache and the memory database in the form of key-value pairs. The start time is the timestamp of the first message being sent, the end time is a preset initial value, and the end flag is used to indicate whether the first message is an alarm trigger message or an alarm end message. The method further includes: when the current state of the vehicle is abnormal and the first message is an alarm termination message, updating the end time corresponding to the unfinished historical alarm information of the vehicle in the local cache of the server and the memory database.

4. The method according to claim 3, characterized in that, The method further includes: If the first alarm information is a new alarm information, the end time corresponding to the unfinished historical alarm information of the vehicle is updated in the local cache of the server and the memory database.

5. The method according to claim 2, characterized in that, The method further includes: If the current state of the vehicle is normal and the first message is an alarm trigger message, the current state of the vehicle is changed to abnormal in the local cache of the server and the memory database. If the current state of the vehicle is abnormal and the first message is an alarm termination message, the current state of the vehicle will be changed to normal in the local cache of the server and the memory database.

6. The method according to claim 1, characterized in that, The step of querying at least one of the vehicle identifier's local cache and memory database to determine whether the vehicle's current status is normal includes: Generate a fuzzy query key that includes the vehicle identifier; The server's local cache is queried according to the fuzzy query key to determine whether there are any unfinished historical alarm messages in the server's local cache that match the fuzzy query key. If the server's local cache contains unfinished historical alarm information that matches the fuzzy query key, the current state of the vehicle is determined to be abnormal. If the server's local cache does not contain any unfinished historical alarm information matching the fuzzy query key, the memory database is queried according to the fuzzy query key to determine whether the memory database contains any unfinished historical alarm information matching the fuzzy query key. If the memory database contains unfinished historical alarm information that matches the fuzzy query key, the current state of the vehicle is determined to be abnormal. If there are no unfinished historical alarm messages matching the fuzzy query key in the memory database, the current state of the vehicle is determined to be normal.

7. The method according to claim 6, characterized in that, When the current state of the vehicle is abnormal and the first message is an alarm trigger message, determining whether the first alarm information corresponding to the first message is a new alarm information includes: When the current state of the vehicle is abnormal and the first message is an alarm trigger message, the fault code in the first alarm information is obtained to obtain the first fault code, and the fault code in the historical alarm information in the returned data is obtained to obtain the second fault code, wherein the returned data is the unfinished historical alarm information matched by the fuzzy query key; The first fault code is matched with the second fault code. If the first fault code is the same as the second fault code, the first alarm information is determined to be a new alarm information; if the first fault code is different from the second fault code, the first alarm information is determined to be a new alarm information.

8. The method according to claim 1, characterized in that, When the current state of the vehicle is abnormal and the first message is an alarm trigger message, determining whether the first alarm information corresponding to the first message is a new alarm information includes: Generate a precise query key that includes the vehicle identifier and the first alarm information; The server's local cache is queried according to the exact query key to determine whether there are any unfinished historical alarm messages in the server's local cache that match the exact query key. If the server's local cache contains unfinished historical alarm information that matches the exact query key, it is determined that the first alarm information is not a new alarm information; If the server's local cache does not contain any unfinished historical alarm information that matches the exact query key, the memory database is queried according to the fuzzy query key to determine whether the memory database contains any unfinished historical alarm information that matches the exact query key. If the memory database contains unfinished historical alarm information that matches the exact query key, it is determined that the first alarm information is not a new alarm information; If no unfinished historical alarm information matching the exact query key exists in the memory database, the first alarm information is determined to be a new alarm information.

9. An alarm information processing device, characterized in that, Applied to a gateway, the device includes: The message acquisition module is used to acquire the first message sent by the vehicle, wherein the first message is an alarm trigger message or an alarm end message, and the first message includes the vehicle identifier of the vehicle. The status determination module is used to query at least one of the local cache and memory database of the server based on the vehicle identifier to determine whether the current status of the vehicle is normal. The first processing module is configured to determine whether the first alarm information corresponding to the first message is a new alarm information when the current state of the vehicle is abnormal and the first message is an alarm trigger message; if it is a new alarm information, the first alarm information is pushed to the downstream system and the first alarm information is stored in the local cache of the server and the memory database; if it is not a new alarm information, the first alarm information is not pushed to the downstream system. The second processing module is used to not push alarm recovery information corresponding to the first message to the downstream system when the current state of the vehicle is normal and the first message is an alarm end message.

10. The apparatus according to claim 9, characterized in that, The device further includes: The third processing module is used to push the first alarm information corresponding to the first message to the downstream system when the current state of the vehicle is normal and the first message is an alarm trigger message, and to store the first alarm information in the local cache of the server and the memory database. The fourth processing module is used to push the alarm recovery information corresponding to the first message to the downstream system when the current state of the vehicle is abnormal and the first message is an alarm end message.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the alarm information processing method as described in any one of claims 1 to 8.

12. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the alarm information processing method as described in any one of claims 1 to 8.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the alarm information processing method as described in any one of claims 1 to 8.

Images