Dynamic combined alarm method based on periodic time switching

Abstract

The application provides a dynamic combination alarm method based on cycle time switching. The method obtains an inspection data request, processes original inspection result data based on a pre-configured basic algorithm library to obtain model data corresponding to a preset device model, determines a target theoretical state corresponding to the current time based on a pre-configured multi-layer device model and a benchmark state cycle switching mechanism, performs device state consistency judgment based on the model data and the target theoretical state to obtain alarm detection results, generates alarm data when the alarm detection results meet preset alarm conditions, and pushes the alarm data to a front-end display terminal, so that the device state consistency is judged based on the model data and the target theoretical state in the case that there are multi-layer device models and multi-component state combination relationships, and the alarm data is automatically generated and pushed when certain conditions are met, thereby realizing dynamic combination alarm in a complex scene.

Description

Technical Field

[0001] This application relates to data processing technology, and more particularly to a dynamic combined alarm method based on periodic time switching. Background Technology

[0002] In complex industrial settings such as coke ovens, inspection robots periodically acquire a large amount of equipment operation data during the inspection process to reflect the operating status of various components of the coke oven under different working conditions.

[0003] Most existing industrial alarm systems are based on single-point, static, fixed-threshold alarm strategies. This means that one or a few fixed thresholds are pre-configured for a specific device or measuring point, and an alarm is triggered by simply comparing the current detection value with the threshold. This approach is suitable for conventional devices with relatively stable states and simple change patterns, such as lights on / off and air conditioners on / off.

[0004] However, for complex equipment such as coke ovens, which have obvious operating cycles, multiple coupled and linked components, and multiple state switching within a cycle, the overall normal operating state of the equipment itself changes periodically over time. Traditional single-threshold alarm methods cannot accurately express the normal state pattern under different time slices, which can easily lead to a large number of false alarms and missed alarms. Maintenance personnel need to rely on experience to manually screen alarms, which seriously affects the reliability and practicality of the alarm system in complex scenarios. Summary of the Invention

[0005] This application provides a dynamic combined alarm method based on periodic time switching, which can automatically and dynamically combine alarms for inspection data when there are multi-layer equipment models and multi-component state combination relationships.

[0006] Firstly, this application provides a dynamic combined alarm method based on periodic time switching, including:

[0007] A request for inspection data is obtained. The inspection data request is reported by the inspection robot during the inspection process through a communication protocol. The inspection data request includes at least: inspection point identifier, inspection object identifier, and corresponding original inspection result data.

[0008] Based on a pre-configured basic algorithm library, the original inspection result data is processed to obtain model data corresponding to the preset equipment model;

[0009] Based on a pre-configured multi-layer device model and a baseline state cycle switching mechanism, the target theoretical state corresponding to the current moment is determined.

[0010] Based on the model data and the target theoretical state, the consistency of the equipment state is judged to obtain the alarm detection result;

[0011] When the alarm detection result meets the preset alarm conditions, alarm data is generated and pushed to the front-end display terminal.

[0012] Secondly, this application provides a dynamic combined alarm system based on periodic time switching, comprising:

[0013] The acquisition module is used to acquire inspection data requests. The inspection data requests are reported by the inspection robot during the inspection process through a communication protocol. The inspection data requests include at least: inspection point identifier, inspection object identifier, and corresponding original inspection result data.

[0014] The processing module is used to process the original inspection result data based on a pre-configured basic algorithm library to obtain model data corresponding to the preset equipment model.

[0015] The determination module is used to determine the target theoretical state at the current moment based on a pre-configured multi-layer device model and a reference state cycle switching mechanism.

[0016] The judgment module is used to judge the consistency of the device state based on the model data and the target theoretical state, and obtain the alarm detection result;

[0017] The alarm module is used to generate alarm data and push the alarm data to the front-end display terminal when the alarm detection result meets the preset alarm conditions.

[0018] Thirdly, this application provides an electronic device, comprising:

[0019] Processor; and,

[0020] Memory for storing the executable instructions of the processor;

[0021] The processor is configured to perform any of the possible methods described in the first aspect by executing the executable instructions.

[0022] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement any of the possible methods described in the first aspect.

[0023] Beneficial Effects: The dynamic combined alarm method based on periodic time switching provided by this invention obtains inspection data requests, processes the original inspection result data based on a pre-configured basic algorithm library to obtain model data corresponding to a preset equipment model, then determines the target theoretical state corresponding to the current moment based on a pre-configured multi-layer equipment model and a baseline state periodic switching mechanism, and then performs equipment state consistency judgment based on the model data and the target theoretical state to obtain alarm detection results. When the alarm detection results meet preset alarm conditions, alarm data is generated and pushed to the front-end display terminal. Thus, in the case of multi-layer equipment models and multi-component state combination relationships, the method performs equipment state consistency judgment based on model data and the target theoretical state, and automatically generates and pushes alarm data when certain conditions are met, thereby realizing dynamic combined alarms in complex scenarios. Attached Figure Description

[0024] 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.

[0025] Figure 1 This is a flowchart illustrating a dynamic combined alarm method based on periodic time switching according to an example embodiment of this application;

[0026] Figure 2 This is a flowchart illustrating a specific implementation of S130 according to an example embodiment of this application;

[0027] Figure 3 This is a flowchart illustrating a dynamic combined alarm method based on periodic time switching according to another example embodiment of this application;

[0028] Figure 4 This is a schematic diagram of the structure of a dynamic combined alarm system based on periodic time switching, according to an example embodiment of this application;

[0029] Figure 5 This is a schematic diagram of the structure of an electronic device according to an example embodiment of this application.

[0030] The accompanying drawings illustrate 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 particular embodiments. Detailed Implementation

[0031] 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.

[0032] Figure 1 This is a flowchart illustrating a dynamic combined alarm method based on periodic time switching, according to an example embodiment of this application. Figure 1 As shown, the method provided in this embodiment includes:

[0033] S110, Request to obtain inspection data.

