Logic alarm implementation method, system and equipment and storage medium

By using a logic alarm method based on configurable rules and dynamic time parsing, the problems of long development cycles, high maintenance costs, and incomplete alarm processes caused by hard-coded logic in existing technologies are solved. This achieves flexible and accurate alarm functions, which are applicable to industrial monitoring software in multiple industries.

CN121833397APending Publication Date: 2026-04-10NARI NANJING CONTROL SYSTEM CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-18
Publication Date
2026-04-10

AI Technical Summary

Technical Problem

Existing industrial monitoring software's alarm functions suffer from hard-coded logic, resulting in long development cycles, high maintenance costs, insufficient flexibility in time configuration, poor robustness in data processing, and incomplete alarm processes, failing to meet the refined operation and maintenance needs of industrial scenarios.

Method used

By configuring rules and using dynamic time parsing, flexible logical alarms are achieved, including configuring logical alarm definition tables, dynamic time parsing, multi-component statistical queries, and alarm closed-loop management. Multi-channel notifications are supported, enhancing the software's flexibility and robustness.

Benefits of technology

It improves software maintenance efficiency, enhances alarm accuracy and scalability, reduces operation and maintenance response time, and is suitable for industrial monitoring software in multiple industries.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121833397A_ABST
    Figure CN121833397A_ABST
Patent Text Reader

Abstract

The invention discloses a logic alarm implementation method, system and device and a storage medium, and the method comprises the steps: configuring a logic alarm definition table in a real-time library of a monitoring platform, starting a logic alarm program, carrying out the dynamic time analysis of each pamnstart time and pamnstop time of a starting rule, and carrying out the dynamic time analysis of the pamnstart time and the pamnstop time of the starting rule according to an analyzed time interval, a monitoring object ID and a statistical item. The statistical value of each component is inquired, a preset alarm logic type comparison table is matched according to the alarm type of the alarm rule, and a corresponding logic judgment formula is obtained for calculation; the system comprises a configuration logic alarm definition module, an alarm rule recording module, a dynamic time analysis module, a statistical value query module, a logic judgment module and an alarm triggering and closed loop management module. According to the method, alarm rule configuration, time analysis dynamic and logic type expandability are realized, and the flexibility, accuracy and maintenance efficiency of alarm in an industrial monitoring scene are improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of industrial monitoring software technology, and in particular to a logical alarm implementation method, system, device and storage medium. Background Technology

[0002] In the field of industrial monitoring software, alarm functionality is a core module for ensuring stable equipment operation and timely detection of anomalies. Existing industrial monitoring software alarm functions suffer from the following technical deficiencies: Hard-coded alarm logic: Traditional software alarm logic is often implemented through hard-coded code (e.g., determining if temperature exceeds a threshold). Adding multi-parameter correlation logic (e.g., alarms for deviations between main and branch water meter usage) requires modifying the program code and redeploying, resulting in long development cycles and high maintenance costs. Insufficient flexibility in time configuration: Alarm statistics often use fixed time intervals (e.g., "00:00-23:59 daily"). Adjusting to dynamic intervals such as "from the 1st of last month to the present" or "same period two years ago" requires modifying the time parsing code, making quick adaptation through configuration impossible. Poor robustness in data processing: Failure to consider scenarios such as abnormal time configurations (e.g., dates greater than 31) and missing data can easily lead to incorrect statistical values ​​or program errors, affecting alarm accuracy. Incomplete alarm process: Only alarm triggering functionality is implemented, lacking modules for alarm level classification, repeated alarm suppression, and closed-loop alarm management, failing to meet the refined operation and maintenance needs of industrial scenarios. To address the aforementioned issues, there is an urgent need for a software implementation method based on configurable rules, supporting dynamic time parsing, and possessing a complete alarm process, in order to improve the flexibility, robustness, and maintainability of alarm functions in industrial monitoring software. Summary of the Invention

