Method, computing device, and storage medium for industrial control system fault diagnosis

Abstract

Embodiments of the present invention relate to a method, a computing device, and a storage medium for fault diagnosis of an industrial control system. The method includes generating at least one diagnostic task to be executed for the current industrial control system based on a predetermined diagnostic policy and / or a received diagnostic instruction; determining an execution weight for 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; determining 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 benchmark; and executing the executable diagnostic task to generate a fault diagnosis result. Thereby, multiple fault collection strategies are provided, which can effectively improve the efficiency of obtaining fault information and reduce the collection cost.

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 industrial control system fault diagnosis. 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 also provided a computer program product including a computer program, and when the computer program is executed by a machine, the method according to the first aspect of the present invention is executed.

[0010] In some embodiments, the types of diagnostic tasks to be executed include one or more of the following: power-on diagnostic tasks for performing a comprehensive diagnosis once after each power-on of the controller; periodic diagnostic tasks for performing regular diagnoses on the whole and / or part of the controller; priority diagnostic tasks for, when performing other diagnostic tasks, in response to determining that the controller has a predetermined fault type, performing a priority diagnosis on the determined predetermined fault type; preventive diagnostic tasks for performing fault preventive diagnoses on the controller based on the failure rate and / or remaining service life of the controller; and event diagnostic tasks for generating corresponding event diagnoses 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 the current system state parameters related to the type of diagnostic task, where the system state includes the 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, weight upper 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, weight upper limit value, and type parameter value.

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

[0013] In some embodiments, the method for industrial control system fault diagnosis further includes: based on the received control message, adjusting one or more of the following regarding the diagnostic tasks: adding an event diagnostic task; the initial weight value, the upper limit value of the weight, and / or the 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 this 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 0; in response to determining that the number of executions of the power-on diagnostic task is 0, determining the started duration of the current controller device and the predetermined started duration benchmark; and in response to the started duration being greater than or equal to the predetermined started duration 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 value of the weight corresponding to the power-on diagnostic task, the started duration, and the predetermined started duration 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 cycle time interval of the current periodic diagnostic task, the current system time, the previous cycle diagnostic time, and the current cycle diagnostic time, where the current cycle diagnostic time is equal to the previous cycle diagnostic time plus the cycle time interval; and calculating the execution weight of the current cycle diagnostic task based on the initial weight value corresponding to the current cycle diagnostic task, the upper limit value of the weight corresponding to the current cycle diagnostic task, the current system time, the previous cycle diagnostic time, the current cycle diagnostic time, and the cycle time interval of the current cycle 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 faulty controller and the fault level of the fault event to determine the fault weight coefficient corresponding to the fault event; and calculating the execution weight of the discovery 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; where the health coefficient is determined based on the fault occurrence frequency 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 content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it used to limit the scope of the present invention. Other features of the present invention will become readily understood from the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In conjunction with the accompanying drawings and with reference to the following detailed description, the above and other features, advantages, and aspects of the embodiments of the present invention will become more apparent. In the drawings, the same or similar reference numerals denote 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 flowchart 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 flowchart of a method for determining the execution weight of each diagnostic task to be executed according to an embodiment of the present invention is shown.

[0023] Figure 4 A flowchart of a method for generating a list of executable diagnostic tasks 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 OF THE EMBODIMENTS

[0025] The following description of exemplary embodiments of the present invention is provided in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to assist in understanding, which should be considered merely exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted below.

[0026] As used herein, the term "comprising" 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 "at least partially based 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. There may be other explicit and implicit definitions below.

[0027] As described above, the deficiencies of traditional methods for fault diagnosis in industrial control systems are as follows: the acquisition of fault information lags behind, the fault collection strategy is single, the efficiency is low, and the cost is high.

