Method, device and medium for processing multi-state alarm of internet of things device

Abstract

This application belongs to the field of Internet of Things (IoT) device technology, and particularly relates to a method, apparatus, device, and medium for processing multi-state alarms of IoT devices. The method includes: acquiring mask data uploaded by any IoT device and operating parameters corresponding to each device state in the mask data, wherein the mask data is generated based on mask information for different device states; parsing the mask data to obtain parsed data of a positional numeral type; identifying alarms in the parsed data using a state policy factory to obtain identification results, wherein the state policy factory includes identification policies corresponding to different alarm states; and pushing alarm information based on the multiple alarm states identified in the identification results and the operating parameters corresponding to each alarm state.

Description

Technical Field

[0001] This application belongs to the field of Internet of Things (IoT) device technology, and particularly relates to a method, apparatus, device and medium for processing multi-state alarms of IoT devices. Background Technology

[0002] With the rapid development of IoT technology, various IoT devices for sensing, intelligent monitoring, and terminal control have been widely deployed in many fields such as industrial production, smart buildings, power operation and maintenance, environmental monitoring, smart homes, and fire protection, forming a large-scale, distributed, multi-node device network system. These massive numbers of IoT terminal devices operate continuously and are susceptible to various faults such as operating parameter deviations, functional failures, offline disconnections, and exceeding limits due to environmental interference, hardware aging, program anomalies, power supply fluctuations, network failures, and human error. Therefore, an efficient and accurate device anomaly alarm mechanism is the core key to ensuring the stable, secure, and reliable operation of IoT systems.

[0003] However, when existing technologies encounter situations where IoT devices report multiple types of alarms in a single report, the volume of data reported by the IoT devices themselves increases with the number of alarm types, and the data processing logic is relatively complex, resulting in high time complexity. In addition, there are issues such as long delivery time to users and incomplete data. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method, apparatus, device, and medium for processing multi-state alarms of IoT devices, in order to solve at least one of the following problems of existing IoT devices: large data volume, complex data processing logic, high time complexity, long push time, and incomplete data.

[0005] A first aspect of this application provides a method for processing multi-state alarms of an Internet of Things (IoT) device, comprising: acquiring mask data uploaded by any IoT device and operating parameters corresponding to each device state in the mask data, wherein the mask data is generated based on mask information of different device states; parsing the mask data to obtain parsed data of a positional numeral type; identifying alarms in the parsed data using a state policy factory to obtain identification results, wherein the state policy factory includes identification policies corresponding to different alarm states; and pushing alarm information based on multiple alarm states identified in the identification results and operating parameters corresponding to each alarm state.

[0006] According to an embodiment of this application, parsing the mask data to obtain parsed data of a positional number type includes: converting the original encoded mask data to obtain parsed data of a binary type, wherein at least two data bits of the parsed data correspond to different device states.

[0007] According to an embodiment of this application, the alarms in the parsed data are identified using a state policy factory to obtain an identification result, including: using multiple alarm identification policies in the state policy factory to identify the state of multiple data bits to obtain the identification result.

[0008] According to an embodiment of this application, the state identification of multiple data bits is performed using multiple alarm identification strategies in the state policy factory to obtain the identification result, including: for any data bit, iterating through multiple alarm identification strategies in the state policy factory; for any alarm identification strategy, if the data bit matches the alarm identification strategy, determining the identification sub-result of the data bit as an alarm state; and generating the identification result based on different identification sub-results of alarm states.

[0009] According to an embodiment of this application, the method of pushing alarm information based on multiple alarm states identified in the identification results and the operating parameters corresponding to each alarm state includes: generating a target message based on the multiple alarm states identified in the identification results and the operating parameters corresponding to each alarm state; and writing the target message into a message queue to push the target message through the message queue.

[0010] According to an embodiment of this application, the method for processing multi-state alarms of IoT devices further includes: when the identification result shows that no alarm is triggered in any device state, performing state prediction for each device state based on the operating parameters of each device state at different operating times to obtain a prediction result; and pushing early warning information based on the prediction results of multiple device states.

[0011] According to an embodiment of this application, the state policy factory is generated in the following manner: for any alarm identification policy in the state policy factory, a policy name for the alarm identification policy is defined; a data bit in the parsed data corresponding to the alarm identification policy is configured; an alarm identification rule corresponding to the data bit is determined, so as to output an alarm status when the data of the data bit satisfies the alarm identification rule.

