Blast furnace state diagnosis method and device based on rule engine

Abstract

This invention provides a blast furnace status diagnosis method and apparatus based on a rule engine, relating to the field of blast furnace condition diagnosis technology. The method includes: acquiring blast furnace data to be diagnosed from a database at regular diagnosis intervals, the data including N parameter fields; diagnosing the N parameter fields according to the parameter rule layer in the configured target rule engine to obtain a first diagnosis result; using the first diagnosis result as initial input, performing diagnosis layer by layer through M logical rule layers in a preset execution order to obtain a target diagnosis result for the data to be diagnosed; if the target diagnosis result indicates that the data to be diagnosed is normal, outputting a prompt that the current state of the blast furnace does not have a target abnormality; if the target diagnosis result indicates that the data to be diagnosed is abnormal, outputting a prompt that the current state of the blast furnace has a target abnormality.

Description

Technical Field

[0001] This invention relates to the field of blast furnace condition diagnosis technology, and in particular to a blast furnace condition diagnosis method and apparatus based on a rule engine. Background Technology

[0002] The blast furnace is the core equipment in steel production, used for smelting iron ore and producing molten iron. Its stability directly determines the output, quality, and energy consumption of molten iron, which is crucial to the company's profitability. Currently, blast furnace operation still heavily relies on human experience, and while intelligent diagnostic technology has been explored, it is still in its early stages.

[0003] Existing blast furnace condition diagnosis methods have the following limitations: most methods employ a single, flat judgment logic, directly comparing the collected parameters with fixed thresholds and triggering an alarm. This simplistic approach cannot effectively simulate the complex coupling and transmission relationships of multiple parameters and steps in the blast furnace process (for example, abnormal furnace temperature may be caused by abnormalities in multiple basic parameters such as gas composition, blast volume, and raw materials through multi-layered logic combinations), resulting in insufficient depth and accuracy of diagnosis, and frequent false alarms and missed alarms. Summary of the Invention

[0004] This invention provides a blast furnace condition diagnosis method and apparatus based on a rule engine, which addresses the problem in related technologies where the diagnostic methods for blast furnaces are too simplistic and have low accuracy in dealing with complex problems involving multiple parameters and steps.

[0005] In a first aspect, embodiments of the present invention provide a blast furnace state diagnosis method based on a rule engine, the method comprising:

[0006] At regular intervals during diagnosis, diagnostic data for the blast furnace is retrieved from the database. This diagnostic data includes N parameter fields.

[0007] The N parameter fields are diagnosed according to the parameter rule layer in the configured target rule engine to obtain a first diagnostic result. The target rule engine is a configuration file for diagnosing whether the data to be diagnosed triggers a target abnormality. The target rule engine includes a parameter rule layer and M logical rule layers, where M is a positive integer.

[0008] Using the first diagnostic result as the initial input, the diagnosis is performed layer by layer through the M logical rule layers in a preset execution order to obtain the target diagnostic result of the data to be diagnosed. The target diagnostic result indicates whether the data to be diagnosed is normal data.

[0009] If the target diagnosis result indicates that the data to be diagnosed is normal, output a prompt that the current state of the blast furnace does not have the target abnormality;

[0010] If the target diagnosis result indicates that the data to be diagnosed is abnormal, a prompt is output indicating that the current state of the blast furnace exhibits the target abnormality.

[0011] Optionally, the step of diagnosing the N parameter fields according to the parameter rule layer in the configured target rule engine to obtain a first diagnostic result includes: for each of the N parameter fields, obtaining the parameter operation rule and parameter threshold corresponding to the parameter field from the parameter rule layer of the configured target rule engine; performing operation processing on the parameter value of the parameter field according to the parameter operation rule; and comparing the result of the operation processing with the parameter threshold to obtain a parameter diagnostic result. The target rule engine is a configuration file for diagnosing whether the data to be diagnosed triggers a target abnormal phenomenon. The target rule engine includes a parameter rule layer and M logical rule layers, where M is a positive integer. The first diagnostic result is generated based on the N parameter diagnostic results.

[0012] Optionally, the M logical rule layers are distributed in a network. The step of using the first diagnostic result as initial input and performing diagnosis layer by layer through the M logical rule layers according to a preset execution order to obtain the target diagnostic result for the data to be diagnosed, wherein the target diagnostic result indicates whether the data to be diagnosed is normal data, includes: sequentially inputting the i-th layer diagnostic result into the i-th logical rule layer of the M logical rule layers, and diagnosing the i-th layer diagnostic result according to the judgment formula in the i-th logical rule layer to obtain the (i+1)-th diagnostic result, where i is sequentially 1, 2, 3...M, and the i-th layer diagnostic result includes at least the first diagnostic result, and using the (M+1)-th diagnostic result output by the M-th logical rule layer as the target diagnostic result; if the (M+1)-th diagnostic result indicates that the data to be diagnosed fully conforms to the judgment formula in the M-th logical rule layer, then the target diagnostic result indicates that the data to be diagnosed is abnormal data; if the (M+1)-th diagnostic result indicates that the data to be diagnosed does not fully conform to the judgment formula in the M-th logical rule layer, then the target diagnostic result indicates that the data to be diagnosed is normal data.

[0013] Optionally, before retrieving the data to be diagnosed from the acquisition database at each diagnostic interval, the method further includes: acquiring the acquired raw blast furnace data at each acquisition interval; cleaning the raw blast furnace data to obtain standard raw data; performing time granularity transformation on the standard raw data according to the time granularity difference between the acquisition interval and the diagnostic interval to obtain a transformation result, the transformation result including parameter values ​​corresponding to multiple raw parameter fields; storing the transformation result in the diagnostic data table corresponding to the target abnormality according to the correspondence between multiple abnormal phenomena included in the parameter transformation table and multiple raw parameter fields, wherein the N parameter fields come from the multiple raw parameter fields, the target abnormality comes from the multiple abnormal phenomena, and the data to be diagnosed comes from the diagnostic data table.

[0014] Optionally, after outputting a prompt indicating that the current state of the blast furnace has the target abnormality if the target diagnostic result indicates that the data to be diagnosed is abnormal data, the method further includes: storing the data to be diagnosed and the target diagnostic result in an abnormality result table, the abnormality result table including at least one field among the following: a unique abnormality number corresponding to the data to be diagnosed, the target abnormality corresponding to the data to be diagnosed, a logical relationship label corresponding to the data to be diagnosed, a resolution operation corresponding to the target abnormality, and a processing status corresponding to the data to be diagnosed, the logical relationship label including (M+1) diagnostic results corresponding to the data to be diagnosed.

[0015] Optionally, the target rule engine is configured through the following steps: obtaining multiple original parameter fields corresponding to the target anomaly and the logical relationship of the target anomaly from the parameter transformation table; for each of the multiple original parameter fields, configuring the original parameter field as a rule parameter within the target rule engine, the rule parameter including a parameter field, a parameter operation rule corresponding to each parameter field, and a parameter threshold corresponding to each parameter field; generating the parameter rule layer based on the parameter operation rule and parameter threshold corresponding to the parameter field; and generating M logical rules from the logical relationship of the target anomaly. The system comprises a first logical rule layer, wherein the judgment expression in the first logical rule layer is generated based on the parameter diagnosis results of each original parameter field output by the parameter rule layer, the diagnosis expression in the j-th logical rule layer is generated by referencing the diagnosis results output by any lower-level rule layer, where j is an integer greater than 1 and not greater than M, and the (M+1)-th diagnosis result output by the M-th logical rule layer is used to characterize whether the parameter value corresponding to the original parameter field triggers the target abnormal phenomenon. The lower-level rule layer is either the parameter rule layer or any one of the first logical rule layer to the (j-1)-th logical rule layer. The target rule engine is constructed based on the generated parameter rule layer and the generated M logical rule layers.