[0028] To at least partially address one or more of the above problems and other potential problems, exemplary embodiments of the present invention propose a solution for fault diagnosis in industrial control systems. In the solution 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; the execution weight of each diagnostic task to be executed is determined based at least on the type of the diagnostic task to be executed and the current system state of the industrial control system; a real-time execution weight benchmark of the industrial control system is determined based on the current system state; 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, enabling the industrial control system to have multiple diagnostic modes, capable of determining the weights of diagnostic tasks in various diagnostic modes according to the system state, and capable of adjusting the weight benchmark according to the system state. Through different diagnostic task scheduling and weight calculation of diagnostic strategies, the diagnostic tasks can be dynamically adjusted according to the actual situation of the system, 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 require continuous monitoring and maintenance.

[0029] Figure 1 FIG. shows a schematic diagram of a system 100 for implementing a method for fault diagnosis in an industrial control system according to an embodiment of the present invention. As Figure 1 shown, the 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 perform data interaction through the network 140 (e.g., industrial Ethernet, local area network, Internet, etc.).

[0030] In the industrial control system 150, there are multiple controllers (150-1 to 105-n), which can transmit various operation data and diagnostic data of 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, which can be one or more, provides an interactive interface and displays the system status, fault information, and diagnostic results in real time; allows 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 receive diagnostic instructions and diagnostic configuration instructions from the terminal 130, where the diagnostic configuration instructions contain diagnostic strategies; and based on the received diagnostic instructions and diagnostic configuration instructions, manage and execute any tasks from the terminal and locally store and report the task execution results 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] Regarding the diagnostic control device 110, it can have one or more processing units, including dedicated processing units such as GPUs, FPGAs, and ASICs, as well as general-purpose processing units such as CPUs. Additionally, one or more virtual machines can also be running on each diagnostic control device 110. In some embodiments, the diagnostic control device 110, for example, includes 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] Regarding the diagnostic task generation module 112, it 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 the received diagnostic instructions.

[0035] Regarding the execution weight determination module 114, it is used to determine 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.

[0036] Regarding the reference weight determination module 116, it is used to determine the real-time execution weight reference of the industrial control system based on the current system state.

[0037] Regarding the diagnostic task execution module 118, it is used 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 The flowchart of the method 200 for... according to an embodiment of the present invention is shown. The method 200 can be executed by the diagnostic control device 110 as shown in Figure 1 shown, or can also be in Figure 5Execute at the electronic device 500 shown. It should be understood that method 200 may also include additional steps not shown and / or may omit the steps shown, and the scope of the present invention is not limited in this regard.

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

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

[0041] Regarding the predetermined diagnostic strategy, when the local diagnostic software of the diagnostic control device 110 runs, it requires various parameter information to adjust the operation of the diagnostic program. These parameters are stored in a 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 types of diagnostic tasks to be executed include one or more of the following: a power-on diagnostic task for performing a comprehensive diagnosis on the controller after each power-on; a periodic diagnostic task for performing regular diagnosis on the whole and / or part of the controller; a priority diagnostic task for performing a priority diagnosis on the determined predetermined fault type in response to determining that the controller has a predetermined fault type when performing other diagnostic tasks; a preventive diagnostic task for performing fault prevention diagnosis on the controller based on the failure rate and / or remaining service life of the controller; and an event diagnostic task for generating a corresponding event diagnosis for the controller based on the received diagnostic instruction.

[0043] Regarding the controller, in an industrial control system, there are multiple controllers, and each controller undertakes its respective function in the industrial control system. The diagnostic control device 110 sends the diagnostic tasks to be executed to each controller, and these diagnostic tasks are executed through the task executor.

[0044] Regarding the power-on diagnostic task, it is a comprehensive diagnosis that must be executed after the controller device is powered on, aiming to ensure that the device can execute various tasks accurately. The power-on diagnostic task can ensure that the device is fully prepared for operation by comprehensively checking the device status.

[0045] Regarding the periodic diagnosis task, after power-on diagnosis, the controller device needs to execute a periodic diagnosis task. To prevent possible failures during device operation, the present invention sets up a periodic diagnosis task. Through a periodic scanning mechanism for the entire controller and its core devices, potential problems can be detected and processed in a timely manner.

[0046] Regarding the event diagnosis task, for example, it can be triggered by a user sending an instruction to the diagnostic control device 110 through a remote device (such as Figure 1 the terminal 130 in it), to trigger the diagnostic program in real time; the event diagnosis task can obtain the current fault information of the device more quickly and accurately without waiting for periodic reporting.

