Intelligent fault diagnosis method and device

Abstract

The invention relates to the technical field of fault diagnosis, in particular to an intelligent fault diagnosis method and device, and the method comprises the steps: obtaining controller data related to a fault, the controller data comprising any one or more of input data, intermediate process data and output data generated in a plurality of controller scanning cycles; acquiring a controller program corresponding to the controller data related to the fault; the controller data related to the fault is played back through the controller program, fault diagnosis is carried out, the diagnosis result is obtained, and compared with playback of only single controller data, the controller data related to the fault is played back and displayed in the corresponding controller program, so that the fault diagnosis efficiency is improved. The controller data at the fault moment and the controller program corresponding to the data can be more visually and completely played back and displayed, and the fault source is quickly determined based on the logic association relationship among the controller data in the controller program, so that intelligent fault diagnosis is realized.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of fault diagnosis, and in particular to a fault intelligent diagnosis method and device. BACKGROUND

[0002] Intelligent manufacturing refers to a new technology that actively applies information and communication technology to the manufacturing process, which is changing the global manufacturing economy. With the advent of the Industry 4.0 era, intelligent manufacturing will integrate more digital technologies with production systems, and the accompanying technologies include 5G / 6G communication technology, Internet of Things technology, artificial intelligence technology, cloud computing technology, and reprogrammable robot technology, thereby forming a super intelligent factory.

[0003] The core of intelligent manufacturing is data, and the acquisition, management, and use of data are important. Among them, a large number of high-precision and high-sampling-frequency sensors are connected in the industrial field. By acquiring thousands of high-frequency sensor data, the most comprehensive running data of all devices can be obtained in real time, and the running state of all devices can be monitored in real time, and an alarm can be given in time when a device fails or abnormally, so that relevant personnel can intervene in time to ensure the safe and stable operation of the production line.

[0004] However, the high-frequency sensor data generated in the actual production process of the industrial field is very large, and the sensor data corresponding to the conventional PLC controller engineering file is as high as tens of thousands. If all the sensor data corresponding to all PLC engineering files at the fault moment is simultaneously diagnosed for fault, a large amount of human resources and network resources will be consumed, and higher requirements will be put forward for the hardware performance and computing power resources required for fault diagnosis. At the same time, it will also cause the fault diagnosis time to be infinitely prolonged, and the device fault cannot be solved at the fastest speed. Long-time device failure will inevitably lead to shutdown of the industrial production line, and thus cause huge economic losses to the enterprise.

[0005] Therefore, how to use controller data for intelligent fault diagnosis to make the industrial production line resume normal operation at the fastest speed is a technical problem to be solved. SUMMARY SUMMARY

[0006] In order to solve the above technical problems, the present disclosure provides a fault intelligent diagnosis method and device.

[0007] A first aspect of an embodiment of the present disclosure provides a fault intelligent diagnosis method, comprising: acquiring controller data related to the fault, the controller data including any one or more of input data, intermediate process data, and output data generated in a plurality of controller scanning periods; acquiring a controller program corresponding to the controller data related to the fault; The controller data related to the fault is played back through a controller program, fault diagnosis is performed, and a diagnosis result is obtained.

[0008] A second aspect of the embodiments of the present disclosure provides a fault intelligent diagnosis apparatus, comprising: a data acquisition module configured to acquire controller data related to the fault, the controller data comprising any one or more of input data, intermediate process data and output data generated in a plurality of controller scanning periods; a program acquisition module configured to acquire a controller program corresponding to the controller data related to the fault; a playback diagnosis module configured to play back the controller data related to the fault through the controller program, perform fault diagnosis, and obtain a diagnosis result.

[0009] A third aspect of the embodiments of the present disclosure provides a fault intelligent diagnosis apparatus, comprising: a processor; a memory; and a computer program; The computer program is stored in the memory and configured to be executed by the processor to implement the fault intelligent diagnosis method provided in the first aspect.

[0010] A fourth aspect of the embodiments of the present disclosure provides a fault intelligent diagnosis system, comprising the fault intelligent diagnosis apparatus provided in the second aspect or the fault intelligent diagnosis apparatus provided in the third aspect.

[0011] A fifth aspect of the embodiments of the present disclosure provides a computer readable storage medium, which stores a computer program. When the computer program is executed by a processor, the processor implements the fault intelligent diagnosis method provided in the first aspect.

[0012] A sixth aspect of the embodiments of the present disclosure provides a computer readable program product, which comprises a computer program or instructions. When the computer program or instructions are executed by a processor, the processor implements the fault intelligent diagnosis method provided in the first aspect.

[0013] The technical solutions provided by the embodiments of the present disclosure have the following advantages compared with the prior art: The fault intelligent diagnosis method and device provided by the embodiments of the present disclosure, by obtaining the controller data related to the fault, the controller data including any one or more of the input data, intermediate process data and output data generated in a plurality of controller scanning periods; obtaining the controller program corresponding to the controller data related to the fault; playing back the controller data related to the fault through the controller program, performing fault diagnosis and obtaining the diagnosis result, compared with the playback of only the controller data itself, playing back and displaying the controller data related to the fault in the corresponding controller program can more intuitively and completely play back and display the controller data at the fault moment and the corresponding controller program, and quickly determine the fault root cause based on the logical association relationship between the controller variables corresponding to the controller data in the controller program, realizing intelligent fault diagnosis. BRIEF DESCRIPTION OF DRAWINGS

[0014] The accompanying drawings, which are incorporated herein and constitute part of the specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced here. Obviously, for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0016] Figure 1 is a flowchart of a fault intelligent diagnosis method provided by the embodiments of the present disclosure; Figure 2 is a schematic diagram of a display example of controller program playback provided by the embodiments of the present disclosure; Figure 3 is a schematic diagram of a display example of controller program and data chart playback provided by the embodiments of the present disclosure; Figure 4 is a schematic diagram of a display example of controller program and data list playback provided by the embodiments of the present disclosure; Figure 5 is a schematic diagram of an extended display example of controller program playback provided by the embodiments of the present disclosure; Figure 6 is a flowchart of another fault intelligent diagnosis method provided by the embodiments of the present disclosure; Figure 7 is a flowchart of identifying abnormal controller data through an artificial intelligence algorithm provided by the embodiments of the present disclosure; Figure 8 is a schematic diagram of labeling of abnormal controller data provided by the embodiments of the present disclosure; Figure 9is a flowchart of another fault intelligent diagnosis method provided by an embodiment of the present disclosure; Figure 10 is a schematic diagram of a display example of a controller variable family provided by an embodiment of the present disclosure; Figure 11 is a structural schematic diagram of a fault intelligent diagnosis device provided by an embodiment of the present disclosure; Figure 12 is a structural schematic diagram of a fault intelligent diagnosis device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION In order to more clearly understand the above-mentioned purposes, features and advantages of the present disclosure, the solutions of the present disclosure will be further described below. It should be noted that the embodiments of the present disclosure and the features in the embodiments can be combined with each other without conflict.

[0017] In the following description, a large number of specific details are set forth in order to facilitate a thorough understanding of the present disclosure, but the present disclosure can also be implemented in other ways different from those described herein; obviously, the embodiments in the description are only some of the embodiments of the present disclosure, not all the embodiments.

[0018] It should be understood that each step recorded in the method embodiments of the present disclosure can be executed in different order and / or in parallel. In addition, the method embodiments can include additional steps and / or omit the execution of the steps shown. The scope of the present disclosure is not limited in this respect.

[0019] It should be noted that in this document, relational terms such as "first" and "second", and the like, are used solely to distinguish one entity or action from another entity or action, without necessarily requiring or implying any such actual relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements recited, but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without more limitations, an element defined by the phrase "comprising a..." does not exclude the existence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0020] It should be noted that the modification of "one" and "multiple" mentioned in the present disclosure is illustrative but not restrictive, and those skilled in the art should understand that "one or more" should be understood unless otherwise explicitly indicated in the context.

[0021] The related concepts and technologies involved in the embodiments of the present application are briefly introduced below.

[0022] Long Short-Term Memory (LSTM) network model: This is a type of recurrent neural network (RNN), different from convolutional neural networks (CNNs). It captures long-term relationships by introducing a "gating mechanism" and "cell state," and is widely used in time series data prediction, natural language processing (NLP), image processing, and video analysis. The core structure of this algorithm lies in its cell unit, which contains three core components and a cell state. The three core components are the input gate, output gate, and forget gate, and the cell state update is also present. Bidirectional Long Short-Term Memory (BiLSTM) network model: This model consists of two independent LSTM networks, forward and backward. Through the synergistic effect of bidirectional information flow, it can utilize both past and future information simultaneously, solving the problem that unidirectional LSTM cannot capture future context and improving sequence modeling capabilities. The forward LSTM processes the sequence in its original order (from time 1 to time n), while the backward LSTM processes it in reverse order (from time n to time 1). The final output at each time step is the concatenation of the hidden states from both directions. Each LSTM unit retains an input gate, an output gate, a forget gate, and a cell state update, with a structure consistent with the standard LSTM.

