Alarm data processing method, device, equipment, medium and product

Abstract

The embodiment of the invention provides an alarm data processing method and device, equipment, a medium and a product, and relates to the field of data processing.According to the method, automatic classification of original alarm data of heterogeneous Internet of Things equipment is achieved through a preset equipment type dictionary and an alarm type dictionary, a manual intervention integration and judgment mode is replaced, and the efficiency is improved. According to the method, the process time consumption caused by manual operation is reduced, meanwhile, different types of classification identifiers are unified into the same data format through standardized conversion, standardized alarm data are formed, the processing barriers caused by scattered alarm information sources and different formats are eliminated from the data level, and the processing efficiency is improved. According to the invention, subsequent alarm data processing can be efficiently carried out based on a unified and normative data basis without additionally consuming time on data format adaptation and information integration, and the problem that alarm data processing efficiency is low due to the fact that an alarm data processing flow is long in time consumption and alarm information cannot be rapidly and efficiently processed in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to an alarm data processing method, apparatus, equipment, medium and product. Background Technology

[0002] The application of IoT technology in public services and intelligent monitoring is deepening. Various types of IoT devices, including those for health monitoring, security protection, and environmental sensing, are deployed across different scenarios. These devices differ in communication modes and data formats, resulting in alarm information that is multi-source, heterogeneous, and distributed, significantly increasing the demand for processing massive amounts of alarm information. Against this backdrop, the ability to efficiently process various alarm information from multiple devices directly impacts the response efficiency and service capabilities of the intelligent monitoring system.

[0003] In existing technologies, alarm data is received through a customized gateway. When the alarm data reaches the preset triggering conditions, the system automatically pushes alarm notifications to the relevant processing terminals, completing the alarm information reception and push processing flow, and realizing the processing of various alarm information.

[0004] However, existing technologies suffer from low efficiency in alarm data processing. Alarm information generated by various IoT monitoring devices comes from diverse sources and formats, requiring manual intervention for data integration and judgment. This results in a lengthy alarm information processing flow, hindering efficient alarm information handling and failing to meet the real-time alarm response requirements of various intelligent monitoring scenarios. Summary of the Invention

[0005] This application provides an alarm data processing method, apparatus, device, medium, and product to solve the problem of low alarm data processing efficiency in the prior art.

[0006] In a first aspect, embodiments of this application provide an alarm data processing method, including:

[0007] Acquire raw alarm data sent by heterogeneous IoT devices; wherein the raw alarm data is used to indicate that the heterogeneous IoT device has detected at least one abnormal state among a number of preset abnormal states of the user, the attributes of the at least one abnormal state, and the device identifier of the heterogeneous IoT device.

[0008] The original alarm data is classified into device types according to a preset device type dictionary to obtain device type identifiers; wherein, the device type identifiers are used to represent the device types of the heterogeneous IoT devices;

[0009] The original alarm data is classified into alarm types according to a preset alarm type dictionary to obtain alarm type identifiers; wherein, the alarm type identifier is used to indicate the alarm type corresponding to the original alarm data;

[0010] The device type identifier and the alarm type identifier are standardized to obtain standardized alarm data; wherein, the standardization conversion is used to convert the device type identifier and the alarm type identifier into the same data format, and the standardized alarm data is used to provide data input for preset alarm data processing to eliminate the abnormal state of the user.

[0011] In one possible design, the standardization conversion of the device type identifier and the alarm type identifier to obtain standardized alarm data includes:

[0012] The device type identifier and the alarm type identifier are converted into a unified data format to obtain the converted device type identifier and the converted alarm type identifier;

[0013] The converted device type identifier and the converted alarm type identifier are integrated to obtain the standardized alarm data.

[0014] In one possible design, after standardizing the device type identifier and the alarm type identifier to obtain standardized alarm data, the method further includes:

[0015] The standardized alarm data is matched with multiple preset alarm processing schemes to obtain the target alarm processing scheme corresponding to the maximum matching degree of the standardized alarm data;

[0016] The target alarm handling scheme is executed to eliminate the abnormal state of the user.

[0017] In one possible design, the execution of the target alarm processing scheme includes:

[0018] Obtain a user feature profile; wherein the user feature profile is used to represent multiple features of the user;

[0019] Based on the user feature profile, the preset processing parameters in the target alarm processing scheme are adjusted to obtain the adjusted target alarm processing scheme, and the adjusted target alarm processing scheme is executed; wherein, the adjustment is used to adapt the multiple processing parameters to the multiple features of the user.

[0020] In one possible design, after executing the target alarm processing scheme, the following is also included:

[0021] Collect execution feedback data of the target alarm handling scheme; wherein, the execution feedback data includes abnormal state elimination results, processing response time and user adaptability;

[0022] The execution feedback data is scored according to a preset evaluation index system to obtain the execution score of the target alarm handling scheme;

[0023] If the execution score is lower than the preset score threshold, the parameters of the adjusted target alarm handling scheme are iteratively optimized based on the execution feedback data to obtain an optimized alarm handling scheme, and the optimized alarm handling scheme is updated to the plurality of alarm handling schemes.

[0024] In one possible design, the step of classifying the original alarm data according to a preset device type dictionary to obtain a device type identifier includes:

[0025] The original alarm data is preprocessed to obtain preprocessed original alarm data;

[0026] Obtain the device identifier from the preprocessed original alarm data, and perform an initial match between the device identifier and the device type dictionary to obtain the initial matching device type identifier and the matching confidence score of the initial matching device type identifier; wherein, the initial matching device type identifier is the identifier in the device type dictionary with the highest correlation to the device identifier, and the matching confidence score is used to indicate the reliability of the initial matching device type identifier as the device type determination result of the original alarm data;

[0027] If the matching confidence level is greater than or equal to the preset confidence level threshold, the initial matching device type identifier is determined as the device type identifier;

[0028] If the matching confidence is less than the confidence threshold, the abnormal state attribute features in the original alarm data are extracted, and the initial matching device type identifier and the abnormal state attribute features are combined into a joint feature; wherein, the abnormal state attribute features are used to represent the attributes of the at least one abnormal state;

[0029] The joint feature is matched twice with the device type dictionary to obtain a secondary matching device type identifier, and the secondary matching device type identifier is determined as the device type identifier; wherein, the secondary matching device type identifier is the identifier in the device type dictionary that has the highest correlation with the joint feature.

[0030] In one possible design, the preprocessing of the original alarm data to obtain preprocessed original alarm data includes:

[0031] The original alarm data is subjected to integrity and validity checks to remove incomplete data with missing fields and invalid data with values ​​exceeding a preset reasonable range, thus obtaining the checked data.

[0032] The verified data is deduplicated to remove redundant alarm data that are repeatedly sent by the same device and under the same abnormal state within a preset time threshold, thus obtaining the preprocessed original alarm data.

[0033] In one possible design, the step of classifying the original alarm data according to a preset alarm type dictionary to obtain alarm type identifiers includes:

[0034] The abnormal state attribute features are matched with the alarm type dictionary to obtain multiple candidate alarm type identifiers and the attribute matching similarity corresponding to each candidate alarm type identifier;

[0035] Candidate alarm type identifiers with attribute matching similarity greater than a preset similarity threshold are integrated to obtain a set of valid candidate alarm type identifiers;

[0036] Based on the device type identifier corresponding to the original alarm data, the scene weight of each candidate alarm type identifier in the set of valid candidate alarm type identifiers is determined; wherein, the scene weight is used to represent the degree of contribution of the abnormal state attribute features collected by different devices to the judgment of the candidate alarm type identifier;

[0037] Based on the attribute matching similarity corresponding to each candidate alarm type identifier and the scene weight of each candidate alarm type identifier, a comprehensive matching value is calculated for each candidate alarm type identifier, and the candidate alarm type identifier corresponding to the maximum comprehensive matching value is determined as the alarm type identifier.

[0038] Secondly, embodiments of this application provide an alarm data processing apparatus, comprising:

[0039] The first acquisition module is used to acquire raw alarm data sent by heterogeneous IoT devices; wherein, the raw alarm data is used to indicate that the heterogeneous IoT device has detected at least one abnormal state among a number of preset abnormal states of the user, the attributes of the at least one abnormal state, and the device identifier of the heterogeneous IoT device.

[0040] The first classification module is used to classify the original alarm data according to a preset device type dictionary to obtain a device type identifier; wherein, the device type identifier is used to represent the device type of the heterogeneous Internet of Things device;

[0041] The second classification module is used to classify the original alarm data according to a preset alarm type dictionary to obtain an alarm type identifier; wherein, the alarm type identifier is used to indicate the alarm type corresponding to the original alarm data;

[0042] The conversion module is used to standardize the device type identifier and the alarm type identifier to obtain standardized alarm data; wherein, the standardization conversion is used to convert the device type identifier and the alarm type identifier into the same data format, and the standardized alarm data is used to provide data input for preset alarm data processing to eliminate the abnormal state of the user.

[0043] In one possible design, the conversion module includes:

[0044] The conversion unit is used to convert the device type identifier and the alarm type identifier into a unified data format to obtain the converted device type identifier and the converted alarm type identifier;

[0045] The first integration unit is used to integrate the converted device type identifier and the converted alarm type identifier to obtain the standardized alarm data.

[0046] In one possible design, the alarm data processing device further includes:

[0047] The matching module is used to match the standardized alarm data with multiple preset alarm processing schemes to obtain the target alarm processing scheme corresponding to the maximum matching degree of the standardized alarm data.

[0048] The execution module is used to execute the target alarm processing scheme to eliminate the abnormal state of the user.

[0049] In one possible design, the execution module includes:

[0050] The first acquisition unit is used to acquire a user feature profile; wherein the user feature profile is used to represent multiple features of the user;

[0051] An adjustment unit is used to adjust multiple preset processing parameters in the target alarm processing scheme according to the user feature profile, to obtain an adjusted target alarm processing scheme, and to execute the adjusted target alarm processing scheme; wherein, the adjustment is used to adapt the multiple processing parameters to multiple features of the user.

[0052] In one possible design, the alarm data processing device further includes:

[0053] The data acquisition module is used to collect the execution feedback data of the target alarm processing scheme; wherein, the execution feedback data includes the abnormal state elimination result, processing response time and user adaptability;