[0012] A second aspect of this application provides a processing apparatus for multi-state alarms of IoT devices, comprising: an acquisition module, configured to acquire mask data uploaded by any IoT device and operating parameters corresponding to each device state in the mask data, wherein the mask data is generated based on mask information of different device states; a parsing module, configured to parse the mask data to obtain parsed data of a positional numeral type; an identification module, configured to identify alarms in the parsed data using a state policy factory to obtain identification results, wherein the state policy factory includes identification policies corresponding to different alarm states; and a push module, configured to push alarm information based on multiple alarm states identified in the identification results and operating parameters corresponding to each alarm state.

[0013] A third aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the multi-state alarm processing method for any of the above-described IoT devices.

[0014] A fourth aspect of this application provides a test instrument including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the multi-state alarm processing method for any of the above-described IoT devices.

[0015] A fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the multi-state alarm processing method for any of the above-described Internet of Things (IoT) devices.

[0016] The beneficial effects of this application embodiment compared with the prior art are as follows: By parsing the mask data uploaded by IoT devices, the alarms in the parsed data of the positional numeric type are identified using a state policy factory, and the identification results are obtained. Based on the multiple alarm states identified in the identification results and the running parameters corresponding to each alarm state, alarm information is pushed. Since the alarm information is transmitted by mask data of a single integer field reported by the device, the message volume is minimized. Moreover, the alarm matching can be completed quickly by matching positional numeric data through a policy factory during data processing. This method has low time complexity, and the atomic association between alarm information and the original running parameters during information push ensures the data integrity and consistency of the user end. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 The diagram illustrates an application scenario of a method for processing multi-state alarms of an IoT device according to an embodiment of this application. Figure 2 A flowchart illustrating a method for processing multi-state alarms of an IoT device according to an embodiment of this application is provided. Figure 3 A flowchart illustrating a method for processing multi-state alarms of an IoT device according to another embodiment of this application is shown; Figure 4 A structural block diagram of a chip test data processing apparatus according to an embodiment of this application is shown; Figure 5 A block diagram of an electronic device suitable for implementing the above-described method according to an embodiment of this application is shown. Detailed Implementation

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

[0020] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0021] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0022] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [the described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [the described condition or event] is detected," or "in response to detection of [the described condition or event]."

[0024] Furthermore, in the description of this application, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] IoT devices (such as the TX3258C pressure monitoring sensor and the AEC2368b combustible gas detector) may simultaneously report multiple alarm states in a single data transmission. Existing alarm identification solutions mainly include the following: (1) Multi-field scheme: Define independent fields for each type of alarm (e.g., isBatteryLow: true / false), and both the device and the server need to maintain the field list. The number of fields in this method increases linearly with the increase of alarm types. Adding a new alarm type requires modifying both the device firmware and the server protocol, resulting in high upgrade costs.

[0026] (2) Alarm list scheme: The device reports a list of alarm codes, such as [1001, 1003, 1007], which requires the transmission of multiple values. The message volume of this method increases with the number of concurrent alarms, and the network overhead is not fixed; the parsing logic is complex, requiring traversal of the list and searching for the corresponding processor.

[0027] (3) State machine polling scheme: The server queries all possible alarm types for each message one by one. This method has poor performance and high time complexity when there are many alarm types. It is also poorly decoupled from the message content and cannot support concurrent alarms.

[0028] In view of this, embodiments of this application provide a method, apparatus, device, and medium for processing multi-state alarms of IoT devices, in order to solve at least one of the following problems of existing IoT devices: large data volume, complex data processing logic, high time complexity, long push time, and incomplete data.

[0029] In this embodiment, alarm information is transmitted by masking data of a single integer field reported by the device, thereby minimizing the message volume. Furthermore, alarm matching can be completed quickly by using a strategy factory to match data of positional numeric types during data processing. This method has low time complexity, and the atomic association between alarm information and original operating parameters during information push ensures the integrity and consistency of data on the user end.

[0030] Figure 1 The diagram illustrates an application scenario of a method for processing multi-state alarms of an IoT device according to an embodiment of this application.

[0031] like Figure 1 As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send information, etc.