[0034] In this step, the inspection data request is reported by the inspection robot through a communication protocol during the inspection process. The inspection data request includes at least: the inspection point identifier, the inspection object identifier, and the corresponding original inspection result data.

[0035] Specifically, communication parameters can be pre-configured for each inspection robot through the inspection robot management system. The communication parameters include at least one of the following: communication protocol type, message queue access address, topic or queue name, authentication account, and authentication key.

[0036] On the inspection robot, the inspection task planning results are sent to the task execution module of the inspection robot body. The task planning results include the inspection point identifier and the inspection object identifier that correspond one-to-one with each inspection task step.

[0037] After the inspection robot arrives at the target inspection point and completes one inspection and data collection on the target inspection object, the inspection data acquisition module formats and encapsulates the collected sensor data and / or image data to generate raw inspection result data. The raw inspection result data includes at least: measurement value, collection timestamp, and raw data type identifier.

[0038] On the inspection robot, an inspection data request message is constructed based on communication parameters. The inspection data request message carries the inspection point identifier, inspection object identifier, and original inspection result data corresponding to the steps of this inspection task, and the inspection data request message is encapsulated into a message object that conforms to the communication protocol.

[0039] When the communication protocol is a message queue protocol, the message object is published to the pre-agreed message topic or message queue through the client message publishing component; when the communication protocol is HTTP or other request / response protocol, a request message containing the message object is sent to the backend server through the preset reporting interface address.

[0040] In the data receiving module on the backend server side, based on the communication protocol adaptation component consistent with the inspection robot end, the received message object or request message is parsed, the inspection point identifier, inspection object identifier and original inspection result data are extracted, and they are organized into an inspection data request in a unified structure form for subsequent alarm processing flow to call.

[0041] S120. Based on the pre-configured basic algorithm library, the original inspection result data is processed to obtain model data corresponding to the preset equipment model.

[0042] In this step, the basic algorithm to be applied can be obtained from the algorithm configuration or query results on the inspection robot side through the basic algorithm configuration interface provided in the background. Then, the subordinate relationship between the basic algorithm and the first-level equipment type and the second-level equipment type is established, and the basic algorithm and its subordinate relationship are stored in the basic algorithm library.

[0043] Then, during alarm processing, based on the inspection point identifier and / or inspection object identifier, the basic algorithm matching the corresponding equipment type is retrieved from the basic algorithm library to identify and transform the original inspection result data. The original inspection result data processed by the basic algorithm is then mapped to model data corresponding to a preset multi-layer equipment model structure.

[0044] Specifically, the pre-configured basic algorithm library mentioned above includes:

[0045] Configure a basic algorithm library data structure in the backend server to store basic algorithms. The basic algorithm library data structure includes a basic algorithm table, an algorithm-device type mapping table, and an algorithm version record table. The basic algorithm table is used to store the unique identifier, algorithm name, algorithm type, algorithm running parameter template, and algorithm implementation reference information of each basic algorithm. The algorithm-device type mapping table is used to store the subordinate relationship between basic algorithms and primary and secondary device types. The algorithm version record table is used to record the version number, activation status, and effective time range of each basic algorithm.

[0046] The basic algorithm configuration interface provided in the backend allows maintenance personnel to create, edit, and delete basic algorithm records through page configuration or interface calls. When creating a basic algorithm record, the following steps are taken: assigning a unique algorithm identifier code to each basic algorithm, setting the algorithm name and algorithm type. The algorithm type must include at least one or more of the following: numerical threshold algorithm, interval judgment algorithm, state enumeration mapping algorithm, image recognition result parsing algorithm, and multi-parameter comprehensive judgment algorithm.

[0047] When configuring the basic algorithm, the basic algorithm is bound to the specific algorithm implementation method through the algorithm implementation reference information. The algorithm implementation method includes at least one of the following: the algorithm processing function pre-set in the application service, the algorithm script stored in the form of a script and executed by the script engine, and the algorithm service address provided in the form of an external algorithm service interface; and the parameter template and return result format definition required to call the algorithm implementation method are saved in the basic algorithm record.

[0048] The algorithm-device type mapping table selects the corresponding basic algorithm for each primary and / or secondary device type. The mapping table records the device type identifier, the associated basic algorithm identifier, and optional limiting conditions such as applicable range, applicable inspection object type, and applicable data source type. This is used to accurately match the available basic algorithm based on the inspection point identifier and / or inspection object identifier during alarm processing.

[0049] Version information is maintained for each basic algorithm in the basic algorithm library. When the logic of a basic algorithm is modified, a new algorithm version record is generated. By setting the effective time and expiration time in the algorithm version record table, it is ensured that there is only one valid algorithm version in the enabled state at the same time, so as to achieve smooth algorithm upgrade without affecting the historical data backtracking analysis.

[0050] In addition, after system initialization or algorithm configuration changes, the valid records in the basic algorithm table and the algorithm-device type mapping table are loaded into the memory or cache system, and an index is built using the algorithm identifier and device type identifier as the query key, so that the matching basic algorithm can be quickly retrieved according to the device type during alarm processing, and the original inspection result data can be processed in real time.

[0051] Furthermore, the specific implementation of establishing the subordinate relationship between the basic algorithm and the primary and secondary device types can be achieved by configuring at least one primary device type and at least one secondary device type associated with it. Then, for each secondary device type, at least one corresponding basic algorithm is configured, with each basic algorithm corresponding to at least one possible secondary device state. Each possible secondary device state is then logically associated with its corresponding primary device state to form a mapping relationship between primary device states and combinations of multiple secondary device states, and this mapping relationship serves as the foundation for the multi-layered device model.

[0052] Optionally, the aforementioned basic algorithm library contains various algorithms for different equipment types and monitoring methods. For example, a temperature value >800℃ is judged as high temperature; 600-800℃ is judged as normal high temperature; and below 600℃ is judged as low temperature. Alternatively, image recognition can be used to determine whether the coke oven door is properly sealed, outputting a result indicating good sealing, slight leakage, or severe leakage. The inspection robot can determine which basic algorithm to use based on the inspection point and the object being inspected. It is worth noting that the algorithms in the aforementioned basic algorithm library can be various existing mature algorithms; this embodiment does not specifically limit the types or number of algorithms in the basic algorithm library.