[0023] Autoencoders (AEs) are unsupervised learning neural network models primarily used for data dimensionality reduction, feature extraction, and generation tasks. Their core idea is to learn a compressed representation of the input data (encoding) and then reconstruct the original data from it (decoding), thereby achieving data reconstruction or feature learning. The core structure of an autoencoder includes an encoder and a decoder. The encoder compresses the input data into a low-dimensional latent representation; the decoder reconstructs the original data from the latent representation, aiming to make the reconstructed data as close as possible to the original input. Autoencoders optimize network parameters by minimizing the reconstruction loss; commonly used loss functions include mean squared error (MSE) and cross-entropy loss.

[0024] The sliding window technique (SWT) is a method that uses a fixed-length window to gradually slide across a data sequence to extract local features or generate samples. It is widely used in time series analysis, signal analysis, natural language processing, and computer vision. Its core objective is to capture local models or contextual relationships in the data. By dynamically dividing local data blocks, it provides a flexible data organization form for tasks such as time series modeling and feature extraction. The key lies in setting the appropriate window size and stride to balance information coverage and computational efficiency. The window size defines the length of the data range for each slide, and the stride controls the distance the window moves each time. A stride of 2 slides the window unit by unit; a stride greater than 2 skips some data. For example, if the original historical data sequence is 1, 2, 3, 4, 5, and the window size is 3 with a stride of 1, the generated predicted samples will be 1, 2, 3, or 2, 3, 4, or 3, 4, 5.

[0025] In typical industrial production processes, the volume of high-frequency sensor data generated is enormous. A standard PLC controller project file may contain hundreds of thousands of sensor data points. Simultaneously performing fault diagnosis on all sensor data from all PLC project files at the time of a fault would require significant human and network resources, placing higher demands on hardware performance and computing power. This would also indefinitely extend the fault diagnosis time, preventing the fastest possible resolution of equipment failures. To address this issue, this disclosure provides an intelligent fault diagnosis method, which will be described below with reference to specific embodiments.

[0026] Figure 1 This is a flowchart of a fault intelligent diagnosis method provided in an embodiment of the present disclosure. The method can be executed by a fault intelligent diagnosis device, which can be implemented in software and / or hardware. The fault intelligent diagnosis device can be configured in an electronic device, such as a server or terminal.

[0027] like Figure 1 As shown, the intelligent fault diagnosis method provided in this embodiment includes the following steps.

[0028] S110. Obtain controller data related to the fault. The controller data includes any one or more of the input data, intermediate process data and output data generated within multiple controller scan cycles.

[0029] In this embodiment of the disclosure, a controller refers to a hardware control device that runs a controller program and generates controller data. The controller program is in software form and controls various configured devices in the work site through digital or analog input / output data. The types of configured devices include, but are not limited to, various hardware devices located in the industrial site such as motors, roller beds, conveyor belts, robotic arms, and cameras.

[0030] Optionally, the controller can be any hardware device capable of controlling the equipment, including but not limited to: programmable logic controllers (PLCs), distributed control systems (DCS), and robot-specific controllers. Different types of controllers have different control methods and application scenarios.

[0031] Correspondingly, fault-related controller data refers to the data generated by the controller during the execution of control functions. The controller executes control functions continuously in a fixed scan cycle. Controller data includes any one or more of the following: input data, intermediate process data, and output data generated within multiple controller scan cycles.

[0032] Optionally, the controller data related to the fault includes controller data at the moment of the fault, as well as controller data for a certain period of time before or after the moment of the fault. The range of the time period before or after the fault is not further limited here.

[0033] Optionally, fault-related controller data includes any one or more of input data, intermediate process data, and output data generated within multiple controller scan cycles. For example, fault-related controller data may include input data, intermediate process data, output data, input data and intermediate process data, input data and output data, intermediate process data and output data, or input data, intermediate process data and output data, etc., generated within multiple controller scan cycles.

[0034] Optionally, fault-related controller data includes fault-related real-time controller data and / or historical controller data. Real-time controller data refers to data generated within the current controller scan cycle, while historical controller data refers to data generated before the current controller scan cycle or in previous scan cycles.

[0035] Optionally, real-time controller data includes any one or more of the following: real-time input data, real-time intermediate process data, and real-time output data generated during the current controller scan cycle. Historical controller data includes any one or more of the following: historical input data, historical intermediate process data, and historical output data generated during historical scan cycles. Normally, real-time controller data is the data within the current controller scan cycle. If it is not stored in a timely manner, the real-time controller data will be overwritten by the data in the next controller scan cycle and thus disappear.

[0036] Optionally, controller data includes input data, intermediate process data, and output data generated within multiple controller scan cycles. The input data, intermediate process data, and output data generated within a controller scan cycle constitute all controller data within that cycle, i.e., the full controller data for that cycle. Conversely, input data or output data alone do not constitute the full controller data for a single controller scan cycle.

[0037] Optionally, in a controller system, data can be categorized into input data, output data, and intermediate process data based on their different functions.

[0038] Input data refers to data from external input devices such as sensors and switches that needs to be input to the controller. Input data is stored in the controller's input module. Input data can directly correspond to external input devices, reflecting their physical state, such as temperature, pressure, and switch on / off status.

[0039] Optionally, the types of input data include, but are not limited to, data stored in area I, area X, and area D. Area I, area X, and area D correspond to different storage areas in the controller's memory. The controller variables corresponding to data located in area I are called I variables, those located in area X are called X variables, and those located in area D are called D variables.

[0040] Output data refers to the data generated by the controller after logical operations and sent to external actuators such as relays, valves, and motors. Output data is stored in the controller's output module. Output data can directly correspond to external actuators and is used to control the actions of these actuators in the industrial field, such as relay outputs controlling the start and stop of electrical appliances, and analog outputs regulating valve opening and closing.

[0041] Optionally, the output data types include, but are not limited to, data stored in the Q area, data in the Y area, and data in the O area. Here, the Q area, Y area, and O area correspond to different storage regions in the controller's memory. The controller variables corresponding to data located in the Q area are Q variables, the controller variables corresponding to data located in the Y area are Y variables, and the controller variables corresponding to data located in the O area are O variables.

[0042] Intermediate process data refers to data generated during the controller's scan cycle other than input and output data. Alternatively, intermediate process data is the data of intermediate calculation results generated by the controller program based on input data. Intermediate process data does not directly interact with external devices and is generally stored in the controller's memory. Examples include recording intermediate flag bits in a self-locking logic operation, temporary variables during the calculation process, recording time delays, and counting time intervals.

[0043] Optionally, the types of intermediate process data include, but are not limited to, data stored in the M area, DB area, C area, T area, W area, and S area. The M area, DB area, C area, T area, W area, and S area correspond to different storage regions in the controller's memory. The controller variables corresponding to data located in the M area are M variables, those in the DB area are DB variables, those in the C area are C variables, those in the T area are T variables, those in the W area are W variables, and those in the S area are S variables.

[0044] Optionally, the data located in controller area D is DB (Data Block) data. DB data is related to background data blocks, such as storing user-defined data. It can be accessed by multiple program blocks and is suitable for scenarios that require saving a large amount of structured data during program execution. The data located in controller area C is C (Counter) data. C data is related to the calculator, recording the number of events that occur, such as the number of times the machine runs or a certain event is triggered. The data located in controller area T is T (Timer) data. T data is related to the timer. The data located in controller area M is M (Memory) data. M data is temporary data and intermediate calculation results, such as recording the intermediate calculation results of a certain calculation. M data is usually used during program execution and is not retained after the PLC is powered off or restarted. It is often used as a flag bit or temporary status indicator and is generally used for storage.

[0045] The controller scan cycle refers to the time required for the controller to complete a full cycle of input processing, program execution, and output update. Typical cycle values ​​range from 1 to 100 milliseconds (ms). Different controllers have different scan cycles; for example, small controllers have scan cycles of tens of milliseconds, while medium to large controllers have cycles of 100 milliseconds.

[0046] Controller data acquisition methods include both data collection and calculation. The methods for acquiring data differ significantly depending on the type of controller. Specific data collection methods include, but are not limited to, active querying and eavesdropping, etc., which will not be further specified here.

