Industrial control system fault diagnosis method, computing device and storage medium

Abstract

The embodiment of the invention relates to a method for fault diagnosis of an industrial control system, computing equipment and a storage medium. The method comprises the steps of generating at least one to-be-executed diagnosis task about a current industrial control system based on a predetermined diagnosis strategy and / or a received diagnosis instruction; determining the execution weight of each to-be-executed diagnosis task at least based on the type of the to-be-executed diagnosis task and the current system state of the industrial control system; determining a real-time execution weight reference of the industrial control system based on the current system state; in response to determining that the execution weight value is higher than the real-time execution weight reference, determining an executable diagnosis task from the at least one to-be-executed diagnosis task; and executing the executable diagnosis task to generate a fault diagnosis result. Therefore, multiple fault acquisition strategies are provided, so that the fault information acquisition efficiency can be effectively improved, and the acquisition cost is reduced.

Description

Technical Field

[0001] Embodiments of the present invention generally relate to the field of industrial control, and more specifically to a method, a computing device, and a storage medium for fault diagnosis of an industrial control system. Background Art

[0002] With the rapid development of industrial automation and intelligent manufacturing, the complexity and system integration of industrial equipment are constantly improving. Fault diagnosis and maintenance have become an important part of ensuring the stability and efficient operation of industrial control systems.

[0003] Traditional methods of fault diagnosis for industrial control systems, such as scanning each component of the controller one by one, require a long time, and when a serious fault of the controller is detected, it is necessary to wait until all inspection items are scanned before the fault can be reported; for example, relying on manual operation for data collection, this method consumes a lot of human resources and reduces collection efficiency and reliability; for example, the maintenance and upgrade costs of traditional data acquisition equipment are high; for example, traditional fault collection methods are relatively fixed and single, and lack the ability to adapt to changing environments.

[0004] In summary, the traditional methods for fault diagnosis of industrial control systems have the following shortcomings: delayed acquisition of fault information, single fault collection strategy, low efficiency and high cost. Summary of the invention

[0005] In view of the above problems, the present invention provides a method, a computing device and a storage medium for industrial control system fault diagnosis, which have multiple fault collection strategies, thereby effectively improving the efficiency of fault information acquisition and reducing the collection cost.

[0006] According to a first aspect of the present invention, there is provided a method for fault diagnosis of an industrial control system, comprising: generating at least one diagnostic task to be executed regarding a current industrial control system based on a predetermined diagnostic strategy and / or a received diagnostic instruction; determining an execution weight of each diagnostic task to be executed based at least on the type of the diagnostic task to be executed and the current system state of the industrial control system; determining a real-time execution weight benchmark of the industrial control system based on the current system state; in response to determining that the execution weight value is higher than the real-time execution weight benchmark, determining an executable diagnostic task from at least one diagnostic task to be executed; and executing the executable diagnostic task to generate a fault diagnosis result.

[0007] According to a second aspect of the present invention, a computing device is provided, comprising: at least one processing unit; at least one memory, the at least one memory being coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the device to perform the steps of the method according to the first aspect.

[0008] According to a third aspect of the present invention, there is provided a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a machine, the method according to the first aspect is implemented.

[0009] According to a fourth aspect of the present invention, there is further provided a computer program product, comprising a computer program, wherein when the computer program is executed by a machine, the method of the first aspect of the present invention is performed.

[0010] In some embodiments, the type of diagnostic tasks to be performed include one or more of the following: a power-on diagnostic task, which is used to perform a comprehensive diagnosis on the controller after each power-on; a periodic diagnostic task, which is used to perform regular diagnosis on the controller as a whole and / or locally; a priority diagnostic task, which is used to perform priority diagnosis on the predetermined fault type determined in response to determining that the controller has a predetermined fault type when executing other diagnostic tasks; a preventive diagnostic task, which is used to perform fault preventive diagnosis on the controller based on the failure rate and / or remaining service life of the controller; and an event diagnostic task, which is used to generate corresponding event diagnosis for the controller based on the received diagnostic instructions.

[0011] In some embodiments, determining the execution weight of each diagnostic task to be executed based at least on the type of diagnostic task to be executed and the current system state of the industrial control system includes: determining the type of diagnostic task to be executed so as to determine current system state parameters related to the type of diagnostic task, the system state including processor state, memory state, network state, running time, and / or task state in the control system; based on the type of diagnostic task to be executed, determining the initial weight value, upper weight limit value and type parameter value corresponding to the type of diagnostic task to be executed; and calculating the execution weight of the diagnostic task to be executed based on the determined system state parameters, initial weight value, upper weight limit value and type parameter value.

[0012] In some embodiments, the method for industrial control system fault diagnosis also includes: determining the priority of the diagnostic task to be executed based on the execution weight value of at least one diagnostic task to be executed, so as to generate a sequence of diagnostic tasks to be executed; generating an executable task list based on the executable diagnostic tasks in the sequence of diagnostic tasks to be executed; and updating the executable task list based on the status changes of the diagnostic tasks to be executed and the status changes of the executable diagnostic tasks, wherein the executable task list includes at least the task number, execution weight, current status and related parameters of the diagnostic task.

[0013] In some embodiments, the method for industrial control system fault diagnosis also includes: based on the received control message, adjusting one or more of the following regarding the diagnostic task: adding a new event diagnostic task; the initial weight value, weight upper limit value and / or type parameter value of the diagnostic task type; the priority of the diagnostic task to be executed; and the priority of the executable diagnostic task.