[0053] S130. Based on the pre-configured multi-layer device model and the reference state cycle switching mechanism, determine the target theoretical state corresponding to the current moment.

[0054] Figure 2 This is a flowchart illustrating a specific implementation of S130 according to an example embodiment of this application. For example... Figure 2 As shown, the above-mentioned S130 specifically includes:

[0055] S131, Configure multi-layer device model.

[0056] In this step, the multi-layer device model is configured, including configuring the baseline state initialization parameters, including the initial theoretical state of the primary device and its subordinate secondary devices at the target startup time, the periodic switching time interval, and the state switching sequence rules.

[0057] Optionally, for the same type of equipment on site, only one general-purpose first-level equipment model can be configured, without the need to configure it separately for each physical device;

[0058] Multiple secondary device models are configured under a primary device model, and the multiple secondary device models and the primary device model form a one-to-many hierarchical relationship.

[0059] Based on a pre-set basic algorithm library, algorithm rules corresponding to each secondary device model are pulled from the basic algorithm library, and the possible states of each secondary device model are bound to the recognition results of the basic algorithm.

[0060] Based on the actual operating logic of the field equipment, multiple secondary equipment state combination conditions are combined using basic logical operations such as AND, OR, and NOT to form multiple combination modes corresponding to the primary equipment state, thereby completing the assembly of the multi-layer equipment model.

[0061] Furthermore, configuring the baseline state initialization parameters and performing baseline state periodic switching specifically includes:

[0062] Through the background baseline state setting interface, select the target primary equipment model and all its associated secondary equipment models. Select a future target time on the timeline as the start time, and configure the corresponding initial theoretical state for the primary equipment model and each of its subordinate secondary equipment models.

[0063] Based on the initial theoretical state of the secondary equipment, the corresponding initial theoretical state of the primary equipment is resolved through the mapping relationship between the primary and secondary equipment states. A periodic switching frequency parameter is configured to indicate the time interval between two adjacent theoretical state updates.

[0064] The startup time, initial theoretical state, and cycle switching frequency parameters are written to the database and simultaneously written to the cache system. A countdown is set for the startup time using the cache system's key expiration mechanism. Upon expiration, the baseline state calibration function is triggered, updating the current cycle target theoretical state of the primary equipment model and each secondary equipment model according to predetermined rules.

[0065] Based on the cycle switching frequency, a countdown for the next cycle is set in the caching system. After the countdown expires, the theoretical state is switched to the next cycle state in a preset order, and the target theoretical state in the cache is updated. When reconfiguring the baseline state or cycle parameters, a cache clearing or reset mechanism is executed to avoid interference from historical configurations to the new configuration.

[0066] S132. Write the initial theoretical state into the cache to obtain the initial target theoretical state.

[0067] In the backend program, based on the startup time, the startup countdown is set using the expiration attribute of the caching system. The corresponding expiration channel is subscribed to, and after receiving the startup time expiration notification, the initial theoretical state is written into the cache to obtain the initial target theoretical state.

[0068] S133. Based on the initial or previous target theoretical state and the preset state switching order rules, switch to obtain the target theoretical state for the next cycle, and update the target theoretical state stored in the cache system.

[0069] In this step, a state switching countdown is set in the cache system based on the period switching time interval. When the expiration notification of the period countdown is received, the target theoretical state of the next period is obtained according to the initial or previous target theoretical state and the preset state switching order rules, and the target theoretical state stored in the cache system is updated.

[0070] Regarding the above S131-S133, in an optional embodiment, in order to facilitate understanding of the configuration process of the multi-layer equipment model and state mapping relationship, the waste gas disc equipment in the coke oven waste gas treatment system can be used as an example for explanation.

[0071] For example, multiple exhaust gas disc devices with identical structures and operating principles exist on-site. Each exhaust gas disc consists of multiple components such as a fan-shaped wheel, an air cover, and a drive mechanism. For this type of large-scale equipment on-site, this embodiment configures only one general-purpose primary equipment model exhaust gas disc to abstractly describe the overall operating state of all exhaust gas disc devices, without needing to configure a separate primary equipment model for each physical exhaust gas disc device. Specifically, the possible states of the primary equipment model exhaust gas disc can include at least one of rising, falling, and holding, used to characterize the overall movement trend or positional state of the exhaust gas disc under different operating conditions.

[0072] Below the primary equipment model exhaust gas disk, this embodiment configures multiple secondary equipment models within a multi-layered equipment model to describe the operational status of key components or local equipment related to the overall operation of the exhaust gas disk. Continuing the example above, secondary equipment models such as the fan-shaped wheel and the air cover can be configured below the primary equipment model exhaust gas disk. The fan-shaped wheel describes its attitude state, which may include being raised and lowered. The air cover describes its opening and closing state, which may also include being raised and lowered. Through this configuration, a multi-level relationship is formed between the primary equipment model (exhaust gas disk) and multiple secondary equipment models (fan-shaped wheel and air cover). Each physical exhaust gas disk instance can be bound to this general primary equipment model in the system and further associated with specific secondary equipment model instances through inspection points.

[0073] After completing the hierarchical structure configuration of the multi-level device model, this embodiment retrieves the algorithm rules corresponding to each secondary device model from the preset basic algorithm library, and binds the possible states of each secondary device model to the recognition results of the basic algorithm.

[0074] Taking the fan-shaped wheel and air cover as examples, the basic algorithm library pre-configures fan-shaped wheel recognition algorithms and air cover recognition algorithms. The fan-shaped wheel recognition algorithm can output a judgment result indicating whether the fan-shaped wheel is raised or lowered based on image data or sensor data collected by the inspection robot. The air cover recognition algorithm can output a judgment result indicating whether the air cover is raised or lowered based on the same raw data. During model configuration, a binding relationship is established between the secondary equipment model's fan-shaped wheel and the fan-shaped wheel recognition algorithm. The "raised" state in the output of the fan-shaped wheel recognition algorithm is mapped to the "raised" state of the secondary equipment model's fan-shaped wheel, and the "lowered" state is mapped to the "lowered" state.