[0016] Secondly, embodiments of the present invention provide a blast furnace condition diagnosis device based on a rule engine, the device comprising:

[0017] The acquisition module is used to acquire the blast furnace diagnostic data from the acquisition database at diagnostic intervals. The diagnostic data includes N parameter fields.

[0018] The diagnostic module is used to diagnose the N parameter fields according to the parameter rule layer in the configured target rule engine to obtain a first diagnostic result. The target rule engine is a configuration file for diagnosing whether the data to be diagnosed triggers a target abnormality. The target rule engine includes a parameter rule layer and M logical rule layers, where M is a positive integer. Taking the first diagnostic result as the initial input, the module performs layer-by-layer diagnosis through the M logical rule layers in a preset execution order to obtain the target diagnostic result of the data to be diagnosed. The target diagnostic result indicates whether the data to be diagnosed is normal data.

[0019] The output module is used to output a prompt that the current state of the blast furnace does not contain the target abnormality if the target diagnosis result indicates that the data to be diagnosed is normal data; and to output a prompt that the current state of the blast furnace contains the target abnormality if the target diagnosis result indicates that the data to be diagnosed is abnormal data.

[0020] Thirdly, embodiments of the present invention provide an electronic device, comprising:

[0021] processor;

[0022] A memory for storing instructions to be executed by the processor, wherein the processor is configured to execute the instructions to implement the method as described in the first aspect.

[0023] Fourthly, embodiments of the present invention provide a storage medium that, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the method described in the first aspect.

[0024] Fifthly, embodiments of the present invention provide a computer program product, the program product comprising a computer program, the computer program being executed by a processor as described in the first aspect.

[0025] According to an embodiment of the present invention, a blast furnace status diagnosis method based on a rule engine is provided. At regular diagnostic intervals, diagnostic data for the blast furnace is retrieved from a database. This diagnostic data includes N parameter fields. The N parameter fields are diagnosed according to a parameter rule layer in a configured target rule engine to obtain a first diagnostic result. The target rule engine is a configuration file for diagnosing whether the diagnostic data triggers a target anomaly. The target rule engine includes a parameter rule layer and M logical rule layers, where M is a positive integer. Using the first diagnostic result as initial input, the M logical rule layers are used to diagnose the data layer by layer according to a preset execution order to obtain a target diagnostic result for the diagnostic data. The target diagnostic result indicates whether the diagnostic data is normal. If the target diagnostic result indicates that the diagnostic data is normal, a message indicating that the current state of the blast furnace does not exhibit the target anomaly is output. If the target diagnostic result indicates that the diagnostic data is abnormal, a message indicating that the current state of the blast furnace exhibits the target anomaly is output. Through the layered design of the target rule engine, the data to be diagnosed is diagnosed layer by layer through the parameter rule layer and the logical rule layer. This enables multi-level logical diagnosis of the data to be diagnosed, making the target diagnosis results more accurate. To a certain extent, this can solve the problem in related technologies where the diagnostic methods for blast furnaces are too simple and the detection accuracy is low when facing complex problems with multiple parameters and multiple steps. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 The flowchart of a blast furnace condition diagnosis method based on a rule engine provided by an embodiment of the present invention is shown;

[0028] Figure 2 This invention illustrates a concept for processing anomalous data according to an embodiment of the present invention;

[0029] Figure 3 This illustrates a configuration concept for parameter configuration provided in one embodiment of the present invention;

[0030] Figure 4 This illustrates a configuration concept for rule configuration provided by an embodiment of the present invention;

[0031] Figure 5 This illustrates the technical concept of modifying parameter configuration provided by one embodiment of the present invention;

[0032] Figure 6 This illustrates the technical concept of a deletion parameter configuration provided by an embodiment of the present invention;

[0033] Figure 7 This illustrates the technical concept of a blast furnace condition diagnosis method based on a rule engine provided by an embodiment of the present invention;

[0034] Figure 8 The structure of a blast furnace condition diagnostic device based on a rule engine provided in an embodiment of the present invention is shown.

[0035] Figure 9 A structural block diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0036] As described in the background section, the blast furnace is the core equipment in steel production, responsible for smelting iron ore and producing molten iron. Its furnace stability directly determines the output, quality, and energy consumption of molten iron, which is crucial to the company's profitability. Currently, blast furnace operation still heavily relies on human experience, and while intelligent diagnostic technology has been explored, it is still in its early stages.

[0037] Existing blast furnace condition diagnosis methods have the following limitations: most methods employ a single, flat judgment logic, directly comparing the collected parameters with fixed thresholds and triggering an alarm. This simplistic approach cannot effectively simulate the complex coupling and transmission relationships of multiple parameters and steps in the blast furnace process (for example, abnormal furnace temperature may be caused by abnormalities in multiple basic parameters such as gas composition, blast volume, and raw materials through multi-layered logic combinations), resulting in insufficient depth and accuracy of diagnosis, and frequent false alarms and missed alarms.

[0038] According to an embodiment of the present invention, a blast furnace status diagnosis method based on a rule engine is provided. At regular diagnostic intervals, diagnostic data for the blast furnace is retrieved from a database. This diagnostic data includes N parameter fields. The N parameter fields are diagnosed according to a parameter rule layer in a configured target rule engine to obtain a first diagnostic result. The target rule engine is a configuration file for diagnosing whether the diagnostic data triggers a target anomaly. The target rule engine includes a parameter rule layer and M logical rule layers, where M is a positive integer. Using the first diagnostic result as initial input, the M logical rule layers are used to diagnose the data layer by layer according to a preset execution order to obtain a target diagnostic result for the diagnostic data. The target diagnostic result indicates whether the diagnostic data is normal. If the target diagnostic result indicates that the diagnostic data is normal, a message indicating that the current state of the blast furnace does not exhibit the target anomaly is output. If the target diagnostic result indicates that the diagnostic data is abnormal, a message indicating that the current state of the blast furnace exhibits the target anomaly is output. Through the layered design of the target rule engine, the data to be diagnosed is diagnosed layer by layer through the parameter rule layer and the logical rule layer. This enables multi-level logical diagnosis of the data to be diagnosed, making the target diagnosis results more accurate. To a certain extent, this can solve the problem in related technologies where the diagnostic methods for blast furnaces are too simple and the detection accuracy is low when facing complex problems with multiple parameters and multiple steps.

[0039] In this embodiment of the invention, the target rule engine is a configuration file that can be flexibly configured for target anomalies. It can respond promptly to the flexible and rapid optimization needs of process engineers. At the same time, the layer-by-layer diagnosis can also transparently display the causal chain of the source of the target diagnosis results, which is convenient for quickly locating the root parameters and intermediate reasoning links that cause the anomalies, providing accurate basis for subsequent adjustment operations, and improving the reliability and practicality of the diagnosis system.

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

[0041] It should be understood that the blast furnace status diagnosis method based on a rule engine provided in this embodiment of the invention can be executed by a target device. The target device can be a single electronic device or multiple electronic devices working together. The electronic device can be a server, such as a physical server, a server cluster consisting of multiple servers, or a cloud server capable of cloud computing.

[0042] In this embodiment of the invention, the server serving as the target device can be configured with a Windows Server 2019 operating system, 64GB of RAM, and 16TB of SSD storage. It should be noted that this configuration is merely an exemplary solution; in actual applications, it can be adaptively adjusted based on the number of blast furnace diagnostic items, the complexity of diagnostic logic, the diagnostic frequency, the number of data acquisition points, and the data acquisition frequency to ensure system operating efficiency. Simultaneously, both the front-end and back-end applications of the server are hosted and deployed using IIS (Internet Information Services) to ensure stable application operation and access. Furthermore, this embodiment of the invention can also provide a client to interact with the target device, such as displaying the target device's workflow and transmitting configuration files such as the target rule engine to the target device. The client can be an operating terminal for process engineers, used to implement functions such as parameter configuration, anomaly querying, and processing. In this embodiment, the client can be a laptop with 16GB of RAM and a dedicated graphics card to meet the needs of front-end page rendering and data interaction.