[0014] In some embodiments, calculating the execution weight of the diagnostic task to be executed includes: when the type of the diagnostic task to be executed is a power-on diagnostic task, determining the number of executions of the power-on diagnostic task of the current controller after the current round of power-on; in response to determining that the number of executions of the power-on diagnostic task is 1, determining the execution weight of the power-on diagnostic task is 0; in response to determining that the number of executions of the power-on diagnostic task is 0, determining the startup time and a predetermined startup time benchmark of the current controller device; and in response to the startup time being greater than or equal to the predetermined startup time benchmark, calculating the execution weight of the power-on diagnostic task based on the initial weight value corresponding to the power-on diagnostic task, the upper limit weight value corresponding to the power-on diagnostic task, the startup time, and the predetermined startup time benchmark.

[0015] In some embodiments, calculating the execution weight of the diagnostic task to be executed includes: when the type of the diagnostic task to be executed is a periodic diagnostic task, determining the periodic time interval of the current periodic diagnostic task, the current system time, the previous round of periodic diagnostic time, and the current round of periodic diagnostic time, wherein the current round of periodic diagnostic time is equal to the previous round of periodic diagnostic time plus the periodic time interval; and calculating the execution weight of the current round of periodic diagnostic tasks based on the initial weight value corresponding to the current periodic diagnostic task, the upper limit weight value corresponding to the current periodic diagnostic task, the current system time, the previous round of periodic diagnostic time, the current round of periodic diagnostic time, and the periodic time interval of the current periodic diagnostic task.

[0016] In some embodiments, calculating the execution weight of the diagnostic task to be executed includes: when the type of the diagnostic task to be executed is a priority diagnostic task, determining the fault controller and fault level of the fault event so as to determine the fault weight coefficient corresponding to the fault event; and calculating the execution weight of the diagnostic task based on the initial weight value corresponding to the current fault diagnostic task and the fault weight coefficient of the fault event.

[0017] In some embodiments, calculating the execution weight of the diagnostic task to be executed includes: when the type of the diagnostic task to be executed is a preventive diagnostic task, determining the remaining service life of the current control device and the health coefficient of the current industrial control system; wherein the health coefficient is determined based on the frequency of failures of the current industrial control system within a predetermined time window; and calculating the execution weight of the preventive diagnostic task based on the remaining service life of the current control device, the health coefficient of the current industrial control system, and the initial weight value corresponding to the current preventive diagnostic task.

[0018] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The above and other features, advantages and aspects of the embodiments of the present invention will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals represent the same or similar elements.

[0020] Figure 1 A schematic diagram of a system for implementing a method for fault diagnosis of an industrial control system according to an embodiment of the present invention is shown.

[0021] Figure 2 A flow chart of a method for fault diagnosis of an industrial control system according to an embodiment of the present invention is shown.

[0022] Figure 3 A flow chart of a method for determining an execution weight of each to-be-executed diagnostic task according to an embodiment of the present invention is shown.

[0023] Figure 4 A flow chart of a method for generating an executable diagnostic task list according to an embodiment of the present invention is shown.

[0024] Figure 5 A block diagram of an electronic device according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0025] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0026] As used herein, the term "including" and its variations mean open inclusion, i.e., "including but not limited to". Unless otherwise stated, the term "or" means "and / or". The term "based on" means "based at least in part on". The terms "an example embodiment" and "an embodiment" mean "at least one example embodiment". The term "another embodiment" means "at least one additional embodiment". The terms "first", "second", etc. may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0027] As described above, the traditional methods for fault diagnosis of industrial control systems have the following shortcomings: delayed acquisition of fault information, single fault collection strategy, low efficiency and high cost.

[0028] In order to at least partially solve one or more of the above problems and other potential problems, an exemplary embodiment of the present invention proposes a scheme for fault diagnosis of an industrial control system. In the scheme of the present invention, at least one diagnostic task to be executed for the current industrial control system is generated based on a predetermined diagnostic strategy and / or a received diagnostic instruction; at least based on the type of the diagnostic task to be executed and the current system state of the industrial control system, the execution weight of each diagnostic task to be executed is determined; based on the current system state, the real-time execution weight benchmark of the industrial control system is determined; in response to determining that the execution weight value is higher than the real-time execution weight benchmark, an executable diagnostic task is determined from the at least one diagnostic task to be executed; and the executable diagnostic task is executed to generate a fault diagnosis result. The present invention can be configured in an industrial control system and an industrial environment, so that the industrial control system has multiple diagnostic modes, can determine the weights of diagnostic tasks of various diagnostic modes according to the state of the system, and can adjust the weight benchmark according to the state of the system. Through different diagnostic task scheduling and diagnostic strategy weight calculation, the diagnostic task can be dynamically adjusted according to the actual situation of the system, thereby improving the response efficiency and diagnostic accuracy of the system; it can be applied to various industrial production lines, manufacturing equipment, energy management systems, transportation equipment and other industrial devices that need to be continuously monitored and maintained.

[0029] Figure 1 FIG. 1 is a schematic diagram of a system 100 for implementing a method for diagnosing faults in an industrial control system according to an embodiment of the present invention. Figure 1 As shown in FIG, system 100 includes a diagnostic control device 110, a terminal 130, an industrial control system 150, and a network 140. The diagnostic control device 110, the terminal 130, and the industrial control system 150 can exchange data through the network 140 (eg, industrial Ethernet, local area network, Internet, etc.).