[0054] The scoring module is used to score the execution feedback data according to a preset evaluation index system to obtain the execution score of the target alarm handling scheme;

[0055] An optimization module is used to iteratively optimize the parameters of the adjusted target alarm handling scheme based on the execution feedback data if the execution score is lower than a preset score threshold, to obtain an optimized alarm handling scheme, and to update the optimized alarm handling scheme to the plurality of alarm handling schemes.

[0056] In one possible design, the first classification module includes:

[0057] The preprocessing unit is used to preprocess the original alarm data to obtain preprocessed original alarm data.

[0058] The initial matching unit is used to obtain the device identifier in the preprocessed original alarm data, and perform an initial matching between the device identifier and the device type dictionary to obtain the initial matching device type identifier and the matching confidence of the initial matching device type identifier; wherein, the initial matching device type identifier is the identifier in the device type dictionary with the highest correlation with the device identifier, and the matching confidence is used to indicate the reliability of the initial matching device type identifier as the device type determination result of the original alarm data;

[0059] The first determining unit is configured to determine the initial matching device type identifier as the device type identifier if the matching confidence level is greater than or equal to a preset confidence level threshold.

[0060] A combination unit is configured to extract abnormal state attribute features from the original alarm data if the matching confidence level is less than the confidence level threshold, and combine the initial matching device type identifier with the abnormal state attribute features into a joint feature; wherein, the abnormal state attribute features are used to represent the attributes of the at least one abnormal state;

[0061] A secondary matching unit is used to perform a secondary matching between the joint feature and the device type dictionary to obtain a secondary matching device type identifier, and to determine the secondary matching device type identifier as the device type identifier; wherein, the secondary matching device type identifier is the identifier in the device type dictionary that has the highest correlation with the joint feature.

[0062] In one possible design, the preprocessing unit includes:

[0063] The verification component is used to perform integrity and validity verification on the original alarm data to remove incomplete data with missing fields and invalid data with values ​​exceeding a preset reasonable range, so as to obtain the verified data.

[0064] The deduplication component is used to deduplicatize the verified data to delete redundant alarm data that are repeatedly sent by the same device and under the same abnormal state within a preset time threshold, so as to obtain the preprocessed original alarm data.

[0065] In one possible design, the second classification module includes:

[0066] The feature matching unit is used to perform feature matching between the abnormal state attribute features and the alarm type dictionary to obtain multiple candidate alarm type identifiers and attribute matching similarity corresponding to each candidate alarm type identifier;

[0067] The second integration unit is used to integrate the candidate alarm type identifiers whose attribute matching similarity is greater than a preset similarity threshold to obtain a set of valid candidate alarm type identifiers.

[0068] The determining unit is used to determine the scene weight of each candidate alarm type identifier in the set of valid candidate alarm type identifiers based on the device type identifier corresponding to the original alarm data; wherein, the scene weight is used to represent the degree of contribution of the abnormal state attribute features collected by different devices to the judgment of the candidate alarm type identifier;

[0069] The calculation unit is used to calculate the comprehensive matching value corresponding to each candidate alarm type identifier based on the attribute matching similarity corresponding to each candidate alarm type identifier and the scene weight of each candidate alarm type identifier, and to determine the candidate alarm type identifier corresponding to the maximum value of the comprehensive matching value as the alarm type identifier.

[0070] Thirdly, embodiments of this application provide an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0071] The memory stores computer-executed instructions;

[0072] When the processor executes the computer execution instructions stored in the memory, it is used to implement the alarm data processing method as described in any of the first aspects.

[0073] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the alarm data processing method as described in any of the first aspects.

[0074] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, is used to implement the alarm data processing method as described in any of the first aspects.

[0075] This application provides an alarm data processing method, apparatus, device, medium, and product. It automates the classification of raw alarm data from heterogeneous IoT devices using a pre-defined device type dictionary and alarm type dictionary, replacing manual integration and judgment methods. This reduces the time-consuming process caused by manual operation. Simultaneously, through standardized conversion, it unifies different types of classification identifiers into the same data format, forming standardized alarm data. This eliminates processing barriers caused by scattered alarm information sources and varying formats at the data level, allowing subsequent alarm data processing to be carried out efficiently based on a unified and standardized data foundation. It eliminates the need for additional time spent on data format adaptation and information integration. By improving the overall processing efficiency of alarm data from both automated classification and standardized processing perspectives, it solves the problems of long processing times and inability to quickly and efficiently handle alarm information in existing technologies, resulting in low alarm data processing efficiency. Attached Figure Description

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

[0077] Figure 1 This is a schematic diagram illustrating an application scenario of the alarm data processing method provided in the embodiments of this application;

[0078] Figure 2 This is one of the flowcharts illustrating the alarm data processing method provided in the embodiments of this application;

[0079] Figure 3 This is one of the flowcharts illustrating the alarm data processing method provided in the embodiments of this application;

[0080] Figure 4 This is one of the flowcharts illustrating the alarm data processing method provided in the embodiments of this application;

[0081] Figure 5 This application provides an architecture diagram of an IoT alarm data processing system for a smart elderly care scenario.

[0082] Figure 6 This is a flowchart of the alarm processing provided in the embodiments of this application;

[0083] Figure 7 This is a flowchart of alarm priority determination provided in the embodiments of this application;

[0084] Figure 8A flowchart of alarm correlation analysis provided for embodiments of this application;

[0085] Figure 9 This is a schematic diagram of the alarm data processing device provided in the embodiments of this application;

[0086] Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0087] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0088] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0089] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0090] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply difference. It should be noted that in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more.

[0091] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation. The embodiments of this application do not specifically limit this. In addition, the alarm data processing method, apparatus, device, medium, and product provided in the embodiments of this application are only examples. An alarm data processing method, apparatus, device, medium, and product may also include more or less content.

[0092] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0093] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0094] To clearly understand the technical solution of this application, we will first provide a detailed introduction to the solutions of existing technologies. Currently, the application of IoT technology in areas such as public services and intelligent monitoring continues to deepen. Various types of IoT devices, including those for health monitoring, security protection, and environmental sensing, are deployed in various scenarios. Different devices have different communication modes and data formats, resulting in alarm information that is multi-source, heterogeneous, and distributed, significantly increasing the demand for processing massive amounts of alarm information. Against this backdrop, the ability to efficiently process various alarm information generated by multiple devices directly affects the response efficiency and service capabilities of the intelligent monitoring system.

[0095] In existing technologies, alarm data is received through a customized gateway. When the alarm data reaches a preset trigger condition, the system automatically pushes an alarm notification to the relevant processing terminal, completing the alarm information reception and push processing flow and enabling the processing of various alarm information. However, alarm information generated by various IoT monitoring devices comes from scattered sources and has different formats, requiring manual intervention for data integration and judgment. This results in a time-consuming alarm information processing flow, hindering efficient alarm information handling and failing to meet the real-time alarm response requirements of various intelligent monitoring scenarios. Therefore, existing technologies suffer from low alarm data processing efficiency.

[0096] Therefore, addressing the low efficiency of alarm data processing in existing technologies, this research found that a standardized classification and conversion mechanism can be established to automate the classification and format unification of raw alarm data by device type and alarm type, replacing manual integration and judgment to improve processing efficiency: ① A standardized classification rule system can be established, relying on a pre-set classification dictionary to perform targeted type classification processing on raw alarm data, achieving accurate classification of alarm data from different sources and in different formats, breaking down processing barriers caused by differences in data attributes. ② Automated processing logic can be used to interface with raw alarm data from heterogeneous IoT devices, completing automatic data identification and classification based on pre-set matching rules, reducing the time consumed by manual operations, improving the automation level of the entire alarm data process from acquisition to initial processing, and shortening the basic processing time. ③ Unified standardized conversion specifications can be formulated for the device attributes and alarm attributes of various types of alarm data, converting the relevant identifiers of the classified alarm data into a unified data format, forming standardized alarm data results. This allows subsequent in-depth processing of alarm data to be carried out based on a unified data foundation, eliminating the adaptation costs of subsequent processing caused by format differences.

[0097] Specifically, an automated processing mechanism adapted to heterogeneous data can be built. By pre-setting classification rules, the original alarm data can be accurately classified by device and alarm dimension. Based on a unified standard, the classification results can be formatted and converted to achieve automated processing of alarm data from raw collection to standardized output. This replaces the traditional method of manual intervention, eliminates processing barriers from the perspective of data classification and format unification, and improves the overall efficiency of alarm data processing.

[0098] This application discloses an alarm data processing method, apparatus, device, medium, and product. It automates the classification of raw alarm data from heterogeneous IoT devices using a pre-defined device type dictionary and alarm type dictionary, replacing manual integration and judgment methods. This reduces the time-consuming process caused by manual operation. Simultaneously, through standardized conversion, different types of classification identifiers are unified into the same data format, forming standardized alarm data. This eliminates processing barriers caused by scattered alarm information sources and varying formats at the data level, allowing subsequent alarm data processing to be carried out efficiently based on a unified and standardized data foundation. No additional time is needed for data format adaptation and information integration. This improves the overall processing efficiency of alarm data from both automated classification and standardized processing perspectives, solving the problems of long processing times and inability to quickly and efficiently handle alarm information in existing technologies, resulting in low alarm data processing efficiency.

[0099] Based on the above-mentioned inventive discovery, the technical solution of this application is proposed.

[0100] The following describes the application scenarios of the alarm data processing method provided in the embodiments of the present invention. Figure 1 This is a schematic diagram illustrating an application scenario of the alarm data processing method provided in the embodiments of this application. For example... Figure 1 As shown, this application scenario includes a mobile terminal 101 and a server 102. The mobile terminal 101 collects raw alarm data sent by heterogeneous IoT devices and sends the raw alarm data to the server 102. The server 102 classifies the raw alarm data according to a preset device type dictionary to obtain a device type identifier. The server 102 also classifies the raw alarm data according to a preset alarm type dictionary to obtain an alarm type identifier. Finally, the server 102 performs a standardized conversion between the device type identifier and the alarm type identifier to obtain standardized alarm data.

[0101] The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0102] Figure 2 This is one of the flowcharts illustrating the alarm data processing method provided in an embodiment of this application. Figure 2 As shown, in this embodiment, the execution entity of this invention is a server. Therefore, the alarm data processing method provided in this embodiment includes the following steps:

[0103] S201. Obtain the original alarm data sent by the heterogeneous IoT device; wherein, the original alarm data is used to indicate that the heterogeneous IoT device has detected that the user is in at least one of a number of preset abnormal states, the attribute of at least one abnormal state, and the device identifier of the heterogeneous IoT device.

[0104] Specifically, a multi-protocol compatible IoT data receiving gateway can be built to connect to heterogeneous IoT devices with different communication protocols. The gateway's protocol parsing module parses the raw communication data from each device into a recognizable digital data format. Simultaneously, based on a pre-defined whitelist of device communication addresses, device identity verification is performed. Upon successful verification, the gateway extracts information containing abnormal states, abnormal state attributes, and device identifiers, which is then received as raw alarm data and temporarily stored in a data buffer. This step directly acquires the raw data collected by heterogeneous IoT devices, containing core anomaly information and device identifiers, providing a complete and effective data foundation for subsequent classification and standardization of device types and alarm types.

[0105] S202. Classify the original alarm data by device type according to the preset device type dictionary to obtain the device type identifier; wherein, the device type identifier is used to represent the device type of heterogeneous IoT devices.

[0106] Specifically, a pre-defined device type dictionary can be stored in a local data storage module. This dictionary contains a one-to-one mapping between device identifiers and device type identifiers. The device identifier field is extracted from the raw alarm data, and the extracted device identifier is precisely matched with the key-value pairs in the device type dictionary using a data matching module. If a match is successful, the corresponding device type identifier is retrieved from the dictionary and associated with the corresponding raw alarm data, completing the device type classification operation. This step is used to extract device-related features from the raw alarm data and complete standardized device type definitions. This provides a unified device type identifier basis for subsequent differentiated processing of alarm data for different device types. It also enables device-dimensional classification of heterogeneous device alarm data, allowing scattered raw alarm data to form an ordered classification based on device type. This ensures that subsequent alarm type classification and standardization conversion can be carried out based on clear device type attributes.

[0107] The device type dictionary is a pre-generated and stored mapping dataset containing device identifiers of heterogeneous IoT devices and unique corresponding device type information. This dataset defines the types of IoT devices of different categories and models and establishes a fixed correspondence, which can directly provide a matching basis for the device type classification of the original alarm data. The device type identifier is a standardized character or number identifier assigned to each heterogeneous IoT device after the device type dictionary has been matched. This identifier uniquely corresponds to a type of IoT device and is a standardized representation of the device type, which can be directly used for the standardized conversion processing of subsequent alarm data.

[0108] S203. Classify the original alarm data according to the preset alarm type dictionary to obtain alarm type identifiers; wherein, the alarm type identifier is used to indicate the alarm type corresponding to the original alarm data.

[0109] Specifically, a pre-defined alarm type dictionary can be stored in a local data storage unit. This dictionary pre-stores the mapping relationship between abnormal states, abnormal state attributes, and alarm type identifiers. Feature fields of abnormal states and abnormal state attributes are extracted from the original alarm data. The data retrieval module accurately searches and matches the extracted feature fields with the associated information in the alarm type dictionary. If a match is successful, the corresponding alarm type identifier in the dictionary is retrieved and associated with the corresponding original alarm data, completing the alarm type classification operation. This step is used to extract alarm-related features from the original alarm data and complete the standardized alarm type definition, providing a unified alarm type identifier basis for subsequent standardized conversion of alarm data. At the same time, it enables the classification of alarm dimensions for heterogeneous alarm data, allowing original alarm data from different sources and in different formats to form an orderly classification based on alarm type, ensuring that subsequent standardized conversion can be carried out based on clear alarm type attributes.

[0110] The alarm type dictionary is a pre-generated and stored mapping dataset containing abnormal states detected by IoT devices and their attributes, along with corresponding alarm type information. This dataset defines alarm types for different forms of abnormal information and establishes fixed correspondences, providing a direct matching basis for the alarm type classification of raw alarm data. The alarm type identifier is a standardized character or number identifier assigned to various types of raw alarm data after matching based on the alarm type dictionary. This identifier uniquely corresponds to one type of alarm and is a standardized representation of the alarm type, which can be directly used for subsequent standardized conversion processing of alarm data.

[0111] S204. Standardize and convert the device type identifier and alarm type identifier to obtain standardized alarm data. The standardization conversion is used to convert the device type identifier and alarm type identifier into the same data format. The standardized alarm data is used to provide data input for the preset alarm data processing to eliminate the abnormal state of the user.

[0112] Specifically, a unified data format specification can be pre-defined. Device type identifiers and alarm type identifiers are imported into the format conversion module according to this specification. First, the module's field extraction unit synchronously extracts basic information such as device identifiers, abnormal states, and abnormal state attributes from the associated original alarm data. Then, the format splicing unit uniformly splices and adapts the device type identifiers, alarm type identifiers, and the aforementioned basic information according to a preset field arrangement order, field length, and data encoding format. Finally, the data verification unit verifies the format compliance of the spliced ​​and adapted overall data. If the verification passes, structured standardized alarm data is generated and stored in a designated data area. This step integrates the classification identifiers of device types and alarm types with the core information in the original alarm data and uniformly converts them into the same structured data format, forming standardized alarm data. This provides a unified and directly callable data input for the preset alarm data processing stages, achieving unified processing of heterogeneous alarm data at the format level, allowing alarm data from different sources and of different types to support subsequent data processing operations in a consistent format.

[0113] The alarm data processing method can be applied to the important technical field of smart elderly care. It solves the technical problems in this field caused by the complexity of alarm information management and the lack of standardized alarm data processing procedures due to the diverse types of IoT devices deployed, such as health monitoring, safety monitoring, emergency assistance, environmental monitoring, and positioning devices, which have heterogeneous protocols and scattered data formats. This leads to delayed alarm response, high false alarm rates, and waste of elderly care resources. The method is adapted to the alarm data processing needs of various heterogeneous IoT devices in smart elderly care scenarios, optimizes the alarm information processing process, and meets the core needs of smart elderly care to upgrade from passive response to proactive service. It also meets the actual needs of efficient utilization of elderly care resources and improved safety protection for the elderly.

[0114] The alarm data processing method can also be applied to the field of smart park technology. It solves the technical problems caused by the differences in equipment manufacturers, communication protocols, and data output formats of various IoT monitoring devices such as video surveillance, fire sensors, access control, energy consumption monitoring, and environmental sensing. These differences result in scattered sources and inconsistent formats of various alarm information, such as security alarms, fire alarms, equipment failure alarms, and environmental anomaly alarms, within the park. The lack of standardized processing procedures leads to chaotic alarm information management, poor alarm handling coordination, and limited efficiency of park operation and management. The method adapts to the integrated and standardized processing needs of smart parks for alarm data from various heterogeneous IoT devices, ensuring efficient processing and flow of various alarm information within the park.

[0115] This embodiment provides an alarm data processing method that automates the classification of raw alarm data from heterogeneous IoT devices through a preset device type dictionary and alarm type dictionary. This replaces the manual integration and judgment method, reducing the time-consuming process caused by manual operation. At the same time, through standardized conversion, different types of classification identifiers are unified into the same data format, forming standardized alarm data. This eliminates the processing barriers caused by the scattered sources and different formats of alarm information at the data level, allowing subsequent alarm data processing to be carried out efficiently based on a unified and standardized data foundation. There is no need to spend extra time on data format adaptation and information integration. This improves the overall processing efficiency of alarm data from the two levels of automated classification and standardized processing, solving the problem of long alarm data processing time and inability to quickly and efficiently handle alarm information in the existing technology, resulting in low alarm data processing efficiency.

[0116] In one possible design, S204, the device type identifier and alarm type identifier are standardized and converted to obtain standardized alarm data, including:

[0117] S2041. Convert the device type identifier and alarm type identifier into a unified data format to obtain the converted device type identifier and the converted alarm type identifier.

[0118] Specifically, a unified character and number combination encoding format can be pre-defined as the standard data format for the identifiers. This specifies the fixed character length, field arrangement rules, and encoding type of the identifiers. A format conversion unit reads the original format data of both device type and alarm type identifiers, and reconstructs and converts the two types of identifiers according to the pre-defined standard data format. Unified character padding, format adaptation, and encoding mapping are performed on identifiers with different original formats, converting all non-standard format identifiers into a unified encoding format conforming to pre-defined rules. This directly generates the converted device type and alarm type identifiers. This step achieves unified processing of device type and alarm type identifiers at the data format level, eliminating the connection barriers caused by differences in the original formats of the two types of identifiers, and providing consistent basic data for subsequent identifier integration.

[0119] S2042. Integrate the converted device type identifier and the converted alarm type identifier to obtain standardized alarm data.

[0120] Specifically, a structured alarm data integration template can be pre-defined, clearly defining the field positions and order of device type identifiers, alarm type identifiers, and core related information from the original alarm data. The data integration module first extracts core information such as device identifiers, abnormal states, and abnormal state attributes from the original alarm data and standardizes the fields according to the template requirements. Then, the converted device type identifiers and converted alarm type identifiers are embedded into the standardized core information according to the preset field positions in the template, forming standardized alarm data. This step integrates the two types of identifiers with the core business information in the original alarm data, forming structured data that combines classification identifiers and actual alarm information. This provides a complete and standardized unified data carrier for the pre-defined alarm data processing steps, realizing the transformation of heterogeneous original alarm data from standardized classification identifiers to overall data structuring, ensuring that all types of alarm data have a consistent information presentation format and retrieval standard.

[0121] The technical effect of this solution in this embodiment is that by converting device type identifiers and alarm type identifiers into a unified data format and then integrating them to obtain standardized alarm data, classification identifiers from different sources and of different types can form standardized alarm data with a completely unified format and regular structure. This eliminates the processing connection barriers caused by differences in data formats, and allows the standardized alarm data to provide a standardized and unified data input for subsequent alarm data processing. It solves the problems of unclear alarm data standardization conversion process, inconsistent format, and easy impact on the overall processing efficiency of alarm data due to conversion connection issues.

[0122] In one possible design, S202, the original alarm data is classified into device types according to a preset device type dictionary to obtain device type identifiers, including:

[0123] S2021. Preprocess the original alarm data to obtain preprocessed original alarm data.

