Cross-platform equipment alarm information acquisition method

Abstract

The invention discloses a cross-platform equipment alarm information acquisition method, and particularly relates to the field of information acquisition, the method adapts to different platform equipment through a standardized interface layer, the interface layer comprises an equipment connection protocol library and a unified data conversion unit, and an original log of the equipment is analyzed in real time based on a preset alarm rule template; extracting key information and generating an alarm event object; converting the alarm key information into an alarm event in a unified format, and adding equipment identification metadata; alarm events are asynchronously transmitted to a central processing server by utilizing a high-reliability message queue, and the transmission reliability is guaranteed by adopting various mechanisms; performing duplicate removal, priority classification and persistent storage on the alarm events in the central server, and ensuring data consistency by adopting a hierarchical storage architecture; the whole processing link is provided with perfect monitoring indexes, and automatic capacity expansion and contraction are achieved.

Description

Technical Field

[0001] The present invention relates to the technical field of information collection, and more specifically, to a cross-platform device alarm information collection method. Background Art

[0002] With the rapid development of information technology, various electronic devices have been widely used in various fields, such as industrial automation, smart homes, intelligent transportation, data centers, etc. The stable operation of these devices is crucial to ensuring the normal operation of production and life. However, various failures or abnormal conditions may occur during the operation of the equipment, such as hardware failures, software errors, network problems, insufficient resources, etc. Timely detection and processing of these alarm information is of great significance for preventing equipment failures, reducing losses, and improving equipment operation efficiency and reliability.

[0003] However, it still has some shortcomings in actual use. For example, traditional alarm information collection systems are often designed for specific manufacturers or protocols, and are difficult to be compatible with diverse data sources such as PLCs, IoT devices, and cloud services, resulting in serious data fragmentation and low alarm processing efficiency. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, an embodiment of the present invention provides a cross-platform device alarm information collection method to solve the problems raised in the above-mentioned background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] Step A1: Adapting devices of different platforms through a standardized interface layer, wherein the standardized interface layer includes a device connection protocol library and a unified data conversion unit;

[0007] Step A2: Based on the preset alarm rule template, the original log output by the device is analyzed in real time to extract the key alarm information;

[0008] Step A3: Convert the extracted alarm key information into an alarm event in a unified format and attach device identification, timestamp, and platform type metadata;

[0009] Step A4: asynchronously transmitting the alarm event to the central processing server via the message queue;

[0010] Step A5: De-duplication, priority classification and persistent storage of alarm events are performed in the central processing server.

[0011] Preferably, in step A1, unified access of cross-platform devices is achieved by constructing a standardized interface layer. The interface layer adopts a modular design, and the core includes a device connection protocol library and a unified data conversion unit; the device connection protocol library integrates multiple types of industrial protocols and cloud platform communication protocols, and calls platform-specific driver plug-ins on demand through a dynamic loading mechanism. The plug-in has a built-in protocol parsing engine and session management function to ensure stable communication with heterogeneous devices.

[0012] Preferably, in step A2, the system parses the original log output by the device in real time based on a preset alarm rule template, and loads a configurable alarm rule template library through a rule engine. The template library supports multi-dimensional rule definition, including regular expression-based log pattern matching (such as matching error code "ERR[0-9]{4}" or abnormal keywords "Failure", "Critical"), dynamic threshold triggering based on device indicators (such as CPU usage exceeding 90% for 5 minutes or memory leakage rate >1MB / s), and compound alarm conditions that rely on multi-log association (such as the same device continuously triggering "temperature limit exceeded" and "fan stop" events within 10 seconds); a streaming processing architecture is used to parse the original logs one by one, first using a pre-processing unit to clean the logs (removing garbled characters, supplementing missing timestamps, etc.), and then using a syntax analyzer to identify the log structure. For unstructured logs, NLP technology is applied to extract entity relationships.

[0013] Preferably, in step A3, the system standardizes and encapsulates the key alarm information extracted in step A2, first converting the format through the unified alarm event model. The model uses JSON Schema to define core fields, including:

[0014] Basic fields: alarm code, severity level (mapped to urgency by numerical value 1-5), original message;

[0015] Device context: device identification, generated by combining the device type and unique ID (e.g., sn=ABCD-1234), and platform type;

[0016] Spatiotemporal metadata: UTC timestamp accurate to milliseconds, time zone offset

[0017] Derived indicator: If the alarm contains a numerical parameter, the percentage deviation from the threshold is calculated;