[0043] Figure 1 The flowchart illustrates a blast furnace condition diagnosis method based on a rule engine provided by an embodiment of the present invention. For example... Figure 1 As shown, the blast furnace status diagnosis method based on a rule engine provided in this embodiment of the invention includes steps 110 to 150.

[0044] Step 110: At regular intervals during diagnosis, retrieve the blast furnace diagnostic data from the database. The diagnostic data includes N parameter fields.

[0045] In this embodiment of the invention, the diagnostic duration can be any preset time period. Since process times are typically long, and to conserve computing resources, the diagnostic duration can be a relatively long period, such as 10 minutes or 30 minutes. That is, diagnostic data for the blast furnace is retrieved from the acquisition database every 30 minutes. The acquisition database can be a MySQL database, the blast furnace can be any blast furnace in operation, and the diagnostic data can be real-time data of the blast furnace in operation, or it can be stage data, such as the average of all real-time data within the acquisition duration.

[0046] In this embodiment of the invention, the blast furnace exhibits various abnormal furnace conditions (hereinafter referred to as abnormal phenomena). To avoid acquiring redundant data for diagnosis, the parameter field requirements corresponding to each abnormal phenomenon are stored in a separate diagnostic data table in the database. That is, one abnormal phenomenon corresponds to one diagnostic data table, which includes the parameter fields required to determine the abnormal phenomenon. The diagnostic data table includes a table name (the database table containing the corresponding parameter fields), field names (parameter fields), parameter types (such as basic parameters or calculated parameters), and calculation order (used to determine the logical order of parameter calculations). It should be noted that, since the target rule engine described below involves logical order, the calculation results of parameters ranked earlier may be used as part of subsequent parameter calculation formulas. Therefore, the parameter calculations in step 120 can be performed according to the calculation order specified in the parameter requirement table to avoid calculation logic errors.

[0047] In this embodiment of the invention, the N parameter fields included in the data to be diagnosed can come from the same diagnostic data table, and all N parameter fields are used to determine one abnormal phenomenon, with a single judgment made using a target rule engine. Alternatively, the N parameter fields can come from different diagnostic data tables, and a composite judgment can be made using multiple target rule engines.

[0048] Step 120: Diagnose the N parameter fields according to the parameter rule layer in the configured target rule engine to obtain a first diagnostic result. The target rule engine is a configuration file for diagnosing whether the data to be diagnosed triggers a target anomaly. The target rule engine includes a parameter rule layer and M logical rule layers, where M is a positive integer.

[0049] In this embodiment of the invention, a rules engine plugin, RulesEngine, developed using the C# language, can be used as the configuration file for diagnosing whether the data to be diagnosed triggers a target anomaly, i.e., the target rules engine. The target anomalies originate from various anomalies present in the blast furnace as described in step 110. The target rules engine can originate from a client device. After the client device has configured the rules for the target anomalies, it is sent to the server, facilitating the execution of steps 120 to 150 by the server acting as the target device.

[0050] In this embodiment of the invention, the target rule engine can be stored on the server in JSON file format. Process engineers can add, delete, modify, and query rules from this JSON file through the client's front-end interface.

[0051] In this embodiment of the invention, the target rule engine includes a parameter rule layer and M logical rule layers. The parameter rule layer is used to perform operational-level judgments on parameter values ​​in the data to be diagnosed. The M logical rule layers are used to diagnose the diagnostic results of the previous rule layer sequentially according to the logical order of the causes of the target anomaly. The target rule engine file can adopt a layered design, with each layer contained in an independent workflow. The naming convention for the workflow can be uppercase letters of A, Z, etc. All judgment rules involving parameter operations are stored in layer A, i.e., the parameter rule layer described above. Diagnostic conclusion rules related to the target anomaly are stored in layer Z, i.e., the Mth logical rule layer described below. The Z-level rule layer only contains diagnostic conclusion rules, which facilitates the unified processing and output of subsequent diagnostic conclusions. Each logical rule includes a judgment formula generated based on the output diagnostic result of the previous rule layer and the logic of the target anomaly. The target rule engine performs a yes / no (true / false) judgment on each rule layer according to the logical order of AZ. After completing the judgment of each rule layer, the diagnostic result of that rule layer is generated, and the diagnostic result is used as a new input parameter to input into the next rule layer. The judgment of the next rule layer continues until the diagnostic conclusion judgment of the Z layer is completed.

[0052] Step 130: Using the first diagnostic result as initial input, the diagnosis is performed layer by layer through the M logical rule layers in a preset execution order to obtain the target diagnostic result of the data to be diagnosed. The target diagnostic result indicates whether the data to be diagnosed is normal data.

[0053] In this embodiment of the invention, after the parameter rule layer diagnosis is completed and a first diagnostic result is obtained, the first diagnostic result can be used as the initial input. Inputting the first logical rule layer among the M logical rule layers facilitates the initiation of layer-by-layer diagnosis. During the layer-by-layer diagnosis process, the first logical rule layer performs the diagnosis, matching the first diagnostic result with the judgment expression in the first logical rule layer. The matching result can be output as the second diagnostic result.

[0054] In this embodiment of the invention, the M logical rule layers are distributed in a network. Therefore, the first and second diagnostic results can be jointly input into the second logical rule layer, and so on, until the diagnostic results of the M layers are jointly input into the Mth logical rule layer, which is the Z-level rule layer, at which point the layer-by-layer diagnosis stops. After the layer-by-layer diagnosis stops, the latest diagnostic result (that is, the (M+1)th diagnostic result) is taken as the target diagnostic result, and it is determined whether the data to be diagnosed is normal data based on the target diagnostic result. If the data to be diagnosed completely conforms to all the judgments in the Mth logical rule layer, the data to be diagnosed is marked as abnormal data, and step 150 is executed; if the data to be diagnosed does not conform to any of the judgments in the Mth logical rule layer, the data to be diagnosed is marked as normal data, and step 140 is executed.

[0055] Step 140: If the target diagnosis result indicates that the data to be diagnosed is normal data, output a prompt that the current state of the blast furnace does not have the target abnormality.

[0056] Step 150: If the target diagnosis result indicates that the data to be diagnosed is abnormal data, output a prompt that the current state of the blast furnace has the target abnormal phenomenon.

[0057] In this invention, when an abnormal furnace condition is detected by the target rule engine, the abnormal detection data can be processed according to the following process: Based on the rule that triggered the abnormality, trace and obtain all relevant items (including diagnostic results, parameter values ​​of the data to be diagnosed, etc.) that caused the abnormality. Then, organize the aforementioned relevant data into a JSON format that can be directly parsed by the front-end program. This JSON format adopts a custom node and line structure, where the node is used to store parameter or conclusion information, and the line is used to represent the logical relationship between each node. Subsequently, the organized JSON format data can be stored in a fixed directory on the server or in the collection database for easy retrieval during subsequent abnormality tracing.

[0058] In this embodiment of the invention, the target rule engine can also be used to predict whether the blast furnace will produce a target abnormality based on the data to be diagnosed. The judgment can be made based on the changing trend of the data to be diagnosed, and the corresponding judgment formula can be modified in the target rule engine.