[0124] Specifically, a raw alarm data preprocessing module can be built. This module includes a data cleaning unit and a data normalization unit. First, the data cleaning unit performs operations such as null value removal, duplicate data deletion, and invalid character filtering on the raw alarm data, eliminating redundant information that has no practical significance. Then, the data normalization unit extracts core fields such as device identifier, abnormal status, and abnormal status attributes from the cleaned alarm data according to preset field extraction rules, and arranges these core fields in a fixed field order to form structured preprocessed raw alarm data. This step is used to preprocess the raw alarm data sent by heterogeneous IoT devices, removing invalid and redundant information and transforming unstructured raw data into structured and standardized data, providing an accurate and interference-free data source for subsequent extraction of device identifiers and initial matching operations.

[0125] S2022. Obtain the device identifier from the preprocessed original alarm data, and perform an initial match between the device identifier and the device type dictionary to obtain the initial matched device type identifier and the matching confidence of the initial matched device type identifier; wherein, the initial matched device type identifier is the identifier with the highest correlation with the device identifier in the device type dictionary, and the matching confidence is used to indicate the reliability of the initial matched device type identifier as the device type determination result of the original alarm data.

[0126] Specifically, a field extraction tool can accurately extract device identifier information from preset fields in the preprocessed raw alarm data. The extracted device identifier is then input as a matching factor into the data matching module. This module has a built-in similarity calculation unit that performs a character-level similarity comparison between the device identifier and all device identifiers stored in the device type dictionary. It calculates the matching degree between the device identifier and each device identifier in the dictionary, selecting the device type identifier with the highest matching degree as the initial matching device type identifier. Simultaneously, this highest matching degree is converted into a standardized value in the 0-1 range, serving as the matching confidence level for this initial matching device type identifier. This step extracts core device identifiers from the standardized preprocessed data to conduct the initial device type matching, quickly obtaining a preliminary device type determination result. The quantified matching confidence level characterizes the reliability of this determination result, providing a direct basis and initial matching result for subsequent determination of whether a secondary matching is needed based on a confidence threshold.

[0127] S2023. If the matching confidence level is greater than or equal to the preset confidence level threshold, the initial matching device type identifier is determined as the device type identifier.

[0128] Specifically, a fixed confidence threshold can be preset in the data matching module, and a threshold determination unit can be built. When this unit receives the initial matching device type identifier and the corresponding matching confidence level, it directly compares the matching confidence level value with the preset confidence threshold. If the determination result is that the matching confidence level is greater than or equal to the confidence threshold, the module's identifier confirmation unit directly marks and locks the initial matching device type identifier, using it as the final result of this device type classification. Simultaneously, the identifier is associated and bound with the corresponding original alarm data and stored in a designated data area. This step is used to directly confirm the initial matching result that meets the confidence level, quickly completing the determination of the device type identifier without performing subsequent secondary matching operations. This simplifies the device type classification process, improves the overall efficiency of device type classification, and provides a definite device type identifier basis for subsequent alarm type classification and standardization conversion.

[0129] S2024. If the matching confidence level is less than the confidence level threshold, extract the abnormal state attribute features from the original alarm data, and combine the initial matching device type identifier with the abnormal state attribute features into a joint feature; wherein, the abnormal state attribute features are used to represent the attributes of at least one abnormal state.

[0130] Specifically, a feature extraction unit and a feature combination unit can be built in the data processing module. When the matching confidence is less than the confidence threshold, the feature extraction unit first extracts feature fields related to abnormal state attributes from the preprocessed raw alarm data, transforms them into structured abnormal state attribute features, and completes feature quantization. Then, the feature combination unit orderly combines the quantized abnormal state attribute features with the initial matching device type identifier according to preset feature concatenation rules to form a joint feature containing initial device type judgment information and abnormal state attribute information. This step is used to supplement abnormal state attribute-related feature information when the reliability of the initial matching result is insufficient, and merges it with the initial matching device type identifier to form a more comprehensive matching feature, providing a richer and more complete matching basis for subsequent secondary matching.

[0131] S2025. Perform a secondary matching between the joint features and the device type dictionary to obtain the secondary matching device type identifier, and determine the secondary matching device type identifier as the device type identifier; wherein, the secondary matching device type identifier is the identifier in the device type dictionary that has the highest correlation with the joint features.

[0132] Specifically, a secondary matching module can be built, comprising a feature parsing unit, a multi-dimensional matching unit, and an identifier confirmation unit. First, the feature parsing unit parses the temporarily stored joint features, separating the initial matching device type identifier and the quantified abnormal state attribute features, and labeling the feature dimensions separately. Then, the multi-dimensional matching unit performs a full-dimensional similarity comparison between the separated multi-dimensional joint features and the device identifiers and adapted abnormal state attribute features corresponding to each entry in the device type dictionary, calculating the comprehensive matching degree between each entry and the joint features. The device type identifier with the highest comprehensive matching degree is selected as the secondary matching device type identifier. Finally, the identifier confirmation unit locks this secondary matching device type identifier as the final device type identifier. This step is used to perform accurate secondary matching based on multi-dimensional joint features when the reliability of the initial matching result is insufficient. By supplementing the abnormal state attribute feature dimensions, the accuracy of device type matching is improved, determining a more realistic device type identifier, avoiding judgment errors caused by matching a single device identifier, and ensuring the accuracy and effectiveness of the device type classification results.

[0133] The technical effect of this solution in this embodiment is as follows: After preprocessing the original alarm data, initial matching of device identifiers is carried out and a matching confidence level is introduced. For low confidence results, abnormal state attribute features are further integrated to form joint features to complete secondary matching. This ensures the accuracy and reliability of device type identification, allowing the original alarm data under heterogeneous devices to be accurately classified. It avoids the device type identification deviation caused by a single matching method, ensures that the classification data before standardization conversion has high accuracy, and solves the problem in the prior art that the device type classification of the original alarm data relies solely on a single matching method, which is prone to inaccurate classification results due to device identifier matching deviation, thereby affecting the effectiveness of subsequent alarm data processing.

[0134] In one possible design, S2021, the raw alarm data is preprocessed to obtain preprocessed raw alarm data, including:

[0135] S20211. Perform integrity and validity checks on the original alarm data to remove incomplete data with missing fields and invalid data with values ​​exceeding the preset reasonable range, and obtain the checked data.

[0136] Specifically, a dual-verification module can be built, comprising an integrity verification unit and a validity verification unit. First, the integrity verification unit retrieves a pre-defined list of core fields from the original alarm data, performing a field-by-field check to directly remove incomplete data lacking core fields such as device identifiers or abnormal states. Then, the validity verification unit reads pre-defined reasonable threshold ranges for each numerical field, comparing the original alarm data (physiological indicators, environmental monitoring values, etc.) within a specified range to remove invalid data exceeding the pre-defined reasonable range. The compliant data remaining after these two layers of verification is then integrated into the verified data and temporarily stored in a designated data buffer. This step filters out complete and compliant valid data from the original alarm data, removing incomplete or invalid data that does not meet processing requirements. This provides a high-quality, complete data source for subsequent deduplication and device type matching processes, preventing incomplete or invalid data from interfering with subsequent data processing operations.

[0137] S20212. Perform deduplication on the verified data to delete redundant alarm data repeatedly sent by the same device and under the same abnormal state within a preset time threshold, and obtain the pre-processed original alarm data.

[0138] Specifically, a data deduplication module can be built, comprising a feature extraction unit, a time determination unit, and a redundancy removal unit. First, the feature extraction unit extracts the device identifier and abnormal state features of each data entry from the verified data and combines them into a single tag. Simultaneously, it extracts the alarm sending timestamp for each data entry. Next, the time determination unit retrieves a preset time threshold and sorts multiple alarm data entries under the same tag combination by timestamp, determining whether each data entry falls within the same preset time threshold range. Finally, the redundancy removal unit, for multiple alarm data entries from the same device, under the same abnormal state, and within the preset time threshold, retains only the earliest valid data entry and deletes the remaining duplicate alarm data. All the deduplicated data is then integrated into structured, pre-processed original alarm data. This step removes duplicate redundant alarm data from the verified compliant data, reducing the interference of meaningless duplicate data in subsequent processing stages, improving the processing efficiency of subsequent stages such as device type matching and alarm type classification, and providing a streamlined and high-quality data source for subsequent data processing stages.

[0139] The technical effect of this solution in this embodiment is as follows: by performing dual verification of the integrity and validity of the original alarm data to remove incomplete and invalid data, and then performing deduplication processing within a time threshold on redundant data of the same abnormal state of the same device, the original data entering the device type classification stage is guaranteed to have high integrity, validity and uniqueness. This allows subsequent device type determination operations such as initial matching and secondary matching to be carried out based on high-quality data sources, ensuring the accuracy and reliability of the processing results at each stage. This solves the problem in the prior art that directly using unprocessed original alarm data for device type classification is prone to distorted device type determination results due to incomplete, invalid and redundant data, which in turn affects the effectiveness of subsequent alarm data processing stages.

[0140] In one possible design, S203, the original alarm data is classified into alarm types according to a preset alarm type dictionary to obtain alarm type identifiers, including:

[0141] S2031. Perform feature matching between the abnormal state attribute features and the alarm type dictionary to obtain multiple candidate alarm type identifiers and the attribute matching similarity corresponding to each candidate alarm type identifier.

[0142] Specifically, an alarm feature matching module can be built. This module includes a feature quantization unit and a similarity calculation unit. First, the feature quantization unit converts the extracted abnormal state attribute features into standardized numerical feature vectors. Then, the similarity calculation unit performs cosine similarity calculations on these feature vectors and the feature vectors corresponding to each alarm type identifier in the alarm type dictionary. This yields the matching values ​​between the abnormal state attribute features and each alarm type identifier. All alarm type identifiers corresponding to the matching values ​​are used as multiple candidate alarm type identifiers. Simultaneously, the cosine similarity calculation results are directly used as the attribute matching similarity of the corresponding candidate alarm type identifiers. This step is used to filter alarm type identifiers related to the abnormal state attribute features from the alarm type dictionary as candidates. The quantified attribute matching similarity characterizes the degree of association between the features and each candidate identifier, providing a foundation of candidate objects and quantified matching criteria for subsequent screening of effective candidate identifiers and calculation of comprehensive matching values.