[0047] Input data can only be obtained through data acquisition. Input and output data include, but are not limited to, high-frequency sensor data. Input data and some pre-configured intermediate process data can be acquired through data acquisition or synchronously calculated by analog controller programs such as soft PLCs.

[0048] Intermediate process data records crucial information about equipment malfunctions or failures, helping engineers troubleshoot and quickly and accurately pinpoint the cause of the problem. This data is complex and voluminous, accounting for over 90% of the total data generated in a single scan cycle by a PLC or other controller, while input and output data only account for about 10%.

[0049] Since intermediate process data is generally stored in the PLC's memory and not transmitted externally, existing technologies typically involve pre-configuring the intermediate process data to be monitored and then collecting the relevant data through polling. However, in reality, very little intermediate process data is collected through this pre-configuration method. This is mainly due to limitations imposed by industrial network bandwidth and the PLC's maximum communication load, which prevent current data acquisition technologies from collecting all intermediate process data within a controller scan cycle in a timely manner. Only a small amount of pre-configured intermediate process data can be obtained, and the vast majority of the uncollected intermediate process data from the previous controller scan cycle is quickly overwritten and lost by the intermediate process data generated in the next controller scan cycle.

[0050] The accuracy of intermediate process data significantly impacts the accuracy of the output results. If the input data is correct but the intermediate calculation data is incorrect, the output data is highly likely to be erroneous. Therefore, intermediate process data is crucial for equipment control. Consequently, when troubleshooting equipment faults, relying solely on input and output data, or only on input, output, and a small amount of intermediate process data without access to all intermediate process data, will make it impossible to accurately determine the root cause of the fault and thus prevent a fundamental solution.

[0051] This is because faults are mainly categorized into those caused by external factors and those caused by internal factors. Faults caused by external factors primarily refer to malfunctions in configured devices such as sensors and switches, while faults caused by internal factors mainly refer to errors (bugs) in the PLC program. Faults caused by external factors can usually be identified by checking input or output data, and in most cases, the root cause can be determined. However, faults caused by internal factors cannot be identified by checking input or output data alone; a large amount of intermediate process data is required to accurately identify the root cause.

[0052] Therefore, it is impossible to accurately pinpoint the root cause of a fault when a large amount of intermediate process data is missing. Only by acquiring all the controller data generated within each controller scan cycle, especially all the intermediate process data, can the root cause of the fault be accurately determined. Furthermore, predictive maintenance can be performed on the equipment based on this complete controller data, allowing for equipment maintenance or replacement before a fault occurs, thus preventing the fault from happening.

[0053] Optionally, in order to obtain all intermediate process data, logical operations can be performed by a simulated controller program. This simulated controller program performs logical operations based on the collected input data, and the target controller program is the controller program that actually corresponds to the fault.

[0054] Because the analog controller program has a controller program that is the same as or similar to the target controller program, it can perform the same logical operations based on the same input data and generate the same intermediate process data and output data. Therefore, the analog controller program can obtain all controller data within the controller scan cycle, including all intermediate process data and output data. This total controller data includes both normal and abnormal controller data.

[0055] Optionally, the analog controller program includes, but is not limited to, a soft PLC, a controller program running on a hardware redundant controller, a controller program running on a data acquisition module integrated in the hardware controller, or a module control program that can run on any electronic device; no limitation is made here.

[0056] The target controller program can be a program running on the target controller. The target controller is a physical controller, which can be a PLC or other controller installed in the industrial field, or a PLC or other controller installed in the cloud or virtual terminal. The target controller connects to and controls the equipment in the industrial field to achieve production automation. The equipment connected to and controlled by the target controller includes, but is not limited to, automated equipment such as sensors, cameras, motors, frequency converters, and robots in the industrial field. These devices are controlled by the target controller and execute in an orderly manner according to a predetermined program.

[0057] Optionally, intermediate process data can also be obtained by: acquiring some intermediate process data through data collection and acquiring some intermediate process data through logical operations of the analog controller program. The analog controller program performs logical operations based on the input data, simulating the target controller program, which is the controller program actually corresponding to the fault. For example, a small amount of intermediate process data that requires long-term monitoring can be quickly acquired through data collection. Due to the small quantity, the acquisition of this portion of intermediate process data will not be limited by network bandwidth and the controller's maximum communication load. Other portions of intermediate process data are obtained through logical operations of the analog controller program. The analog controller program performs logical operations based on the input data, simulating the target controller program, which is the controller program actually corresponding to the fault.

[0058] Optionally, intermediate process data can also be obtained by performing logical operations on the target controller program, where the target controller program is the controller program actually corresponding to the fault. Alternatively, if the target controller program is available, the intermediate process data formed through logical operations on the target controller program can be obtained directly; here, the target controller program is the controller program actually corresponding to the fault.

[0059] Optionally, intermediate process data can also be obtained through data acquisition. Alternatively, when not limited by network bandwidth or the maximum communication load of the target controller, intermediate process data can also be obtained through high-speed data acquisition.

[0060] Optionally, after calculating and obtaining all controller data, especially all intermediate process data, these intermediate process data can be used according to the actual situation. 80% or 90% of the intermediate process data can be used, without further limitation.

[0061] Optionally, the acquired full controller data includes full controller data at the time of failure or before / after the failure (within any range), as well as full controller data during normal operation when there is no failure. The full controller data at the time of failure can be used for troubleshooting or detection of the faulty equipment, while the full controller data during normal operation when there is no failure can be used for predictive maintenance of the equipment. This allows for routine maintenance of the equipment before a failure occurs, early identification of abnormal equipment that may lead to failure, and prevention of the failure.

[0062] In the industrial sector, a malfunction typically refers to a piece of equipment stopping operation or a production line shutting down; while an anomaly is an abnormal operating state that has not yet reached the point of stopping operation or shutting down. The damage caused by a malfunction is greater than that caused by an anomaly.

[0063] Optionally, the acquired controller data is time-series data, which includes at least the controller variable name, controller variable address, timestamp, and specific value.

[0064] S120. Obtain the controller program corresponding to the controller data related to the fault.

[0065] In this embodiment of the disclosure, the controller data related to the fault corresponds to the controller program, and there are various ways to obtain it, including but not limited to exporting it directly from the target controller through a dedicated export tool, editing it into a corresponding controller program through a controller programming language, and other possible implementation methods, which are not further limited here.

[0066] Controller programs can be categorized into, but are not limited to: ladder diagrams (LD), function block diagrams (FBD), sequential function charts (SFC), instruction lists (IL), and structured text (ST) conforming to the international standard IEC61131-3; extended or non-standard programming languages, such as continuous function charts (CFC), structured control languages ​​(SCL), graphical scripting languages ​​(e.g., GRAFCET), object-oriented PLC programming (CODESYS, TWinCAT, and other PLC platforms support object-oriented programming OPP), and industrial robot languages ​​(in collaboration with PLCs, such as KRL and RAPID).

[0067] Optionally, the controller program displays multiple controller variables with logical relationships. These controller variables are used in the controller program to store controller data. Controller variables can be set in advance during the controller program programming.

[0068] By parsing the project file corresponding to the controller program, the controller variables related to that controller program can be obtained. The project file corresponding to the controller program refers to the files created and used during the controller development process. It contains all the information required to achieve a specific automated control task, such as configuration files describing the controller's hardware configuration, communication configuration, parameter configuration, etc., as well as program files describing the controller's control logic.

[0069] Optionally, the project file can be in XML format, JSON format, or other formats.

[0070] Optionally, depending on the controller's configuration and settings, the number of project files can be one or more.

[0071] S130. Play back the controller data related to the fault through the controller program, perform fault diagnosis and obtain the diagnosis results.

[0072] In this embodiment of the disclosure, the acquired fault-related controller inputs are input into the corresponding controller program, and the fault-related controller data is replayed through the controller program. This allows the controller data corresponding to each controller variable to be replayed and displayed in the controller program. Compared with the replay of the controller data itself, the data, the corresponding controller variables, and the logical relationship between each data and variable can be replayed simultaneously.

[0073] Specifically, since the controller program includes multiple logically related controller variables, these controller variables are elements used in the controller program to store and manipulate the actual controller data. The controller program operates instructions through these controller variables. Controller variables are generally set in advance during the controller program programming; therefore, different controller data can have their display position in the controller program determined by their corresponding controller variables.

[0074] Optionally, the controller data can be displayed in the controller program as specific numerical values, such as 0, 1, 5, 6.8, 100.5, or as letters corresponding to specific numerical values, such as TRUE for 1 and FALSE for 0. There are various display methods available, and no further limitations are imposed here, as long as the acquired fault-related controller data can be displayed.