[0018] During the conversion process, the metadata injection engine automatically adds device topology information and geographic location data; for normalized fields, the mapping formula is called to perform encoding conversion.

[0019] Preferably, in step A4, the system implements asynchronous transmission of alarm events through a highly reliable message queue, and adopts a producer-consumer model to ensure reliable delivery of cross-platform data; the message queue is based on a distributed publish / subscribe architecture, supports multiple transmission protocols, and adopts an exponential backoff retransmission algorithm to ensure transmission reliability. The retransmission time interval calculation method is specifically as follows:

[0020] t r =min(t max ,t0×2 m-1 )

[0021] Among them, t r Indicates the current retry interval, t max It represents the maximum interval threshold, m represents the current number of retries, and t0 represents the initial retry interval;

[0022] Before sending, the message producer compresses the alarm event in binary encoding, compresses the JSON format using the Zstandard algorithm, and appends a CRC-32 checksum to the message header. The message queue adopts a priority partitioning design, automatically routing it to topics of different priorities based on the severity level S1-S4 of the alarm event:

[0023] Emergency queue (S1-S2): Memory resident mode, ensuring end-to-end latency < 100ms

[0024] Normal queue (S3-S4): persistent disk storage, allowing latency < 1s;

[0025] The system uses a sliding window flow control mechanism to prevent network congestion, and the window size is adjusted dynamically.

[0026] Preferably, in step A5, after the central processing server receives the alarm event transmitted by the message queue, it first performs multi-dimensional deduplication processing and uses a composite key comparison algorithm to generate an event fingerprint, which is composed of the device hardware hash value, the normalized alarm code and the first trigger time window, to ensure that repeated alarms of the same device can be accurately identified; the deduplication unit uses a Bloom filter to make a quick prediction, and then uses a precise B+ tree index to retrieve the historical library for comparison of repeated events, and supports manually configured suppression rules, such as "only retain the highest severity instance of the same alarm within 10 minutes of the same device"; the event that completes deduplication enters the dynamic priority classification stage, and automatically increases the priority of the associated alarm according to the preset static level combined with real-time topology analysis - when the core switch fails, the associated alarm weight of its downstream device will be multiplied by a 1.5 times coefficient, and the cascade risk probability is calculated through the Bayesian network, and finally a comprehensive score including the basic priority and the dynamic adjustment value is generated.

[0027] The technical effects and advantages of the present invention are as follows:

[0028] The present invention adapts to multi-platform devices through a standardized interface layer, integrates protocol libraries and data conversion modules to achieve unified access; parses device logs in real time, extracts alarm information based on rule templates, encapsulates it into standardized events and attaches metadata; uses message queues for asynchronous transmission to a central server, supports priority partitioning and breakpoint resumption, and dynamically adjusts the buffer size; the central server deduplicates and prioritizes events and stores them in layers, with hot data stored in Redis, warm data in Elasticsearch, and cold data archived in object storage to ensure data consistency and high availability; the present invention monitors key indicators throughout the entire process to achieve efficient alarm processing and storage optimization, and effectively solves the protocol fragmentation problem of traditional solutions. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 Schematic diagram of the method of the present invention. DETAILED DESCRIPTION

[0030] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0031] See also Figure 1 As shown, the present invention provides a cross-platform device alarm information collection method, comprising the following steps:

[0032] Step A1: Adapting devices of different platforms through a standardized interface layer, wherein the standardized interface layer includes a device connection protocol library and a unified data conversion unit;

[0033] In step A1, unified access of cross-platform devices is achieved by building a standardized interface layer. The interface layer adopts a modular design, and its core includes a device connection protocol library and a unified data conversion unit. The device connection protocol library integrates multiple types of industrial protocols and cloud platform communication protocols, and calls platform-specific driver plug-ins on demand through a dynamic loading mechanism. The plug-in has a built-in protocol parsing engine and session management function to ensure stable communication with heterogeneous devices.

[0034] The unified data conversion unit implements normalized processing of raw data based on the intermediate data model. It first performs syntax parsing on heterogeneous data such as binary streams, JSON or XML input by the device, extracts the effective load, and converts device-specific parameters (such as PLC register addresses, cloud service indicator names) into standardized data point identifiers according to predefined field mapping rules. At the same time, the metadata of the original data (such as collection timestamps, equipment manufacturer codes) is retained to support traceability. The unit also integrates a data verification mechanism to verify data integrity through pattern matching, trigger re-collection or alarm processes for data in abnormal formats, and finally outputs structured data that conforms to the unified schema for downstream processing. The standardized interface layer maintains long links through heartbeat detection and connection pool management.