[0047] Regarding the priority diagnosis task, when performing other diagnosis tasks, if a core controller or other critical faults are detected, the most critical information can be immediately collected and reported without waiting for the completion of the full diagnosis task.

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

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

[0050] Regarding determining the execution weight of each pending diagnosis task, in the above solution, different diagnosis weights are assigned to different diagnosis tasks. Whenever the controller completes the diagnosis of a diagnosis content, the diagnosis task and the diagnosis weight will be updated according to the current system environment. The execution target of the next round of diagnosis tasks is determined according to the diagnosis weight. When multiple diagnosis tasks have the same weight, for example, the execution of the diagnosis task can be determined according to the priority of the diagnosis task.

[0051] Thus, through the design of the diagnosis weight, the importance level of the diagnosis task can be quantified and used as the basis for scheduling and executing the diagnosis task. Compared with a simple priority design, such a design makes the diagnosis system have better flexibility.

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

[0053] For example, please refer to Table 1, which shows the diagnostic weight intervals of the diagnostic task types mentioned in the embodiments of the present invention.

[0054] Table 1:

[0055]

[0056] Please refer to Table 1, which shows that the default priority order of the diagnostic tasks is: event diagnostic task, priority diagnostic task, power-on diagnostic task, periodic diagnostic task, preventive diagnostic task; and the ranges of the diagnostic weight values of these diagnostic tasks are respectively: 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).

[0057] Thus, based on the above solution, the weight of each diagnostic task always falls within the diagnostic weight interval, and there is an overlap in the numerical values of the weight intervals of different types of diagnostic tasks. This design comprehensively and fully takes into account the current system state of the industrial control system, and does not make it inevitable for a certain type of diagnostic task to be executed once it is generated. The actual execution weight of the diagnostic task will also fluctuate according to the system state, which helps to first execute the diagnostic task that is more in line with the current system state and has a high real-time priority.

[0058] For example, when performing an event diagnostic task, if a fatal fault is found, a priority diagnostic task is generated and its weight value is made higher than the weight value of the event diagnostic task being executed currently, thereby interrupting the event diagnostic task and performing the priority diagnostic task in order to report the key information in a timely manner; while when performing an event diagnostic task, if a medium-level fault is found, it is considered to first execute the event diagnostic task to meet the needs of the terminal operator. Regarding the determination of the severity of the fault, it can be based on the control message from the interrupted device, and be pre-set for the fault type and severity, and support real-time adjustment of the fault parameters through the control message.

[0059] The following will be combined with Figure 3 Method 220 for determining the execution weight of each diagnostic task to be executed will be described in detail. Here, it will not be elaborated further.

[0060] In step 230, the diagnostic control device 110 determines the real-time execution weight benchmark of the industrial control system based on the current system state.

[0061] Regarding the real-time execution weight benchmark, when a diagnostic task is generated, its diagnostic weight must necessarily be within the weight range. However, considering that there may be other tasks to be executed in the control system at any given moment, in order to prevent the diagnostic task from occupying resources during peak controller usage and thus 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 this execution weight benchmark is the diagnostic task likely to be executed. Moreover, the execution weight benchmark also changes in real time, and its value depends on the current state of the industrial system, such as factors like system CPU, memory, network, bandwidth, etc. The execution weight benchmark can be adjusted according to the current system state to further allocate the computing resources of the control system and better ensure that diagnostic tasks can be executed without affecting other running tasks of the system.

[0062] 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, and 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, instruction sending, and status updates; user interface interaction tasks: the controller may need to process inputs from operators, such as setting parameters, starting / stopping operations, etc.; security monitoring tasks: ensuring the safe operation of the system, including access control, anomaly detection, and emergency response; maintenance and self-check tasks: regularly executed maintenance tasks, such as checking system status, updating firmware or software, executing self-diagnostic programs; energy management tasks: in some systems, the controller may execute energy management tasks to optimize energy usage; logging and auditing tasks: recording system operations and events for auditing and troubleshooting.

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

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