[0143] S2032. Integrate the candidate alarm type identifiers whose attribute matching similarity is greater than the preset similarity threshold to obtain a set of valid candidate alarm type identifiers.

[0144] Specifically, a candidate identifier filtering module can be built. This module has a built-in threshold determination unit and a set integration unit. First, the threshold determination unit retrieves a preset similarity threshold and compares the attribute matching similarity of each temporarily stored candidate alarm type identifier with this threshold. Candidate alarm type identifiers with attribute matching similarity greater than the preset threshold are filtered out. Then, the set integration unit orderly aggregates all the filtered candidate alarm type identifiers according to preset character encoding rules, adds a unique set identifier to the aggregated identifier set, and completes structured storage to form a valid candidate alarm type identifier set. This step is used to remove identifiers that do not meet the matching degree from the initial multiple candidate alarm type identifiers, retaining valid candidate identifiers with a high correlation with the abnormal state attribute characteristics, forming a standardized valid candidate set. This provides accurate filtering objects for subsequent configuration of scene weights and calculation of comprehensive matching values ​​based on device type identifiers.

[0145] S2033. Based on the device type identifier corresponding to the original alarm data, determine the scene weight of each candidate alarm type identifier in the set of valid candidate alarm type identifiers; wherein, the scene weight is used to represent the degree of contribution of the abnormal state attribute features collected by different devices to the judgment of candidate alarm type identifiers.

[0146] Specifically, a device-alarm scenario weight library can be pre-built, storing different device type identifiers and corresponding scenario weight values ​​for each alarm type identifier. A weight matching module can be built, comprising an identifier retrieval unit and a weight assignment unit. First, the identifier retrieval unit extracts core identifier information from the device type identifier corresponding to the determined original alarm data. Then, the weight assignment unit performs a precise search in the device-alarm scenario weight library based on the device type identifier, retrieving the preset scenario weight values ​​corresponding to each candidate identifier in the set of valid candidate alarm type identifiers under that device type. The corresponding scenario weights are then directly assigned to each candidate alarm type identifier in the set, completing the association and binding. This step assigns weight values ​​that fit the device application scenario to each identifier in the set of valid candidate alarm type identifiers, reflecting the different contributions of abnormal state attribute characteristics collected by different devices to alarm type determination. This provides a scenario-based weight basis for subsequent calculation of the comprehensive matching value, making the alarm type determination results more consistent with the actual device application scenario.

[0147] Among them, the scenario weight is a quantitative value assigned to the valid candidate alarm type identifier based on the device type, core function and application scenario of the alarm data collected during the alarm type determination process. It is used to define the contribution of the abnormal state attribute features collected by different devices to the final alarm type determination result. Its core function is to make the alarm type determination refer to both feature matching degree and actual device usage scenario, avoid the judgment bias caused by relying solely on feature matching, and improve the accuracy of alarm classification and scenario adaptability. For example, in a smart park scenario, when the same "infrared sensing anomaly" feature is detected, if the data comes from an infrared beam detector at the perimeter of the park's perimeter wall, the scene weight for this feature corresponding to "illegal intrusion alarm" will be set to 0.95. This is because the core function of this device is to monitor intrusion for park security, and its data has core reference value for determining this alarm type. However, if the data comes from a human infrared sensor in the park's office building corridor, the scene weight for this feature corresponding to "illegal intrusion alarm" will only be set to 0.2. This is because this device is mainly used to sense personnel passage and trigger lighting, and is not dedicated to security. Its infrared anomaly data has very low reference value for determining intrusion alarms and is more likely to correspond to equipment malfunction or false triggering by normal personnel activities.

[0148] S2034. Based on the attribute matching similarity corresponding to each candidate alarm type identifier and the scene weight of each candidate alarm type identifier, calculate the comprehensive matching value corresponding to each candidate alarm type identifier, and determine the candidate alarm type identifier corresponding to the maximum comprehensive matching value as the alarm type identifier.

[0149] Specifically, a comprehensive matching calculation module can be built, comprising a data retrieval unit, a numerical calculation unit, and an identifier determination unit. First, the data retrieval unit extracts the attribute matching similarity and scene weight values ​​corresponding to each identifier within the set of valid candidate alarm type identifiers from the associated stored data. Then, the numerical calculation unit uses a weighted product algorithm to multiply the attribute matching similarity of each candidate alarm type identifier by its corresponding scene weight value, obtaining the comprehensive matching value for each candidate identifier. Finally, the identifier determination unit sorts all comprehensive matching values ​​and selects the candidate alarm type identifier corresponding to the maximum value in the sorted results as the final alarm type identifier. This step combines the quantitative results of feature matching with the weight attributes of the device scene to calculate the comprehensive matching value of each valid candidate identifier. By numerically sorting, the most realistic alarm type identifier is determined, ensuring that the alarm type determination result simultaneously considers feature matching degree and the adaptability to the device application scenario, providing an accurate alarm type basis for subsequent standardized conversion of alarm data.

[0150] The technical effect of this solution in this embodiment is as follows: After performing feature matching between the abnormal state attribute features and the alarm type dictionary, valid candidate identifiers are screened. The candidate identifiers are then assigned scene weights based on the device type identifiers, and a comprehensive matching value is calculated to determine the final alarm type identifier. This makes the alarm type determination result more consistent with the actual scene characteristics of the device, ensuring the accuracy and scene adaptability of the alarm type identifier. The standardization conversion process based on this identifier can proceed with high-precision alarm type information, avoiding the alarm type determination bias caused by single feature matching. This allows the subsequently generated standardized alarm data to truly and accurately reflect the actual alarm situation. This solves the problem in the prior art where alarm type classification is based solely on single feature matching without considering the scene characteristics of the device type, which easily leads to the alarm type determination result not matching the actual scene and insufficient determination accuracy.

[0151] Figure 3 This is one of the flowcharts illustrating the alarm data processing method provided in this application embodiment. In this embodiment, in Figure 2 Based on the provided embodiments, the alarm data processing method is further explained. The alarm data processing method includes:

[0152] S301. Obtain the original alarm data sent by the heterogeneous IoT device; wherein, the original alarm data is used to indicate that the heterogeneous IoT device has detected that the user is in at least one of a number of preset abnormal states, the attribute of at least one abnormal state, and the device identifier of the heterogeneous IoT device.

[0153] S302. Classify the original alarm data by device type according to the preset device type dictionary to obtain the device type identifier; wherein, the device type identifier is used to represent the device type of heterogeneous IoT devices.

[0154] S303. Classify the original alarm data according to the preset alarm type dictionary to obtain alarm type identifiers; wherein, the alarm type identifier is used to indicate the alarm type corresponding to the original alarm data.

[0155] S304. Standardize and convert the device type identifier and alarm type identifier to obtain standardized alarm data. The standardization conversion is used to convert the device type identifier and alarm type identifier into the same data format. The standardized alarm data is used to provide data input for the preset alarm data processing to eliminate the abnormal state of the user.

[0156] S301-S304 are similar to S201-S204, and will not be described again in this embodiment.

[0157] S305. Match the standardized alarm data with multiple preset alarm handling schemes to obtain the target alarm handling scheme corresponding to the maximum matching degree of the standardized alarm data.

[0158] Specifically, an alarm handling scheme library can be pre-built, storing multiple preset alarm handling schemes and configuring a unique matching feature set for each scheme. This feature set is associated with core fields in the standardized alarm data, such as device type identifier, alarm type identifier, and abnormal status attributes. A data matching module extracts the core feature fields from the standardized alarm data and compares them field-by-field with the matching feature sets of each scheme in the alarm handling scheme library. The matching degree between the standardized alarm data and each alarm handling scheme is calculated, and the alarm handling scheme with the highest matching degree is selected as the target alarm handling scheme. This step is used to match suitable handling schemes to the standardized alarm data, establishing a precise correlation between alarm data and handling strategies. This provides clear and specific scheme basis for subsequent alarm handling operations, ensuring that all types of alarm data can be matched with suitable handling strategies, guaranteeing the targetedness and effectiveness of alarm handling operations.

[0159] S306. Execute the target alarm handling plan to eliminate the abnormal state of the user.

[0160] Specifically, an alarm handling execution module can be pre-built. This module connects to various execution terminals and heterogeneous IoT devices, extracting the execution instructions, execution objects, and operation steps contained in the target alarm handling solution. First, the module's instruction parsing unit converts the textual execution requirements in the solution into executable machine instructions. Then, based on the execution object, the corresponding terminal or device is determined. The parsed machine instructions are pushed to the corresponding execution terminal and device through the communication module. Simultaneously, the core content of the target alarm handling solution is pushed to the terminals of relevant personnel in text form, and the instruction push status and handling progress are recorded synchronously to ensure accurate issuance of execution instructions and orderly progress of handling operations until the abnormal state of the user is eliminated. This step is used to transform the matched target alarm handling solution into actual handling operations. By accurately issuing execution instructions and linking relevant execution terminals and personnel, the abnormal state is quickly eliminated, and the handling requirements corresponding to standardized alarm data are implemented into concrete actions, ensuring that the alarm handling process forms a closed loop and effectively solving the abnormal problems encountered by users.

[0161] The technical effect of this solution in this embodiment is as follows: By accurately matching standardized alarm data based on a unified format with multiple preset alarm handling solutions, and selecting the solution with the highest matching degree to execute in order to eliminate abnormal states, the standardized alarm data enables automated matching of alarm handling solutions. This allows the standardized alarm data to be directly connected to subsequent handling stages, avoiding matching deviations or manual intervention caused by inconsistent data formats. This improves the overall accuracy of alarm data from processing to handling, and solves the problem in the prior art that there is a lack of efficient automated handling connection mechanism after alarm data processing, which easily affects the overall response efficiency of alarms due to inaccurate solution matching and disconnection of handling processes.

[0162] In one possible design, S306 executes the target alarm processing scheme, including:

[0163] S3061. Obtain user feature profile; wherein, user feature profile is used to represent multiple features of a user.