[0075] Optional, Figure 2 This diagram illustrates an example of a controller program playback display. (By...) Figure 2 It can be seen that the controller program is a function block diagram, which displays multiple controller variables with logical relationships. The location corresponding to each controller variable displays its variable information and controller data. Specifically, the diagram shows that the controller program includes an independent data block (named FGDB-000XCP, address %DB10.DBW0). This data block includes multiple fixed constants with logical relationships (named fct, fixed value 10) and controller variables. The variable names of the controller variables are FGDB-000XCP, Tag-86, Mov-32, FGDB-000YMW, and Tag-57, respectively, and their addresses are %DB10.DBW0, %DB10.DBX68.0, %I100.1, and %M238, respectively. %Q82.0, the controller data corresponding to each controller variable includes a numerical value (such as 50, 2.6, 6) or the corresponding letter (TRUE, FALSE). The controller data in the figure is marked with an underline.

[0076] Compared to existing technologies that simply replay and display the controller data itself, this method replays and displays the controller data corresponding to multiple logically related controller variables in the controller program. This allows for a more intuitive and complete replay of the logical relationships between controller data, and enables rapid identification of the root cause of the fault based on the logical relationships between the controller variables corresponding to the controller data in the controller program, thus achieving intelligent fault diagnosis.

[0077] Optionally, the controller data corresponding to each controller variable can be displayed in the controller program near the corresponding controller variable, including but not limited to displaying it above, below, to the left, or to the right of the controller variable.

[0078] Optionally, for Boolean controller variables in the controller program, the corresponding controller data values ​​are generally 1 or 0, where 1 generally corresponds to TRUE and 0 generally corresponds to FALSE. For integer controller variables, the corresponding controller data values ​​are generally integers, such as 1, 2, 5, etc. For floating-point controller variables, the corresponding controller data values ​​generally include a decimal point, such as 0.5, 10.2, 87.5, etc.

[0079] Optional, Figure 3 This diagram illustrates an example of a controller program and data chart playback. (By...) Figure 3 As can be seen, each controller's data is displayed near its corresponding controller variable, including but not limited to positions above, below, to the left, or to the right of the controller variable. Simultaneously, each controller's data can also be displayed synchronously as data charts, including but not limited to line charts, scatter plots, and area charts. Each data chart can display all controller data corresponding to different controller variables that have changed over time. This controller data includes historical controller data and / or real-time controller data.

[0080] Specifically, Figure 3The document illustrates the specific program of the function block diagram and a data chart showing the controller data corresponding to the multiple controller variables contained within it. The function block diagram contains a separate data block (named FGDB-000XCP, address %DB10.DBW0), which includes multiple logically related fixed constants (named fct, fixed value 10) and controller variables. The variable names of these controller variables are FGDB-000XCP, Tag-86, Mov-32, FGDB-000YMW, and Tag-57, respectively, and their addresses are %DB10.DBW0, %I100.1, %M238, %DB10.DBX68.0, and %Q82.0, respectively. The controller data corresponding to each controller variable includes numerical values ​​(e.g., 50, 2.6, 6) or corresponding letters (TRUE, FALSE). The data chart section shows the changes in controller data over time for the three controller variables Tag-86, FGDB-OOOXCP, and Tag-57 contained in this function block diagram. For controller variables named Tag-86 and Tag-57, their variable type is Boolean, and the corresponding controller data is 0 or 1, where 0 corresponds to the letter "TRUE" and 1 corresponds to the letter "FALSE". By using both controller programs and data charts to replay fault-related controller data, compared to replaying fault-related controller data using only a controller program, a diagnostic method that identifies abnormal data from the perspective of data change trends is added, thereby improving fault diagnosis efficiency.

[0081] Optional, Figure 4 This diagram illustrates an example of a controller program and data list playback. Figure 4 As can be seen, the data list can directly display the controller data stored in different controller variables at different times. This controller data includes historical controller data and / or real-time controller data. The content of the controller program is related to... Figure 3 The content of the controller program is the same and will not be repeated here. The data list section shows the data list of the controller data corresponding to the three controller variables Tag-86, FGDB-OOOXCP, and Tag-57 contained in this function block diagram as a function changes over time. As for 20240517180819575, 20240517180819576, 20240517180819577, 20240517180819578, 20240517180819579, 20240517180819580, and 20240517180819581, these are the corresponding time information. This time information includes the year-month-day-hour-minute-second-millisecond sequence corresponding to the controller data.

[0082] By using both the controller program and the data list to replay fault-related controller data simultaneously, compared to replaying fault-related controller data using only the controller program, an additional method of identifying abnormal data from the perspective of the data itself is added, thereby improving fault diagnosis efficiency.

[0083] Optionally, in addition to this, fault-related controller data can be replayed by using controller programs, data charts, and data lists simultaneously. Compared to replaying fault-related controller data using a single controller program, this adds a diagnostic method to identify abnormal data from the dimensions of data change trends and the data itself, thereby improving fault diagnosis efficiency.

[0084] Optional, Figure 5 This diagram illustrates an example of an extended display for controller program playback. (By...) Figure 5 As can be seen, the controller program is equipped with corresponding time buttons. By dragging the time buttons to move the time nodes, the controller program can display controller data at different time nodes corresponding to at least one controller variable. This facilitates the playback of controller data at different time nodes for the user, improving fault diagnosis efficiency. The controller data here includes real-time controller data and / or historical controller data.

[0085] Specifically, Figure 5 The diagram shows the controller program and corresponding controller data. The controller program is in the form of a function block diagram, and the content of the function block diagram is... Figure 2 The content of the function block diagram is the same as that in the middle, so it will not be repeated here. Also, Figure 5 The diagram also shows a time button 51 and a time bar 52 for displaying time scales. By dragging the time button 51 to any time, the controller data corresponding to the controller variables in the function block diagram will also change synchronously, displaying the controller data at different times. This allows for a more intuitive display of the controller data corresponding to different controller variables at different times in the controller program, which means that it can synchronously display different controller data with related relationships, thereby facilitating fault diagnosis and enabling intelligent fault diagnosis.

[0086] Optional, Figure 5 The program switching button is also shown. This button is used to switch between different controller programs to display the program information of different controller programs, which is conducive to rapid troubleshooting and intelligent fault diagnosis.

[0087] Optionally, the time button can be set in ways including but not limited to time bars, time scales, time rulers, etc., and no further restrictions are imposed here.

[0088] Optionally, by dragging the time buttons on the controller program and data chart corresponding to the controller data, controller data at different times corresponding to at least one controller variable in the controller program and data chart can be displayed synchronously. The controller data includes real-time controller data and / or historical controller data. The number of time buttons can be one or two. When there is only one time button, it is assumed that the controller program and data chart share the same time button. When there are two time buttons, it is assumed that the controller program and data chart each have their own corresponding time buttons.

[0089] Optionally, by dragging the time buttons corresponding to the controller program, data chart, and data list, controller data at different times corresponding to at least one controller variable in the controller program, data chart, and data list can be displayed synchronously. The controller data includes real-time controller data and / or historical controller data. The number of time buttons can be one or three. When there is only one time button, it is assumed that the controller program, data chart, and data list share the same time button. When there are three time buttons, it is assumed that the controller program, data chart, and data list each have their own corresponding time buttons.

[0090] Optionally, diagnostic results obtained through fault diagnosis. The diagnostic results include controller data and variable information for at least one controller variable related to the fault. The variable information includes any one or more of the following: variable name, variable address, variable type, name of the device corresponding to the variable, address of the device corresponding to the variable, physical function of the device corresponding to the variable, purpose of the device corresponding to the variable, priority of the variable, and probability of device failure.

[0091] This embodiment of the disclosure acquires fault-related controller data, which includes any one or more of input data, intermediate process data, and output data generated within multiple controller scan cycles; acquires the controller program corresponding to the fault-related controller data; and replays the fault-related controller data through the controller program to perform fault diagnosis and obtain diagnostic results. Compared to replaying only the single controller data itself, replaying and displaying the fault-related controller data in the corresponding controller program provides a more intuitive and complete replay of the controller data at the time of the fault and the corresponding controller program. Furthermore, it quickly determines the root cause of the fault based on the logical relationship between the controller data in the controller program, thereby achieving intelligent fault diagnosis.

[0092] Based on the above embodiments, Figure 6 This is a flowchart of another intelligent fault diagnosis method provided in this disclosure embodiment, such as... Figure 6 As shown, the specific steps include the following: S610. Obtain controller data related to the fault. The controller data includes any one or more of the input data, intermediate process data and output data generated within multiple controller scan cycles.