[0065] Please refer to Table 1 above. For example, if the real-time execution weight benchmark value of the industrial control system is 6, then in the current system state, only the diagnostic tasks with an execution weight reaching 6 can be executed. Due to the periodic diagnostic tasks (1 - 5) and preventive diagnostic tasks (1 - 5), these two types of tasks currently do not meet the execution weight conditions. For the event diagnostic tasks (3 - 9), priority diagnostic tasks (3 - 8), and power-on diagnostic tasks (2 - 8), currently only the event diagnostic tasks with an execution weight between 6 - 9, priority diagnostic tasks between 6 - 8, and power-on diagnostic tasks between 6 - 8 may become executable diagnostic tasks. It should be understood that when specifically performing tasks, it is also necessary to determine which diagnostic task to execute currently based on the real-time execution weights of various tasks. For example, if the current power-on diagnostic task weight is 3, there are no priority diagnostic tasks, and the event diagnostic task weight is 6, then the event diagnostic task (execution weight 6) is determined as the executable diagnostic task.

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

[0067] In the above solution, multiple diagnostic task types are set through multiple diagnostic modes (such as power-on diagnosis, periodic diagnosis, event diagnosis, priority diagnosis, preventive diagnosis) to enable real-time monitoring, analysis, and diagnosis of the operating status of industrial equipment, so as to achieve efficient and intelligent fault diagnosis and preventive maintenance; it has multiple fault acquisition strategies to more efficiently perform real-time intelligent diagnosis on the industrial system, improve the accuracy and response speed of fault diagnosis, and reduce the acquisition cost.

[0068] The above solution also supports the interaction design between the remote terminal and the diagnostic control device. By designing the control message and parsing the control message at the diagnostic control device and the controller side, flexible adjustment of the local diagnostic strategy can be achieved, which can adapt to different operating environments and improve the adaptability and diagnostic efficiency of the system. In addition, based on the combination of the priority, execution weight of the diagnostic task type, and the execution weight benchmark based on the system environment, the diagnostic task scheduling strategy is improved, thereby optimizing the execution process of diagnostic tasks, ensuring real-time determination of the current optimal diagnostic strategy and diagnostic tasks and timely execution, thus improving the efficiency and effect of fault handling; moreover, 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 quickly respond and operate efficiently in various environments.

[0069] Regarding the control message, it contains information such as task configuration, for example, replacing the corresponding paragraphs of the local configuration file of the controller and diagnostic control device in the form of issuing a control message. The main process includes: an 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 issues 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 differential, integrity, and security checks. After passing the checks, it replaces the corresponding paragraphs of the local original configuration file. Regarding the external device, it is, for example, a cloud device, an external device accessing the industrial system, an operation display interface provided by the industrial system, etc.

[0070] Figure 3 The flowchart of method 220 for determining the execution weight of each diagnostic task to be executed according to an embodiment of the present invention is shown. Method 220 can be executed by a diagnostic control device 110 as Figure 1 shown, or can be executed at an electronic device 500 as Figure 5 shown. It should be understood that method 220 may also include additional steps not shown and / or steps shown may be omitted, and the scope of the present invention is not limited in this regard.

[0071] In step 222, the diagnostic control device 110 determines the type of the diagnostic task to be executed in order to determine the current system state parameters related to the type of the diagnostic task. The system state includes the processor state, memory state, network state, running time, and / or task state in the control system.

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

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

[0074] 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 this power-on; in response to determining that the number of executions of the power-on diagnostic task is 1, determining that the execution weight W1 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 started duration T1 of the current controller device and the predetermined start duration reference T2; and, in response to T1≥T2, calculating the execution weight of the power-on diagnostic task where W c1 is the weight initial value corresponding to the power-on diagnostic task, W m1is the weight upper limit value corresponding to the power-on diagnosis task.