[0032] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be, for example, various Internet of Things (IoT) devices, such as smoke detectors, heat detectors, flame detectors, and fire alarm buttons in fire scenarios.

[0033] Server 105 can be a server providing various services, such as a backend management server supporting data uploaded by the first terminal device 101, the second terminal device 102, and the third terminal device 103 (for example only). It can also provide data storage services, such as storing data through a database. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and basic cloud computing services such as big data. The server can be a backend server for the aforementioned target application, used to provide backend services to the client of the target application.

[0034] It should be noted that the data processing method for IoT devices provided in this application embodiment can generally be executed by server 105. Accordingly, the data processing device for IoT devices provided in this application embodiment can generally be located in server 105.

[0035] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0036] Figure 2 A flowchart illustrating a method for processing multi-state alarms of an IoT device according to an embodiment of this application is shown.

[0037] Please see Figure 2 One embodiment of a method for processing multi-state alarms of an IoT device in this application may include operations S201 to S204: In operation S201, the mask data uploaded by any IoT device and the operating parameters corresponding to each device state in the mask data are obtained. The mask data is generated based on the mask information of different device states.

[0038] In operation S202, the mask data is parsed to obtain parsed data of the positional numeric type.

[0039] In operation S203, the state policy factory is used to identify alarms in the parsed data and obtain the identification results.

[0040] In operation S204, alarm information is pushed based on the multiple alarm states identified in the identification results and the operating parameters corresponding to each alarm state.

[0041] The specific types of IoT devices can be set based on actual scenarios. For example, fire alarm devices in a fire scenario include, but are not limited to, smoke detectors, heat detectors, flame detectors, and fire alarm buttons. This application uses a fire scenario as an example, but it is not limited to fire scenarios; devices in other scenarios, such as water leak alarm devices in a smart home scenario, can also be used.

[0042] The state policy factory includes identification policies corresponding to different alarm states, such as policies for alarm identification of IoT devices' battery level, pressure, sensor working status, device collision, tilt, etc.

[0043] In some embodiments, IoT devices can upload mask data containing different device states. For example, when both low battery and pressure limit exceedance alarms occur simultaneously, mask data 262145 can be sent, where 262145 = 1 | 262144, where 1 represents low battery and 262144 represents pressure limit exceedance.

[0044] The masked data uploaded by IoT devices is parsed to obtain positional numeric data, such as binary data. The state policy factory is used to identify alarms in the parsed data to obtain identification results. For example, different data bits in the binary parsed data are identified by policy to obtain alarm identification results corresponding to different states. Based on the multiple alarm states identified in the identification results and the running parameters corresponding to each alarm state, alarm information is pushed.

[0045] According to embodiments of this application, by parsing the masked data uploaded by IoT devices, a state policy factory is used to identify alarms in the parsed data of positional numeric types, obtaining identification results. Based on the multiple alarm states identified in the identification results and the operating parameters corresponding to each alarm state, alarm information is pushed. Since the alarm information is transmitted by masked data of a single integer field reported by the device, the message volume is minimized. Furthermore, by using a policy factory to match positional numeric data during data processing, alarm matching can be completed quickly. This method has low time complexity, and the atomic association between alarm information and the original operating parameters during information push ensures the data integrity and consistency on the user end.

[0046] According to an embodiment of this application, parsing mask data to obtain parsed data of positional numerical type includes: converting the original encoded mask data to obtain parsed data of binary type, wherein at least two data bits of the parsed data correspond to different device states.

[0047] In some embodiments, when a device malfunctions, the identifier bit value corresponding to each alarm type of the malfunction is shown in Table 1 below. After parsing, different binary bits (i.e. data bits) in the binary parsed data represent different device states. For example, bit 0 in the parsed data can correspond to the battery level. When bit 0 is 1, it indicates that there is a low battery alarm type.

[0048] Table 1

[0049] In some embodiments, the positional number type can be decimal or hexadecimal, requiring only a corresponding modification to the identification strategy in the state strategy factory.

[0050] According to an embodiment of this application, the alarms in the parsed data are identified using a state policy factory to obtain identification results, including: using multiple alarm identification policies in the state policy factory to identify the state of data in multiple data bits to obtain identification results.