[0059] In this embodiment of the invention, step 120 may include the following processing: for each of the N parameter fields, obtain the parameter operation rules and parameter thresholds corresponding to the parameter field from the parameter rule layer of the configured target rule engine; perform operation processing on the parameter value of the parameter field according to the parameter operation rules; and compare the result of the operation processing with the parameter threshold to obtain a parameter diagnosis result. The target rule engine is a configuration file for diagnosing whether the data to be diagnosed triggers a target abnormal phenomenon. The target rule engine includes a parameter rule layer and M logical rule layers, where M is a positive integer; and generate a first diagnosis result based on the N parameter diagnosis results.

[0060] In this embodiment of the invention, for each of the N parameter fields, the parameter threshold corresponding to the parameter field is obtained from the parameter rule layer of the configured target rule engine (which can be understood as the A-level rule layer described above). The parameter value of the parameter field is compared with the parameter threshold according to the parameter operation rules of the N parameter fields included in the parameter rule layer to obtain a parameter diagnosis result. The parameter rule layer, which is the A-level rule layer, includes numerical judgment rules for parameter fields related to target anomalies. The parameter operation rules can be combinations of addition, subtraction, multiplication, division, and remainder operations or constants, and the parameter threshold can be any threshold. For example, the parameter rule layer includes rules such as "furnace top temperature - ambient temperature > 100" and "hot air pressure × 0.8 ≥ 500," where "furnace top temperature - ambient temperature" and "hot air pressure" are parameter fields, "hot air pressure × 0.8" can be a parameter operation rule, and "100" and "500" can be parameter thresholds. After comparing the parameter values ​​of the parameter fields with the parameter thresholds according to the parameter operation rules in the parameter rule layer, the comparison results of N parameter fields can be directly used as the parameter diagnosis results of the parameter rule layer. Then, step 130 is executed to input the parameter diagnosis results as the first diagnosis results into the next rule layer, which is the first logical rule layer.

[0061] In this embodiment of the invention, as described above, the M logical rule layers are distributed in a network. The diagnostic results output by the lower-level logical rule layers do not affect the judgment calculation of subsequent logical rule layers. The input of each logical rule layer can be the diagnostic results output by all preceding rule layers. That is, the input of the i-th logical rule layer includes one or more diagnostic results from the i-th layer's diagnostic results, and the i-th layer's diagnostic results include the first diagnostic result output by the parameter rule layer and the (i-1)-th layer's diagnostic results output by the (i-1)-th layer's logical rule layers.

[0062] For example, if the (i+1)th diagnosis result output by the i-th logical rule layer is (1, 0, 1), i.e. RULEI0011:1, RULEI002:0, RULEI003:1, then the judgment expression of the j-th logical rule layer can include RULEJ001:RULEI001:1 AND RULEI002:0 => RULEJ001:0, RULEJ002:RULEI001:0 OR RULEI002:0 OR RULEI003:0 => RULEJ002:1. That is, in the j-th logical rule layer, if rule J001 is negative (RULE J001: 0), the required (i+1)-th diagnostic result is (1, 0, 1), where the third 1, although not used by rule J001, is uniformly used as input to rule J001. If rule J002 is positive (RULE J002: 1), the required (i+1)-th diagnostic result is (0, 0, 0). Therefore, in order to maximize the satisfaction of subsequent logical rule layers, the M logical rule layers can be distributed in a network, and the input of each logical rule layer can be at least one or more of the diagnostic results output by all previous rule layers.

[0063] In this embodiment of the invention, step 130, using the first diagnostic result as initial input, performs diagnosis layer by layer through the M logical rule layers according to a preset execution order to determine whether the data to be diagnosed is normal data. This process may include the following steps: inputting the i-th layer diagnostic result into the i-th logical rule layer of the M logical rule layers, and diagnosing the i-th layer diagnostic result according to the judgment formula in the i-th logical rule layer to obtain the (i+1)-th diagnostic result, where i is 1, 2, 3...M in sequence. The i-th layer diagnostic result includes at least the first diagnostic result, and the (M+1)-th diagnostic result is used as the target diagnostic result. If the (M+1)-th diagnostic result indicates that the data to be diagnosed fully conforms to the judgment formula in the M-th logical rule layer, then the target diagnostic result indicates that the data to be diagnosed is abnormal data. If the (M+1)-th diagnostic result indicates that the data to be diagnosed does not fully conform to the judgment formula in the M-th logical rule layer, then the target diagnostic result indicates that the data to be diagnosed is normal data.

[0064] In this embodiment of the invention, the i-th logical rule layer can be the i-th logical rule layer arranged in logical order in the target rule engine. After the parameter diagnosis result is input into the first logical rule layer as the first diagnosis result, the layer-by-layer judgment begins, with i being 1. The first (i) diagnosis result is judged according to the diagnostic expression in the first (i) logical rule layer to obtain the second (i+1) diagnosis result. Subsequently, both the second (i+1) diagnosis result and the first diagnosis result can be input into the (i+1) logical rule layer to facilitate the diagnosis of the (i+1) diagnosis result through the judgment expression in the (i+1) logical rule layer, until the (M+1) diagnosis result is obtained as the target diagnosis result. If the (M+1) diagnosis result indicates that the data to be diagnosed conforms to the judgment expression in the M-th logical rule layer (which can be understood as the data to be diagnosed completely conforming to all the judgment expressions in the M-th logical rule layer), the target diagnosis result indicates that the data to be diagnosed is abnormal data. Accordingly, if the data to be diagnosed does not conform to any of the judgments in the Mth logical rule layer, that is, the (M+1)th diagnostic result indicates that the data to be diagnosed does not completely conform to the judgments in the Mth logical rule layer, then the target diagnostic result is considered to indicate that the data to be diagnosed is normal data.

[0065] In this embodiment of the invention, before obtaining the data to be diagnosed from the acquisition database at each diagnostic interval in step 110, the method further includes: acquiring the acquired raw blast furnace data at each acquisition interval; cleaning the raw blast furnace data to obtain standard raw data; performing time granularity conversion on the standard raw data according to the time granularity difference between the acquisition interval and the diagnostic interval to obtain a conversion result, the conversion result including parameter values ​​corresponding to multiple raw parameter fields; storing the conversion result in the diagnostic data table corresponding to the abnormal phenomenon according to the correspondence between multiple abnormal phenomena included in the parameter conversion table and multiple raw parameter fields, wherein the N parameter fields come from the multiple raw parameter fields, the target abnormal phenomenon comes from the multiple abnormal phenomena, and the data to be diagnosed comes from the diagnostic data table.

[0066] In this embodiment of the invention, technical communication can be conducted with process engineers and equipment maintenance personnel at the blast furnace site to clarify the distribution, data types, and corresponding furnace condition parameters of the data acquisition points. Raw blast furnace data transmitted from each acquisition point is acquired at each acquisition duration. Simultaneously, all data acquisition points on site are comprehensively reviewed, and relevant data are categorized and integrated according to the correlation between different furnace condition anomalies (such as abnormal furnace temperature, abnormal gas composition, etc.). Based on the classification results, a preliminary data acquisition database design is completed. This database is built on a PLC (Programmable Logic Controller) data acquisition system to ensure compatibility between data acquisition and storage.

[0067] Based on the database design and considering the data characteristics and cleaning requirements of each data collection point, data cleaning rules are designed, and the cleaned standard raw data is populated into a data dictionary table containing processing rule information. Data cleaning rules include, but are not limited to: upper and lower limits for data anomalies (used to filter out abnormal data exceeding reasonable ranges), cleaning methods (such as missing value imputation and duplicate value removal), filtering (used to eliminate data noise), and precision conversion (unifying data precision units). Additionally, the data dictionary table must contain basic information, specifically: database table name, field names, corresponding data collection point number, data unit (such as temperature unit ℃, pressure unit kPa), display precision (such as retaining 1 or 2 decimal places), and data type (such as integer or floating-point).