[0075] Regarding the above-mentioned weight calculation of the power-on diagnosis task, the power-on diagnosis task runs only once or does not run during the current device power-on and power-off cycle; in the case where the device startup duration T1 does not reach the predetermined startup duration benchmark T2, the power-on diagnosis task is not allowed to run. When the device startup duration is greater than or equal to the predetermined startup duration benchmark, the greater the difference between the two times, the greater the execution weight of the power-on diagnosis task; when there is a comprehensive diagnosis in the system, the power-on diagnosis task is no longer executed during the current device power-on and power-off cycle; when the current controller has not performed a comprehensive diagnosis, as the power-on time gets closer to the predetermined startup duration benchmark T2, the weight of the power-on diagnosis task becomes greater. When the power-on time is greater than or equal to the predetermined startup duration benchmark T2, the weight reaches and remains at the weight upper limit of the power-on diagnosis.

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

[0077] Regarding the periodic diagnosis task, after completing one round of periodic diagnosis, the execution time of the next round of periodic diagnosis is confirmed according to the completion time and execution cycle of the current round of periodic diagnosis; the closer to the periodic diagnosis target time, the greater the weight of the current periodic diagnosis; when reaching the periodic diagnosis time, 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 interval.

[0078] In some embodiments, calculating the execution weight of a to-be-executed diagnosis task includes: when the type of the to-be-executed diagnosis task is a priority diagnosis task, determining the faulty controller and fault level of the fault event to determine the fault weight coefficient θ corresponding to the fault event; and calculating the execution weight of the discovery diagnosis task W3 = W c3 +θ, where W c3 is the weight initial value corresponding to the current fault diagnosis task.

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

[0080] The mapping relationship between the controller and the fault type and fault level, for example, includes the following relationships:

[0081] Level 1 (minor fault): For example, sensor accuracy degradation, poor sensor connection, slight actuator blockage, slight controller parameter misadjustment, etc. These faults are usually easy to identify and repair and have little impact on the entire system.

[0082] Level 2 (medium fault): For example, external faults, such as faults in devices such as switches, actuators, sensors, and loads. These faults will directly affect the relevant control functions of the system.

[0083] Level 3 (relatively severe fault): For example, hardware faults, such as problems caused by template damage. Generally, such faults are obvious and the impact is also local.

[0084] Level 4 (severe fault): For example, electrical faults, such as electrical component damage, loose wiring, circuit short - circuit, etc. Such faults may cause power supply problems in part or the entire system and may affect safety seriously in severe cases.

[0085] Level 5 (most severe fault): For example, system faults, such as global faults in system operation, including fixed faults and accidental faults. Such faults may cause the entire control system to collapse.

[0086] 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 diagnosis task, determining the remaining service life F of the current control device and the health coefficient G of the current industrial control system; wherein, the health coefficient G is determined based on the fault occurrence frequency of the current industrial control system within a predetermined time window; and calculating the execution weight of the preventive diagnosis task W4 = W c4 ×F×G, where W c4 is the initial weight value corresponding to the current preventive diagnosis task.

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

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

[0089] In some embodiments, the execution weight W5 of the event diagnosis task = W c5 + d; where W c5 is the initial weight value corresponding to the current event diagnosis task, and d is the event coefficient. 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 diagnosis instruction. The value range of the event coefficient d is the difference between the upper and lower limits of the execution weight interval of the event diagnosis task. As shown in Table 1, the weight distribution of event diagnosis is (3, 9), so the value range mapped to the event coefficient d is (0, 6). For example, d can be flexibly configured for different events according to the user type, diagnosis target, etc.

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

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

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

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

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

[0095] Table 2

[0096]

[0097] As shown in Table 2, it illustrates the ID numbers of multiple diagnostic tasks, the real-time execution weights, and the current execution status (such as in execution, waiting), and the relevant execution parameters are omitted here.

[0098] In the above solution, by designing a flexible diagnostic task form system to carry and configure various diagnostic tasks, it can describe and handle different task scenarios, while enhancing the flexibility and scalability of the system. Thus, the user can obtain an executable task list from the diagnostic control device 110 through the terminal 130 to facilitate real-time monitoring of the execution status of each diagnostic task in the industrial control system 150, so that the user can adjust the weights, priorities, configuration parameters of various scheduled tasks, and create new event diagnostic tasks through control messages, greatly improving the flexibility and interaction ability of diagnostic tasks, thereby improving the system diagnosis efficiency and effect.

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