[0051] After parsing the binary data, multiple alarm identification strategies in the status policy factory can be used to identify the status of multiple data bits, thereby determining whether an alarm exists in each device status and obtaining the corresponding identification result.

[0052] In some embodiments, such as for a low battery alarm, the corresponding binary bits in the parsed data can be identified using the alarm identification strategy corresponding to low battery in the state policy factory to determine whether a low battery alarm exists. The identification result can be obtained based on the alarm corresponding to different device states.

[0053] According to an embodiment of this application, multiple alarm identification strategies in a state policy factory are used to identify the state of data in multiple data bits to obtain identification results. The process includes: for any data bit, iterating through multiple alarm identification strategies in the state policy factory; for any alarm identification strategy, if the data in the data bit matches the alarm identification strategy, determining the identification sub-result of the data bit as an alarm state; and generating an identification result based on different identification sub-results as alarm states.

[0054] In specific alarm identification, for each binary bit (data bit), it is necessary to iterate through multiple alarm identification policies in the state policy factory to determine the corresponding alarm identification policy. The data of the binary bit is matched with the alarm triggering rule in the alarm identification policy. If the data triggers the rule, it means that the match is successful. Thus, the identification sub-result of the data bit can be determined as an alarm state. The identification sub-results that are determined as alarms for different device states are used to generate the identification results corresponding to the mask data.

[0055] According to an embodiment of this application, the push of alarm information is performed based on multiple alarm states identified in the identification results and the operating parameters corresponding to each alarm state, including: generating a target message based on the multiple alarm states identified in the identification results and the operating parameters corresponding to each alarm state; and writing the target message into a message queue to push the target message through the message queue.

[0056] In some embodiments, a target message can be generated using a message builder based on all identified alarm states and the operating parameters corresponding to each alarm state, and the target message can be sent to a message queue, thereby enabling the message queue to push the target message to the user.

[0057] In some embodiments, in a fire protection scenario, when a fire alarm deployed in a residential building is manually activated, it indicates a fire safety hazard. At this time, the device itself may be subject to collision (e.g., a resident presses the alarm with excessive force). The mask data reported by the device contains multiple alarms. After receiving the mask data, the server can determine that the alarm status reported by the device is one of two types through parsing and alarm identification: fire alarm and collision alarm. The server can then generate a target message based on the fire alarm and collision alarm and their corresponding operating parameters, and transmit the target message to the large screen in the fire control room and / or a third-party terminal device through a message queue. The third party may include, but is not limited to, the property management's monitoring room.

[0058] In some embodiments, when constructing target messages, target messages corresponding to different alarm states can be generated based on each alarm state and its corresponding operating parameters, and different target messages can be pushed through a message queue. During the push phase, the message queue can push different target messages based on configured receiving rules. For example, for disaster alarms, the corresponding target messages can be sent to the fire control room and property management, while for device performance alarms (such as low battery), they can be pushed only to the fire control room. Specific push rules can be configured based on actual needs.

[0059] According to an embodiment of this application, the method for processing multi-state alarms of IoT devices further includes: when the identification result shows that no alarm is triggered in any device state, performing state prediction for each device state based on the operating parameters of each device state at different running times, and obtaining prediction results; and pushing early warning information based on the prediction results of multiple device states.

[0060] If the identification results show that there are no alarms in the mask data reported by the IoT device, the server can predict the device status based on the operating parameters received in the most recent operating period, such as battery level, pressure, and tilt status, and then issue an early warning based on the prediction results.

[0061] In some embodiments, the state of the device itself typically fluctuates over time. By analyzing the fluctuations in parameters, it is possible to predict the approximate time period in which the device will fail. For example, when a device is tilted, the tilting process is usually slow, and this can be reflected in the corresponding operating parameters. Since the judgment criteria are not met, the corresponding fault will not be present in the mask data reported by the device. During this process, the server can analyze the operating parameters related to the device tilt state at different times, and thus predict the time period in which the device will trigger an alarm, thereby issuing early warning information in advance.

[0062] In some embodiments, the server can plot performance change curves based on operating parameters at different times, and use these performance change curves to predict when a failure will occur. Alternatively, a status warning model corresponding to each device state can be used for status prediction.