[0068] In this embodiment of the invention, the data cleaning procedure can be executed according to the following process: raw blast furnace data is acquired from the PLC data acquisition system, and cleaning rules are obtained from the data dictionary table. The raw data is then processed based on these cleaning rules, specifically including: removing data exceeding the upper and lower limits of anomalies, filling in missing values, eliminating data noise, and converting data precision. The processed standard raw data is then stored in the corresponding table in the database to ensure data accuracy and usability. To reduce the resource consumption of subsequent target rule engine calculations and improve diagnostic efficiency, some commonly used secondary calculation results can be continuously calculated and stored. For example, basic time-granularity mean conversion (e.g., converting minute-level data to hour-level mean data) and results from commonly used process calculation models (e.g., thermal efficiency parameters calculated based on blast furnace gas composition) are performed to obtain conversion results. Based on the correspondence between multiple anomalies and multiple raw parameter fields included in the parameter conversion table, the conversion results are stored in the diagnostic data table corresponding to the anomalies, facilitating rapid retrieval by the subsequent rule engine.

[0069] In this embodiment of the invention, after step 150, the method further includes: storing the data to be diagnosed in an anomaly result table. The anomaly result table includes at least one field from the following: a unique anomaly number corresponding to the data to be diagnosed, the target anomaly phenomenon corresponding to the data to be diagnosed, a logical relationship label corresponding to the data to be diagnosed, a resolution operation corresponding to the target anomaly phenomenon, and a processing status corresponding to the data to be diagnosed. The logical relationship label includes (M+1) diagnostic results corresponding to the data to be diagnosed. In this embodiment of the invention, the furnace condition anomaly results (including the data to be diagnosed itself and the diagnostic conclusion) obtained according to the target rule engine can be stored in the anomaly result table of the database. The anomaly result table may include a unique anomaly number that uniquely identifies each anomaly record, a textual description of the target anomaly phenomenon and its degree, and a process adjustment or equipment maintenance suggestion proposed for the target anomaly phenomenon as a resolution operation. The resolution operation can be obtained from the anomaly handling operation suggestion table through the anomaly rule number. The anomaly handling operation suggestion table is different from the target rule engine and can be maintained separately. The processing status can mark the processing progress of an anomaly (such as "unprocessed", "processing", "processed") and trace the file path, which is the absolute path of the relevant JSON file on the server related to the anomaly data to be diagnosed, facilitating subsequent tracing and querying.

[0070] In an embodiment of the present invention, Figure 2 This illustrates a concept for processing anomalous data according to an embodiment of the present invention. For example... Figure 2 As shown, in response to the marking operation that identifies the data to be diagnosed as abnormal data, an alarm signal can also be generated to facilitate further action, such as... Figure 2 The abnormal alarm shown includes at least one of the following alarm signals: message push, pop-up window, and sound signal. The abnormal alarm function is implemented by real-time monitoring of the collected database. The specific process is as follows: Database monitoring: The client's front-end page maintains real-time monitoring of the abnormal result table in the collected database. When a new abnormal record (data to be diagnosed) is detected being written, the alarm mechanism is triggered. Alarm methods include message push, automatically sending an abnormal message to the designated process manager, or a pop-up window, where a flashing red pop-up window appears on the manager's operation page while playing an alarm sound to attract their attention. In addition, alarm methods may also include information display, where the pop-up window displays key information about the new abnormality, including an abnormality description and corresponding solutions or alarm confirmation. Process personnel need to manually click the "Confirm" button in the pop-up window to close the alarm pop-up, ensuring that the manager is aware of and handles the abnormality.

[0071] In embodiments of the present invention, such as Figure 2As shown, the system also provides anomaly query and tracing for abnormal data awaiting diagnosis. Specifically, it can retrieve all furnace condition anomaly records from the last 24 hours by default, and process engineers can also customize the time range for querying. Anomaly results are displayed to process engineers in tabular form, containing fields including, but not limited to, anomaly number, anomaly description, suggested action, and processing status. Each anomaly record in the table corresponds to three action buttons: a "Mark as Processed" button, which updates the anomaly's processing status to "Processing" after the process engineer clicks it; a "Mark as Unprocessed" button, which resets the anomaly's processing status to "Unprocessed" after the process engineer clicks it; and an "Anomaly Tracing" button, which pops up an anomaly tracing chart popup after the process engineer clicks it. Multi-dimensional filtering functionality allows process engineers to query and filter by time period, type of anomaly (e.g., abnormal furnace temperature, abnormal material level), and processing status (e.g., unprocessed, processed), facilitating statistical analysis of anomaly data.

[0072] In this invention, the visualization of anomaly tracing can be achieved through secondary development based on the relation-graph-vue3 plugin. After a single anomaly tracing, the JSON file address of the data to be diagnosed is obtained, and the relevant files are read and parsed. The parsing results can then be displayed on the front end in the form of a mind map. The mind map can display all relevant intermediate conclusions and specific parameter values ​​that caused the anomaly, clearly presenting the causal chain of the anomaly (e.g., "original parameter A → intermediate calculation result B → anomaly conclusion Z"). Based on the traditional mind map, the following functions are added: logical relationship annotation, marking logical relationships in the causal chain (e.g., "greater than", "less than", "equal to", describing a series of diagnostic results that lead to the target diagnostic conclusion, i.e., from the first diagnostic result to the (i+1)th diagnostic result); actual parameter value display: displaying the actual parameter value in the corresponding node (e.g., "original parameter A: 1200℃"); and also including detailed expansion and collapse, supporting process personnel to click on a node to expand or collapse the detailed information of that node (e.g., intermediate calculation process, parameter source), which retains detailed information while facilitating the viewing of the overall causal structure.

[0073] In this embodiment of the invention, the target rule engine can be configured through the following steps: obtaining multiple original parameter fields corresponding to the target anomaly and the logical relationship of the target anomaly from the parameter conversion table; configuring each original parameter field as a rule parameter in the target rule engine for each of the multiple original parameter fields, the rule parameter including a parameter field, a parameter operation rule, and a parameter threshold; generating the parameter rule layer according to the parameter operation rule and / or parameter threshold corresponding to the original parameter field; generating M logical rule layers from the logical relationship of the target anomaly, wherein the judgment expression in the first logical rule layer is generated according to the parameter diagnosis results of each of the original parameter fields output by the parameter rule layer, the diagnosis expression of the j-th logical rule layer is generated by referencing the diagnosis results output by any lower-level rule layer, j is an integer greater than 1 and not greater than M, the (M+1)-th diagnosis result output by the M-th logical rule layer is used to characterize whether the parameter value corresponding to the original parameter field triggers the target anomaly, the lower-level rule layer is the parameter rule layer or any layer from the first logical rule layer to the (j-1)-th logical rule layer; constructing the target rule engine based on the generated parameter rule layer and the generated M logical rule layers.

[0074] In this embodiment of the invention, during the process of configuring multiple original parameter fields as rule parameters within the target rule engine, reference can be made to... Figure 3 . Figure 3 This illustrates a configuration concept for parameter configuration provided in one embodiment of the present invention. For example... Figure 3 As shown, before configuring the target rule engine, the judgment process and required diagnostic parameters for different categories of furnace condition anomalies (such as furnace temperature anomaly, material level anomaly, and gas composition anomaly) differ significantly. By configuring parameter requirements separately for each anomaly, the acquisition and calculation of irrelevant parameters can be reduced, system resource consumption can be reduced, and diagnostic efficiency can be improved. Before configuring parameters, you can obtain at least one of the following: table name, field name group, aggregation logic, data retrieval rules, and result type for the original parameter fields. The table name is the database table corresponding to the target anomaly where the original parameter field is located. The data source table for a single parameter is unique, ensuring the uniqueness and accuracy of the data source. The field name group is the set of fields in the database table corresponding to the parameter. The aggregation logic is the calculation logic used for the parameter operation rules (such as summation, average, maximum, etc.) when the original parameter field contains multiple data entries. The data retrieval rules limit the range of data retrieval, including time periods (e.g., "last 10 minutes," "2024-05-01 08:00-09:00") and the number of data entries (e.g., "latest 5 entries"). The result type is the data type of the parameter calculation result (e.g., integer, floating-point, boolean).