[0035] Step A2: Based on the preset alarm rule template, the original log output by the device is analyzed in real time to extract the key alarm information;

[0036] In step A2, the system parses the raw logs output by the device in real time based on preset alarm rule templates. The system loads a configurable alarm rule template library through the rule engine. This template library supports multi-dimensional rule definition, including regular expression-based log pattern matching (such as matching error codes "ERR[0-9]{4}" or abnormal keywords "Failure" and "Critical"), dynamic threshold triggering based on device indicators (such as CPU usage exceeding 90% for 5 consecutive minutes or memory leakage rate >1MB / s), and compound alarm conditions that rely on multi-log association (such as the same device triggering "temperature limit exceeded" and "fan stopped" events continuously within 10 seconds). The system uses a streaming processing architecture to parse the raw logs one by one. The preprocessing unit first cleans the logs (removing garbled characters and supplementing missing timestamps), then uses a parser to identify the log structure. For unstructured logs, natural language processing (NLP) technology is used to extract entity relationships.

[0037] When an event matching a rule is detected, the rule engine triggers the alarm generation process: first, it extracts key fields, then automatically labels the alarm level according to the severity matrix configured by the rule, and associates it with solution suggestions in the knowledge base. For complex alarms that require contextual judgment, the system starts the correlation analysis unit, which retrieves logs from similar devices through a sliding time window to identify whether the cross-device propagation conditions are met. Finally, it generates an alarm event object containing the complete context. In addition to the basic fields, this object also includes the original log fragment, correlation rule ID, and diagnostic fingerprint.

[0038] Step A3: Convert the extracted alarm key information into an alarm event in a unified format and attach device identification, timestamp, and platform type metadata;

[0039] In step A3, the system standardizes and encapsulates the key alarm information extracted in step A2. First, it converts the format through the unified alarm event model. The model uses JSON Schema to define core fields, including:

[0040] Basic fields: alarm code, severity level (mapped to urgency by numerical value 1-5), original message;

[0041] Device context: device identification, generated by combining the device type and unique ID (e.g., sn=ABCD-1234), and platform type;

[0042] Spatiotemporal metadata: UTC timestamp accurate to milliseconds, time zone offset

[0043] Derived indicator: If the alarm contains a numerical parameter, the percentage deviation from the threshold is calculated;

[0044] During the conversion process, the metadata injection engine automatically adds device topology information and geographic location data; for normalized fields, the mapping formula is called to perform encoding conversion:

[0045] standard_code=M(vendor_code)

[0046] Where standard_code represents the standardized code, M represents the mapping function, and vendor_code represents the original manufacturer code;

[0047] M:VendorCode→IEC62443

[0048] Among them, VendorCode represents the original manufacturer code set, and IEC62443 represents the standardized coding system;

[0049] The final generated alarm event is verified by the data consistency verification unit to ensure the integrity of the required fields and the legality of the value range. Events that fail the verification will trigger the backtracking process to re-extract data; all events are verified as

[0050] 256 (n-1-i) It is represented as the weight of the i-th byte, and E is represented as the standard polynomial modulus of CRC32;

[0051] The output event stream is transmitted in parallel to the downstream system through the device_id hash sharding strategy to ensure load balancing under high throughput.

[0052] Step A4: asynchronously transmitting the alarm event to the central processing server via the message queue;

[0053] In step A4, the system implements asynchronous transmission of alarm events through a highly reliable message queue, and adopts a producer-consumer model to ensure reliable delivery of cross-platform data. The message queue is based on a distributed publish / subscribe architecture, supports multiple transmission protocols, and adopts an exponential backoff retransmission algorithm to ensure transmission reliability. The retransmission time interval calculation method is specifically as follows:

[0054] t r =min(t max ,t0×2 m-1 )

[0055] Among them, t r Indicates the current retry interval, t max It represents the maximum interval threshold, m represents the current number of retries, and t0 represents the initial retry interval;

[0056] Before sending, the message producer compresses the alarm event in binary encoding, compresses the JSON format using the Zstandard algorithm, and appends a CRC-32 checksum to the message header. The message queue adopts a priority partitioning design, automatically routing it to topics of different priorities based on the severity level S1-S4 of the alarm event:

[0057] Emergency queue (S1-S2): Memory resident mode, ensuring end-to-end latency < 100ms

[0058] Normal queue (S3-S4): persistent disk storage, allowing latency < 1s;