[0063] In some embodiments, if a state warning model is used, a state warning model needs to be trained in advance for each device state. For example, for the device tilt state, a training set can be used for training. The training set includes multiple operating parameter samples corresponding to the device tilt state that change continuously over time for a certain device model. Each sample has its own time label representing the occurrence of the tilt alarm. These samples are trained by a neural network based on an attention mechanism. Each sample can output a predicted time. The network parameters of the neural network are iteratively adjusted based on the difference between the predicted time and the time label to obtain the corresponding state warning model.

[0064] The neural networks in the above embodiments may include, but are not limited to, LSTM-Attention, GRU-Attention, Transformer, Autoformer, and other networks. Preferably, an Autoformer network is used for training.

[0065] According to an embodiment of this application, the state policy factory is generated in the following manner: for any alarm identification policy in the state policy factory, a policy name for the alarm identification policy is defined; data bits in the parsed data corresponding to the alarm identification policy are configured; and alarm identification rules corresponding to the data bits are determined so as to output an alarm status when the data of the data bits meets the alarm identification rules.

[0066] When building a state policy factory, for each alarm identification policy, you first need to define the policy name of the alarm identification policy, such as "low battery policy", and configure the data bit in the parsed data corresponding to the policy, such as the 0th bit of "low battery policy" in the parsed data. Then, configure the alarm identification rules. For example, when the 0th bit in the parsed data is identified as "1", the policy is hit, and the policy can output the alarm status as "low battery".

[0067] When using the State Policy Factory, for each identified alarm state, the identification results can be displayed in the form of a set. For example, when both low battery and low pressure alarm states exist at the same time, the set can include "low battery" and "pressure lower limit exceeded". If the IoT device does not have any abnormalities, the set is empty.

[0068] Figure 3 A flowchart illustrating a method for processing multi-state alarms of an IoT device according to another embodiment of this application is shown.

[0069] like Figure 3 As shown, IoT devices can report data, which includes mask data of alarm status and corresponding operating parameters. The server reads the mask data and determines whether the mask data is 0 or null. If it is 0 or null, it means that there is no alarm status in the mask data reported this time, and status warnings can be given based on operating parameters at different times.

[0070] If the mask data is not empty or is 0, the mask data can be parsed to obtain the parsed data. The identification strategy in the state strategy factory is then used to identify whether the identification result is empty. If it is empty, the state is analyzed and alerted based on the running parameters. If the identification result is not empty, each alarm state in the identification result can be traversed. For each alarm state, a Kafka message (i.e., the target message) can be constructed based on the alarm state and its corresponding running parameters and sent to the Kafka business state topic (i.e., the message queue) for message push. After completing the alarm state, the next alarm message can be pushed until all alarm states have been pushed.

[0071] In some embodiments, all alarm states and their corresponding operational data contained in this mask data can be generated into a single Kafka message for push.

[0072] To verify the feasibility of the multi-state alarm processing method provided in this application embodiment, this embodiment parses and identifies the mask data reported by the TX3258C pressure monitoring sensor. When six alarm states are triggered simultaneously, the server correctly identifies and sends six independent Kafka messages (i.e., target messages). Furthermore, this embodiment parses and identifies 10,000 concurrent mask data entries, with a single-core processing time of less than 50ms. This demonstrates that the method in this application embodiment can quickly and accurately distribute alarms to consumers, improving data processing efficiency.

[0073] The multi-state alarm processing method provided in this application embodiment occupies an independent number of bits for each alarm state, supporting 64 concurrent alarms for binary types. Adding new alarm states requires no modification to existing logic. The time complexity depends only on the actual number of triggered alarms, and is independent of the total number of alarm states. Each alarm distribution carries a complete collection value context, ensuring the data integrity processed by downstream consumers. The system quickly exits when a data bit in the parsed data is 0, without performing any calculations, minimizing processing overhead in alarm-free scenarios.

[0074] Compared to existing technologies, the multi-state alarm processing method provided in this application ensures that, regardless of the number of concurrent alarm states, the reported mask data contains only one integer field, resulting in constant network transmission volume. When adding a new alarm state, only a bitwise AND judgment needs to be added to the server, and the corresponding bit needs to be set in the device firmware, requiring minimal changes to both ends. Simultaneously, all alarm states are identified at the same time, without serial waiting, resulting in a short alarm identification time for processing a single mask data entry. Finally, when sending the message, the running parameters and alarm states are sent in an atomic binding manner, preventing downstream consumers from experiencing data silos where "alarms exist but no collected values" occur.