[0075] Subsequently, the original parameter fields are configured as rule parameters within the target rule engine through the following processing: First, the table name corresponding to the target anomaly is selected from the database table list. By calling the data dictionary and parameter conversion table, all field names of the table corresponding to the target anomaly are automatically obtained and displayed in checkbox form for the user to select the required fields. If the currently configured original parameter fields include "lower-level parameters" (such as date type parameters calculated earlier in the parameter calculation order), the date type parameter can be used as a filtering condition for the data retrieval rule, such as "retrieve the latest 1 data before the lower-level parameter [anomaly occurrence time]" or "retrieve all data between the lower-level parameters [StartTime] and [EndTime]". If the data retrieval rule limits the data volume to more than one record (such as "all data within the last 30 minutes"), then it is necessary to select aggregation logic (such as "calculate the average value of data within 30 minutes"). Finally, SQL commands are generated and compiled. A built-in compiler automatically compiles the user-configured aggregation logic and data retrieval rules into corresponding SQL command lines and stores them in the database. To enhance configuration flexibility, users with SQL knowledge can manually input SQL command lines to meet personalized parameter calculation needs. Furthermore, code verification and result preview are available: after a user submits an SQL command (whether generated by the compiler or manually entered), code verification is automatically executed. If compilation is successful, a small amount of sample data is extracted from the database for simulation calculations, and the structure of the parameter calculation results (such as field names, data types, and example values) is returned for the user to verify whether the configuration results meet expectations. If verification is successful, the parameter configuration information is stored in the parameter requirement table. If compilation fails, the specific reason for the failure (such as SQL syntax errors, missing fields, or data retrieval rule logic conflicts) is returned for the user to correct.

[0076] In this embodiment of the invention, after the parameters of the target rule engine are configured, addition, deletion, and modification operations can be performed on the parameter configuration. The addition operation can refer to the parameter configuration operation described above. All parameters already in the target rule engine support modification (except for parameter IDs, which are unique identifiers and cannot be modified) and deletion operations. Before performing a modification or deletion operation, the parameter usage table (a table in the data collection database used to record the relationship between parameters and rules) is automatically queried, and all diagnostic rules currently using the parameter are displayed. If a parameter is already referenced by a rule, it cannot be directly deleted; the rule referencing the parameter must be deleted or modified first to avoid rule calculation errors.

[0077] In this embodiment of the invention, after parameter configuration is completed, rule configuration can be performed. Rule configuration includes generating the parameter rule layer based on the parameter operation rules and / or parameter thresholds corresponding to the original parameter fields; generating M logical rule layers based on the logical relationship of the target anomaly, wherein the judgment expression in the first logical rule layer is generated based on the parameter diagnosis results of each of the original parameter fields output by the parameter rule layer, the diagnosis expression of the j-th logical rule layer is generated by referencing the diagnosis results output by any lower-level rule layer, j is an integer greater than 1 and not greater than M, and the (M+1)-th diagnosis result output by the M-th logical rule layer is used to characterize whether the parameter value corresponding to the original parameter field triggers the target anomaly. The lower-level rule layer is either the parameter rule layer or any one of the first to (j-1)-th logical rule layers; and constructing the target rule engine based on the generated parameter rule layer and the generated M logical rule layers.

[0078] Specifically, Figure 4 This illustration demonstrates a rule configuration concept provided by an embodiment of the present invention. During rule configuration, to facilitate the configuration of the logical rule layer described above, and while adhering to the workflow layering logic (AZ layer), rules can be configured from low to high in the order of "A→B→C→…→Z". The parameter sources and configuration requirements differ for rules at different levels. The parameter rule layer in the target rule engine (corresponding to level A rules in the workflow layering) is the basic calculation layer, containing all judgment rules involving parameter arithmetic operations. All parameter fields in the parameter configuration above can be directly used as the data source for level A rules. During the configuration of level A rules... First, obtain the rule ID and rule description used for quickly locating rules and matching abnormal operation suggestions. The rule ID is usually in the format RULEAXXX, such as RULEA001. The rule description is usually the custom name of the newly added Class A rule (it must reflect the meaning of the rule, such as "furnace top temperature > 1200℃"). Then, configure the calculation formula. The calculation formula must be a logical judgment statement. The page provides a standardized configuration method: displaying the "formula writing area on the left side of the equation / inequality", the "formula writing area on the right side", and the "comparison operator selection list" (such as >, <, =, ≥, ≤, ≠). The formula supports combining parameters or constants based on addition, subtraction, multiplication, division, and remainder operations (such as "furnace top temperature - ambient temperature > 100" and "hot air pressure × 0.8 ≥ 500"). Finally, record the association relationship: each time a new Class A rule is added, all parameters used by the rule are automatically associated with the current rule ID and stored in the parameter usage table to form a "parameter-rule" mapping relationship, preventing users from accidentally deleting parameters and causing rule calculation failure.

[0079] In this embodiment of the invention, after configuring the A-level rules, the correspondence between the parameters and rules in the A-level rules, i.e., the parameters, can be stored in the data collection database using a table. BZ-level rules, i.e., the j-th logical rule layer, can also be configured. BZ-level rules are logical judgment layers. During the configuration of the j-th logical rule layer, diagnostic results output from lower levels (i.e., lower-level rule layers) can be referenced for configuration. Lower-level rule layers are either parameter rule layers or one or more layers from the first logical rule layer to the (j-1)-th logical rule layer. For example, a B-level rule is based on the diagnostic results of a A-level rule, i.e., the diagnostic results of the parameter rule layer; a C-level rule is based on the diagnostic results of a A-level rule and / or the diagnostic results of a B-level rule, and so on. A Z-level rule is based on the diagnostic results of all levels of rules except Z-level. To ensure the clarity of anomaly tracing, each BZ-level rule contains only one logical judgment (i.e., AND logic or OR logic), and parameters must be selected from the already configured lower-level rules. For example, when configuring a B-level rule, only A-level rules can be selected as parameters; when configuring a C-level rule, both A-level and B-level rules can be selected as parameters. After adding a new BZ-level rule, the newly added "parent rule" is automatically marked in its "child rules" (i.e., lower-level rules), forming a "parent rule-child rule" mapping relationship to prevent users from accidentally deleting child rules, which could cause the parent rule calculation to fail. Once configured, the BZ-level rule is saved to a JSON file used as the target rule engine.

[0080] In this embodiment of the invention, if an original parameter field is added to the parameter rule layer, as described above, the added original parameter field is associated and bound to the target anomaly in the parameter conversion table, and corresponding operation rules and thresholds are set for the added original parameter field in the parameter rule layer. If a diagnostic expression is added to any of the M logical rule layers, as described above, the diagnostic result of the added diagnostic expression is configured as the input of the diagnostic expression in the next logical rule layer of the aforementioned logical rule layer.

[0081] In this embodiment of the invention, if an original parameter field is modified or deleted in the parameter rule layer, the system queries whether the original parameter field to be operated on exists in the logical rule layer based on the original parameter field to be operated on. If it exists, the system modifies the original parameter field to be operated on after modifying the original parameter field to be operated on. If the logical rule layer does not have a judgment expression generated based on the original parameter field to be operated on, the system modifies or modifies the original parameter field to be operated on. If a diagnostic expression is deleted or modified in any of the M logical rule layers, the system modifies the reference relationship between the logical rule layer above and / or the logical rule layer below the logical rule layer where the diagnostic expression to be operated is located, and then deletes or modifies the diagnostic expression to be operated on. Specifically, please refer to the description below.