[0093] It should be noted that the specific implementation of S610 is similar to the implementation described above, and will not be repeated here.

[0094] S620. Obtain abnormal controller data identified from fault-related controller data. The abnormal controller data is obtained based on abnormal identification rules and is controller data that does not conform to normal data patterns.

[0095] In the embodiments of this disclosure, abnormal controller data refers to controller data that does not conform to normal data patterns. Here, normal data patterns refer to the patterns of controller data corresponding to each controller variable under normal circumstances. For example, data patterns with fixed change period types, sine / cosine wave types, stepped change pulse signal types, signal value fixed period occurrence types, and fixed change period change types all belong to the normal data patterns corresponding to controller data. Controller data conforming to normal data patterns is normal controller data; conversely, controller data that does not conform to normal data patterns is abnormal controller data. For instance, controller data of Boolean type with a fixed change period of 2 milliseconds (ms) changes between 0 and 1 according to a 2ms change period. This data pattern is a normal data pattern, and controller data conforming to this normal data pattern is normal controller data; otherwise, it is abnormal controller data.

[0096] Optionally, anomaly identification rules include, but are not limited to, human-preset anomaly identification rules, anomaly identification rules based on historical data, anomaly identification rules based on expert experience, and artificial intelligence algorithms.

[0097] Optionally, the anomaly identification rules include artificial intelligence algorithms, which include anomaly identification rules that identify fault-related controller data exceeding standard monitoring thresholds as abnormal controller data. These standard monitoring thresholds include, but are not limited to, the optimal model parameter thresholds for the artificial intelligence algorithm and manually preset standard monitoring thresholds.

[0098] Optionally, the types of artificial intelligence algorithms include, but are not limited to, recurrent neural networks (RNNs), convolutional neural networks (CNNs), long short-term memory networks (LSTMs), and bidirectional long short-term memory networks (BiLSTMs). The artificial intelligence algorithms may include anomaly identification rules that recognize fault-related controller data exceeding the optimal model parameter threshold as abnormal controller data; such algorithms can all be set as the anomaly identification rules in this embodiment.

[0099] Optionally, the artificial intelligence algorithm includes a Long Short-Term Memory Network-Autoencoder (LSTM-AE) algorithm, which includes anomaly identification rules that identify fault-related controller data that exceeds the threshold of the optimal model parameters as abnormal controller data.

[0100] Specifically, Figure 7 This diagram illustrates the process of identifying abnormal controller data using the LSTM-AE artificial intelligence algorithm. Figure 7 It can be seen that identifying abnormal controller data using the LSTM-AE artificial intelligence algorithm includes the following steps: S7201. Obtain the training dataset.

[0101] Specifically, this refers to acquiring historical controller data for the target controller, preprocessing the historical controller data, and forming a training dataset. This historical controller data includes data from normal operating conditions, and may also include a small amount of data from abnormal operating conditions.

[0102] Optionally, the proportion of historical controller data under abnormal conditions should not be too high, otherwise it will affect the accuracy of the model training results. For example, the amount of historical controller data under abnormal conditions should not exceed 5% of the total amount of training data.

[0103] S7202. Construct an LSTM-AE model and train it to obtain the standard monitoring threshold for the best model.

[0104] Specifically, this involves constructing an LSTM-AE model based on a Long Short-Term Memory (LSTM) recurrent neural network and an auto-encoder (AE). The training dataset is then input into the LSTM-AE model for training, and the standard monitoring threshold for the optimal model is obtained. The optimal model refers to the model with the best parameters. The threshold corresponding to the optimal model parameters is the standard monitoring threshold.

[0105] Optionally, any method of constructing an LSTM-AE model based on a Long Short Term Memory (LSTM) recurrent neural network (LSTM) and an auto-encoder (AE) is acceptable and no further restrictions are imposed here.

[0106] Optionally, the construction process of the LSTM-AI model is dynamic. The model is trained by inputting the training dataset into the LSTM-AI model, and the construction process is continuously monitored by tracking the values ​​of one or more model parameters, such as reconstruction error, gradient descent metric, and validation error. When the values ​​of one or more of these parameters approach zero, the corresponding model is considered the optimal model.

[0107] Optionally, the model parameters in the best model are the optimal model parameters, which include, but are not limited to, model parameters such as reconstruction error, gradient descent metric, and validation error. Here, optimal model parameters refer to model parameters whose values ​​are close to zero.

[0108] Optionally, the calculation methods for model parameters such as reconstruction error, gradient descent metric, and validation error are not further limited here; any method used to calculate reconstruction error, gradient descent metric, and validation error is acceptable.

[0109] Optionally, given the optimal model, one or more of the following can be calculated using any one or more of the following methods: root mean square error, mean absolute error, and mean absolute percentage error. These can then be used as the standard monitoring threshold for the optimal model.

[0110] S7203. Input the controller data related to the fault to be identified under the sliding window into the constructed LSTM-AE model, obtain the current monitoring threshold of the controller data related to the fault to be identified, compare the current monitoring threshold of the controller data related to the fault with the standard monitoring threshold, and identify the controller data that exceeds the standard monitoring threshold as abnormal controller data.

[0111] Specifically, the controller data related to the fault to be identified is acquired within a sliding window; this controller data is time-series data. This controller data is input into the constructed LSTM-AE model, and the output is calculated using any one or more of the following methods: root mean square error (RMSE), mean absolute error (MAE), and mean absolute percentage error (MAS%). This calculated value is then used as the current monitoring threshold for the controller data related to the fault to be identified.

[0112] Optionally, the standard monitoring threshold of the best model is compared with the current monitoring threshold obtained by calculation. The mean square error of the window is calculated by using the model inference through the input data, and then compared with the global mean square error trained. If it is higher than the trained threshold, it is considered abnormal. As for the classification, T2 can be used if the window error is less than 10% of the global threshold, T3 if it is higher than 10%, and so on.

[0113] Specifically, the standard monitoring threshold of the optimal model is used as the comparison benchmark for abnormal controller data. By comparing the current abnormal monitoring threshold of the fault-related controller data with the standard monitoring threshold of the optimal model, the difference between the current abnormal monitoring threshold and the standard monitoring threshold is calculated. Controller data with a difference exceeding the range is identified as abnormal controller data.

[0114] Furthermore, the anomaly level of the controller data can be determined based on the magnitude of the difference ΔT between the current anomaly monitoring threshold and the standard monitoring threshold. The anomaly level then determines whether to initiate subsequent operations such as anomaly alarms or anomaly notifications.

[0115] Optionally, the standard global threshold can be used as the standard monitoring threshold for the optimal model. By comparing the current global threshold of fault-related controller data with the standard global threshold of the optimal model, the difference between the current global threshold and the standard global threshold is calculated, and controller data with a difference exceeding the range is identified as abnormal controller data.

[0116] Optionally, controller data at the time of the fault to be identified, or at any time before the fault, is used as new data and input into the trained LSTM-AE model according to a fixed window slice. The current anomaly monitoring threshold T1 for the corresponding controller data is calculated, and the standard monitoring threshold T2 of the optimal model is obtained. The difference ΔT between the current anomaly monitoring threshold T1 and the standard monitoring threshold T2 is calculated. Controller data with a difference ΔT exceeding the range is identified as anomaly controller data. The magnitude of the difference ΔT between the current anomaly monitoring threshold T1 and the standard monitoring threshold T2 determines whether the controller data is anomaly controller data and the anomaly level. The anomaly level can be adjusted to three, four, or more levels according to the actual situation.

[0117] For example, when △T≤0, the controller data is considered to be normal controller data, without any abnormalities; When 1>△T>0, the controller data is considered abnormal controller data, and the abnormality level is the lowest level (or level four, which can be marked in blue). When 2>△T>1, the controller data is considered abnormal controller data, and the abnormality level is low to medium (or, for example, level three, which can be marked in yellow). When 3>△T>2, the controller data is considered abnormal controller data, and the abnormality level is medium (or, for example, level two, which can be marked in orange). When △T>3, the controller data is considered abnormal controller data, and the abnormality level is the highest level (or, for example, level one, which can be marked in red). In addition, the criteria for classifying anomaly levels can be set using expert knowledge or adjusted based on business needs or an understanding of the business scenario to achieve better anomaly monitoring performance.

[0118] Optionally, based on the identified abnormal controller data and its anomaly level, all abnormal data can be classified into anomaly levels, and data from abnormal controllers with higher anomaly levels can be prioritized as high-risk abnormal controller data. By prioritizing the push of high-risk abnormal controller data, troubleshooting time can be shortened and troubleshooting efficiency improved.