[0030] The industrial control system 150 includes multiple controllers (150-1 to 105-n), which can transmit various operating data and diagnostic data about the controllers to the diagnostic control device 110 through the network 140 or the internal network of the industrial control system; the diagnostic control device controls the generation, determination and execution of diagnostic tasks, and the diagnostic tasks can be executed on the controllers so that the controllers can feedback relevant data to the diagnostic control device 110.

[0031] The terminal 130 may have one or more terminals, providing an interactive interface and displaying the system status, fault information and diagnostic results in real time; allowing users to perform manual control and parameter adjustment, and operators and technicians can edit diagnostic instructions and diagnostic configuration instructions through the interactive interface to send to the diagnostic control device 110.

[0032] The diagnostic control device 110, for example, can accept diagnostic instructions and diagnostic configuration instructions from the terminal 130, wherein the diagnostic configuration instructions include diagnostic strategies; and based on the received diagnostic instructions and diagnostic configuration instructions, manage and execute tasks from the terminal and store the task execution results locally and report them to the terminal; and the diagnostic control device 110 can also obtain relevant data required for the operation of the industrial system from the field IO.

[0033] The diagnostic control device 110 may have one or more processing units, including dedicated processing units such as GPU, FPGA and ASIC, and general processing units such as CPU. In addition, one or more virtual machines may also be running on each diagnostic control device 110. In some embodiments, the diagnostic control device 110 includes, for example, a diagnostic task generation module 112, an execution weight determination module 114, a reference weight determination module 116, and a diagnostic task execution module 118.

[0034] The diagnostic task generating module 112 is used to generate at least one diagnostic task to be executed for the current industrial control system based on a predetermined diagnostic strategy and / or a received diagnostic instruction.

[0035] The execution weight determination module 114 is configured to determine the execution weight of each to-be-executed diagnostic task based at least on the type of the to-be-executed diagnostic task and the current system state of the industrial control system.

[0036] The reference weight determination module 116 is used to determine a real-time execution weight reference of the industrial control system based on the current system status.

[0037] The diagnostic task execution module 118 is configured to determine an executable diagnostic task from at least one diagnostic task to be executed in response to determining that the execution weight value is higher than the real-time execution weight reference, and execute the executable diagnostic task to generate a fault diagnosis result.

[0038] Figure 2 2 is a flowchart of a method 200 for use according to an embodiment of the present invention. The method 200 may be performed as follows: Figure 1 The diagnostic control device 110 shown may also be executed in Figure 5The method 200 is executed at the electronic device 500. It should be understood that the method 200 may further include additional steps not shown and / or may omit the steps shown, and the scope of the present invention is not limited in this respect.

[0039] In step 210 , the diagnosis control device 110 generates at least one to-be-executed diagnosis task for the current industrial control system based on a predetermined diagnosis strategy and / or a received diagnosis instruction.

[0040] Regarding diagnostic strategies and / or diagnostic instructions, the user can send diagnostic strategies and / or diagnostic instructions to the diagnostic control device 110 through the terminal 130, such as sending a diagnostic strategy regarding a certain diagnostic task, sending a certain diagnostic instruction, etc.; the diagnostic strategies and / or diagnostic instructions can be sent through a control message (such as a configuration message).

[0041] Regarding the predetermined diagnostic strategy, the local diagnostic software of the diagnostic control device 110 requires various parameter information to adjust the operation of the diagnostic program when it is running. These parameters are stored in the local configuration file, and the diagnostic task parameter information of the local configuration file is modified, adjusted or newly created through the data in the control message.

[0042] In some embodiments, the type of diagnostic tasks to be performed include one or more of the following: a power-on diagnostic task, which is used to perform a comprehensive diagnosis on the controller after each power-on; a periodic diagnostic task, which is used to perform regular diagnosis on the controller as a whole and / or locally; a priority diagnostic task, which is used to perform priority diagnosis on the predetermined fault type determined in response to determining that the controller has a predetermined fault type when executing other diagnostic tasks; a preventive diagnostic task, which is used to perform fault preventive diagnosis on the controller based on the failure rate and / or remaining service life of the controller; and an event diagnostic task, which is used to generate corresponding event diagnosis for the controller based on the received diagnostic instructions.

[0043] Regarding controllers, an industrial control system includes multiple controllers, each of which performs its own function in the industrial control system. The diagnostic control device 110 sends diagnostic tasks to be executed to each controller, and the task executor executes these diagnostic tasks.

[0044] The power-on diagnostic task is a comprehensive diagnosis that must be performed after the controller device is powered on. It aims to ensure that the device can perform various tasks accurately and correctly. The power-on diagnostic task can ensure that the device is fully ready for operation by comprehensively checking the device status.

[0045] Regarding periodic diagnostic tasks, the controller device needs to perform regular diagnostic tasks after power-on diagnosis. In order to prevent possible failures of the device during operation, the present invention sets up periodic diagnostic tasks. By performing a periodic scanning mechanism on the controller as a whole and its core devices, potential problems can be discovered and handled in a timely manner.