[0100] Figure 5 The schematic step diagram of an example electronic device 500 that can be used to implement the embodiments of the content of this specification is shown. For example, as Figure 1 shown, the diagnostic control device 110 can be implemented by the electronic device 500. As shown in the figure, the electronic device 500 includes a central processing unit (CPU) 501, which can execute various appropriate actions and processes according to the computer program instructions stored in the read-only memory (ROM) 502 or the computer program instructions loaded from the storage unit 508 into the 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 through a bus 504. The input / output (I / O) interface 505 is also connected to the bus 504.

[0101] 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 disc, 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.

[0102] Each of the processes and treatments described above, such as methods 200 to 400, may be executed by the central processing unit 501. For example, in some embodiments, methods 200 to 400 may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed onto 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 methods 200 to 400 described above may be performed.

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

[0104] 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 foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium 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 disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device, such as a punched card or raised structures in grooves storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage medium as used herein is not construed as being a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.

[0105] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to various computing / processing devices, 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 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 the computer-readable storage medium in each computing / processing device.

[0106] The computer program instructions for performing the operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine - related 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 the "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, executed as a stand - alone software package, partially on the user's computer and 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., through the Internet using an Internet service provider). In some embodiments, by using the state information of the computer - readable program instructions to customize an electronic circuit, such as a programmable logic circuit, a field - programmable gate array (FPGA), or a programmable logic array (PLA), the electronic circuit can execute the computer - readable program instructions to implement various aspects of the present invention.

[0107] Aspects of the present invention are described herein with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the invention. It should be understood that each step of the flowcharts and / or block diagrams, and combinations of steps in the flowcharts and / or block diagrams, can be implemented by computer - readable program instructions.

[0108] 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 apparatus to produce a machine such that the instructions, when executed by the processing unit of the computer or other programmable data - processing apparatus, create a means for implementing the functions / acts specified in one or more steps of the flowchart and / or block diagram. These computer - readable program instructions can also be stored in a computer - readable storage medium, which causes a computer, a programmable data - processing apparatus, and / or other devices to operate in a particular manner. Thus, the computer - readable medium storing the instructions comprises a manufacture, which includes instructions for implementing various aspects of the functions / acts specified in one or more steps of the flowchart and / or block diagram.

[0109] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other devices to produce a computer-implemented process such that the instructions executed on the computer, other programmable data processing apparatus, or other devices implement the functions / acts specified in one or more of the blocks of the flowchart and / or block diagram.

[0110] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, a segment of code, or a portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two consecutive blocks may in fact be executed substantially in parallel, or they may sometimes be executed in the reverse order, depending upon the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0111] The embodiments of the present invention have been described above. 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 choice of terms used herein is intended to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable other ordinary skilled artisans in the art to understand the embodiments disclosed herein.

Claims

1. A method for fault diagnosis of industrial control systems, characterized in that, Including: Generating at least one diagnostic task to be executed for the current industrial control system based on a predetermined diagnostic strategy and / or the received diagnostic instruction; Determining the execution weight of each diagnostic task to be executed based at least on the type of the diagnostic task to be executed, the weight interval of the diagnostic task to be executed, and the current system state of the industrial control system. The weight interval of the diagnostic task to be executed determines the maximum and minimum values of the weight of this type of diagnostic task. There are numerical overlaps in the weight intervals of different types of diagnostic tasks, and the diagnostic weight interval is adjusted through a diagnostic configuration instruction; Determining a real-time execution weight benchmark of the industrial control system based on the current system state. The system state includes the task state in the control system. The tasks in the control system include diagnostic tasks and other tasks. The other tasks at least include real-time control tasks, data processing tasks, optimization tasks, communication tasks, energy management tasks, interaction tasks, maintenance and self-check tasks; Determining an executable diagnostic task from the 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 benchmark; And Executing the executable diagnostic task to generate a fault diagnosis result; And Real-time adjusting diagnostic tasks and fault parameters through control messages, at least including: adjusting the severity information of different faults, adjusting the fault weight coefficient, reconfiguring the execution weight form, modifying the priority sequence information of diagnostic tasks in the executable task list, and adjusting the weight intervals of each diagnostic task.