[0059] The system uses a sliding window flow control mechanism to prevent network congestion, and the window size is dynamically adjusted:

[0060]

[0061] Among them, W represents the window size, W max It represents the maximum window, H represents the current queue depth, and D represents the queue depth;

[0062] The transport layer implements breakpoint resuming, with each message carrying a globally unique sequence number. The consumer maintains a red-black tree-structured message cache to detect out-of-order and loss. When the network is interrupted, the producer uses a local ring buffer to temporarily store unconfirmed messages. The buffer size is adaptively adjusted based on the device's memory capacity.

[0063] K=min(Mem free ×0.2,100MB)

[0064] Among them, K represents the buffer size, Mem free Indicates the remaining memory capacity of the device, with 100MB representing the maximum buffer threshold;

[0065] When the central server consumes messages, it first distributes the messages to multiple processing threads through consistent hashing:

[0066] WorkerID=Hash(DeviceID)modN workers

[0067] Among them, WorkerID represents the target working node number, Hash(DeviceID) represents the hash value of the device ID, N workers Expressed as the total number of working nodes;

[0068] It also monitors the number of backlog messages Q in each partition in real time, and automatically triggers elastic expansion of consumers when it detects that Q exceeds the threshold. Message trajectory logs are recorded throughout all transmission processes, including indicators such as end-to-end latency, transmission success rate, and network jitter.

[0069] Step A5: De-duplication, priority classification, and persistent storage of alarm events in the central processing server;

[0070] In step A5, after the central processing server receives the alarm event transmitted by the message queue, it first performs multi-dimensional deduplication processing and uses a composite key comparison algorithm to generate an event fingerprint. The fingerprint is composed of the device hardware hash value, the normalized alarm code and the first trigger time window, ensuring that repeated alarms of the same device can be accurately identified; the deduplication unit uses a Bloom filter to quickly predict, and then uses a precise B+ tree index to search the historical library for comparison for repeated events, while supporting manually configured suppression rules, such as "only retain the highest severity instance of the same alarm within 10 minutes of the same device"; the event after deduplication enters the dynamic priority classification stage, and automatically increases the priority of the associated alarm based on the preset static level combined with real-time topology analysis - when the core switch fails, the weight of the associated alarm of its downstream device will be multiplied by a 1.5 times coefficient, and the cascade risk probability is calculated through the Bayesian network, and finally a comprehensive score including the basic priority and the dynamic adjustment value is generated;

[0071] The persistent storage layer uses a tiered storage architecture. Hot data is stored in a distributed in-memory database, Redis Cluster, using a hybrid storage strategy of time sharding and hash partitioning, supporting over 100,000 concurrent writes per second. Warm data (within 30 days) is written to an Elasticsearch cluster, where a multi-level index is created based on "device type - date" and column-based compression is enabled. Cold data is archived to object storage using the Apache Parquet format, and aggregated statistics (such as hourly counts of various alarm types) are generated to accelerate historical queries.

[0072] The stored procedure strictly adheres to the ACID principle and ensures data consistency across storage engines through a two-phase commit protocol. Each write generates a WAL log for fault recovery and automatically triggers a backup task to asynchronously copy critical data to an off-site disaster recovery center.

[0073] The retention period is automatically adjusted based on the alarm status and business importance tags, and storage optimization recommendations are generated. The entire processing chain is equipped with comprehensive monitoring indicators, including core indicators such as deduplication compression rate, classification decision latency, and storage throughput, which are collected in real time through Prometheus and trigger automatic expansion and contraction.

[0074] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A cross-platform device alarm information collection method, characterized in that: include: Step A1: Adapting devices of different platforms through a standardized interface layer, wherein the standardized interface layer includes a device connection protocol library and a unified data conversion unit; Step A2: Based on the preset alarm rule template, the original log output by the device is analyzed in real time to extract the key alarm information; Step A3: Convert the extracted alarm key information into an alarm event in a unified format and attach device identification, timestamp, and platform type metadata; Step A4: asynchronously transmitting the alarm event to the central processing server via the message queue; Step A5: De-duplication, priority classification and persistent storage of alarm events are performed in the central processing server.

2. The cross-platform device alarm information collection method according to claim 1, characterized in that: In step A1, unified access of cross-platform devices is achieved by building a standardized interface layer. The interface layer adopts a modular design, and the core includes a device connection protocol library and a unified data conversion unit; the device connection protocol library integrates multiple types of industrial protocols and cloud platform communication protocols, and calls the platform-specific driver plug-in on demand through a dynamic loading mechanism. The plug-in has a built-in protocol parsing engine and session management.