[0119] Therefore, through artificial intelligence algorithms, it is possible to automatically identify abnormal controller data at the time of failure and before and after, which greatly improves the accuracy and efficiency of fault diagnosis and provides strong support for quickly resolving production problems.

[0120] Optionally, the anomaly identification rules include an artificial intelligence algorithm, which includes anomaly identification rules that identify controller data exceeding a standard monitoring threshold as abnormal controller data.

[0121] Optionally, the anomaly identification rules include obtaining the normal patterns of controller data under normal conditions and identifying controller data that does not conform to the normal patterns as abnormal controller data.

[0122] The rules for identifying anomalies in controller data need to be set in advance. To set these rules, it's necessary to pre-analyze the patterns in the controller data, identifying data that doesn't conform to these patterns as abnormal controller data. Abnormal controller data here refers to controller data that doesn't follow normal patterns. Different types of controller data have different patterns. Normal data patterns refer to the correct patterns observed under normal conditions.

[0123] Optionally, the data patterns of the controller data include, but are not limited to: data with a constant change period, data conforming to a sine / cosine wave pattern, data with a step change pattern, and data with a fixed periodic value.

[0124] By analyzing data from different types of controllers and identifying patterns in the data for each type, anomaly identification rules for that type of controller can be determined. The core idea of ​​these identification rules is to identify data that does not conform to normal controller data patterns as abnormal controller data. Normal controller data patterns refer to the rules or correct rules of controller data under normal circumstances.

[0125] Optionally, for sensors with pulse signals having a constant period of variation, the corresponding controller data follows a pattern of high and low level changes according to a constant period. If the data at a given moment is normally high-level, but the acquired data is low-level, then the low-level data at that moment is considered abnormal controller data that does not conform to the data pattern; or, if the data at a given moment is normally low-level, but the acquired data is high-level, then the high-level data at that moment is considered abnormal controller data that does not conform to the data pattern. Optionally, before identifying abnormal controller data based on controller anomaly identification rules, the process also includes identifying the controller type and matching the corresponding controller anomaly identification rules.

[0126] Optionally, after determining the controller data type, for different types of controller data, match the corresponding controller anomaly identification rules, and identify abnormal controller data that does not conform to the data pattern based on the corresponding rules.

[0127] S630, Obtain the controller program corresponding to the controller data related to the fault.

[0128] In embodiments of this disclosure, the controller program corresponding to fault-related controller data includes the controller program corresponding to identified abnormal controller data.

[0129] Furthermore, the specific implementation of S630 is similar to the above-described implementation, and will not be repeated here.

[0130] S640. By replaying the identified abnormal controller data through the controller program, fault diagnosis is performed and diagnostic results are obtained. The abnormal controller data includes any one or more of abnormal input data, abnormal intermediate process data, and abnormal output data.

[0131] In the embodiments of this disclosure, abnormal controller data identified by the controller program is replayed to perform fault diagnosis and obtain diagnostic results. The abnormal controller data includes any one or more of abnormal input data, abnormal intermediate process data, and abnormal output data. Compared to replaying a single abnormal controller data point, replaying the controller program allows for the simultaneous display of the abnormal controller data itself, the corresponding controller variables, the controller program containing the controller variables, and other related controller variables within that program. This facilitates intelligent fault diagnosis based on this information, thereby improving fault diagnosis efficiency.

[0132] Optionally, the abnormal controller data can be replayed using the controller program and data charts corresponding to the identified abnormal controller data; or, the abnormal controller data can be replayed using the controller program and data list corresponding to the identified abnormal controller data; or, the abnormal controller data can be replayed using the controller program, data charts, and data list corresponding to the identified abnormal controller data. Compared to replaying abnormal controller data through the controller program, synchronously displaying the corresponding data charts or data lists can simultaneously perform fault diagnosis from multiple dimensions such as data change trends or the data itself, thereby improving fault diagnosis efficiency.

[0133] Optional, Figure 8 This is a schematic diagram illustrating the annotation of abnormal controller data. To improve fault diagnosis efficiency, identified abnormal controller data is annotated in one or more of the controller program, data charts, and data lists. This highlights the abnormal controller data, helping engineers quickly locate the relevant controller data causing the fault and achieving intelligent fault diagnosis. Specifically, Figure 8 By using graphical selection boxes, three abnormal controller data points are marked in the controller program and corresponding data charts, thus displaying the abnormal controller data that users need to focus on and troubleshoot more intuitively, thereby improving the user experience.

[0134] Optionally, by annotating the abnormal controller data, the identified abnormal controller data can be highlighted, allowing users to more intuitively and quickly pinpoint the abnormal controller data that needs to be investigated. Annotation methods include, but are not limited to: graphical selection, different colors, enlarged shapes, and adding alert or abnormal indicators. Furthermore, the forms of added alert or abnormal indicators include, but are not limited to: dots, cross marks, red flags, triangles, and stars.

[0135] Optionally, to more intuitively display abnormal controller data at different times in different controller programs, the abnormal controller data at different times corresponding to at least one controller variable in the controller program can be displayed by dragging the time button of the controller program corresponding to the abnormal controller data. The abnormal controller data includes real-time abnormal controller data and / or historical abnormal controller data.

[0136] Optionally, by dragging at least one time button on the controller program and data chart corresponding to the abnormal controller data, abnormal controller data at different times corresponding to at least one controller variable in the controller program and data chart can be displayed synchronously. The abnormal controller data includes real-time abnormal controller data and / or historical abnormal controller data.

[0137] Optionally, by dragging at least one time button in the controller program and data list corresponding to the abnormal controller data, abnormal controller data at different times corresponding to at least one controller variable in the controller program and data chart can be displayed synchronously. The abnormal controller data includes real-time abnormal controller data and / or historical abnormal controller data.

[0138] Optionally, by dragging at least one time button of the controller program, data chart, and data list corresponding to the abnormal controller data, abnormal controller data at different times corresponding to at least one controller variable in the controller program, data chart, and data list can be displayed synchronously. The abnormal controller data includes real-time abnormal controller data and / or historical abnormal controller data.

[0139] This embodiment of the disclosure identifies abnormal controller data from fault-related controller data through anomaly identification rules, which can narrow the scope of fault diagnosis from hundreds of thousands of controller data to a few thousand abnormal controller data, greatly reducing the data diagnosis scope of fault diagnosis, reducing the demand for computing power and hardware performance in fault diagnosis, and expanding the application scenarios of fault diagnosis methods.

[0140] Based on the above embodiments, Figure 9 This is a flowchart of another intelligent fault diagnosis method provided in this disclosure embodiment, such as... Figure 9 As shown, the specific steps include the following: S910. Obtain controller data related to the fault. The controller data includes any one or more of the input data, intermediate process data and output data generated within multiple controller scan cycles.

[0141] S920. Obtain abnormal controller data identified from fault-related controller data. The abnormal controller data is obtained based on abnormal identification rules and is controller data that does not conform to normal patterns.

[0142] S930, Obtain the controller program corresponding to the controller data related to the fault.

[0143] It should be noted that the specific implementation methods of S910-S930 are similar to those described above, and will not be repeated here.

[0144] S940. Obtain the controller variable family corresponding to the abnormal controller data, and push the leaf node variables and / or intermediate node variables of the abnormal controller data in the controller variable family. The controller variable family is obtained by parsing the controller program. The controller variable family includes the root node variable, the intermediate node variables and leaf node variables that have a logical relationship with the root node variable. The root node variable is a controller variable without a parent node, the intermediate node variable is a controller variable that has both a parent node and a child node, and the leaf node variable is a controller variable without a child node.

[0145] In reality, the amount of abnormal controller data identified is enormous. Not all abnormal controller data is the root cause of the fault. This is because there are correlations between controller data. An abnormality in some controller data will cause all related controller data to become abnormal synchronously, while an abnormality in some controller data will not cause related controller data to become abnormal synchronously. Therefore, it takes a lot of time to filter out the root cause data that truly caused the fault from thousands of abnormal controller data, resulting in a relatively long diagnosis time required for fault diagnosis.

[0146] This embodiment of the disclosure analyzes the logical relationships between controller variables corresponding to abnormal controller data, finds the controller variable families corresponding to these abnormal controller data, splits the abnormal controller data with logical relationships into multiple controller variable families, and then uses the controller variable families as diagnostic units to perform fault diagnosis. This can effectively utilize the logical relationships between controller variables corresponding to controller data and improve fault diagnosis efficiency.