[0075] Figure 4 A structural block diagram of a chip test data processing apparatus according to an embodiment of this application is shown.

[0076] like Figure 4 As shown, the multi-state alarm processing device 400 for IoT devices includes an acquisition module 410, a parsing module 420, an identification module 430, and a push module 440.

[0077] The acquisition module 410 is used to acquire the mask data uploaded by any IoT device and the operating parameters corresponding to each device state in the mask data, wherein the mask data is generated based on the mask information of different device states.

[0078] The parsing module 420 is used to parse the mask data to obtain parsed data of the positional numeric type.

[0079] The identification module 430 is used to identify alarms in the parsed data using the state policy factory and obtain identification results. The state policy factory includes identification policies corresponding to different alarm states.

[0080] The push module 440 is used to push alarm information based on multiple alarm states identified in the identification results and the running parameters corresponding to each alarm state.

[0081] According to embodiments of this application, by parsing the masked data uploaded by IoT devices, a state policy factory is used to identify alarms in the parsed data of positional numeric types, obtaining identification results. Based on the multiple alarm states identified in the identification results and the operating parameters corresponding to each alarm state, alarm information is pushed. Since the alarm information is transmitted by masked data of a single integer field reported by the device, the message volume is minimized. Furthermore, by using a policy factory to match positional numeric data during data processing, alarm matching can be completed quickly. This method has low time complexity, and the atomic association between alarm information and the original operating parameters during information push ensures the data integrity and consistency on the user end.

[0082] According to an embodiment of this application, the parsing module includes an encoding conversion unit.

[0083] The encoding conversion unit is used to convert the original encoded mask data into binary parsed data, wherein at least two data bits of the parsed data correspond to different device states.

[0084] According to an embodiment of this application, the identification module includes a status identification unit.

[0085] The status identification unit is used to identify the status of multiple data bits using multiple alarm identification strategies in the status policy factory, and obtain the identification result.

[0086] According to an embodiment of this application, the state recognition unit includes a traversal subunit, a determination subunit, and a generation subunit.

[0087] The traversal sub-unit is used to iterate through multiple alarm identification strategies in the state strategy factory for any given data bit.

[0088] The determination sub-unit is used to determine the identification sub-result of the data bit as an alarm state when the data bit matches the alarm identification strategy for any alarm identification strategy.

[0089] The generation sub-unit is used to generate identification results based on different identification sub-results for alarm states.

[0090] According to an embodiment of this application, the push module includes a message generation unit and a message writing unit.

[0091] The message generation unit is used to generate target messages based on multiple alarm states identified in the identification results and the corresponding operating parameters for each alarm state.

[0092] The message writing unit is used to write the target message to the message queue so that the target message can be pushed through the message queue.

[0093] According to embodiments of this application, the processing apparatus for multi-state alarms of IoT devices further includes a state prediction module and a second push module.

[0094] The status prediction module is used to predict the status of each device based on the operating parameters of each device at different running times when the identification results show that no device status has an alarm.

[0095] The second push module is used to push early warning information based on the prediction results of multiple device statuses.

[0096] According to an embodiment of this application, the state policy factory is generated through a definition unit, a configuration unit, and a rule determination unit.

[0097] The definition unit is used to define the policy name of any alarm identification policy in the state policy factory.

[0098] The configuration unit is used to configure the data bits in the parsed data that correspond to the alarm identification strategy.

[0099] The rule determination unit is used to determine the alarm identification rule corresponding to the data bit, so as to output the alarm status when the data of the data bit meets the alarm identification rule.

[0100] According to embodiments of this application, any multiple modules among the acquisition module 410, parsing module 420, identification module 430, and push module 440 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the acquisition module 410, parsing module 420, identification module 430, and push module 440 can be at least partially implemented as a hardware circuit, such as a field-programmable gate array, a programmable logic array, a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit, or any other reasonable means of integrating or packaging the circuit, or implemented in software, hardware, or firmware, or in any appropriate combination of any of these three implementation methods. Alternatively, at least one of the acquisition module 410, parsing module 420, identification module 430, and push module 440 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0101] Figure 5 A block diagram of an electronic device suitable for implementing the above-described method according to an embodiment of this application is shown.