[0046] Regarding the event diagnosis task, it can be performed by a user via a remote device (e.g. Figure 1 The terminal 130 in the system sends instructions to the diagnosis control device 110 to trigger the diagnosis program in real time; the event diagnosis task can obtain the current fault information of the device more quickly and accurately without waiting for the periodic report.

[0047] Priority diagnostic tasks are used to collect and report the most critical information immediately if a core controller or other fatal failure is detected while other diagnostic tasks are being executed, without waiting for the entire diagnostic task to be completed.

[0048] Regarding preventive diagnosis tasks, preventive diagnosis is a supplement to power-on diagnosis, periodic diagnosis and event diagnosis. It mainly increases the diagnosis frequency of specific controllers according to the importance of the controller and the aging of the equipment to prevent problems with key components.

[0049] In step 220 , the diagnosis control device 110 determines the execution weight of each diagnostic task to be executed based at least on the type of the diagnostic task to be executed and the current system state of the industrial control system.

[0050] Regarding determining the execution weight of each diagnostic task to be executed, the above scheme assigns different diagnostic weights to different diagnostic tasks. Whenever the controller completes the diagnosis of a diagnostic content, it will update the diagnostic task and diagnostic weight according to the current system environment, and determine the execution target of the next round of diagnostic tasks based on the diagnostic weight. When multiple diagnostic tasks have the same weight, the execution of the diagnostic task can be determined, for example, based on the priority of the diagnostic task.

[0051] Therefore, the importance of diagnostic tasks can be quantified through the design of diagnostic weights, which serves as the basis for scheduling and executing diagnostic tasks. Compared with simple priority design, this design makes the diagnostic system more flexible.

[0052] In addition, regarding the design of diagnostic weights, the present invention designs a set of diagnostic weight intervals for each type of diagnostic task, which determines the maximum and minimum values ​​that the weight of the diagnostic task of this type can reach. The design of the weight interval constrains the weight value of the diagnostic task so that it will not cause the diagnostic operation to exceed the expected behavior in extreme cases. In addition, the diagnostic weight interval can also be adjusted through the diagnostic configuration instruction.

[0053] For example, please refer to Table 1 which illustrates the diagnosis weight intervals of the diagnosis task types mentioned in the embodiment of the present invention.

[0054] Table 1:

[0055] Please refer to Table 1, which shows that the default priority order of diagnostic tasks is: event diagnostic task, priority diagnostic task, power-on diagnostic task, periodic diagnostic task, and preventive diagnostic task; and the ranges of diagnostic weight values ​​of these diagnostic tasks are: event diagnostic task (3~9); priority diagnostic task (3~8); power-on diagnostic task (2~8); periodic diagnostic task (1~5); preventive diagnostic task (1~5).

[0056] Therefore, based on the above scheme, the weight of each diagnostic task always falls within the diagnostic weight range, and the weight ranges of different types of diagnostic tasks overlap in value. This design comprehensively and fully considers the current system status of the industrial control system. It will not necessarily execute a certain type of diagnostic task once it is generated. The actual execution weight of the diagnostic task will also fluctuate according to the system status, which helps to execute diagnostic tasks that are more in line with the current system status and have a high real-time priority first.

[0057] For example, when performing an event diagnosis task, a priority diagnosis task is generated when a fatal fault is found and its weight value is higher than the weight value of the event diagnosis task executed by the current event, thereby interrupting the event diagnosis task and performing the priority diagnosis task so that key information can be reported in a timely manner; while when performing an event diagnosis task, if a medium-level fault is found, the event diagnosis task is considered to be executed first to meet the needs of terminal operators. Regarding the determination of the severity of the fault, the fault type and severity can be pre-set based on the control message from the interrupt device, and the real-time adjustment of fault parameters through the control message is supported.

[0058] The following will combine Figure 3 The method 220 for determining the execution weight of each to-be-executed diagnostic task is described in detail and will not be repeated here.

[0059] At step 230 , the diagnostic control device 110 determines a real-time execution weight reference of the industrial control system based on the current system status.

[0060] Regarding the real-time execution weight benchmark, when a diagnostic task is generated, its diagnostic weight must be within the weight range. However, considering that the control system may have other tasks to execute at any time, in order to avoid the diagnostic task occupying resources during the busy period of the controller, thereby interfering with other normal tasks of the controller, this solution designs an execution weight benchmark. Only when the real-time weight of the diagnostic task reaches the execution weight benchmark, the diagnostic task can be executed. In addition, the execution weight benchmark also changes in real time, and its value depends on the current state of the industrial system, such as system CPU, memory, network, bandwidth and other factors. The execution weight benchmark can be adjusted according to the current system state to further allocate the computing resources of the control system, so that the better control diagnostic tasks can be executed without affecting other running tasks of the system.

[0061] Regarding other tasks in the current system, for example, real-time control tasks: these are the main tasks of the controller, responsible for real-time monitoring and control of industrial processes or equipment, such as temperature control, speed regulation, pressure maintenance, etc.; data processing tasks: including data acquisition, processing, analysis and storage, these tasks may involve real-time processing of sensor data, analysis of historical data, etc.; optimization tasks: the controller may execute optimization algorithms to improve system efficiency, reduce energy consumption or improve product quality; communication tasks: the controller needs to communicate with other systems or devices, including data exchange, command sending and status update; user interface interaction tasks: the controller may need to process input from the operator, such as setting parameters, starting / stopping operations, etc.; security monitoring tasks: ensure the safe operation of the system, including access control, anomaly detection and emergency response; maintenance and self-test tasks: maintenance tasks performed regularly, such as checking system status, updating firmware or software, and performing self-diagnostic procedures; energy management tasks: in some systems, the controller may perform energy management tasks to optimize energy use; logging and auditing tasks: record system operations and events for auditing and troubleshooting.

[0062] In step 240 , if the diagnosis control device 110 determines that the execution weight value is higher than the real-time execution weight reference, the diagnosis control device 110 determines an executable diagnosis task from the at least one to-be-executed diagnosis task.

[0063] In step 250 , the diagnosis control device 110 executes the executable diagnosis task to generate a fault diagnosis result.

[0064] Please refer to Table 1 above. For example, if the real-time execution weight reference value of the industrial control system is 6, then in the current system state, only the diagnostic task with an execution weight of 6 can be executed. Since the periodic diagnostic task (1~5) and the preventive diagnostic task (1~5) do not meet the execution weight conditions, the event diagnostic task (3~9), the priority diagnostic task (3~8), and the power-on diagnostic task (2~8) currently only have the event diagnostic task with an execution weight between 6-9, the priority diagnostic task between 6-8, and the power-on diagnostic task between 6-8. It should be understood that when executing a task, it is also necessary to determine which diagnostic task is currently being executed based on the real-time execution weights of various tasks. For example, if the current power-on diagnostic task weight is 3, there is no priority diagnostic task, and the event diagnostic task weight is 6, then the event diagnostic task (execution weight 6) is determined as the executable diagnostic task.

[0065] In some embodiments, the diagnostic control device 110 adjusts one or more of the following regarding the diagnostic task based on the received control message: adding a new event diagnostic task; the initial weight value, weight upper limit value and / or type parameter value of the diagnostic task type; the priority of the diagnostic task to be executed; and the priority of the executable diagnostic task.

[0066] In the above scheme, multiple diagnostic task types are set through multiple diagnostic modes (such as power-on diagnosis, periodic diagnosis, event diagnosis, priority diagnosis, and preventive diagnosis), so that the operating status of industrial equipment can be monitored, analyzed, and diagnosed in real time, so as to achieve efficient and intelligent fault diagnosis and preventive maintenance; it has multiple fault collection strategies to more efficiently perform real-time intelligent diagnosis of industrial systems, improve the accuracy and response speed of fault diagnosis, and reduce collection costs.

[0067] The above scheme also supports the interactive design between remote terminals and diagnostic control devices. By designing control messages and parsing control messages on the diagnostic control device and controller side, the local diagnostic strategy can be flexibly adjusted to adapt to different operating environments and improve the adaptability and diagnostic efficiency of the system. In addition, the diagnostic task scheduling strategy is improved based on the priority, execution weight and execution weight benchmark based on the system environment of the diagnostic task type, thereby optimizing the execution process of the diagnostic task, ensuring that the current optimal diagnostic strategy and diagnostic task are determined in real time and executed in a timely manner, thereby improving the efficiency and effectiveness of fault handling; and the entire diagnostic task architecture design can meet the real-time and network connection requirements of the industrial system to ensure that the system can respond quickly and operate efficiently in various environments.

[0068] Regarding the control message, it contains information about the task configuration, such as replacing the corresponding paragraphs of the local configuration files of the controller and the diagnostic control device in the form of a control message. The main process includes: the external device establishes a connection with the diagnostic control device, the external device unlocks the corresponding security level of the diagnostic system through a specific key, the external device sends a configuration message carrying configuration information to the diagnostic control device, the diagnostic control device extracts the configuration information from the control message, and performs difference, integrity and security verification, and replaces the corresponding paragraphs of the local original configuration file after passing the verification. Regarding external devices, they are, for example, cloud devices, external devices connected to the industrial system, and the operation display interface provided by the industrial system to the outside world.

[0069] Figure 3 FIG. 2 is a flow chart of a method 220 for determining the execution weight of each to-be-executed diagnostic task according to an embodiment of the present invention. Figure 1 The diagnostic control device 110 shown may also be executed in Figure 5 The method 220 is executed at the electronic device 500. It should be understood that the method 220 may further include additional steps not shown and / or may omit the steps shown, and the scope of the present invention is not limited in this respect.

[0070] In step 222, the diagnostic control device 110 determines the type of diagnostic task to be performed so as to determine current system state parameters related to the type of diagnostic task, the system state including processor state, memory state, network state, runtime, and / or task state in the control system.

[0071] In step 224 , the diagnosis control device 110 determines the initial weight value, the upper weight limit value, and the type parameter value corresponding to the type of the diagnosis task to be performed based on the type of the diagnosis task to be performed.

[0072] In step 226 , the diagnosis control device 110 calculates the execution weight of the to-be-executed diagnosis task based on the determined system state parameter, the initial weight value, the upper weight limit value, and the type parameter value.

[0073] In some embodiments, calculating the execution weight of the diagnostic task to be executed includes: when the type of the diagnostic task to be executed is a power-on diagnostic task, determining the number of executions of the power-on diagnostic task of the current controller after the current round of power-on; in response to determining that the number of executions of the power-on diagnostic task is 1, determining that the execution weight of the power-on diagnostic task is W1=0; in response to determining that the number of executions of the power-on diagnostic task is 0, determining the startup time T of the current controller device 1 and the scheduled start time benchmark T 2 ; and, in response to T 1 ≥T 2 , calculate the execution weight of the power-on diagnosis task , where W c1 is the initial weight value corresponding to the power-on diagnosis task, W m1 It is the upper limit of the weight corresponding to the power-on diagnosis task.

[0074] Regarding the weight calculation of the power-on diagnosis task, the power-on diagnosis task is only run once or not run during the power-on and power-off cycle of the current round of equipment; 1 The scheduled startup time benchmark T is not reached 2 , the power-on diagnosis task is not allowed to be run. When the device has been started for a time greater than or equal to the predetermined startup time benchmark, the greater the difference between the two times, the greater the execution weight of the power-on diagnosis task; when the system has a comprehensive diagnosis, the power-on diagnosis task will no longer be executed during the power-on and power-off cycle of this round of equipment; when the current controller has not performed a comprehensive diagnosis, as the power-on time approaches the predetermined startup time benchmark T 2 , the greater the weight of the power-on diagnosis task, the greater the power-on time is when it is greater than or equal to the predetermined startup time benchmark T 2 , the weight reaches and remains at the upper limit of the power-on diagnosis weight.

[0075] In some embodiments, calculating the execution weight of the to-be-executed diagnostic task includes: when the type of the to-be-executed diagnostic task is a periodic diagnostic task, determining the periodic time interval T of the current periodic diagnostic task z 、Current system time T d , the last cycle diagnosis time T m-1 , the diagnostic time of this cycle is T m = T m-1 +T z ; and calculate the execution weight of the diagnostic task in this cycle , where W c2 is the initial weight value corresponding to the current period diagnosis task, W m2 The upper limit of the weight corresponding to the diagnostic task in the current period.

[0076] Regarding the periodic diagnosis task, after completing a round of periodic diagnosis, the execution time of the next round of periodic diagnosis is confirmed based on the completion time and execution cycle of this round of periodic diagnosis; the closer to the target time of the periodic diagnosis, the greater the weight of the current periodic diagnosis; when the periodic diagnosis time is reached, the weight reaches the maximum value, and when the time exceeds the target time, the weight of the periodic diagnosis remains at the maximum value of its weight range.

[0077] In some embodiments, calculating the execution weight of the diagnostic task to be executed includes: when the type of the diagnostic task to be executed is a priority diagnostic task, determining the fault controller and the fault level of the fault event so as to determine the fault weight coefficient θ corresponding to the fault event; and calculating the execution weight W of the diagnostic task to be executed. 3 =Wc3 +θ, where W c3 is the initial weight value corresponding to the current fault diagnosis task.

[0078] Regarding the priority diagnosis task, for example, the fault weight coefficient 5 is determined according to the severity level of the currently discovered fault and the importance of the controller where the fault is located. The mapping relationship between the fault code and the fault weight coefficient 5 can be adjusted through remote configuration instructions. The current fault level coefficient is mapped to the difference between the upper and lower limits of the discovered diagnosis. As shown in the weight distribution diagram in Table 1, the execution weight distribution of the priority diagnosis is (3~8), so the fault level coefficient value range mapped to its fault pair is, for example, 0~5; the more serious the fault problem level currently discovered, the higher the execution weight of the current priority diagnosis.

[0079] The mapping relationship between the controller, the fault type and the fault level includes, for example, the following relationship: Level 1 (minor fault): For example, sensor accuracy degradation, poor sensor connection, slight actuator blockage, slight controller parameter imbalance, etc. These faults are usually easy to identify and repair, and have little impact on the entire system; Level 2 (moderate fault): For example, external faults, such as faults of switches, actuators, sensors, and loads, which directly affect the relevant control functions of the system; Level 3 (more serious failure): For example, hardware failure, such as problems caused by template damage. This type of failure is generally obvious and the impact is local; Level 4 (serious fault): For example, electrical faults, such as damaged electrical components, loose wiring, short circuits, etc. This type of fault may cause power supply problems in part or the entire system, which may affect safety in serious cases; Level 5 (most serious failure): for example, system failure, such as global failure of system operation, including fixed failure and accidental failure, which may lead to paralysis of the entire control system.

[0080] In some embodiments, calculating the execution weight of the diagnostic task to be executed includes: when the type of the diagnostic task to be executed is a preventive diagnostic task, determining the remaining service life F of the current control device and the health factor G of the current industrial control system; wherein the health factor G is determined based on the frequency of failures of the current industrial control system within a predetermined time window; and calculating the execution weight W of the preventive diagnostic task. 4 = W c4 ×F×G, where W c4 is the initial weight value corresponding to the current preventive diagnosis task.

[0081] Regarding the remaining service life F of the current control device, the coefficient can be adjusted, for example, by remote configuration; the larger the F value, the closer the device is to its service life.

[0082] Regarding the health coefficient G of the current industrial control system, the overall health of the system can be determined by traversing the recent fault generation situation in a time window (the frequency of faults occurring in a recent time period). The larger G is, the higher the recent failure rate of the equipment.

[0083] In some embodiments, the execution weight W of the event diagnosis task is 5 = W c5 +d; where W c5 is the initial weight value corresponding to the current event diagnosis task, d is the event coefficient, and the event coefficient d is determined according to the priority of the event. For example, a larger event coefficient d is obtained based on the user's diagnostic instruction. The value range of the event coefficient d is the difference between the upper and lower limits of the event diagnosis task execution weight interval. As shown in Table 1, the weight distribution of event diagnosis is (3, 9), so the value range of the event coefficient d mapped to it is (0, 6). For example, the event coefficient d of different events can be flexibly configured according to user type, diagnostic target, etc.

[0084] Figure 4 FIG. 4 is a flowchart of a method 400 for generating an executable diagnostic task list according to an embodiment of the present invention. The method 400 may be performed as follows: Figure 1 The diagnostic control device 110 shown may also be executed in Figure 5 The method 400 is executed at the electronic device 500. It should be understood that the method 400 may further include additional steps not shown and / or may omit the steps shown, and the scope of the present invention is not limited in this respect.

[0085] In step 402 , the diagnosis control device 110 determines the priority of the diagnostic tasks to be executed based on the execution weight value of at least one diagnostic task to be executed, so as to generate a sequence of diagnostic tasks to be executed.

[0086] In step 404 , the diagnosis control device 110 generates an executable task list based on the executable diagnostic tasks in the to-be-executed diagnostic task sequence.

[0087] In step 406 , the diagnosis control device 110 updates the executable task list based on the status changes of the diagnostic tasks to be executed and the status changes of the executable diagnostic tasks. The executable task list includes at least the task number, execution weight, current status and related parameters of the diagnostic task.

[0088] For example, please refer to Table 2, which illustrates an executable task list according to an embodiment of the present invention.

[0089] Table 2

[0090] As shown in Table 2, the IDs of multiple diagnostic tasks, real-time execution weights, and current execution states (such as executing or waiting) are shown. The relevant execution parameters are omitted here.

[0091] In the above scheme, by designing a flexible diagnostic task form system to carry and configure various diagnostic tasks, it is possible to describe and respond to different task scenarios, while enhancing the flexibility and scalability of the system. As a result, the user can obtain an executable task list from the diagnostic control device 110 through the terminal 130, so as to monitor the execution status of each diagnostic task in the industrial control system 150 in real time, so that the user can adjust the weight and priority of the diagnostic task, the configuration parameters of various scheduled tasks, and create new event diagnostic tasks through control messages, which greatly improves the flexibility and interaction of the diagnostic task, thereby improving the system diagnostic efficiency and effect.

[0092] Regarding the diagnostic task adjustment function of the control message, for example, it includes but is not limited to: modifying the start diagnostic time information of the power-on diagnosis; modifying the diagnostic interval information of the periodic diagnosis; modifying the severity information of different faults of the controller in the discovery diagnosis; modifying the life information of the controller in the preventive diagnosis; reconfiguring the execution weight form, modifying the priority sequence information of the diagnostic tasks in the executable task list, and the weight range of each diagnostic task.

[0093] Figure 5 Schematic diagram of an example electronic device 500 that can be used to implement an embodiment of the present specification is shown. Figure 1 The diagnostic control device 110 shown can be implemented by an electronic device 500. As shown, the electronic device 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) 502 or computer program instructions loaded from a storage unit 508 to a random access memory (RAM) 503. In the random access memory 503, various programs and data required for the operation of the electronic device 500 can also be stored. The central processing unit 501, the read-only memory 502, and the random access memory 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0094] Multiple components in the electronic device 500 are connected to the input / output interface 505, including: an input unit 506, such as a keyboard, a mouse, a microphone, etc.; an output unit 507, such as various types of displays, speakers, etc.; a storage unit 508, such as a disk, an optical disk, etc.; and a communication unit 509, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 509 allows the electronic device 500 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0095] The various processes and processing described above, such as methods 200 to 400, may be performed by the central processing unit 501. For example, in some embodiments, methods 200 to 400 may be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as a storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 500 via the read-only memory 502 and / or the communication unit 509. When the computer program is loaded into the random access memory 503 and executed by the central processing unit 501, one or more actions of the methods 200 to 400 described above may be performed.