2. The method according to claim 1, wherein The types of diagnostic tasks to be executed include one or more of the following: Power-on diagnostic task, used for a comprehensive diagnosis after each power-on of the controller; Periodic diagnostic task, used for periodic diagnosis of the whole and / or part of the controller; Priority diagnostic task, used for performing a priority diagnosis for the determined predetermined fault type in response to determining that the controller has a predetermined fault type when executing other diagnostic tasks; Preventive diagnostic task, used for fault preventive diagnosis of the controller based on the failure rate and / or remaining service life of the controller; And Event diagnostic task, used for generating a corresponding event diagnosis for the controller based on the received diagnostic instruction.

3. The method according to claim 2, wherein Determining 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 includes: Determining the type of the diagnostic task to be executed to determine the current system state parameters related to the type of the diagnostic task. The system state also includes the processor state, memory state, network state, and / or running time; Based on the type of the diagnostic task to be executed, determining the weight initial value, weight upper limit value, and type parameter value corresponding to the type of the diagnostic task to be executed; and Calculating the execution weight of the diagnostic task to be executed based on the determined system state parameters, weight initial value, weight upper limit value, and type parameter value.

4. The method according to claim 3, characterized in that, Also including: Determining the priority of the diagnostic tasks to be executed based on the high and low of the execution weight values of the at least one diagnostic task to be executed 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 Update the list of executable tasks based on the status changes of the diagnostic tasks to be executed and the status changes of the executable diagnostic tasks. The list of executable tasks includes at least the task number, execution weight, current status, and related parameters of the diagnostic tasks.

5. The method according to claim 2, characterized in that It also includes adjusting one or more of the following regarding the diagnostic tasks based on the received control messages: Add an 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 tasks to be executed; and The priority of the executable diagnostic tasks.

6. The method according to claim 3, wherein Calculating the execution weight of the diagnostic tasks to be executed includes: When the type of the diagnostic task to be executed is a power-on diagnostic task, determine the number of executions of the power-on diagnostic task by the current controller after this power-on; In response to determining that the number of executions of the power-on diagnostic task is 1, determine that 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, determine the elapsed startup time of the current controller device and the predetermined startup time benchmark; and In response to the elapsed startup time being greater than or equal to the predetermined startup time benchmark, calculate the execution weight of the power-on diagnostic task based on the initial weight value corresponding to the power-on diagnostic task, the weight upper limit value corresponding to the power-on diagnostic task, the elapsed startup time, and the predetermined startup time benchmark.

7. The method according to claim 3, characterized in that, Calculating the execution weight of the diagnostic tasks to be executed includes: When the type of the diagnostic task to be executed is a periodic diagnostic task, determine the cycle 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, where the current round of periodic diagnostic time is equal to the previous round of periodic diagnostic time plus the cycle time interval; and Calculate 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 weight upper limit 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 cycle time interval of the current periodic diagnostic task.

8. The method according to claim 3, wherein Calculating the execution weight of the diagnostic tasks to be executed includes: When the type of the diagnostic task to be executed is a priority diagnostic task, determine the faulty controller and the fault level of the fault event to determine the fault weight coefficient corresponding to the fault event; and Calculate the execution weight of the discovery diagnostic task based on the initial weight value corresponding to the current fault diagnostic task and the fault weight coefficient of the fault event.

9. The method according to claim 3, characterized in that, Calculating the execution weight of the diagnostic tasks to be executed includes: When the type of the diagnostic task to be executed is a preventive diagnostic task, determine the remaining service life of the current control device and the health coefficient of the current industrial control system; where the health coefficient is determined based on the fault occurrence frequency of the current industrial control system within a predetermined time window; and Calculate 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.

10. A computing device, characterized in that, It includes: 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, The computer program, when executed by a machine, implements the method according to any one of claims 1 to 9.

12. A computer program product, comprising a computer program, characterized in that, The computer program, when executed by a machine, performs the method according to any one of claims 1 - 9.

Images