[0164] Specifically, a user profile database can be pre-built. This database stores various characteristic data such as basic user information, physical condition, and behavioral habits, and establishes a unique user identifier. Relevant user identifiers are extracted from standardized alarm data. A data retrieval module then uses this user identifier to perform a precise search in the user profile database, retrieving all the corresponding characteristic data. Finally, a data integration unit categorizes and integrates the retrieved discrete characteristic data according to preset dimensions to form a user profile. This step is used to obtain specific user characteristic data for adjusting the parameters of the target alarm handling solution, extracting and integrating various characteristic information of users related to the alarm data to form a complete user profile that can be directly used for parameter adaptation. This ensures that subsequent adjustments to processing parameters are tailored to the actual characteristics of the user.

[0165] S3062. Adjust multiple preset processing parameters in the target alarm processing scheme according to the user feature profile to obtain the adjusted target alarm processing scheme, and execute the adjusted target alarm processing scheme; wherein, the adjustment is used to adapt multiple processing parameters to multiple user features.

[0166] Specifically, a matching rule base for user characteristics and processing parameters can be pre-established. This rule base stores the adjustment thresholds and methods for processing parameters corresponding to different user characteristics. First, the parameter extraction unit extracts all preset processing parameters from the target alarm handling scheme. Then, the feature matching unit matches each feature in the user feature profile with the feature entries in the matching rule base one by one. Based on the matched matching rules, the specific adjustment direction and value of each processing parameter are determined. The parameter adjustment unit modifies the preset processing parameters according to the adjustment requirements, generating the adjusted target alarm handling scheme. Finally, the scheme execution unit converts the adjusted scheme into executable machine instructions and pushes them to the corresponding execution terminal and device to complete the entire scheme execution operation according to the instructions. This step is used to ensure that the processing parameters of the target alarm handling scheme are aligned with the actual characteristics of the associated user, to personalize and target the preset parameters, to form a custom processing scheme adapted to the user characteristics, and then to implement the scheme into actual execution operations. This allows the alarm handling operation to meet the actual needs of different users, improving the adaptability and effectiveness of the scheme execution.

[0167] The technical effect of this solution in this embodiment is as follows: by acquiring user feature profiles and adjusting the processing parameters in the solution accordingly, the alarm handling solution can accurately adapt to the personalized characteristics of different users, and the target solution can fit the user needs of actual application scenarios. This improves the execution fit of the target alarm handling solution and ensures that abnormal states can be eliminated in a way that is accurately tailored to the user's actual situation. This solves the problem in the prior art where the alarm handling solution execution stage uses generalized parameters that cannot adapt to the personalized characteristics of users, which easily leads to poor solution execution effect and inaccurate elimination of abnormal states.

[0168] Figure 4 This is one of the flowcharts illustrating the alarm data processing method provided in this application embodiment. In this embodiment, in Figure 3 Based on the provided embodiments, the alarm data processing method is further explained. The alarm data processing method includes:

[0169] S401. Match the standardized alarm data with multiple preset alarm handling schemes to obtain the target alarm handling scheme corresponding to the maximum matching degree with the standardized alarm data.

[0170] S402. Execute the target alarm handling plan to eliminate the abnormal state of the user.

[0171] S401-S402 are similar to S305-S306, and will not be described again in this embodiment.

[0172] S403. Collect execution feedback data of the target alarm handling scheme; among which, the execution feedback data includes the abnormal state elimination result, processing response time and user adaptability.

[0173] Specifically, a multi-dimensional feedback data acquisition module can be built. This module connects to the alarm handling execution terminal, user-end interaction devices, and the system backend timing unit. The execution terminal's status acquisition unit obtains the final handling result of the user's abnormal state, serving as the abnormal state elimination result. The system backend timing unit extracts the entire process time data from the issuance of the solution execution command to the completion of the abnormal state handling, serving as the processing response time. The user-end interaction device's information collection unit obtains the user's subjective feedback information on the handling process and results and converts it into quantitative data, serving as user fit. After summarizing and verifying these three types of data, they are integrated into the execution feedback data of the target alarm handling solution. This step comprehensively collects relevant data on the execution process and results of the target alarm handling solution, obtaining multi-dimensional information that reflects the solution's execution effectiveness, providing a complete and accurate data source for subsequent scoring operations based on a preset evaluation index system.

[0174] S404. The execution feedback data is scored according to the preset evaluation index system to obtain the execution score of the target alarm handling plan.

[0175] Specifically, an evaluation index system encompassing three dimensions—abnormal state elimination results, processing response time, and user adaptability—can be pre-defined. Corresponding score ranges, scoring rules, and weighting percentages are assigned to each dimension and stored in the index configuration module. The data parsing unit extracts raw data for the three dimensions from the execution feedback data. Following the scoring rules in the evaluation index system, the raw data for each dimension is converted into corresponding dimension scores. Then, the weighting calculation unit performs a weighted sum of the scores for each dimension according to preset weighting percentages to obtain the comprehensive execution score of the target alarm handling solution. This step transforms multi-dimensional execution feedback data into a quantified comprehensive score. Standardized scoring rules objectively measure the actual execution effect of the target alarm handling solution, providing a clear quantitative basis for subsequent judgments on whether iterative optimization of the solution parameters is necessary.

[0176] S405. If the execution score is lower than the preset score threshold, the parameters of the adjusted target alarm handling scheme are iteratively optimized based on the execution feedback data to obtain the optimized alarm handling scheme, and the optimized alarm handling scheme is updated to multiple alarm handling schemes.

[0177] Specifically, a pre-set scoring threshold and a parameter iteration optimization module can be built. This module includes a problem localization unit, a parameter optimization unit, and a solution update unit. When the execution score is lower than the preset scoring threshold, the problem localization unit first compares the various dimensions of the execution feedback data with the standard requirements of the evaluation indicator system to locate the dimensions that do not meet the standards in abnormal state elimination results, processing response time, and user adaptability, as well as the corresponding parameter problems. Then, based on the localization results and combined with the actual feedback data of the non-compliant dimensions, the parameter optimization unit performs numerical correction and logical optimization on the corresponding processing parameters in the adjusted target alarm handling solution, generating an optimized alarm handling solution. Finally, the solution update unit synchronizes the optimized alarm handling solution to the alarm handling solution library, replacing the original non-compliant solution content. This step is used to optimize parameters and update solutions for alarm handling solutions that do not meet the execution results, to mine problems in solution parameters from the execution feedback data and make targeted corrections, generating optimized solutions that are more suitable for actual handling needs, and simultaneously synchronizing the optimized solutions to the preset alarm handling solution library to achieve iterative improvement of alarm handling solutions.

[0178] The technical effect of this solution in this embodiment is as follows: By collecting execution feedback data including abnormal state elimination results, processing response time, and user adaptability, and relying on a preset evaluation index system to complete the scoring, and performing parameter iteration optimization and updating of low-scoring solutions to the solution library, the alarm handling solution can be continuously improved based on actual execution results. This allows the personalized alarm handling solution to continuously adapt to the actual needs and scenario characteristics of users in practice, continuously improving the implementation adaptability and execution effectiveness of the alarm handling solution. It ensures that the standardized alarm data docking handling solution is always in the optimal adaptation state, solving the problem that the alarm handling solution in the prior art is fixed and cannot be dynamically optimized according to the actual execution results, which easily leads to insufficient long-term adaptability of the solution and difficulty in improving the abnormal state handling effect.

[0179] Alarm data processing methods can be applied to the field of smart elderly care. As my country's population ages, smart elderly care has become an important way to solve the problem of elderly care. In smart elderly care scenarios, it is typically necessary to deploy various IoT devices to monitor the health status and activity levels of the elderly, including but not limited to:

[0180] 1. Health monitoring equipment: smart blood pressure monitors, smart blood glucose meters, multi-parameter detectors, etc.

[0181] 2. Safety monitoring equipment: fall detection and protection devices, human presence sensors, sleep monitoring and protection devices, etc.

[0182] 3. Emergency assistance devices: wristwatches, one-button alarms, stand-alone one-button alarms, etc.

[0183] 4. Environmental monitoring equipment: gas alarms, alarm gateways, etc.

[0184] 5. Positioning devices: caregiver locators, etc.

[0185] However, existing technologies have the following problems:

[0186] 1. Equipment heterogeneity: Different manufacturers and different types of equipment use different communication protocols and data formats, making it difficult to manage and process them uniformly.

[0187] 2. Dispersed alarm information: Alarm information generated by various devices is scattered across different subsystems, lacking a unified alarm processing mechanism.

[0188] 3. Complex alarm types: There are more than 20 types of alarms (such as fall alarms, SOS alarms, abnormal blood pressure alarms, abnormal blood sugar alarms, abnormal heart rate alarms, offline alarms, low battery alarms, loitering alarms, fence alarms, etc.), lacking a unified classification and processing standard.

[0189] 4. Unclear alarm priorities: Different alarm types have different levels of urgency, but the existing system lacks an intelligent priority judgment and processing mechanism.

[0190] 5. Insufficient alarm correlation analysis: Multiple devices may generate related alarms simultaneously, but the existing system lacks the ability to analyze the correlation of alarms.

[0191] Figure 5 The system architecture diagram of the IoT alarm data processing system in the smart elderly care scenario provided in the embodiments of this application is as follows: Figure 5 As shown, the system architecture includes:

[0192] Device Access Layer: Supports the access of various IoT devices, including: Health Monitoring Devices: Smart Blood Pressure Monitors, Smart Blood Glucose Meters, Multi-Parameter Analyzers; Safety Monitoring Devices: Fall Detection Devices, Human Presence Sensors, Sleep Monitoring Devices; Emergency Assistance Devices: Wristwatches, One-Button Alarms, Standalone One-Button Alarms, Alarm Gateways; Environmental Monitoring Devices: Gas Alarms; Positioning Devices: Caregiver Positioners.

[0193] Data standardization layer: Device type dictionary: Unified management of device types and their models; Alarm type dictionary: Unified management of 20+ alarm types, including: emergency alarms, health alarms, device alarms, behavior alarms, and location alarms.

[0194] Alarm Processing Engine: Alarm Receiving Module: Receives alarm information from various devices; Alarm Standardization Module: Converts alarm information from heterogeneous devices into a unified alarm data format; Alarm Classification Module: Classifies alarms according to an alarm type dictionary; Alarm Priority Judgment Module: Intelligently determines alarm priority based on factors such as alarm type, urgency, and the elderly person's condition; Alarm Correlation Analysis Module: Analyzes the correlation between multiple alarms from the same elderly person within the same time period.