[0096] The present invention relates to methods, apparatuses, systems, electronic devices, computer-readable storage media and / or computer program products. The computer program products may include computer-readable program instructions for executing various aspects of the present invention.

[0097] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. More specific examples (a non-exhaustive list) of computer-readable storage media include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punch card or a raised structure in a groove on which instructions are stored, and any suitable combination of the above. The computer-readable storage medium used herein is not to be interpreted as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted through a wire.

[0098] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge computing devices. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in each computing / processing device.

[0099] The computer program instructions for performing the operation of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect through the Internet). In some embodiments, the electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be executed by using the state information of the computer-readable program instructions to personalize and customize the electronic circuit, thereby implementing various aspects of the present invention.

[0100] Various aspects of the present invention are described herein with reference to flow charts and / or step diagrams of methods, devices (systems) and computer program products according to embodiments of the present invention. It should be understood that each of the steps in the flow charts and / or step diagrams and the combination of the steps in the flow charts and / or step diagrams can be implemented by computer-readable program instructions.

[0101] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processing unit of the computer or other programmable data processing device, a device that implements the functions / actions specified in one or more steps in the flowchart and / or step diagram is generated. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable medium storing the instructions includes a manufactured product, which includes instructions for implementing various aspects of the functions / actions specified in one or more steps in the flowchart and / or step diagram.