[0075] Similarly, a binding relationship is established between the air cover of the secondary equipment model and the air cover recognition algorithm, mapping the lifting / lowering results output by the algorithm to the corresponding states of the air covers of the secondary equipment models. Through this binding, when the raw inspection result data reported by the inspection robot is processed by the basic algorithm library, the system can automatically obtain model data that corresponds one-to-one with the state of each secondary equipment model.

[0076] Based on this, this embodiment further combines multiple secondary device state combination conditions through basic logical operations such as AND, OR, and NOT, according to the actual operating logic of the field equipment, to form multiple combination modes corresponding to the primary device state, thereby completing the assembly of the multi-layer equipment model and the configuration of the state mapping relationship.

[0077] Continuing with the example of the exhaust gas disc, in actual processes, when the fan-shaped wheel is in the lowered state and the air cover is in the raised state, the on-site operating procedures consider the exhaust gas disc to be in an upward state. When the fan-shaped wheel is in the raised state and the air cover is in the lowered state, the exhaust gas disc is considered to be in a downward state. Corresponding to the state mapping configuration of the multi-layer equipment model, the upward movement of the exhaust gas disc can be defined as a secondary equipment state combination: the fan-shaped wheel lowering and the air cover raising, and the downward movement of the exhaust gas disc can be defined as a secondary equipment state combination: the fan-shaped wheel raising and the air cover lowering.

[0078] When other operating modes need to be considered, additional OR and NOT logical operations can be added to construct combinations of secondary device states corresponding to other primary device states, such as exhaust gas disc holding or exhaust gas disc failure. Through the combination configuration of the above-mentioned basic logical operations such as AND, OR, and NOT, the same primary device state can correspond to multiple different combinations of secondary device states, thereby adapting to diverse operating scenarios under complex working conditions.

[0079] Therefore, in actual operation, when the inspection robot inspects the fan-shaped wheel and air cover and reports the original inspection results data, the system first calls the pre-configured basic algorithm library to identify and convert the original data related to the fan-shaped wheel and air cover to obtain the corresponding model data, that is, the actual state of the fan-shaped wheel and air cover in the current cycle.

[0080] Subsequently, based on the pre-established state mapping relationship between the first and second level equipment in the multi-level equipment model, the system matches the actual state combination of the second level equipment model with the theoretical state combination mode of the corresponding first level equipment model exhaust gas disk, thereby parsing the overall actual state of the exhaust gas disk at the current moment, and making a consistency judgment with the current period target theoretical state given by the benchmark state cycle switching mechanism.

[0081] If the two are consistent, the exhaust gas control panel is determined to be in normal condition; if they are inconsistent, the abnormality accumulation statistics and alarm generation process can be further triggered to realize dynamic combination alarms for complex multi-component combined working conditions.

[0082] As can be seen from the above specific examples, the multi-layer device model configuration method provided in this embodiment utilizes a combination structure of a general first-level device model, multiple second-level device models, and state mapping relationships based on logical operations. This not only avoids a large amount of repetitive work in configuring complex alarm logic for each physical device individually, but also enables the characterization of the overall operating state of complex devices under different cycles and different component state combinations through flexible state combination rules.

[0083] S140. Based on model data and target theoretical state, determine the consistency of equipment state and obtain alarm detection results.

[0084] Specifically, during the inspection robot's inspection task, it subscribes to preset message topics to receive inspection result data reported via message queue protocol. Then, it parses the received inspection result data to extract the inspection point identifier, inspection object identifier, and various associated raw data items. Based on a pre-established false alarm record database, it filters specific result values ​​with a high historical frequency of false alarms. When the current inspection result matches false alarm characteristics, it performs intelligent filtering to reduce the false alarm rate.

[0085] Furthermore, the timestamps of the inspection results are processed, and the system maintains records of state changes within the two most recent cycle time windows to improve the time tolerance and accuracy of state judgment in the presence of data reporting delays. The parsed raw data is converted into model data. This conversion includes calling a model mapping method to extract key features matching the equipment model from the raw data according to preset rules and map them into unique model codes. Then, based on the unique model code, the corresponding theoretical state of the current cycle target is queried from the cache system. Finally, based on the state mapping relationship between first- and second-level equipment in the multi-layered equipment model, the model data is parsed into actual state information.

[0086] Finally, the target theoretical state is compared with the actual state. When the target theoretical state and the actual state are consistent, the corresponding equipment is determined to be in normal state; when they are inconsistent, the corresponding equipment is marked as abnormal, and the corresponding abnormal detection result is generated.

[0087] Furthermore, for situations where the theoretical state and the actual state of the target are inconsistent, and the corresponding device is marked as abnormal and a corresponding abnormality detection result is generated, the current cumulative number of abnormalities for the corresponding device can be read from the cache or database. When the current detection result is abnormal, the cumulative number of abnormalities is incremented by one, and the updated cumulative number of abnormalities is written back to the cache or database.

[0088] Next, compare the abnormal accumulation count with the preset abnormal accumulation threshold. If the abnormal accumulation count does not reach the abnormal accumulation threshold, only record the abnormal status and do not trigger an alarm.

[0089] When the abnormal accumulation count reaches or exceeds the abnormal accumulation threshold, upgrade the current abnormal detection result to an alarm event, generate corresponding alarm data, and the abnormal accumulation count can be reset or maintained according to the strategy. Here, the abnormal accumulation threshold is the preset number of consecutive abnormal occurrences, which is used to balance the alarm timeliness and false alarm rate.

[0090] S150. When the alarm detection result meets the preset alarm condition, generate alarm data and push the alarm data to the front-end display terminal.