[0195] Alarm Management Module: Alarm Status Management: Pending, Processed, Automatic Processing; Alarm Processing Flow: Alarm Reception → Priority Judgment → Correlation Analysis → Processing Allocation → Processing Follow-up → Processing Completion; Alarm Information Display: Alarm List and Alarm Details.

[0196] Device Management Module: Device Registration and Binding: Management of the binding relationship between devices and the elderly; Device Status Monitoring: Online, Offline, Under Maintenance, Fault; Device Information Management: Device type, device model, device number, and Integrated Circuit Card Identifier (ICCID), etc.

[0197] Figure 6 The alarm processing flowchart provided in the embodiments of this application is as follows: Figure 6 As shown, the process includes:

[0198] Step 1: Alarm Reception: The device sends alarm data through protocols such as Message Queuing Telemetry Transport (MQTT) / Hypertext Transfer Protocol (HTTP), and the system receives the raw alarm data.

[0199] Step 2: Data Standardization: Identify device types based on the device type dictionary and alarm types based on the alarm type dictionary, and convert them into a unified alarm data format.

[0200] Step 3: Priority determination: Call the priority determination algorithm to calculate the alarm priority (0-100 points) and mark the urgency of the alarm.

[0201] Step 4: Correlation Analysis: Query other alarms for the same elderly person within the last 5 minutes, call the correlation analysis algorithm, and identify the correlation of alarms.

[0202] Step 5: Allocation: Based on the alarm type and priority, the allocation algorithm is invoked to automatically assign the alarm to the appropriate personnel and send notifications (SMS, APP push, etc.).

[0203] Step 6: Follow up on the process: Record changes in the processing status, record the actions taken by the personnel handling the process, and update the alarm status.

[0204] Step 7: Processing complete: Record the processing result and update the alarm status to processed.

[0205] Figure 7 The alarm priority determination flowchart provided in the embodiments of this application is as follows: Figure 7 As shown, the process first initializes priority scores, then retrieves alarm types. The first diamond-shaped judgment node categorizes alarms into ten types: SOS alarms, fall alarms, gas leak alarms, hypoglycemia alarms, hypertension alarms, hyperglycemia alarms, heart rate alarms, bed exit alarms, smoke alarms, and fall-related alarms. Each type is assigned a base priority score ranging from 20 to 100 points. Next, the "Check Elderly Person's Status" node checks if the elderly person is in an abnormal state such as a fall or unconsciousness; otherwise, no points are added. Then, the "Check Device Status" node deducts 10 points to reduce alarm credibility if the device is offline; otherwise, no points are added. Following this, the "Check Alarm Frequency" node checks the frequency of alarms; if the alarm is a recent recurring alarm, 15 points are added to increase its priority; otherwise, no points are added. Finally, all scores are normalized and mapped to a standard range of 0-100 to obtain the final priority score for this alarm, ending the process.

[0206] Figure 8 The alarm correlation analysis flowchart provided in the embodiments of this application is as follows: Figure 8 As shown, the association result data structure is first initialized, then grouped by elderly person, and the alarm groups of each elderly person are traversed. For all alarms of a single elderly person, they are grouped again according to a 5-minute time window. Then, each time window is traversed. First, the number of alarms in the window is checked. If the number is insufficient, it is skipped directly. If the number meets the standard, the association analysis stage is entered. First, the list of alarm types in the time window is obtained. Then, it is checked in turn to see if there are preset alarm combinations such as "hypertension + abnormal heart rate", "hypoglycemia + inactivity", "device offline + other alarms". After matching the corresponding combination, it is marked as an association type such as "cardiovascular system abnormality", "hypoglycemia causing abnormal movement", "device offline causing data abnormality" or "multiple alarms". Then, the association event is constructed and its severity is calculated. Finally, the association event is added to the association result array. After all elderly people and all time windows have been processed, the final association analysis result is returned.

[0207] This application enables standardized access for 12 types of devices (such as smart blood pressure monitors and fall detectors) through a device type dictionary, and supports automatic conversion of mainstream protocols such as MQTT and Constrained Application Protocol (CoAP), solving the protocol barrier problem caused by device heterogeneity. During device registration, the application automatically associates the elderly person's identity information, achieving a three-dimensional binding of "device-elderly person-scenario," which differs from the independent device management model in existing technologies.

[0208] This application constructs a unified dictionary containing over 20 alarm types, pioneering a five-dimensional classification method based on "emergency-health-device-behavior-location." For example, "heart rate alarm" is further subdivided into three levels of subcategories: "tachycardia / bradycardia / arrhythmia," achieving precise semantic mapping of alarm information. The standardized alarm data format includes 12 mandatory fields such as timestamp, device ID, senior ID, original value, standardized value, and threshold deviation, supporting cross-device data fusion analysis.

[0209] This application develops a priority calculation model based on multi-factor weighting: Priority Score = Base Priority (e.g., SOS alarm set to the highest level) + Elderly Status Adjustment Value (e.g., 20% weighting for elderly living alone) + Device Status Adjustment Value (e.g., 15% weighting for offline devices) + Alarm Frequency Adjustment Value (e.g., escalation triggered by 3 consecutive alarms). An "Elderly Vulnerability Index" is introduced as a dynamic adjustment factor. This index is calculated in real-time using historical health data (e.g., history of chronic diseases, recent number of falls) to achieve personalized priority determination.

[0210] This application employs a 5-minute time window combined with a spatial clustering algorithm to identify the correlation between multiple alarms for the same elderly person within the same time period. For example, when a fall alarm, sudden drop in heart rate, and offline alarm occur simultaneously, it is automatically classified as a "complex health crisis," triggering a three-level response mechanism. The association rule base supports dynamic updates, continuously optimizing association patterns through machine learning (such as adding "gas leak + abnormal movement of the locator" as a fire fault association).

[0211] This application integrates a three-tiered response channel encompassing audible and visual alarms, mobile push notifications, and community service dispatch, automating the entire process from alarm triggering to intelligent assignment, processing follow-up, and result feedback. For example, emergency alarms are directly pushed to children's mobile phones and the community first aid station, while non-emergency alarms are automatically queued and send SMS reminders to caregivers.

[0212] Figure 9 This is a schematic diagram of the alarm data processing device provided in an embodiment of this application. Figure 9 As shown, the alarm data processing device includes:

[0213] The first acquisition module 901 is used to acquire the original alarm data sent by the heterogeneous IoT device; wherein, the original alarm data is used to indicate that the heterogeneous IoT device has detected that the user is in at least one of a number of preset abnormal states, the attribute of at least one abnormal state, and the device identifier of the heterogeneous IoT device.

[0214] The first classification module 902 is used to classify the original alarm data according to the device type based on the preset device type dictionary to obtain the device type identifier; wherein, the device type identifier is used to represent the device type of heterogeneous IoT devices.

[0215] The second classification module 903 is used to classify the original alarm data according to the preset alarm type dictionary to obtain alarm type identifiers; wherein, the alarm type identifier is used to indicate the alarm type corresponding to the original alarm data.

[0216] The conversion module 904 is used to standardize the device type identifier and alarm type identifier to obtain standardized alarm data. The standardization conversion is used to convert the device type identifier and alarm type identifier into the same data format. The standardized alarm data is used to provide data input for preset alarm data processing to eliminate the abnormal state of the user.

[0217] In one possible design, the conversion module 904 includes:

[0218] The conversion unit is used to convert the device type identifier and alarm type identifier into a unified data format to obtain the converted device type identifier and the converted alarm type identifier.

[0219] The first integration unit is used to integrate the converted device type identifier and the converted alarm type identifier to obtain standardized alarm data.

[0220] In one possible design, the alarm data processing device further includes:

[0221] The matching module is used to match standardized alarm data with multiple preset alarm handling schemes to obtain the target alarm handling scheme corresponding to the maximum matching degree of the standardized alarm data.

[0222] The execution module is used to execute the target alarm handling plan to eliminate the abnormal state of the user.

[0223] In one possible design, the execution module includes:

[0224] The first acquisition unit is used to acquire a user feature profile; wherein, the user feature profile is used to represent multiple features of the user.

[0225] The adjustment unit is used to adjust multiple preset processing parameters in the target alarm processing scheme according to the user feature profile, to obtain the adjusted target alarm processing scheme, and to execute the adjusted target alarm processing scheme; wherein, the adjustment is used to adapt multiple processing parameters to multiple user features.

[0226] In one possible design, the alarm data processing device further includes:

[0227] The data acquisition module is used to collect execution feedback data of the target alarm handling scheme; the execution feedback data includes the result of abnormal state elimination, processing response time and user adaptability.

[0228] The scoring module is used to score the execution feedback data according to the preset evaluation index system to obtain the execution score of the target alarm handling solution.

[0229] The optimization module is used to iteratively optimize the parameters of the adjusted target alarm handling scheme based on the execution feedback data if the execution score is lower than the preset score threshold, so as to obtain the optimized alarm handling scheme and update the optimized alarm handling scheme to multiple alarm handling schemes.

[0230] In one possible design, the first classification module 902 includes:

[0231] The preprocessing unit is used to preprocess the original alarm data to obtain preprocessed original alarm data.

[0232] The initial matching unit is used to obtain the device identifier in the preprocessed original alarm data and perform an initial matching with the device type dictionary to obtain the initial matching device type identifier and the matching confidence of the initial matching device type identifier. The initial matching device type identifier is the identifier with the highest correlation with the device identifier in the device type dictionary, and the matching confidence is used to indicate the reliability of the initial matching device type identifier as the device type determination result of the original alarm data.

[0233] The first determining unit is used to determine the initial matching device type identifier as the device type identifier if the matching confidence level is greater than or equal to a preset confidence level threshold.

[0234] The combination unit is used to extract abnormal state attribute features from the original alarm data if the matching confidence is less than the confidence threshold, and combine the initial matching device type identifier with the abnormal state attribute features into a joint feature; wherein, the abnormal state attribute features are used to represent the attributes of at least one abnormal state.

[0235] The secondary matching unit is used to perform a secondary matching between the joint features and the device type dictionary to obtain the secondary matching device type identifier, and to determine the secondary matching device type identifier as the device type identifier; wherein, the secondary matching device type identifier is the identifier in the device type dictionary that has the highest correlation with the joint features.

[0236] In one possible design, the preprocessing unit includes:

[0237] The verification component is used to perform integrity and validity checks on the original alarm data to remove incomplete data with missing fields and invalid data with values ​​exceeding the preset reasonable range, thus obtaining the verified data.

[0238] The deduplication component is used to deduplicatize the verified data to remove redundant alarm data that are repeatedly sent by the same device and under the same abnormal state within a preset time threshold, thus obtaining the pre-processed original alarm data.

[0239] In one possible design, the second classification module 903 includes:

[0240] The feature matching unit is used to perform feature matching between the abnormal state attribute features and the alarm type dictionary to obtain multiple candidate alarm type identifiers and the attribute matching similarity corresponding to each candidate alarm type identifier.

[0241] The second integration unit is used to integrate candidate alarm type identifiers whose attribute matching similarity is greater than a preset similarity threshold to obtain a set of valid candidate alarm type identifiers.

[0242] The determination unit is used to determine the scene weight of each candidate alarm type identifier in the set of valid candidate alarm type identifiers based on the device type identifier corresponding to the original alarm data; wherein, the scene weight is used to represent the degree of contribution of the abnormal state attribute features collected by different devices to the judgment of the candidate alarm type identifier.

[0243] The calculation unit is used to calculate the comprehensive matching value corresponding to each candidate alarm type identifier based on the attribute matching similarity and the scene weight of each candidate alarm type identifier, and to determine the candidate alarm type identifier corresponding to the maximum comprehensive matching value as the alarm type identifier.

[0244] The alarm data processing device provided in this embodiment can perform... Figures 2 to 4 The technical solution of the alarm data processing method embodiment shown herein, its implementation principle and technical effect are similar to Figures 2 to 4 The alarm data processing method shown in the example is similar and will not be described in detail here.

[0245] Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application. Figure 10As shown, the electronic device 100 includes at least one processor 1001 and a memory 1002. The electronic device 100 also includes a communication component 1003. The processor 1001, the memory 1002, and the communication component 1003 are connected via a bus 1004.

[0246] In a specific implementation, at least one processor 1001 executes computer execution instructions stored in memory 1002, causing at least one processor 1001 to implement an alarm data processing method of the above embodiment.

[0247] The specific implementation process of processor 1001 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0248] In the above embodiments, it should be understood that the processor 1001 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0249] The memory 1002 may include high-speed RAM memory, and may also include non-volatile memory (NVM), such as at least one disk storage.

[0250] Bus 1004 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 1004 can be divided into address bus, data bus, control bus, etc. For ease of illustration, bus 1004 in the accompanying drawings of this application is not limited to only one bus or one type of bus.

[0251] The above description of the functions implemented by electronic devices and main control devices has introduced the solutions provided by the embodiments of the present invention. It is understood that, in order to implement the above functions, the electronic device or main control device includes hardware structures and / or software modules corresponding to the execution of each function. By combining the units and algorithm steps of the various examples described in the embodiments of the present invention, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of the embodiments of the present invention.

[0252] This application also provides a computer-readable storage medium storing computer-executable instructions. When executed by a processor, these instructions are used to implement an alarm data processing method as described in the above embodiments. In a specific implementation of the aforementioned alarm data processing method, each module can be implemented as a processor.

[0253] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0254] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in application-specific integrated circuits (ASICs). Alternatively, the processor and the readable storage medium can exist as discrete components in an electronic device or a host device.

[0255] This application also provides a computer program product, including a computer program, which, when executed by a processor, is used to implement an alarm data processing method according to the above embodiments.

[0256] The computer program is stored in a readable storage medium, and at least one processor can read the computer program from the readable storage medium and execute the computer program to perform the scheme provided in any of the above embodiments.

[0257] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.

[0258] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. 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 or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. An alarm data processing method, characterized in that, include: Acquire raw alarm data sent by heterogeneous IoT devices; wherein the raw alarm data is used to indicate that the heterogeneous IoT device has detected at least one abnormal state among a number of preset abnormal states of the user, the attributes of the at least one abnormal state, and the device identifier of the heterogeneous IoT device. The original alarm data is classified into device types according to a preset device type dictionary to obtain device type identifiers; wherein, the device type identifiers are used to represent the device types of the heterogeneous IoT devices; The original alarm data is classified into alarm types according to a preset alarm type dictionary to obtain alarm type identifiers; wherein, the alarm type identifier is used to indicate the alarm type corresponding to the original alarm data; The device type identifier and the alarm type identifier are standardized to obtain standardized alarm data; wherein, the standardization conversion is used to convert the device type identifier and the alarm type identifier into the same data format, and the standardized alarm data is used to provide data input for preset alarm data processing to eliminate the abnormal state of the user.

2. The alarm data processing method according to claim 1, characterized in that, The standardization conversion of the device type identifier and the alarm type identifier to obtain standardized alarm data includes: The device type identifier and the alarm type identifier are converted into a unified data format to obtain the converted device type identifier and the converted alarm type identifier; The converted device type identifier and the converted alarm type identifier are integrated to obtain the standardized alarm data.

3. The alarm data processing method according to claim 1, characterized in that, After standardizing the device type identifier and the alarm type identifier to obtain standardized alarm data, the process further includes: The standardized alarm data is matched with multiple preset alarm processing schemes to obtain the target alarm processing scheme corresponding to the maximum matching degree of the standardized alarm data; The target alarm handling scheme is executed to eliminate the abnormal state of the user.

4. The alarm data processing method according to claim 3, characterized in that, The execution of the target alarm processing scheme includes: Obtain a user feature profile; wherein the user feature profile is used to represent multiple features of the user; Based on the user feature profile, the preset processing parameters in the target alarm processing scheme are adjusted to obtain the adjusted target alarm processing scheme, and the adjusted target alarm processing scheme is executed; wherein, the adjustment is used to adapt the multiple processing parameters to the multiple features of the user.

5. The alarm data processing method according to claim 4, characterized in that, After executing the target alarm processing scheme, the method further includes: Collect execution feedback data of the target alarm handling scheme; wherein, the execution feedback data includes abnormal state elimination results, processing response time and user adaptability; The execution feedback data is scored according to a preset evaluation index system to obtain the execution score of the target alarm handling scheme; If the execution score is lower than the preset score threshold, the parameters of the adjusted target alarm handling scheme are iteratively optimized based on the execution feedback data to obtain an optimized alarm handling scheme, and the optimized alarm handling scheme is updated to the plurality of alarm handling schemes.

6. The alarm data processing method according to claim 1, characterized in that, The step of classifying the original alarm data according to a preset device type dictionary to obtain device type identifiers includes: The original alarm data is preprocessed to obtain preprocessed original alarm data; Obtain the device identifier from the preprocessed original alarm data, and perform an initial match between the device identifier and the device type dictionary to obtain the initial matching device type identifier and the matching confidence score of the initial matching device type identifier; wherein, the initial matching device type identifier is the identifier in the device type dictionary with the highest correlation to the device identifier, and the matching confidence score is used to indicate the reliability of the initial matching device type identifier as the device type determination result of the original alarm data; If the matching confidence level is greater than or equal to the preset confidence level threshold, the initial matching device type identifier is determined as the device type identifier; If the matching confidence is less than the confidence threshold, the abnormal state attribute features in the original alarm data are extracted, and the initial matching device type identifier and the abnormal state attribute features are combined into a joint feature; wherein, the abnormal state attribute features are used to represent the attributes of the at least one abnormal state; The joint feature is matched twice with the device type dictionary to obtain a secondary matching device type identifier, and the secondary matching device type identifier is determined as the device type identifier; wherein, the secondary matching device type identifier is the identifier in the device type dictionary that has the highest correlation with the joint feature.

7. The alarm data processing method according to claim 6, characterized in that, The preprocessing of the original alarm data to obtain preprocessed original alarm data includes: The original alarm data is subjected to integrity and validity checks to remove incomplete data with missing fields and invalid data with values ​​exceeding a preset reasonable range, thus obtaining the checked data. The verified data is deduplicated to remove redundant alarm data that are repeatedly sent by the same device and under the same abnormal state within a preset time threshold, thus obtaining the preprocessed original alarm data.

8. The alarm data processing method according to claim 6, characterized in that, The step of classifying the original alarm data according to a preset alarm type dictionary to obtain alarm type identifiers includes: The abnormal state attribute features are matched with the alarm type dictionary to obtain multiple candidate alarm type identifiers and the attribute matching similarity corresponding to each candidate alarm type identifier; Candidate alarm type identifiers with attribute matching similarity greater than a preset similarity threshold are integrated to obtain a set of valid candidate alarm type identifiers; Based on the device type identifier corresponding to the original alarm data, the scene weight of each candidate alarm type identifier in the set of valid candidate alarm type identifiers is determined; wherein, the scene weight is used to represent the degree of contribution of the abnormal state attribute features collected by different devices to the judgment of the candidate alarm type identifier; Based on the attribute matching similarity corresponding to each candidate alarm type identifier and the scene weight of each candidate alarm type identifier, a comprehensive matching value is calculated for each candidate alarm type identifier, and the candidate alarm type identifier corresponding to the maximum comprehensive matching value is determined as the alarm type identifier.

9. An alarm data processing device, characterized in that, include: The first acquisition module is used to acquire raw alarm data sent by heterogeneous IoT devices; wherein, the raw alarm data is used to indicate that the heterogeneous IoT device has detected at least one abnormal state among a number of preset abnormal states of the user, the attributes of the at least one abnormal state, and the device identifier of the heterogeneous IoT device. The first classification module is used to classify the original alarm data according to a preset device type dictionary to obtain a device type identifier; wherein, the device type identifier is used to represent the device type of the heterogeneous Internet of Things device; The second classification module is used to classify the original alarm data according to a preset alarm type dictionary to obtain an alarm type identifier; wherein, the alarm type identifier is used to indicate the alarm type corresponding to the original alarm data; The conversion module is used to standardize the device type identifier and the alarm type identifier to obtain standardized alarm data; wherein, the standardization conversion is used to convert the device type identifier and the alarm type identifier into the same data format, and the standardized alarm data is used to provide data input for preset alarm data processing to eliminate the abnormal state of the user.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; When the processor executes the computer execution instructions stored in the memory, it is used to implement the alarm data processing method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the alarm data processing method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, is used to implement the alarm data processing method as described in any one of claims 1 to 8.

Images