[0003] Purpose of the invention: The purpose of this invention is to provide a logical alarm implementation method, system, device, and storage medium; used to achieve flexible and accurate logical alarms through configurable rules and dynamic time parsing.

[0004] Technical solution: The logic alarm implementation method of the present invention includes the following steps:

[0005] S1: Configure a logical alarm definition table in the real-time library of the monitoring platform. The logical alarm definition table includes an alarm identifier field, a component parameter field, a dynamic time field, an alarm logic field, and a status field.

[0006] S2: Start the logical alarm program. The program reads the alarm rule records in the logical alarm definition table where alarm_status is enabled and stores them in the memory cache.

[0007] S3: The logic alarm program performs dynamic time parsing of pam_n_starttime and pam_n_stoptime for each enabled rule;

[0008] S4: The logic alarm program calls the statistical interface of the real-time library of the monitoring platform to query the statistical values ​​of each component based on the parsed time interval, monitoring object ID and statistical items.

[0009] S5: The logic alarm program matches the alarm logic type lookup table with the alarm rule's alarm_type, obtains the corresponding logic judgment formula, and substitutes the statistical values ​​of each component and alarm_limit into the formula for calculation.

[0010] S6: If the calculation result meets the alarm conditions, the program will write the alarm information to the alarm log and trigger an alarm notification; if it does not meet the conditions, the program will continue to process the next activation rule.

[0011] Further, in step S1, the alarm identifier field includes alarm ID number, alarm name, and the plant / station to which it belongs; the component parameter field includes the number of valid parameters, component n (n=1~4), and component n statistical items; the dynamic time field includes the component n statistical start time and component n statistical end time; the alarm logic field includes alarm logic type, alarm limit, and alarm content; and the status field includes alarm status and last modified definition time.

[0012] Furthermore, in step S1, the domain type of component n is int64 and supports multiple references to the monitoring object ID set. The number of valid parameters ranges from 1 to 4, corresponding to the number of valid components from pam_1 to pam_4. The range of valid parameters can be expanded in the logical alarm definition table.

[0013] Furthermore, in step S3, the dynamic time parsing follows the colon-separated format of "year:month:day", where the year / month / day values ​​are non-negative integers to represent specific times, negative integers to represent the corresponding unit before the current time, and 0 to represent the corresponding unit of the current time. After parsing, the default start time is "00:00:00" and the default end time is "23:59:59" or the current time. When the date field is greater than 31, the last day of the corresponding month is automatically taken.

[0014] Furthermore, the statistical interface in step S4 supports the statistical dimensions of summation, average, maximum, and interval difference, and includes a data missing completion strategy: when the monitored object has missing data within a time interval, the average of adjacent time periods is used to complete the data or the missing data status is marked and a data anomaly prompt is triggered.

[0015] Furthermore, the alarm logic type lookup table in step S5 is an expandable lookup table, which includes logic identifier, logic formula description, and applicable scenario fields. When adding alarm logic, it is entered into the lookup table after syntax validation, without the need to modify the logic alarm program code.

[0016] Furthermore, the alarm notification in step S6 includes a multi-channel notification mechanism, supporting SMS, email, and pop-up notifications from the industrial monitoring platform. The notification content carries alarm_id, alarm name, statistical time interval, statistical values ​​of each component, and reasons for deviation.

[0017] The logic alarm implementation system of the present invention includes:

[0018] The configuration logic alarm definition module is used to configure the logic alarm definition table in the real-time library of the monitoring platform. The logic alarm definition table includes alarm identifier field, component parameter field, dynamic time field, alarm logic field and status field.

[0019] The alarm rule recording module is used to start the logical alarm program. The program reads the alarm rule records in the logical alarm definition table where alarm_status is enabled and stores them in the memory cache.

[0020] The dynamic time parsing module is used by the logic alarm program to perform dynamic time parsing of pam_n_starttime and pam_n_stoptime for each enabling rule;

[0021] The statistical value query module is used by the logic alarm program to call the statistical interface of the real-time library of the monitoring platform to query the statistical values ​​of each component based on the parsed time interval, monitoring object ID and statistical items.