[0091] Specifically, when generating alarm data, key information related to the alarm can be recorded. The key information at least includes: the device identifier corresponding to the alarm, the inspection point identifier, the inspection object identifier, the alarm occurrence time, the alarm level, the theoretical status, the actual status, the abnormal accumulation count, and the index information of the on-site image or video data corresponding to the alarm.

[0092] Then, based on the message push mechanism, encapsulate the alarm data into an alarm message conforming to the preset format and push it to the preset alarm channel. So that the front-end display terminal subscribes to the alarm channel and performs page display, prompt or linkage processing after receiving the alarm message.

[0093] In this embodiment, by obtaining the inspection data request, and then based on the pre-configured basic algorithm library, process the original inspection result data to obtain model data corresponding to the preset device model. Then, based on the pre-configured multi-layer device model and the benchmark status period switching mechanism, determine the target theoretical status corresponding to the current moment.

[0094] Next, based on the model data and the target theoretical status, perform device status consistency judgment to obtain the alarm detection result. And when the alarm detection result meets the preset alarm condition, generate alarm data and push the alarm data to the front-end display terminal. Thus, in the case of a multi-layer device model and a multi-component status combination relationship, perform device status consistency judgment based on the model data and the target theoretical status, and automatically generate and push alarm data when certain conditions are met, so as to achieve dynamic combined alarms in complex scenarios.

[0095] In a specific application scenario, the dynamic combined alarm method based on cycle time switching provided in the above embodiment can be applied to the inspection alarm system at the coke oven production site.

[0096] Taking a large coke oven as an example, the coke oven includes multiple blowers, multiple oven doors and various valves and other equipment. The actual production process of the coke oven shows obvious periodic process rhythms, such as the coke pushing process, the coal charging process and the air volume adjustment process. The target operating status of each piece of equipment varies significantly in different time periods.

[0097] To achieve automated monitoring and intelligent alarm of the coke oven's operating status, inspection robots are deployed around the coke oven. The inspection robots conduct periodic inspections of the coke oven equipment using various sensors such as cameras and infrared thermometers, and report the collected data to the background intelligent alarm system. The background intelligent alarm system executes the method provided in the above embodiment to uniformly process the inspection data and make dynamic alarm judgments.

[0098] Specifically, at 8:00 AM on a certain production day, the inspection robot moves to the location of the No. 3 furnace door of the coke oven according to the preset inspection path, collects images and temperature data of the environment around the No. 3 furnace door, and records the inspection point markers and inspection object markers corresponding to this inspection.

[0099] The inspection point identifier uniquely identifies the inspection point location of furnace door No. 3, while the inspection object identifier uniquely identifies the specific equipment object of furnace door No. 3. The inspection robot encapsulates the inspection data, including the inspection point identifier, inspection object identifier, image data, temperature data, and timestamp, into an inspection data request, which is then sent to the backend intelligent alarm system via a wireless communication network. Upon receiving the inspection data request, the backend system initiates the subsequent alarm processing procedure.

[0100] In this embodiment, the background intelligent alarm system is pre-configured with a basic algorithm library. The basic algorithm library stores corresponding basic detection algorithms for different device types and different detection methods, which are used to convert the original inspection result data into unified structured model data.

[0101] For example, regarding the sealing status of coke oven doors, the basic algorithm library includes a sealing detection algorithm that uses temperature data and image feature data around the oven door for joint discrimination. This algorithm takes the temperature value collected by the temperature sensor and the smoke and flame features extracted by the image recognition module as input, and outputs a discrete level value representing the sealing status, such as normal, slight leakage, and severe leakage.

[0102] When processing the inspection data request for the No. 3 furnace door, the background intelligent alarm system selects basic algorithms related to the sealing and temperature of the coke oven door from the basic algorithm library based on the inspection point identifier and the inspection object identifier. It processes the temperature data of 830℃ and the image data containing smoke and flame features, and converts the processing results into structured model state data. For example, it determines the current sealing state of the No. 3 furnace door as serious leakage and the temperature state as high temperature, and uses these states as inputs for subsequent alarm judgment.

[0103] Furthermore, to ensure that alarm judgments fully reflect the cycle time characteristics of the production process, the back-end intelligent alarm system establishes equipment models and cycle time models corresponding to the coke oven. The equipment model models the entire coke oven as primary equipment and each oven door, each set of fans, each valve, etc., as corresponding secondary equipment. For each secondary equipment, corresponding state attributes and value ranges are defined. For example, the oven door is defined as closed, open, and different levels of leakage status, and the fans are defined as start / stop status and speed levels, etc.

[0104] The cycle time model pre-configures the process cycles corresponding to each time period based on the coke oven production process, such as the coke pushing cycle and the non-coke pushing cycle, and configures the corresponding theoretical target state for each secondary equipment within each process cycle. For example, the coke pushing cycle of furnace door No. 3 is configured from 7:50 to 8:10 every day. During this period, furnace door No. 3 is allowed to be open or within the allowable coke pushing range, and a certain degree of temperature rise and short-term smoke are allowed. During the non-coke pushing period, furnace door No. 3 is required to be completely sealed and with basically no obvious smoke or fire leakage.

[0105] When the background intelligent alarm system receives the above-mentioned No. 3 furnace door inspection data request at 8:00 and generates the corresponding model data, the system determines the current process cycle as the coking cycle from the cycle time model based on the current time, and determines the target theoretical state of No. 3 furnace door under this cycle based on the equipment model and cycle time model, that is, the allowable temperature range, the allowable smoke intensity range, and the unacceptable serious gas leakage state under the coking condition.

[0106] Subsequently, the system compares the actual model states obtained from the basic algorithm library, such as a severe air leak in the sealing state or a temperature that is too high, with the target theoretical state configured for the current process cycle. If only the temperature is too high but within the configured allowable coking temperature range, the system can determine that it is consistent with the theoretical state and will not trigger an alarm. However, when the sealing state is determined to be a severe air leak and is inconsistent with the allowable leak threshold for the coking cycle, the system determines that there is an inconsistency between the actual state and the theoretical target state for the current cycle, thereby generating a corresponding alarm detection result, clarifying the anomaly type as an excessive air leak at furnace door No. 3 within the coking cycle, and providing the severity of the anomaly and handling suggestions.