3. The cross-platform device alarm information collection method according to claim 1, characterized in that: In step A2, the system parses the raw logs output by the device in real time based on preset alarm rule templates. The system then loads a configurable alarm rule template library through the rule engine. This template library supports multi-dimensional rule definition, including regular expression-based log pattern matching, dynamic threshold triggering based on device indicators, and compound alarm conditions that rely on multi-log correlation. A streaming processing architecture is used to parse raw logs one by one. The logs are first cleaned by a preprocessing unit, and then a parser is used to identify the log structure. For unstructured logs, natural language processing (NLP) technology is used to extract entity relationships. When an event matching a rule is detected, the rule engine triggers the alarm generation process: first, it extracts key fields, then automatically labels the alarm level according to the severity matrix configured by the rule, and associates it with solution suggestions in the knowledge base. For complex alarms that require contextual judgment, the system starts the correlation analysis unit, which retrieves logs from similar devices through a sliding time window to identify whether the cross-device propagation conditions are met. Finally, it generates an alarm event object containing the complete context. In addition to the basic fields, this object also includes the original log fragment, correlation rule ID, and diagnostic fingerprint.

4. The cross-platform device alarm information collection method according to claim 1, characterized in that: In step A3, the system standardizes and encapsulates the key alarm information extracted in step A2. First, it converts the format through the unified alarm event model, which uses JSON Schema to define core fields. During the conversion process, the metadata injection engine automatically adds device topology information and geographic location data; for normalized fields, the mapping formula is called to perform encoding conversion: standard_code=M(vendor_code) Where standard_code represents the standardized code, M represents the mapping function, and vendor_code represents the original manufacturer code; M:VendorCode→IEC62443 Among them, VendorCode represents the original manufacturer code set, and IEC62443 represents the standardized coding system.

5. The cross-platform device alarm information collection method according to claim 4, characterized in that: All events are serialized in a compressed binary format with a version identifier and CRC32 checksum appended to the header; Among them, CRC32 represents a 32-bit cyclic redundancy check code, byte i The i-th byte of the input data, 256 (n-1-i) is represented as the weight of the i-th byte, and E is represented as the standard polynomial modulus of CRC32.

6. The cross-platform device alarm information collection method according to claim 1, characterized in that: In step A4, asynchronous transmission of alarm events is achieved through a highly reliable message queue, and a producer-consumer model is adopted to ensure reliable delivery of cross-platform data. The message queue is based on a distributed publish / subscribe architecture and uses an exponential backoff retransmission algorithm for calculation. The retransmission time interval is calculated as follows: t r =min(t max ,t0×2 m-1 ) Among them, t r Indicates the current retry interval, t max It represents the maximum interval threshold, m represents the current number of retries, and t0 represents the initial retry interval.

7. The cross-platform device alarm information collection method according to claim 6, characterized in that: In the transport layer, each message carries a globally unique sequence number. The consumer maintains a red-black tree-structured message cache to detect disorder and loss. When the network is interrupted, the producer uses a local ring buffer to temporarily store unconfirmed messages. The buffer size is adaptively adjusted according to the device memory capacity: K=min(Mem free ×0.2,100MB) Among them, K represents the buffer size, Mem free Indicates the remaining memory capacity of the device, with 100MB representing the maximum buffer threshold; When the central server consumes messages, it first distributes the messages to multiple processing threads through consistent hashing: WorkerID=Hash(DeviceID)modN workers Among them, WorkerID represents the target working node number, Hash(DeviceID) represents the hash value of the device ID, N workers Expressed as the total number of worker nodes.

8. The cross-platform device alarm information collection method according to claim 1, characterized in that: In step A5, after the central processing server receives the alarm event transmitted by the message queue, it first performs multi-dimensional deduplication processing and uses a composite key comparison algorithm to generate an event fingerprint, which is composed of the device hardware hash value, the normalized alarm code and the first trigger time window; the deduplication unit uses a Bloom filter to make a quick prediction, and then uses a precise B+ tree index to search the historical library for comparison for repeated events; the events that have completed deduplication enter the dynamic priority classification stage, and automatically increase the priority of the associated alarms based on the preset static level combined with real-time topology analysis - when the core switch fails, the associated alarm weight of its downstream device will be multiplied by a 1.5 times coefficient, and the cascade risk probability is calculated through a Bayesian network, and finally a comprehensive score including the basic priority and the dynamic adjustment value is generated.

Images