[0022] The logic judgment module is used to match the alarm logic type lookup table with the alarm rule's alarm_type, obtain the corresponding logic judgment formula, and substitute the statistical values ​​of each component and alarm_limit for calculation.

[0023] The alarm triggering and closed-loop management module is used to determine whether the alarm conditions are met. If they are met, the program writes the alarm information to the alarm log and triggers an alarm notification; if not, it continues to process the next activation rule.

[0024] Furthermore, the processor implements the logical alarm implementation method when executing the program.

[0025] Furthermore, the computer program is designed to implement the logical alarm implementation method at runtime.

[0026] Beneficial effects: Compared with the prior art, the present invention has the following significant advantages:

[0027] (1) Improved flexibility: Through configurable rules and dynamic time parsing, new alarm logic can be added without modifying the code, and the time range can be quickly adapted to scenarios such as "current month, previous month, and specified year", thus improving software maintenance efficiency;

[0028] (2) Enhanced robustness: The software has built-in time validity verification and data missing completion strategies to avoid invalid statistics and program errors, and improve alarm accuracy;

[0029] (3) Scalability optimization: The alarm logic type lookup table supports unlimited expansion, and the number of components can be expanded to more than 4 through configuration (the table structure needs to be adjusted) to adapt to more complex business scenarios;

[0030] (4) Improved operation and maintenance efficiency: Complete alarm closed-loop management and multi-channel notification reduce the response time of operation and maintenance personnel and improve alarm processing efficiency;

[0031] (5) High versatility: It supports multiple real-time libraries such as MySQL, InfluxDB, and DM, and can be deployed on operating systems such as Windows and Linux. It is suitable for industrial monitoring software in multiple industries such as energy, manufacturing, and water. Attached Figure Description

[0032] Figure 1 This is a flowchart of the logic alarm implementation method of the present invention. Detailed Implementation

[0033] The technical solution of the present invention will be further described below with reference to the accompanying drawings.

[0034] like Figure 1 As shown, the logical alarm implementation method of the present invention includes the following steps:

[0035] S1: Configure a logical alarm definition table in the real-time database of the monitoring platform. This logical alarm definition table must include at least an alarm identifier field, component parameter field, dynamic time field, alarm logic field, and status field. Specifically, the alarm identifier field includes alarm_id (alarm ID), alarm_name (alarm name), and Fac_id (belonging plant / station). The component parameter field includes pam_num (number of valid parameters), pam_n (component n, n=1~4), and pam_n_stattype (statistical item for component n). The dynamic time field includes pam_n_starttime (start time for component n statistics) and pam_n_stop. The alarm logic fields include alarm_type (alarm logic type), alarm_limit (alarm limit), and alarm_content (alarm content); the status fields include alarm_status (alarm status) and Last_modify_define_time (last modification definition time); the field type of pam_n is int64 and supports multiple references to the monitoring object ID set; the value range of pam_num is 1~4, corresponding to the number of valid components from pam_1 to pam_4; the value range of pam_num can be expanded in the logical alarm definition table.

[0036] S2: Start the logical alarm program. The program reads the alarm rule records in the logical alarm definition table where alarm_status is enabled and stores them in the memory cache.