[0107] In this embodiment, the background intelligent alarm system also has a preset alarm triggering condition strategy, which is used to determine whether to push alarm information to the front-end display terminal based on factors such as the anomaly level, duration, and number of historical occurrences.

[0108] When a severe gas leakage level anomaly occurs as described above, the anomaly directly meets the triggering conditions for a Level 1 alarm. Based on this, the system generates alarm data including equipment identifier, component identifier, current time, current process cycle, theoretical target status, actual model status, consistency judgment conclusion, alarm level, and handling suggestions. The alarm data is then sent to the central control room monitoring screen and the terminal equipment of the on-duty personnel through a message push mechanism. The location of the No. 3 furnace door is marked in a bright or flashing manner on the coke oven schematic screen, accompanied by an audible and visual alarm prompt.

[0109] Based on this, on-duty personnel can promptly identify a serious gas leakage hazard at furnace door No. 3 that exceeds the allowable range under the current coking process, thereby quickly arranging on-site inspection and handling, achieving the technical effect of reducing safety risks and improving the accuracy of inspection alarms.

[0110] As can be seen from the above embodiments, these embodiments provide a method for collecting multi-source data through inspection robots, performing unified structured transformation of the raw data using a basic algorithm library, and combining equipment models and cycle time models to achieve dynamic switching and matching of the theoretical state of the equipment, thus realizing a dynamic combination alarm function based on the process cycle. Compared with traditional single-point, static threshold alarm methods, the above embodiments provide a method that can make consistency judgments under the premise of considering time cycles, changes in operating conditions, and combinations of multiple equipment states, effectively reducing false alarms and false negatives, and enhancing the consistency between alarm results and the actual production state.

[0111] In addition, Figure 1In the alarm system for inspection robots shown in the embodiment, inspection point information and inspection object information are usually maintained independently by the inspection robot system. The background alarm processing module often interfaces with field equipment using equipment codes or simple text descriptions, lacking a unified and structured inspection point model. Existing systems often rely on manually agreed-upon fields or hard-coded mapping relationships in the code when mapping inspection results to equipment models. This results in a lack of unified standards between different inspection tasks and different robot platforms, requiring significant manual configuration and verification when expanding to new inspection points or adding new inspection objects.

[0112] At the same time, the hierarchical relationship between inspection points and inspection objects is often represented by a flat record in the data structure. When the background program performs alarm processing, it needs to repeatedly perform multi-table associations or complex condition judgments, which is inefficient and prone to association errors, thus affecting the stable application of subsequent multi-layer device models and alarm logic.

[0113] In response, Figure 3 This is a flowchart illustrating a dynamic combined alarm method based on periodic time switching, according to another example embodiment of this application. Figure 3 As shown, in Figure 1 Before S110 of the illustrated embodiment, the method further includes:

[0114] S210. Synchronize inspection point information and inspection object information from the inspection robot system via the interface.

[0115] In this step, the access parameters of the inspection robot system can be configured through the backend. The access parameters should include at least the service address, authentication method and interface authentication information of the target inspection robot system.

[0116] Then, the preset inspection point synchronization interface is called to obtain the basic information of the currently valid inspection points in batches from the inspection robot system. The basic information of the inspection points includes at least the inspection point identifier, inspection point name, region, inspection route, and activation status.

[0117] Furthermore, the system calls the preset inspection object synchronization interface to obtain the basic information of the inspection objects associated with each inspection point in batches from the inspection robot system. The basic information of the inspection objects includes at least the inspection object identifier, the inspection object name, the inspection point identifier, and the inspection object type information.

[0118] During the synchronization process, the basic information of inspection points and inspection objects obtained from the inspection robot system is checked for data integrity and format. When a required field is missing or the format does not conform to the preset specifications, an abnormal synchronization log is recorded and the abnormal record is marked or filtered.

[0119] Finally, the verified basic information of the inspection points and the basic information of the inspection objects are stored in the corresponding basic tables of the inspection points and inspection objects in the backend database, respectively, as the basic data source for subsequent construction of the two-level tree structure and configuration of the inspection point model attributes.

[0120] S220. Based on the synchronously obtained inspection point and inspection object information, construct a two-level tree structure with inspection points as upper-level nodes and inspection objects as lower-level nodes.

[0121] In this step, you can query all inspection point records that are enabled and valid from the inspection point base table, and map each inspection point record to a higher-level node in a tree structure, where the higher-level node is uniquely identified by the inspection point identifier.

[0122] Next, query all inspection object records that are enabled or enabled by default from the inspection object base table, and attach the inspection object records to the corresponding upper-level nodes according to the inspection point identifier in the inspection object records to form a set of lower-level nodes corresponding to the inspection points.

[0123] Then, the one-to-many relationship between the upper-level nodes and the lower-level nodes is maintained in memory in the form of a tree data structure object, a nested list, or a key-value mapping, so that each inspection point node is associated with one or more inspection object nodes, or is placed in the form of an empty set when there are no inspection objects.

[0124] After the structure is built, a consistency check is performed on the two-layer tree structure. The check includes at least the following: whether the inspection point identifiers of the inspection objects can all be found in the inspection point base table; whether there are isolated inspection object nodes or duplicate inspection point identifiers; when an inconsistency is detected, an alarm log is recorded in the background and the corresponding node is marked as abnormal or temporarily excluded from alarm processing.

[0125] Finally, the completed and consistent two-level tree structure is persistently stored in the database or stored in the cache system as a serialized structure, so that the front-end page can load and configure the inspection point model attributes later.

[0126] S230. By binding the front-end page with the back-end interface, configure the corresponding first-level equipment model attributes for each inspection point, and configure the corresponding second-level equipment model attributes for each inspection object associated with the inspection point, so as to form the inspection point model attribute configuration.