[0102] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more steps in the flowchart and / or step diagram.

[0103] The flowchart and step diagram in the accompanying drawings show the possible architecture, functions and operations of the system, method and computer program product according to multiple embodiments of the present invention. In this regard, each square step in the flowchart or step diagram can represent a part of a module, program segment or instruction, and a part of a module, program segment or instruction contains one or more executable instructions for realizing the specified logical function. In some alternative implementations, the functions marked in the square steps can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive square steps can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square step in the step diagram and / or the flowchart, and the combination of the square steps in the step diagram and / or the flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0104] The embodiments of the present invention have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A method for fault diagnosis of an industrial control system, characterized in that: include: Based on a predetermined diagnostic strategy and / or the received diagnostic instruction, generating at least one to-be-performed diagnostic task regarding the current industrial control system; Determining an execution weight of each to-be-executed diagnostic task based at least on the type of the to-be-executed diagnostic task and the current system state of the industrial control system; Determining a real-time execution weight benchmark for the industrial control system based on a current system state; In response to determining that the execution weight value is higher than the real-time execution weight reference, determining an executable diagnostic task from the at least one to-be-executed diagnostic task; as well as The executable diagnostic task is executed to generate a fault diagnosis result.

2. The method according to claim 1, characterized in that The types of diagnostic tasks to be performed include one or more of the following: Power-on diagnosis task, used to perform a comprehensive diagnosis on the controller after each power-on; Periodic diagnostic tasks are used to perform regular diagnosis on the entire controller and / or part of the controller; A priority diagnosis task, used to, in response to determining that a predetermined fault type occurs in the controller, perform a priority diagnosis on the determined predetermined fault type when executing other diagnosis tasks; Preventive diagnosis task, used to perform fault preventive diagnosis on the controller based on the failure rate and / or remaining service life of the controller; as well as The event diagnosis task is used to generate corresponding event diagnosis for the controller based on the received diagnosis instruction.