[0037] S3: The program performs dynamic time parsing on pam_n_starttime and pam_n_stoptime for each enabling rule. The dynamic time parsing follows the colon-separated format of "year:month:day", where the year / month / day values ​​are non-negative integers to represent the specific time, negative integers to represent the corresponding unit backward from the current time, and 0 to represent the corresponding unit of the current time. After parsing, the default start time is "00:00:00" and the default end time is "23:59:59" or the current time (selecting today's time). When the date field is greater than 31, the last day of the corresponding month is automatically taken.

[0038] Dynamic time parsing does not support the "0:-1:0" (today last month) format to avoid statistical deviations caused by differences in the number of days in each month; and time validity checks are added during the parsing process to ensure that the end time is after the start time and less than the current date.

[0039] S4: The program calls the statistical interface of the real-time library of the monitoring platform to query the statistical values ​​of each component based on the parsed time interval, pam_n (monitoring object ID) and pam_n_stattype (statistical item). The statistical interface supports statistical dimensions such as summation, average, maximum, and interval difference, and includes a data missing completion strategy: when the monitored object has missing data within the time interval, it uses the average of adjacent time periods to complete the data or marks the missing data status and triggers a data anomaly prompt.

[0040] S5: The program matches the alarm logic type lookup table according to the alarm rule's alarm_type, obtains the corresponding logic judgment formula, and substitutes the statistical values ​​of each component and alarm_limit into the formula for calculation.

[0041] The alarm logic type lookup table is an expandable lookup table that includes fields such as alarm_type (logic identifier), logic formula description, and applicable scenarios. When adding alarm logic, it is entered into the lookup table after syntax validation, without needing to modify the logic alarm program code.

[0042] S6: If the calculation result meets the alarm conditions, the program will write the alarm information to the alarm log and trigger an alarm notification; if it does not meet the conditions, the program will continue to process the next activation rule. The alarm notification includes a multi-channel notification mechanism, supporting SMS, email, and pop-up notifications from the industrial monitoring platform. The notification content includes alarm_id, alarm name, statistical time interval, statistical values ​​of each component, and reason for deviation.

[0043] This invention is based on a software process design of "configuration-parsing-statistics-judgment-closed loop". Its core components include logical alarm definition table configuration, dynamic time parsing, multi-component statistical querying, extensible logical judgment, and alarm closed-loop management. The specific steps are as follows:

[0044] 1. Configure the logical alarm definition table

[0045] Create a structured "Logical Alarm Definition Table" in the real-time database of the monitoring platform (such as MySQL, InfluxDB, or DM) as the configuration carrier for alarm rules. The table structure and field functions are shown in the table below. All fields can be visually edited through the software configuration interface without modifying the program code.

[0046] Serial Number Domain English name Domain Chinese name Domain type Software Function Description 1 alarm_id Alarm ID int A unique identifier automatically generated by the software, used for querying, modifying, and deleting alarm rules. 2 alarm_name Alarm Name varchar

[60] The service name displayed on the software interface (such as "Branch Leakage Alarm") makes it easy for maintenance personnel to identify. 3 Fac_id Affiliated factory station int Foreign keys associated with plant / station information tables are used by the software to limit the scope of alarm rules (e.g., a specific water plant). 4 alarm_limit Alarm Limits float The threshold for software logic judgment (e.g., 20.0 represents 20%) supports two decimal places of precision. 5 alarm_type Alarm Logic Types int The software uses a foreign key in the alarm logic type lookup table to match logical formulas. 6 pam_num Number of valid parameters short The software identifies the number of components involved in alarm judgment (1~4) and automatically masks unenabled component fields. 7 pam_1 ~ pam_4 Quantity 1~4 int64 The software supports multiple references to the monitored object ID (such as water meter ID, device ID), and allows input of multiple IDs (separated by commas). 8 pam_1_stattype ~ pam_4_stattype Components 1-4 Statistical Items int Foreign keys in the software's statistical dictionary table identify statistical dimensions (e.g., 1 = monthly water consumption, 2 = hourly average current). 9 pam_1_starttime ~pam_4_starttime Components 1-4: Start Time of Statistics varchar

[20] The software parses dynamic time strings (such as "0:0:1") in the format "year:month:day". 10 pam_1_stoptime ~ pam_4_stoptime Statistical end time for components 1-4 varchar

[20] With the same start time format, the software ensures that the end time is later than the start time after parsing. 11 Alarm_content Alarm content varchar

[256] The alert messages displayed in the software alarm notifications support variable placeholders (e.g., "deviation exceeds {alarm_limit}%"). 12 Last_modify_define_time Last modified definition time time_t The software automatically records rule modification times (in the format "YYYY-MM-DD HH:MM:SS") for version tracking. 13 alarm_status Alarm status short Whether the software identification rule is enabled (0 = disabled, 1 = enabled), only rules with the enabled status are read.

[0047] 2. Read alarm rule records

[0048] After the logic alarm program (developed based on C++ / QT) starts, it connects to the real-time database of the monitoring platform through an interface and executes SQL query statements (such as "SELECT * FROM Logic Alarm Definition Table WHERE alarm_status=1"). The queried activation rule records are stored in an in-memory hash table (the key is alarm_id and the value is the rule object), which reduces repeated database queries and improves the efficiency of software operation.

[0049] 3. Dynamic Time Analysis

[0050] The software has a built-in "dynamic time parsing module" that parses the pam_n_starttime and pam_n_stoptime of each rule. During the parsing process, the software adds a time validity check: if the parsed end time is less than or greater than the current time, an error message is automatically triggered and the rule is skipped to avoid invalid statistics.

[0051] 4. Statistical Value Query

[0052] The software calls the "Statistical Query Module," which sends a statistical request to the real-time database based on the parsed time interval, pam_n (monitoring object ID), and pam_n_stattype (statistical item). The statistical service is supported by the platform. To call the statistical value query service, the following variables need to be input: measurement point number, query type, start time, end time, sampling interval (0, real-time statistics; 1, pre-statistics; -1, statistics according to sampling interval), query mode (0, historical sampling; 1, recall information; 2, conditional query), keywords, and conditional query keywords.

[0053] 5. Logical judgment

[0054] The software predefines an "alarm logic type lookup table" to store expandable logic formulas, as shown in the table below:

[0055] alarm_type Logical formula description Software calculation formula Applicable Scenarios 1 (Component 1 - Component 2) / Component 1 × 100% > alarm_limit (pam1Value - pam2Value) / pam1Value * 100 > limit Total measurement and sub-measurement deviation alarm 2 Component 1 > alarm_limit and Component 2 < alarm_limit pam1Value > limit && pam2Value < limit Two-parameter threshold alarm 3 Component 1 + Component 2 + Component 3 > alarm_limit pam1Value + pam2Value + pam3Value > limit Multi-parameter summation alarm

[0056] 6. Alarm Triggering and Closed-Loop Management

[0057] Alarm Trigger: If the calculation result meets the alarm conditions, the software will write the alarm information (including alarm_id, alarm_name, time interval, statistical value, and deviation value) into the "Alarm Log Table" and call the "Alarm Notification Module" to send a notification to the operation and maintenance personnel via SMS (calling a third-party SMS API), email (SMTP protocol), and monitoring platform pop-up window (WebSocket push).

[0058] Repeated alarm suppression: The software records the trigger time of each alarm. If alarms with the same alarm_id repeatedly meet the conditions within 30 minutes (which can be modified through the configuration interface), only one notification will be triggered to avoid information bombardment.

[0059] Alarm closed loop: The software provides an alarm processing interface where maintenance personnel can enter "processing results" (such as "leakage point repaired"). The software automatically records the processing time and the person who handled the alarm, forming a closed loop process of "trigger-processing-archiving" for easy maintenance traceability.

[0060] The following example, "a water leak alarm in a branch pipeline of a water plant," illustrates the software implementation process of this invention in detail:

[0061] 1. Software operating environment

[0062] Operating systems: Linux, CentOS 7.9;

[0063] Databases: InfluxDB 2.0 (for real-time storage of monitoring data), MySQL 8.0 (for storing alarm rules and logs);

[0064] Logical alarm program: developed based on C++ / QT, deployed on Tomcat 9.0 server;

[0065] Monitoring data: Water consumption data of the main water meter (object_id=1001) and 10 sub-water meters (object_id=2001~2010) are collected every 5 minutes and stored in InfluxDB.

[0066] 2. Configure alarm rules

[0067] The operations and maintenance personnel enter the following rules in the "Logical Alarm Definition Table" of MySQL through the software configuration interface:

[0068] Domain English name Configuration value Software Interface Operation Instructions alarm_id 10001 Software automatically generated alarm_name Water Plant A Branch Pipeline Leakage Alarm Manual input Fac_id 5 Select "Water Plant Area A" from the drop-down menu. alarm_limit 20 Manually enter "20.0" (representing 20%). alarm_type 1 Select "Total-Minute Measurement Deviation" from the drop-down menu. pam_num 2 Select "2" from the dropdown menu (2 valid components). pam_1 1001 Enter the main water meter ID "1001" pam_1_stattype 1 Select "Monthly Water Consumption" from the drop-down menu (related to the dictionary table of statistics). pam_1_starttime 0:00:01 Enter "0:0:1" (the 1st of this month). pam_1_stoptime 0:00:00 Enter "0:0:0" (current day) pam_2 2001,2002,...,2010 Enter 10 water meter IDs, separated by commas. pam_2_stattype 1 Select "Monthly Water Consumption" from the drop-down menu. pam_2_starttime 0:00:01 Same as pam_1_starttime pam_2_stoptime 0:00:00 Same as pam_1_stoptime Alarm_content Water plant A experienced a pipeline leak, with a total water consumption of {1} tons and a partial water consumption of {2} tons, exceeding the deviation by {3}%. Enter content with variable placeholders; {1}~{3} will be automatically replaced with statistical values. alarm_status 1 Check the "Enable" box.

[0069] 3. Software Execution Flow

[0070] (1) Rule reading: The logic alarm program is executed once every 5 minutes to read the rule with alarm_status=1 in MySQL and store the rule with alarm_id=10001 in memory;

[0071] (2) Time parsing: The software calls the startStringToDateTime function to parse the time.

[0072] pam_1_starttime=0:0:1→“2025-10-01 00:00:00”, pam_1_stoptime=0:0:0→“2025-10-15 14:30:25” (current time is 2025-10-15 14:30:25);

[0073] (3) Statistical query:

[0074] To query the monthly water consumption of pam_1 (1001): call the queryStatValues ​​interface, which returns a statistical value of 1200 tons;

[0075] Query the total monthly water consumption of pam_2 (2001~2010): Call the API, and the returned statistical value is 900 tons;

[0076] (4) Logical judgment: The software reads the formula of alarm_type=1 and calculates (1200-900) / 1200×100=25%>20%, which meets the alarm conditions;

[0077] (5) Alarm Trigger:

[0078] Write to the alarm log: Insert a record into the MySQL "Alarm Log Table" (alarm_id=1001, trigger time=2024-10-15 14:30:25, statistics=1200 / 900 tons, deviation=25%).

[0079] Send notification: Send an SMS to the maintenance personnel with the message "[Water Plant Monitoring] Alarm: Water leak in the pipeline of Water Plant A, total water consumption 1200 tons, water consumption 900 tons, deviation exceeds 25%, please handle in time", and at the same time, a pop-up notification will appear on the monitoring platform.

[0080] (6) Closed-loop management: After the maintenance personnel repair the leak, they enter the processing result "The leak in the No. 3 branch pipeline of Area A has been repaired" in the software interface. The software records the processing time as 2025-10-15 15:45:00, the processor as "Zhang San", and the alarm status as "archived".

Claims

1. A method for implementing logical alarms, characterized in that, Includes the following steps: S1: Configure a logical alarm definition table in the real-time library of the monitoring platform. The logical alarm definition table includes an alarm identifier field, a component parameter field, a dynamic time field, an alarm logic field, and a status field. S2: Start the logical alarm program. The program reads the alarm rule records in the logical alarm definition table where alarm_status is enabled and stores them in the memory cache. S3: The logic alarm program performs dynamic time parsing of pam_n_starttime and pam_n_stoptime for each enabled rule; S4: The logic alarm program calls the statistical interface of the real-time library of the monitoring platform to query the statistical values ​​of each component based on the parsed time interval, monitoring object ID and statistical items. S5: The logic alarm program matches the alarm logic type lookup table with the alarm rule's alarm_type, obtains the corresponding logic judgment formula, and substitutes the statistical values ​​of each component and alarm_limit into the formula for calculation. S6: If the calculation result meets the alarm conditions, the program will write the alarm information to the alarm log and trigger an alarm notification; if it does not meet the conditions, the program will continue to process the next activation rule.

2. The logic alarm implementation method according to claim 1, characterized in that, The alarm identifier field in step S1 includes alarm ID number, alarm name, and the plant / station to which it belongs; The component parameter field includes the number of valid parameters, component n (n=1~4), and component n statistical items; The dynamic time field includes the start time and end time of component n statistics. The alarm logic field includes alarm logic type, alarm limit, and alarm content; the status field includes alarm status and last modified definition time.

3. The logic alarm implementation method according to claim 1, characterized in that, In step S1, the domain type of component n is int64 and supports multiple references to the monitoring object ID set. The number of valid parameters ranges from 1 to 4, corresponding to the number of valid components from pam_1 to pam_4. The range of valid parameters can be expanded in the logical alarm definition table.

4. The logic alarm implementation method according to claim 1, characterized in that, In step S3, the dynamic time parsing follows the colon-separated format of "year:month:day", where the year / month / day values ​​are non-negative integers to represent the specific time, negative integers to represent the corresponding unit before the current time, and 0 to represent the corresponding unit of the current time. After parsing, the default start time is "00:00:00" and the default end time is "23:59:59" or the current time. When the date field is greater than 31, the last day of the corresponding month is automatically taken.

5. The logic alarm implementation method according to claim 1, characterized in that, In step S4, the statistical interface supports summation, average, maximum, and interval difference statistical dimensions, and includes a data missing completion strategy: when the monitored object has missing data within a time interval, it uses the average of adjacent time periods to complete the data or marks the missing data status and triggers a data anomaly prompt.

6. The logic alarm implementation method according to claim 1, characterized in that, The alarm logic type lookup table in step S5 is an expandable lookup table, which includes logic identifier, logic formula description, and applicable scenario fields. When adding alarm logic, it is entered into the lookup table after syntax validation, without needing to modify the logic alarm program code.

7. The logic alarm implementation method according to claim 1, characterized in that, The alarm notification in step S6 includes a multi-channel notification mechanism, supporting SMS, email, and pop-up notifications from the industrial monitoring platform. The notification content carries alarm_id, alarm name, statistical time interval, statistical values ​​of each component, and reasons for deviation.

8. A logic alarm implementation system, characterized in that, include: The configuration logic alarm definition module is used to configure the logic alarm definition table in the real-time library of the monitoring platform. The logic alarm definition table includes alarm identifier field, component parameter field, dynamic time field, alarm logic field and status field. The alarm rule recording module is used to start the logical alarm program. The program reads the alarm rule records in the logical alarm definition table where alarm_status is enabled and stores them in the memory cache. The dynamic time parsing module is used by the logic alarm program to perform dynamic time parsing of pam_n_starttime and pam_n_stoptime for each enabling rule; The statistical value query module is used by the logic alarm program to call the statistical interface of the real-time library of the monitoring platform to query the statistical values ​​of each component based on the parsed time interval, monitoring object ID and statistical items. The logic judgment module is used to match the alarm logic type lookup table with the alarm rule's alarm_type, obtain the corresponding logic judgment formula, and substitute the statistical values ​​of each component and alarm_limit for calculation. The alarm triggering and closed-loop management module is used to determine whether the alarm conditions are met. If they are met, the program writes the alarm information to the alarm log and triggers an alarm notification; if not, it continues to process the next activation rule.

9. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the logical alarm implementation method according to any one of claims 1-7.

10. A storage medium storing a computer program, characterized in that, The computer program is designed to implement the logical alarm implementation method according to any one of claims 1 to 7 at runtime.