[0147] Controller variable families can be obtained by parsing the controller program. A controller variable family begins with a root variable and includes, from top to bottom, the root variable, intermediate variable (which has a logical relationship with the root variable), and leaf variable. Root variables are controller variables without parent nodes, intermediate variable variables have both parent and child nodes, and leaf variable variables have no child nodes. The controller program is decomposed into multiple different controller variable families based on different root variables.

[0148] Optional, Figure 10 A schematic diagram of the controller variable family is shown, consisting of... Figure 10It can be seen that the controller variable family includes multiple node hierarchical relationships, specifically: the first-level nodes include a root node variable Q1.0; the second-level nodes include two first-level intermediate node variables M2.0 and DB1, and one first-level leaf node variable I2.0, where the first-level intermediate node variables M2.0, DB1, and the first-level leaf node variable I2.0 have the root node variable Q1.0 as their parent node; the third-level nodes include four second-level intermediate node variables M3.5, M7.1, M2.0, and DB3, and two second-level leaf nodes. Point variables I3.0 and a10, where different second-level intermediate node variables and second-level leaf node variables take different first-level intermediate node variables as their parent nodes. For example, second-level intermediate node variables M3.5 and M7.1 and second-level leaf node variable I3.0 take first-level intermediate node variable M2.0 as their parent node, and second-level intermediate node variables M2.0 and DB3 and second-level leaf node variable I7.0 take first-level intermediate node variable DB1 as their parent node; the fourth-level nodes include six third-level leaf node variables I8.2, I11.0, I5.3, I6.4, I9.2, and I4.0 as their controller variables.

[0149] Furthermore, a node refers to an element in the abstract syntax tree corresponding to the controller program within the project file; each element in the tree is called a node. These elements can be basic components of the controller program (such as variables, constants, and operators) or more complex structures (such as expressions, statements, functions, or modules). The hierarchical relationship between nodes reflects the logical relationships within the program code.

[0150] Node types can include root nodes, leaf nodes, and intermediate nodes. A root node is a node without a parent node. The root node is generally the top-level node and may contain multiple intermediate and leaf nodes. A leaf node is a node without children and is generally the bottom-level node. Intermediate nodes are any nodes other than the root and leaf nodes.

[0151] A parent node is a node one level up in the tree structure; a child node is a node one level down in the tree structure.

[0152] Each node typically contains corresponding variable information. This variable information refers to the variable name, variable type, variable address, and location information of the DB block or program block containing at least one controller variable contained in the node.

[0153] Optionally, the root node contains root node variables, leaf nodes contain leaf node variables, and intermediate nodes contain intermediate node variables. Leaf node variables are controller variables without child nodes, root node variables are controller variables without parent nodes, and intermediate node variables are controller variables that have both parent and child nodes.

[0154] Optionally, the root node is the starting node, and root node variables are variables that have no parent nodes above them. Root node variables are generally global variables, and their types include, but are not limited to: Q variables, DB variables, M variables, T variables, and C variables. Intermediate node variables are variables that have both parent and child nodes, and their types include, but are not limited to: M variables, DB variables, C variables, and T variables. Leaf node variables are variables that have no descendant nodes, and their types include, but are not limited to: I variables, DB variables, M variables, T variables, and C variables.

[0155] Optionally, controller variables that have a logical relationship with the root node variable include leaf node variables and intermediate node variables. Both leaf node variables and intermediate node variables are variables that have a relationship with the root node variable. This relationship refers to the dependency relationship between the variables contained in each node. By analyzing the logical relationships in the control program code, the hierarchical relationship between nodes can be obtained, and thus the dependency relationship between the variables contained in each node can be obtained, determining the relationship between the variables contained in each node.

[0156] After obtaining the controller variable family corresponding to the abnormal controller data, the corresponding controller variable family is checked from top to bottom level for the root node variable containing abnormal controller data, until the leaf node variable and / or root node variable causing the fault are identified, and then pushed to the appropriate department. The method of investigation is not further limited here; it can be manual investigation or investigation based on artificial intelligence algorithms, etc.

[0157] S950. By replaying the abnormal controller data identified by the controller program, fault diagnosis is performed and diagnostic results are obtained. The abnormal controller data includes any one or more of the following: abnormal input data, abnormal intermediate process data, and abnormal output data.

[0158] It should be noted that the specific implementation of S950 is similar to the implementation described above, and will not be repeated here.

[0159] This embodiment further filters the acquired abnormal controller data from the dimension of controller variables to obtain the leaf node variables and / or intermediate node variables corresponding to the abnormal controller data that cause the root cause of the fault. This reduces the data range for fault diagnosis from thousands of abnormal controller data to a few or a dozen leaf node variables and / or intermediate node variables, greatly reducing the data range for fault diagnosis, improving fault diagnosis efficiency, and realizing intelligent fault diagnosis.

[0160] Figure 11 This is a schematic diagram of the structure of an intelligent fault diagnosis device provided in an embodiment of this disclosure. The intelligent fault diagnosis device provided in this embodiment can execute the processing flow provided in the embodiment of the intelligent fault diagnosis method, such as... Figure 11 As shown, the intelligent fault diagnosis device 11 includes: a data acquisition module 111, a program acquisition module 112, and a playback diagnosis module 113.

[0161] The data acquisition module 111 can be used to acquire controller data related to the fault. The controller data includes any one or more of the input data, intermediate process data and output data generated within multiple controller scan cycles.

[0162] The program retrieval 112 can be used to retrieve the controller program corresponding to the controller data related to the fault.

[0163] The playback diagnostic module 113 can be used to play back the controller data related to the fault through the controller program, perform fault diagnosis and obtain diagnostic results.

[0164] In this embodiment, fault-related controller data can be acquired, including any one or more of input data, intermediate process data, and output data generated within multiple controller scan cycles; the controller program corresponding to the fault-related controller data can be acquired; and the fault-related controller data can be replayed through the controller program to perform fault diagnosis and obtain diagnostic results. Compared to simply replaying the controller data itself, replaying and displaying the fault-related controller data in the corresponding controller program can more intuitively and completely replay the controller data at the time of the fault and the corresponding controller program, and quickly determine the root cause of the fault based on the logical relationship between the controller data in the controller program, thereby achieving intelligent fault diagnosis.

[0165] In some embodiments of this disclosure, the data acquisition module 111 further includes an intermediate process data calculation submodule, which is used to obtain intermediate process data through logical operations of the simulated controller program. The simulated controller program performs logical operations on the target controller program based on the input data, and the target controller program is the controller program that actually corresponds to the fault.

[0166] In some embodiments of this disclosure, the playback diagnostic module 113 further includes a data chart playback submodule and a data list playback submodule. The data chart playback submodule is used to play back fault-related controller data using fault-related data charts, and the data list playback submodule is used to play back fault-related controller data using fault-related data lists.

[0167] In some embodiments of this disclosure, the fault intelligent diagnosis device further includes an abnormal data identification module, which can be used to acquire abnormal controller data identified from controller data related to the fault. The abnormal controller data is obtained based on abnormal identification rules and is controller data that does not conform to normal patterns.

[0168] In some embodiments of this disclosure, the fault intelligent diagnosis device further includes an abnormal data annotation module, which can be used to annotate abnormal controller data in any combination of one or more types of controller programs, data charts and data lists corresponding to fault-related controller data.

[0169] In some embodiments of this disclosure, the intelligent fault diagnosis device further includes a controller variable analysis module, which can be used to obtain a controller variable family corresponding to abnormal controller data, and push leaf node variables and / or intermediate node variables corresponding to the abnormal controller data in the controller variable family. The controller variable family is obtained by parsing the controller program. The controller variable family includes a root node variable, intermediate node variables and leaf node variables that have a logical relationship with the root node variable. The root node variable is a controller variable without a parent node, the intermediate node variable is a controller variable that has both a parent node and a child node, and the leaf node variable is a controller variable without a child node.

[0170] In some embodiments of this disclosure, the intelligent fault diagnosis device further includes a diagnosis result display module, which can be used to display the diagnosis result. The diagnosis result includes controller data and variable information of at least one controller variable related to the fault. The variable information includes any one or more of the following: variable name, variable address, variable type, variable corresponding device name, variable corresponding device address, physical function of the variable corresponding device, purpose of the variable corresponding device, variable importance priority, and device fault probability.

[0171] Figure 11 The fault intelligent diagnosis device in the embodiments can be used to execute the technical solutions of the above method embodiments. Its implementation principle and technical effect are similar, and will not be repeated here.