[0082] In this embodiment of the invention, after the rules are configured, the configured rules can also be modified. Figure 5 This illustrates a technical concept for modifying parameter configuration according to an embodiment of the present invention, such as... Figure 5 As shown, rule modification is used to adjust the logic or parameter references of configured rules. In terms of scope, it supports modifying the rule name, calculation formula (Level A rules), logical judgment type (Level BZ rules), and referenced parameters / sub-rules, but the rule ID (unique identifier) ​​and its level (e.g., Level A, Level B) cannot be modified. During rule configuration modification, attention must be paid to synchronizing relationships. If the modification operation causes changes to the parameters (Level A rules) or sub-rules (Level BZ rules) referenced by the rule, the system will synchronously update the corresponding relationship data. For Level A rules, if the modified referenced parameters are different from the original parameters, the system automatically updates the "rule-parameter" mapping relationship in the parameter usage table, deletes the original parameter's association with the rule, and adds a new parameter's association with the rule. For Level BZ rules: if the modified referenced parent rule is different from the original parent rule, the system automatically updates the "parent rule-child rule" annotation, deletes the parent rule's annotation in the atomic rules, and adds the parent rule's annotation to the new child rules.

[0083] In this embodiment of the invention, after the rules are configured, the configured rules can also be deleted. Figure 6 This illustrates the technical concept of a deletion parameter configuration provided by an embodiment of the present invention, such as... Figure 6 As shown, rule deletion is used to remove invalid or redundant diagnostic rules. Before deleting a rule, pay attention to the deletion constraints, which means automatically checking whether the rule is referenced by a higher-level "parent rule" (e.g., when deleting a level A rule, check if a level B rule references the level A rule). If there are referencing sub-rules, the page prompts the user to delete or modify the referencing sub-rules first to avoid calculation errors in the sub-rules. If there are no referencing sub-rules, the deletion operation is performed after the user confirms. After deleting a rule, the associated data is updated synchronously. Specifically, for level A rules: delete the association relationship between the rule and all parameters in the parameter usage table; for level BZ rules: delete the parent rule annotations in the referenced sub-rules. After the deletion operation, also pay attention to workflow cleanup. If the deleted rule is the last rule in its level (e.g., level B, level C), the system will synchronously delete the corresponding workflow of that level to avoid empty levels occupying system resources and ensure the simplicity of the workflow structure.

[0084] In this embodiment of the invention, the abnormal result table also includes abnormal operation suggestions. This embodiment further provides a process for configuring abnormal operation suggestions, configuring associations such that each Z-level abnormal conclusion (i.e., the diagnostic results output by the Z-layer, such as "furnace temperature too high" or "material level too low") uniquely corresponds to one operation suggestion, forming a one-to-one mapping relationship of "abnormal conclusion - operation suggestion" to ensure the specificity of the suggestions. Specifically, the configuration of abnormal operation suggestions can be done through manual configuration, batch import, or configuration update. For manual configuration, process engineers can directly input operation suggestions through the front-end page, including but not limited to specific operation steps and parameter ranges such as "adjust hot air temperature to XX℃", "reduce coke ratio by XX%", and "check the position of the material feeding chute". For batch import, it supports batch importing expert-preset "abnormal conclusion - operation suggestion" comparison tables (in Excel or CSV format) into the system via the page upload function. Before importing, the system automatically verifies the data format (e.g., whether there are unmatched Z-level abnormal conclusions). After verification, batch configuration is completed, improving configuration efficiency. Configuration updates: When blast furnace processes are optimized or expert experience is updated, process engineers can modify or supplement existing abnormal operation suggestions through manual configuration or batch import as described above, ensuring the timeliness and accuracy of the suggestions.

[0085] In this embodiment of the invention, in order to better understand the blast furnace state method based on the rule engine provided by this embodiment of the invention, examples are given below. It should be understood that the examples are not intended to limit the scope of the invention. Figure 7 This illustrates the technical concept of a blast furnace condition diagnosis method based on a rule engine, according to an embodiment of the present invention. Figure 7 As shown, the method provided in this embodiment of the invention mainly includes two types of processing: parameter judgment and rule judgment. Firstly, in the parameter judgment process, the data is collected from MyS, which serves as the database. ql The system retrieves raw blast furnace data from the database and iterates through each raw blast furnace parameter according to the parameter configuration. The raw parameter fields are processed to obtain data to be diagnosed. The data to be diagnosed is input into the target rule engine in the form of a workflow. If the current input satisfies the current workflow, the current i-th diagnosis result is used as input to the rule layer of the next workflow until the workflow is completely traversed or does not conform to the current workflow. Based on the diagnosis result, it is determined whether there is an anomaly in the data to be diagnosed. If there is an anomaly, the relevant rules and logical relationships are integrated and stored in the anomaly result table. If there is no anomaly, the next target rule engine is used to judge the next target anomaly phenomenon.

[0086] In this embodiment of the invention, through the layered design of the target rule engine, the data to be diagnosed is diagnosed layer by layer through parameter rule layers and logical rule layers. This enables multi-level logical diagnosis of the data, resulting in higher accuracy of the target diagnosis results. To a certain extent, this addresses the problem in related technologies where the diagnostic methods for blast furnaces are too simplistic and have low accuracy when dealing with complex problems involving multiple parameters and steps. The target rule engine is a configuration file that can be flexibly configured for target anomalies, enabling timely responses to the flexible and rapid optimization needs of process engineers. Furthermore, the layered diagnosis can transparently display the causal chain of the target diagnosis results, facilitating the rapid identification of the root parameters and intermediate reasoning steps leading to the anomaly. This provides accurate evidence for subsequent adjustment operations, improving the reliability and practicality of the diagnostic system.

[0087] Figure 8 The structure of a blast furnace condition diagnosis device based on a rule engine, provided in an embodiment of the present invention, is shown. Figure 8 As shown, an embodiment of the present invention provides a blast furnace condition diagnosis device 800 based on a rule engine, comprising:

[0088] The acquisition module 810 is used to acquire the blast furnace diagnostic data from the acquisition database at diagnostic intervals, the diagnostic data including N parameter fields;

[0089] The diagnostic module 820 is used to diagnose the N parameter fields according to the parameter rule layer in the configured target rule engine to obtain a first diagnostic result. The target rule engine is a configuration file for diagnosing whether the data to be diagnosed triggers a target abnormal phenomenon. The target rule engine includes a parameter rule layer and M logical rule layers, where M is a positive integer. The first diagnostic result is used as the initial input, and the M logical rule layers are used to perform layer-by-layer diagnosis according to a preset execution order to obtain the target diagnostic result of the data to be diagnosed. The target diagnostic result indicates whether the data to be diagnosed is normal data.

[0090] The output module 830 is used to output a prompt that the current state of the blast furnace does not have the target abnormality if the target diagnosis result indicates that the data to be diagnosed is normal data; and to output a prompt that the current state of the blast furnace has the target abnormality if the target diagnosis result indicates that the data to be diagnosed is abnormal data.

[0091] It should be noted that the embodiments of the blast furnace condition diagnosis device based on the rule engine in this specification and the embodiments of the blast furnace condition diagnosis method based on the rule engine in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the corresponding embodiments of the blast furnace condition diagnosis method based on the rule engine mentioned above, and the repeated parts will not be described again.

[0092] Figure 9 This is a structural block diagram of an electronic device provided in an embodiment of this application. Figure 9 As shown, the rocket provided in this application embodiment includes a processor 910 and a memory 920, wherein the memory is used to store instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the above method.