3. The method according to claim 2, characterized in that Based at least on the type of the diagnostic task to be performed and the current system state of the industrial control system, determining the execution weight of each diagnostic task to be performed includes: Determining the type of diagnostic task to be performed so as to determine current system state parameters related to the type of diagnostic task, the system state including processor state, memory state, network state, runtime, and / or task state in the control system; Based on the type of the to-be-performed diagnostic task, determining an initial weight value, an upper weight limit value, and a type parameter value corresponding to the type of the to-be-performed diagnostic task; and Based on the determined system state parameter, weight initial value, weight upper limit value and type parameter value, the execution weight of the to-be-executed diagnostic task is calculated.

4. The method according to claim 3, characterized in that Also includes: Determining the priority of the diagnostic task to be executed based on the execution weight value of the at least one diagnostic task to be executed, so as to generate a sequence of diagnostic tasks to be executed; Generate an executable task list based on the executable diagnostic tasks in the sequence of diagnostic tasks to be executed; as well as Based on the status changes of the diagnostic tasks to be executed and the status changes of the executable diagnostic tasks, the executable task list is updated, and the executable task list includes at least the task number, execution weight, current status and related parameters of the diagnostic task.

5. The method according to claim 2, characterized in that: The method further includes adjusting one or more of the following regarding the diagnostic task based on the received control message: Added event diagnosis tasks; The initial weight value, the upper weight limit value and / or the type parameter value of the diagnostic task type; The priority of the diagnostic task to be performed; and The priority of executable diagnostic tasks.