[0172] Figure 12 This is a schematic diagram of the intelligent fault diagnosis device provided in an embodiment of this disclosure. The intelligent fault diagnosis device provided in this embodiment of the disclosure can execute the processing flow provided in the embodiment of the intelligent fault diagnosis method, such as... Figure 12As shown, the intelligent fault diagnosis device 12 includes: a processor 121, a memory 122, and a computer program 123; wherein the computer program is stored in the memory 122 and configured to read the computer program 123 from the memory 122 and execute the computer program 123 to implement the embodiments of this disclosure. Figures 1 to 10 The provided intelligent fault diagnosis method.

[0173] In addition, this disclosure also provides a fault intelligent diagnosis system, which includes the features of this disclosure. Figure 11 or Figure 12 The provided intelligent fault diagnosis device has a similar implementation principle and technical effect, which will not be elaborated here.

[0174] Furthermore, this disclosure also provides a computer-readable storage medium that can store a computer program, which, when executed by a processor, causes the processor to implement the embodiments of this disclosure. Figures 1 to 10 The provided intelligent fault diagnosis method.

[0175] The aforementioned storage medium may, for example, include a computer program memory, which can be executed by the processor of the intelligent fault diagnosis device to complete the embodiments of this disclosure. Figures 1 to 10 The provided intelligent fault diagnosis method. Optionally, the storage medium can be a non-transitory computer-readable storage medium, such as ROM, random access memory (RAM), compact disc ROM (CD-ROM), magnetic tape, floppy disk, and optical data storage configuration device, etc.

[0176] Furthermore, this disclosure also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, implement the above-described intelligent fault diagnosis method.

[0177] The above are merely specific embodiments of this disclosure, enabling those skilled in the art to understand or implement this disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A fault intelligent diagnosis method, characterized in that, include: Acquire fault-related controller data, which includes any one or more of the following: input data, intermediate process data, and output data generated within multiple controller scan cycles; Obtain the controller program corresponding to the controller data related to the fault; The controller program replays the controller data related to the fault to perform fault diagnosis and obtain diagnostic results.

2. The method according to claim 1, characterized in that, The step of replaying the controller data related to the fault through the controller program, performing fault diagnosis and obtaining diagnostic results, further includes: The controller data related to the fault is replayed by the controller program and data charts corresponding to the controller data related to the fault. Alternatively, the controller data related to the fault can be replayed using the controller program and data list corresponding to the controller data related to the fault; Alternatively, the controller data related to the fault can be replayed using the controller program, data charts, and data lists corresponding to the controller data related to the fault.

3. The method according to claim 1, characterized in that, The intermediate process data is obtained through logical operations of a simulated controller program. The simulated controller program performs logical operations on a target controller program based on the input data. The target controller program is the controller program that actually corresponds to the fault. Alternatively, the intermediate process data includes some intermediate process data obtained through acquisition and some intermediate process data obtained through logical operations of the simulation controller program. The simulation controller program simulates the target controller program to perform logical operations based on the input data. The target controller program is the controller program that actually corresponds to the fault. Alternatively, the intermediate process data is obtained through logical operations of the target controller program, where the target controller program is the controller program that actually corresponds to the fault. Alternatively, the intermediate process data can be obtained through data collection.

4. The method according to claim 1, characterized in that, By dragging the time button of the controller program corresponding to the controller data, the controller program displays the controller data at different times corresponding to at least one controller variable in the controller program. The controller data includes real-time controller data and / or historical controller data. Alternatively, by dragging the time buttons of the controller program and data chart corresponding to the controller data, the controller data corresponding to at least one controller variable in the controller program and the data chart at different times can be displayed synchronously, and the controller data includes real-time controller data and / or historical controller data; Alternatively, by dragging the time buttons of the controller program and data list corresponding to the controller data, the controller data corresponding to at least one controller variable in the controller program and data list at different times can be displayed synchronously, and the controller data includes real-time controller data and / or historical controller data; Alternatively, by dragging the time buttons of the controller program, data chart, and data list corresponding to the controller data, the controller data at different times corresponding to at least one controller variable in the controller program, the data chart, and the data list can be displayed synchronously. The controller data includes real-time controller data and / or historical controller data.

5. The method according to claim 1, characterized in that, After acquiring fault-related controller data, which includes input data, intermediate process data, and output data generated within multiple controller scan cycles, the method further includes: Obtain abnormal controller data identified from the controller data related to the fault. The abnormal controller data is obtained based on anomaly identification rules and is controller data that does not conform to normal data patterns.

6. The method according to claim 5, characterized in that, The step of replaying the controller data related to the fault through the controller program, performing fault diagnosis and obtaining diagnostic results, further includes: The abnormal controller data identified by the controller program is replayed to perform fault diagnosis and obtain diagnostic results. The abnormal controller data includes any one or more of abnormal input data, abnormal intermediate process data, and abnormal output data.

7. The method according to claim 6, characterized in that, The step of replaying the identified abnormal controller data through the controller program, performing fault diagnosis, and obtaining diagnostic results further includes: The abnormal controller data is replayed using the controller program and data charts corresponding to the identified abnormal controller data; Alternatively, the abnormal controller data can be replayed using the controller program and data list corresponding to the identified abnormal controller data; Alternatively, the abnormal controller data can be replayed using the controller program, data charts, and data lists corresponding to the identified abnormal controller data.

8. The method according to claim 5, characterized in that, The abnormal controller data is labeled in any combination of one or more of the controller programs, data charts, and data lists corresponding to the controller data related to the fault.

9. The method according to claim 5, characterized in that, By dragging the time button of the controller program corresponding to the abnormal controller data, the abnormal controller data corresponding to at least one controller variable in the controller program at different times is displayed. The abnormal controller data includes real-time abnormal controller data and / or historical abnormal controller data. Alternatively, by dragging the time buttons of the controller program and data chart corresponding to the abnormal controller data, the abnormal controller data corresponding to at least one controller variable in the controller program and the data chart at different times can be displayed synchronously. The abnormal controller data includes real-time abnormal controller data and / or historical abnormal controller data. Alternatively, by dragging the time buttons of the controller program and data list corresponding to the abnormal controller data, the abnormal controller data corresponding to at least one controller variable in the controller program and the data list at different times can be displayed synchronously. The abnormal controller data includes real-time abnormal controller data and / or historical abnormal controller data. Alternatively, by dragging the time buttons of the controller program, data chart, and data list corresponding to the abnormal controller data, the abnormal controller data at different times corresponding to at least one controller variable in the controller program, the data chart, and the data list can be displayed synchronously. The abnormal controller data includes real-time abnormal controller data and / or historical abnormal controller data.

10. The method according to claim 5, characterized in that, The anomaly identification rules include an artificial intelligence algorithm, which includes anomaly identification rules that identify controller data that exceeds a standard monitoring threshold as abnormal controller data.

11. The method according to claim 5, characterized in that, Before replaying the controller data related to the fault through the controller program, performing fault diagnosis, and obtaining the diagnosis result, the method further includes: Obtain the controller variable family corresponding to the abnormal controller data, and push the leaf node variables and / or intermediate node variables corresponding to the abnormal controller data in the controller variable family. The controller variable family is obtained by parsing the controller program. The controller variable family includes root node variables, intermediate node variables and leaf node variables that have a logical relationship with the root node variables. The root node variables are controller variables without parent nodes, the intermediate node variables are controller variables that have both parent nodes and child nodes, and the leaf node variables are controller variables without child nodes.

12. The method according to claim 1, characterized in that, The diagnostic results are displayed, including controller data and variable information of at least one controller variable related to the fault. The variable information includes any one or more of the following: variable name, variable address, variable type, variable corresponding device name, variable corresponding device address, physical function of the variable corresponding device, purpose of the variable corresponding device, variable importance priority, and device fault probability.

13. A fault intelligent diagnostic device, characterized in that, include: The data acquisition module is used to acquire controller data related to the fault. The controller data includes any one or more of the input data, intermediate process data and output data generated within multiple controller scan cycles. The program acquisition module is used to acquire the controller program corresponding to the controller data related to the fault; The playback diagnostic module is used to play back the controller data related to the fault through the controller program, perform fault diagnosis, and obtain diagnostic results.

14. A fault intelligent diagnostic device, characterized in that, include: processor; Memory; as well as Computer programs; The computer program is stored in the memory and configured to be executed by the processor to implement the method as described in any one of claims 1-12.

15. A fault intelligent diagnosis system, characterized in that, Includes the intelligent fault diagnosis device as described in claim 13 or 14.

16. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, causes the processor to implement the method described in any one of claims 1-12.

17. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the method as described in any one of claims 1-12.

Images