[0093] In an exemplary embodiment, the electronic device may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0094] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory including instructions, which can be executed by a processor of a device to perform the described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc. This non-transitory computer-readable storage medium, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform... Figure 1 The method shown.

[0095] This application also provides a computer program product, including a computer program, which, when executed by a processor, performs... Figure 1 The method shown.

[0096] The above description does not provide detailed technical specifications regarding the structure of each layer. However, those skilled in the art should understand that layers and regions of desired shapes can be formed using various technical means. Furthermore, to form the same structure, those skilled in the art can also design methods that are not entirely identical to those described above. Additionally, although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be advantageously combined.

[0097] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0098] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A rule engine-based blast furnace state diagnosis method, characterized by, The method includes: At regular intervals during diagnosis, diagnostic data for the blast furnace is retrieved from the database. This diagnostic data includes N parameter fields. The N parameter fields are diagnosed according to the parameter rule layer in the configured target rule engine to obtain a first diagnostic result. The target rule engine is a configuration file for diagnosing whether the data to be diagnosed triggers a target abnormality. The target rule engine includes a parameter rule layer and M logical rule layers, where M is a positive integer. Using the first diagnostic result as the initial input, the diagnosis is performed layer by layer through the M logical rule layers in a preset execution order to obtain the target diagnostic result of the data to be diagnosed. The target diagnostic result indicates whether the data to be diagnosed is normal data. If the target diagnosis result indicates that the data to be diagnosed is normal, output a prompt that the current state of the blast furnace does not have the target abnormality; If the target diagnosis result indicates that the data to be diagnosed is abnormal, a prompt is output indicating that the current state of the blast furnace exhibits the target abnormality.

2. The method of claim 1, wherein, The step of diagnosing the N parameter fields based on the parameter rule layer in the configured target rule engine to obtain a first diagnostic result includes: For each of the N parameter fields, the parameter operation rules and parameter thresholds corresponding to the parameter field are obtained from the parameter rule layer of the configured target rule engine. The parameter values ​​of the parameter fields are processed according to the parameter operation rules, and the result of the processing is compared with the parameter thresholds to obtain the parameter diagnosis result. The target rule engine is a configuration file for diagnosing whether the data to be diagnosed triggers the target abnormal phenomenon. The target rule engine includes a parameter rule layer and M logical rule layers, where M is a positive integer. The first diagnostic result is generated based on the diagnostic results of N parameters.

3. The method of claim 1, wherein, The M logical rule layers are distributed in a network structure; The first diagnostic result is used as the initial input, and the diagnosis is performed layer by layer through the M logical rule layers according to a preset execution order to obtain the target diagnostic result of the data to be diagnosed. The target diagnostic result indicates whether the data to be diagnosed is normal data, including: The i-th layer diagnostic results are sequentially input into the i-th logical rule layer of M logical rule layers, and the i-th layer diagnostic results are diagnosed according to the judgment formula in the i-th logical rule layer to obtain the (i+1)-th diagnostic result, where i is 1, 2, 3...M in sequence. The i-th layer diagnostic result includes at least the first diagnostic result, and the (M+1)-th diagnostic result output by the M-th logical rule layer is taken as the target diagnostic result. If the (M+1)th diagnostic result indicates that the data to be diagnosed fully conforms to the judgment expression in the Mth logical rule layer, then the target diagnostic result indicates that the data to be diagnosed is abnormal data; If the (M+1)th diagnostic result indicates that the data to be diagnosed does not fully conform to the judgment expression in the Mth logical rule layer, then the target diagnostic result indicates that the data to be diagnosed is normal data.

4. The method of claim 1, wherein, Before retrieving the diagnostic data from the collection database at each diagnostic interval, the method further includes: The raw data from the blast furnace is collected at regular intervals. The raw blast furnace data is cleaned to obtain standard raw data; Based on the time granularity difference between the acquisition duration and the diagnosis duration, the standard raw data is transformed by time granularity to obtain a transformation result, which includes parameter values ​​corresponding to multiple raw parameter fields. Based on the correspondence between multiple abnormal phenomena and multiple original parameter fields included in the parameter conversion table, the conversion result is stored in the diagnostic data table corresponding to the target abnormal phenomenon. The N parameter fields come from the multiple original parameter fields, the target abnormal phenomenon comes from the multiple abnormal phenomena, and the data to be diagnosed comes from the diagnostic data table.

5. The method of claim 1, wherein, After outputting a prompt indicating that the target diagnostic result indicates that the data to be diagnosed is abnormal, and the current state of the blast furnace exhibits the target abnormality, the method further includes: The data to be diagnosed and the target diagnostic results are stored in an anomaly result table. The anomaly result table includes at least one field from the following: a unique anomaly number corresponding to the data to be diagnosed, the target anomaly phenomenon corresponding to the data to be diagnosed, a logical relationship label corresponding to the data to be diagnosed, a resolution operation corresponding to the target anomaly phenomenon, and a processing status corresponding to the data to be diagnosed. The logical relationship label includes (M+1) diagnostic results corresponding to the data to be diagnosed.

6. The method of claim 4, wherein, The target rule engine is configured through the following steps: Obtain multiple original parameter fields corresponding to the target anomaly and the logical relationship of the target anomaly from the parameter conversion table; For each of the plurality of original parameter fields, the original parameter field is configured as a rule parameter in the target rule engine. The rule parameter includes a parameter field, a parameter operation rule corresponding to each parameter field, and a parameter threshold corresponding to each parameter field. The parameter rule layer is generated based on the parameter operation rules and parameter thresholds corresponding to the parameter fields; The logical relationship of the target anomaly is generated into M logical rule layers. The judgment expression in the first logical rule layer is generated based on the parameter diagnosis results of each original parameter field output by the parameter rule layer. The diagnosis expression of the j-th logical rule layer is generated by referencing the diagnosis results output by the lower-level rule layer. j is an integer greater than 1 and not greater than M. The (M+1)-th diagnosis result output by the M-th logical rule layer is used to characterize whether the parameter value corresponding to the original parameter field triggers the target anomaly. The lower-level rule layer is one or more layers of the parameter rule layer or the first logical rule layer to the (j-1)-th logical rule layer. The target rule engine is constructed based on the generated parameter rule layer and the generated M logical rule layers.

7. A blast furnace state diagnosis apparatus based on a rule engine, characterized by, The device includes: The acquisition module is used to acquire the blast furnace diagnostic data from the acquisition database at diagnostic intervals. The diagnostic data includes N parameter fields. The diagnostic module is used to diagnose the N parameter fields according to the parameter rule layer in the configured target rule engine to obtain a first diagnostic result. The target rule engine is a configuration file for diagnosing whether the data to be diagnosed triggers a target abnormality. The target rule engine includes a parameter rule layer and M logical rule layers, where M is a positive integer. Taking the first diagnostic result as the initial input, the module performs layer-by-layer diagnosis through the M logical rule layers in a preset execution order to obtain the target diagnostic result of the data to be diagnosed. The target diagnostic result indicates whether the data to be diagnosed is normal data. The output module is used to output a prompt that the current state of the blast furnace does not contain the target abnormality if the target diagnosis result indicates that the data to be diagnosed is normal data; and to output a prompt that the current state of the blast furnace contains the target abnormality if the target diagnosis result indicates that the data to be diagnosed is abnormal data.

8. An electronic device, comprising: include: processor; A memory for storing instructions to be executed by the processor, wherein the processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 6.

9. A storage medium, characterized by When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the method as described in any one of claims 1-6.

10. A computer program product, characterised in that, The program product includes a computer program that is executed by a processor according to any one of claims 1-6.

Images