6. The method according to claim 3, characterized in that Calculating the execution weight of the to-be-executed diagnostic task includes: When the type of the diagnostic task to be executed is a power-on diagnostic task, determining the number of executions of the power-on diagnostic task of the current controller after the current round of power-on; In response to determining that the execution count of the power-on diagnosis task is 1, determining the execution weight of the power-on diagnosis task is 0; In response to determining that the number of executions of the power-on diagnostic task is 0, determining a startup time length and a predetermined startup time length benchmark of the current controller device; and In response to the startup duration being greater than or equal to a predetermined startup duration benchmark, the execution weight of the power-on diagnosis task is calculated based on the initial weight value corresponding to the power-on diagnosis task, the weight upper limit value corresponding to the power-on diagnosis task, the startup duration, and the predetermined startup duration benchmark.

7. The method according to claim 3, characterized in that Calculating the execution weight of the to-be-executed diagnostic task includes: When the type of the diagnostic task to be executed is a periodic diagnostic task, determining the periodic time interval of the current periodic diagnostic task, the current system time, the previous periodic diagnostic time, and the current periodic diagnostic time, wherein the current periodic diagnostic time is equal to the previous periodic diagnostic time plus the periodic time interval; and The execution weight of the current cycle diagnosis task is calculated based on the initial weight value corresponding to the current cycle diagnosis task, the upper limit weight value corresponding to the current cycle diagnosis task, the current system time, the previous cycle diagnosis time, the current cycle diagnosis time, and the periodic time interval of the current cycle diagnosis task.

8. The method according to claim 3, characterized in that Calculating the execution weight of the to-be-executed diagnostic task includes: When the type of the to-be-performed diagnostic task is a priority diagnostic task, determining a fault controller and a fault level where a fault event occurs, so as to determine a fault weight coefficient corresponding to the fault event; and Based on the initial weight value corresponding to the current fault diagnosis task and the fault weight coefficient of the fault event, the execution weight of the discovery diagnosis task is calculated.

9. The method according to claim 3, characterized in that Calculating the execution weight of the to-be-executed diagnostic task includes: When the type of the diagnostic task to be performed is a preventive diagnostic task, determining the remaining service life of the current control device and the health factor of the current industrial control system; wherein the health factor is determined based on the frequency of failures of the current industrial control system within a predetermined time window; and The execution weight of the preventive diagnosis task is calculated based on the remaining service life of the current control equipment, the health coefficient of the current industrial control system, and the initial weight value corresponding to the current preventive diagnosis task.

10. A computing device, characterized in that include: at least one processing unit; At least one memory, the at least one memory being coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the device to perform the steps of the method according to any one of claims 1 to 9.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a machine, the method according to any one of claims 1 to 9 is implemented.

12. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a machine, the method according to any one of claims 1 to 9 is performed.

Images