[0102] like Figure 5 As shown, an electronic device 500 according to an embodiment of this application includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory 502 or a program loaded from a storage portion 508 into a random access memory 503. The processor 501 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0103] Random access memory 503 stores various programs and data required for the operation of electronic device 500. Processor 501, read-only memory 502, and random access memory 503 are interconnected via bus 504. Processor 501 executes various steps of the method flow according to embodiments of this application by executing programs in read-only memory 502 and / or random access memory 503. It should be noted that the programs may also be stored in one or more memories other than read-only memory 502 and random access memory 503. Processor 501 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0104] According to embodiments of this application, the electronic device 500 may further include an input / output interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the input / output interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card, such as a local area network card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0105] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0106] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 502, and / or random access memory 503, and / or one or more memories other than read-only memory 502 and random access memory 503 described above.

[0107] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0108] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0109] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0110] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

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

[0112] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method for processing multi-state alarms of Internet of Things (IoT) devices, characterized in that, include: Obtain the mask data uploaded by any IoT device and the operating parameters corresponding to each device state in the mask data, wherein the mask data is generated based on the mask information of different device states; The mask data is parsed to obtain parsed data of positional numeric type; The alarms in the parsed data are identified using a state policy factory to obtain identification results, wherein the state policy factory includes identification policies corresponding to different alarm states; Alarm information is pushed based on the multiple alarm states identified in the identification results and the corresponding operating parameters for each alarm state.

2. The method for processing multi-state alarms of IoT devices according to claim 1, characterized in that, The mask data is parsed to obtain parsed data of positional numeric type, including: The original encoded mask data is converted to binary parsed data, wherein at least two data bits of the parsed data correspond to different device states.

3. The method for processing multi-state alarms of IoT devices according to claim 2, characterized in that, The alarms in the parsed data are identified using a state policy factory to obtain the identification results, including: The status of multiple data bits is identified by using multiple alarm identification strategies in the status policy factory to obtain the identification result.

4. The method for processing multi-state alarms of IoT devices according to claim 3, characterized in that, The status identification results are obtained by using multiple alarm identification policies in the status policy factory to identify the status of multiple data bits, including: For any given data bit, iterate through multiple alarm identification strategies in the state strategy factory. For any of the alarm identification strategies, if the data in the data bit matches the alarm identification strategy, the identification sub-result of the data in the data bit is determined to be an alarm state; The identification result is generated based on the different identification sub-results of the alarm state.

5. The method for processing multi-state alarms of IoT devices according to claim 1, characterized in that, Alarm information is pushed based on multiple alarm states identified in the recognition results and the corresponding operating parameters for each alarm state, including: Based on the multiple alarm states identified in the identification results and the operating parameters corresponding to each alarm state, a target message is generated; The target message is written into a message queue so that it can be pushed through the message queue.

6. The method for processing multi-state alarms of IoT devices according to claim 1, characterized in that, Also includes: If the identification results show that no alarm is triggered in any device status, a status prediction is performed on each device status based on the operating parameters of each device status at different operating times to obtain a prediction result; Early warning information is pushed based on the prediction results of multiple device statuses.

7. The method for processing multi-state alarms of IoT devices according to any one of claims 1 to 6, characterized in that, The state policy factory is generated in the following way: For any alarm identification policy in the state policy factory, define the policy name of the alarm identification policy; Configure the data bits in the parsed data that correspond to the alarm identification strategy; Determine the alarm identification rule corresponding to the data bit, and output the alarm status when the data of the data bit satisfies the alarm identification rule.

8. A processing device for multi-state alarms of Internet of Things (IoT) devices, characterized in that, include: The acquisition module is used to acquire the mask data uploaded by any IoT device and the operating parameters corresponding to each device state in the mask data, wherein the mask data is generated based on the mask information of different device states; The parsing module is used to parse the mask data to obtain parsed data of positional numeric type; The identification module is used to identify alarms in the parsed data using a state policy factory to obtain identification results, wherein the state policy factory includes identification policies corresponding to different alarm states. The push module is used to push alarm information based on multiple alarm states identified in the identification results and the corresponding operating parameters for each alarm state.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images