[0127] Specifically, a two-level tree structure can be loaded in the front-end page, displaying each upper-level node as a tree list or hierarchical structure, and allowing users to select specific inspection point nodes.

[0128] When a user selects an inspection point node on the front-end page, the system calls the back-end binding query interface to retrieve a list of first-level device models that can be bound from the preset device model configuration library, and displays them on the front-end page in the form of a drop-down box or a selection list.

[0129] In addition, in response to the user's selection of a primary equipment model, the model identifier of the selected primary equipment model is bound to the current inspection point identifier through the front-end and back-end binding interface, and the binding relationship is submitted to the back-end for verification and temporary storage.

[0130] Expand all inspection object nodes associated with the current inspection point node on the front-end page, call the backend binding query interface for each inspection object node, retrieve the list of secondary equipment models that can be bound from the preset equipment model configuration library, and provide the user with an interactive control for selection.

[0131] Then, in response to the user's operation of selecting the secondary equipment model for each inspection object node, the model identifier of the selected secondary equipment model is bound to the corresponding inspection object identifier through the front-end and back-end binding interface, and a secondary equipment model binding record consistent with the relationship under the corresponding inspection point node is established in the back-end.

[0132] Finally, after the user completes the binding of the model attributes of the inspection point and all its inspection objects, the user submits the overall configuration through the front-end page. The back-end performs a legality check on the submitted binding data. The check includes at least: whether the same inspection point is bound to only one valid first-level equipment model, whether the same inspection object is bound to only one valid second-level equipment model, and whether the selected equipment model is in the enabled state. When the check passes, the binding result is marked as effective.

[0133] S240. Save the inspection point model attribute configuration results to the database, and load them into memory or cache when needed for the alarm processing module to call.

[0134] Specifically, the binding relationship between inspection points and primary equipment models, and the binding relationship between inspection objects and secondary equipment models, after legality verification, can be structurally encapsulated in the background to form inspection point model attribute configuration data. The configuration data includes at least the inspection point identifier, the corresponding primary equipment model identifier, the identifier of each inspection object and its corresponding secondary equipment model identifier.

[0135] Then, the model attribute configuration data of the inspection point is written into the inspection point model attribute configuration table in the backend database. The configuration table establishes a corresponding model attribute record for each inspection point and its subordinate inspection objects, and adds audit fields such as effective status identifier, version number, creation time, and update time to the configuration record.

[0136] When the alarm processing module is initialized or its configuration is changed, the currently effective configuration record is read from the inspection point model attribute configuration table, and reorganized according to the mapping rules from inspection point identifier / inspection object identifier to device model attribute. The reorganized mapping relationship is then loaded into memory or cache system.

[0137] In the caching system, the inspection point identifier and the inspection object identifier are used as a combination key or hierarchical key to store the corresponding first-level device model attributes and second-level device model attributes, so that the alarm processing module can quickly retrieve data based on the inspection point identifier and / or the inspection object identifier when it receives an inspection data request.

[0138] Finally, when the inspection point model attribute configuration is added, modified, or deleted, the mapping data of the corresponding inspection point and its associated inspection object in the cache is updated or cleared through the configuration change notification mechanism or cache invalidation mechanism, and the latest valid configuration is reloaded from the database to ensure that the alarm processing module always judges the device status based on the latest inspection point model attribute configuration during operation.

[0139] It is understandable that the above steps, before obtaining inspection data requests, first synchronize inspection point information and inspection object information from the inspection robot system through an interface. Based on this information, a two-level tree structure is constructed with inspection points as upper-level nodes and inspection objects as lower-level nodes. The front-end page binds to the back-end interface to configure corresponding first-level equipment model attributes for each inspection point and corresponding second-level equipment model attributes for each inspection object associated with it. The configuration results of the inspection point model attributes are saved to the database and loaded into memory or cache as needed for the alarm processing module to call. This can form a unified, stable and scalable inspection point model at the bottom layer of the system.

[0140] In this way, during alarm processing, the backend module can quickly retrieve the attributes of the first- and second-level equipment models bound to them by the inspection point identifier and the inspection object identifier, realizing the automatic mapping of inspection result data to multi-level equipment models. This reduces the probability of human intervention and errors when configuring and adjusting alarm logic, and improves the system's adaptability to changes in inspection points and scale expansion.

[0141] Figure 4 This is a schematic diagram illustrating the structure of a dynamic combined alarm system based on periodic time switching, according to an example embodiment of this application. Figure 4 As shown, the dynamic combined alarm system 300 based on periodic time switching provided in this embodiment includes:

[0142] The acquisition module 310 is used to acquire inspection data requests. The inspection data requests are reported by the inspection robot during the inspection process through a communication protocol. The inspection data requests include at least: inspection point identifier, inspection object identifier, and corresponding original inspection result data.

[0143] Processing module 320 is used to process the original inspection result data based on a pre-configured basic algorithm library to obtain model data corresponding to the preset equipment model;

[0144] The determination module 330 is used to determine the target theoretical state at the current moment based on a pre-configured multi-layer device model and a reference state period switching mechanism.

[0145] The judgment module 340 is used to judge the consistency of the device state based on the model data and the target theoretical state, and obtain the alarm detection result;

[0146] The alarm module 350 is used to generate alarm data and push the alarm data to the front-end display terminal when the alarm detection result meets the preset alarm conditions.

[0147] Figure 5 This is a schematic diagram of the structure of an electronic device according to an example embodiment of this application. For example... Figure 5 As shown, the electronic device 400 provided in this embodiment includes: a processor 401 and a memory 402; wherein:

[0148] Memory 402 is used to store computer programs, and the memory may also be flash memory.

[0149] Processor 401 is used to execute the execution instructions stored in the memory to implement the various steps in the above method. For details, please refer to the relevant descriptions in the preceding method embodiments.

[0150] Alternatively, the memory 402 can be either standalone or integrated with the processor 401.

[0151] When the memory 402 is a device independent of the processor 401, the electronic device 400 may further include:

[0152] Bus 403 is used to connect the memory 402 and the processor 401.

[0153] This embodiment also provides a readable storage medium storing a computer program, which, when executed by at least one processor of an electronic device, enables the electronic device to perform the methods provided in the various embodiments described above.

[0154] This embodiment also provides a program product including a computer program stored in a readable storage medium. At least one processor of an electronic device can read the computer program from the readable storage medium, and the at least one processor executes the computer program to cause the electronic device to perform the methods provided in the various embodiments described above.

[0155] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0156] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A dynamic combined alarm method based on periodic time switching, characterized in that, The method comprises the following steps: acquiring an inspection data request, wherein the inspection data request is reported by an inspection robot during an inspection process through a communication protocol, and the inspection data request at least comprises an inspection point identifier, an inspection object identifier, and corresponding original inspection result data; processing the original inspection result data based on a pre-configured basic algorithm library to obtain model data corresponding to a preset device model, comprising: obtaining a basic algorithm to be applied from algorithm configuration or query results on the side of the inspection robot through a basic algorithm configuration interface provided by a background; establishing a subordinate relationship between the basic algorithm and a primary device type and a secondary device type, and storing the basic algorithm and the subordinate relationship in the basic algorithm library; in an alarm processing process, according to the inspection point identifier and / or the inspection object identifier, calling a basic algorithm matched with a corresponding device type from the basic algorithm library to identify and convert the original inspection result data; mapping the original inspection result data processed by the basic algorithm to model data corresponding to a preset multi-layer device model structure; based on a pre-configured multi-layer device model and a benchmark state periodic switching mechanism, determining a target theoretical state corresponding to a current time, comprising: configuring a multi-layer device model, comprising: configuring benchmark state initialization parameters, including initial theoretical states of primary devices and subordinate secondary devices at a target start time, a periodic switching time interval, and a state switching sequence rule; in a back-end program, based on a start time, setting a start countdown using an expiration attribute of a cache system, subscribing to a corresponding expiration channel, receiving a start time expiration notification, and writing the initial theoretical state to the cache to obtain an initial target theoretical state after the notification; based on the periodic switching time interval, setting a state switching countdown in the cache system, and when receiving an expiration notification of the periodic countdown, switching to obtain a target theoretical state of a next period according to the initial or last target theoretical state and a preset state switching sequence rule, and updating the target theoretical state stored in the cache system; based on the model data and the target theoretical state, performing device state consistency judgment to obtain an alarm detection result; when the alarm detection result meets a preset alarm condition, generating alarm data and pushing the alarm data to a front-end display terminal.

2. The method of claim 1, wherein, The establishment of the subordinate relationship between the basic algorithm and the primary device type and the secondary device type comprises: configuring at least one primary device type and at least one secondary device type associated with the primary device type; for each secondary device type, configuring at least one basic algorithm corresponding thereto, and each basic algorithm corresponds to at least one secondary device possible state; logically associating each secondary device possible state with a corresponding primary device state to form a mapping relationship between the primary device state and a plurality of secondary device state combinations, and taking the mapping relationship as a composition basis of the multi-layer device model.

3. The method of claim 1, wherein, The configuration of the multi-layer device model comprises: for the same type of device on site, only one general primary device model is configured; A plurality of secondary device models are configured under the primary device model, and the plurality of secondary device models and the primary device model constitute a one-to-many hierarchical relationship; Based on the preset basic algorithm library, the algorithm rules corresponding to each secondary device model are pulled from the basic algorithm library, and the possible state of each secondary device model is bound with the basic algorithm identification result; According to the actual operation logic of the field device, a plurality of secondary device state combination conditions are combined through and, or, and non-basic logic operations to form a plurality of combination modes of the corresponding primary device state, so as to complete the assembly of the multi-layer device model.

4. The method of claim 1, wherein, Before the acquisition of the inspection data request, further comprising: Synchronizing inspection point information and inspection object information from the inspection robot system through an interface; Based on the synchronized inspection points and inspection object information, a two-layer tree structure is constructed with the inspection points as upper nodes and the inspection objects as lower nodes; Through the binding interface of the front-end page and the back-end, a corresponding primary device model attribute is configured for each inspection point, and a corresponding secondary device model attribute is configured for each inspection object associated with the inspection point, so as to form an inspection point model attribute configuration; The inspection point model attribute configuration result is saved to a database, and is loaded into memory or cache when needed for calling by an alarm processing module.

5. The method of claim 1, wherein, When the alarm detection result meets the preset alarm condition, alarm data is generated, and the alarm data is pushed to a front-end display terminal, comprising: When the alarm data is generated, key information related to the alarm is recorded; Based on the message pushing mechanism, the alarm data is encapsulated into an alarm message conforming to a preset format and is pushed to a preset alarm channel; The front-end display terminal subscribes to the alarm channel and performs page display, prompting or linkage processing after receiving the alarm message.

6. A dynamic combined alarm system based on periodic time switching according to any of the methods of claims 1-5, characterized in that, Comprising: An acquisition module is configured to acquire an inspection data request, wherein the inspection data request is reported by an inspection robot during an inspection process through a communication protocol, and the inspection data request at least includes an inspection point identifier, an inspection object identifier, and corresponding original inspection result data; A processing module is configured to process the original inspection result data based on a pre-configured basic algorithm library to obtain model data corresponding to a preset device model; A determination module is configured to determine a target theoretical state corresponding to a current time based on a pre-configured multi-layer device model and a reference state period switching mechanism; A judgment module is configured to perform device state consistency judgment based on the model data and the target theoretical state to obtain an alarm detection result; An alarm module is configured to generate alarm data when the alarm detection result meets a preset alarm condition, and push the alarm data to a front-end display terminal.

7. An electronic device, comprising: Comprising: A processor; And A memory configured to store executable instructions of the processor; The processor is configured to execute the executable instructions to perform the method of any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method of any one of claims 1 to 5.

Images