Method for identifying an automation component that causes a process disturbance in a linked automation device

Abstract

The present invention relates to a method and an automation component for identifying an automation component (BN, ..., C-6) that causes a process disturbance in an industrial automation system having a plurality of linked automation components (BN, ..., C-6), wherein the process disturbance is determined in a first automation component (BN) and checked there by a first local evaluation device. Each automation component (BN, ..., C-6) first determines at least one automation component (BN, ..., C-6) located upstream of the link and / or at least one automation component (BN, ..., C-6) located downstream of the link. A query message is then sent from the first automation component (BN) to at least one of the second automation components, and the second automation component (BN, ..., C-6) recursively sends the same or another query message to at least one third automation component (BN, ..., C-6) located upstream or downstream of the second automation component (BN, ..., C-6) and processes it in a similar manner there. If a disturbance is detected locally, the corresponding automation component (BN, ..., C-6) sends a response message, which propagates back to the origin and ultimately emits a signal. This allows a decentralized error analysis even if the plant topology changes without a new configuration.

Description

Background Art

[0001] Modern industrial automation installations, particularly production facilities (e.g., filling plants in the beverage or food industry), manufacturing facilities, or process technology facilities, are characterized by complex plant structures with a large number of interconnected workstations or modules. These workstations or modules are regularly controlled by programmable logic controllers. In the following, these stations or modules, together with their controllers, will be referred to simply as automation components.

[0002] In such facilities, a mainframe group ("bottleneck," "bottleneck component," "bottleneck unit") that limits throughput during production time may experience a failure. The cause of this failure is not immediately apparent because it lies outside the mainframe group itself, which determines the efficiency of the entire facility. Consequently, downtime at the bottleneck results in efficiency losses. To make the component actually responsible for the efficiency loss visible, thereby identifying potential measures to improve efficiency and diagnosing the cause, a so-called "root cause analysis," or "RCA" for short, is performed for the entire facility. Here, the disturbances that caused the facility failure are identified. This analysis requires, on the one hand, general knowledge of the facility structure and, on the other hand, knowledge of the behavior of the existing components (e.g., throughput, switching behavior). This general knowledge must be modeled and made available to the RCA. Furthermore, the current state history of the automation components involved in the disturbances, if any, must be analyzed within the mainframe group. Within the context of this RCA, so-called early warning (EW) analyses can also be performed for preventive purposes. The purpose of this EW analysis is to predict the point at which component downtime must be corrected to prevent a negative impact on the bottleneck. This also requires manual modeling of the facility structure and component behavior.

[0003] Until now, a facility had to be digitally modeled. This meant that all machines (automation components consisting of controllers and controlled mechatronic components) and the connections between them had to be created in a software tool such as Tecnomatix Plant Simulation. Furthermore, all relevant parameters of all affected machines (e.g., output per minute, start-up time, idle time) had to be stored. This could represent a significant amount of data, which was often not even specified by the machine manufacturer or could not be specified at all, as it depended on the environment (e.g., the actual product to be manufactured) and had to be measured manually. Due to fluctuations in reality, a certain degree of uncertainty (minimum and maximum values) had to be considered in the modeling. Once the facility model was finally completed, RCA could be performed on an external computer that was capable of receiving data from all machines. For example, a higher-level SCADA (Supervisory Control and Data Acquisition) system could be used if the following prerequisites were met: 1. The created facility model was up-to-date not only in terms of the relevant structure but also in terms of the relevant parameters. 2. The SCADA system had continuous access to all relevant dynamic data. This meant that all registered components / machine groups had to provide information in a suitable format at all times.

[0004] Document WO 2005093530 A2, “MODULARE MASCHINE UNDENTSPRECHENDES VERFAHREN ZUM DYNAMISCHEN KONFIGURIEREN DER TOPOLOGIE DIESERMASCHINE [MODULAR MACHINE AND CORRESPONDING METHOD FOR DYNAMICALLY CONFIGURING THE TOPOLOGY OF SAID MACHINE]” by Danz et al., discloses a method for finding neighboring machines in a distributed topology to configure communication relationships.

[0005] The publication DE 102 54 009 A1 by Heinemann, “Method and data network for automatically configuring closed-loop and open-loop controllers of machine tools or production machines”, describes a method for automatically configuring machines, wherein the machine topology is automatically determined.

[0006] A problem arises when RCA is to be performed temporarily in a newly configured or not yet fully modeled automation plant. Another problem arises when the facility is frequently reconfigured, especially when different products are to be manufactured alternately. Summary of the Invention

[0007] It is therefore an object of the present invention to be able to determine the causes of errors in a simple manner, ie to perform a root cause analysis (RCA), in an environment with a dynamic structure of an automation device.

[0008] The core idea for achieving this goal according to the invention is that RCA is performed directly on or within the automation components of the facility to be analyzed (automation device). To this end, the facility structure must discover itself dynamically, and the calculation of the RCA is decentralized across the linked machines (automation components or their controllers). The data required for this by the corresponding components (status information, configuration parameters for the analysis) can be continuously updated. In addition, it is hoped that the complexity for the user of the analysis will be reduced by reducing the configuration effort. In addition, the local processing of the locally recorded data reduces the requirements on the communication system of the automation device and eliminates the need for a superior execution and coordination unit for the analysis.

[0009] The solution to this object is provided in the present invention. The present invention discloses a method according to the present invention and an automation component according to the present invention.

[0010] The solution to this problem provides a method for identifying automation components causing process disturbances in an industrial automation system having a plurality of linked automation components, wherein the process disturbance is determined in a first automation component and checked there by a first local evaluation device. In a first step, each automation component determines at least one automation component located upstream and / or at least one automation component located downstream of the link. In a second step, depending on the type of process disturbance, the first automation component sends a query message to at least one second automation component located upstream or downstream of the link, and in a third step, the local evaluation device of the second automation component decides, based on locally stored or measured characteristic parameters, whether the second automation component is the cause of the process disturbance. In the affirmative case, a response message is sent to the first automation component (BN) in a fourth step. In the negative case, the second automation component recursively sends the same or another query message to at least one third automation component located upstream or downstream of the second automation component in a fifth step, where it is processed in a similar manner. In a sixth step, the response message received by the automation component is forwarded to the other automation component from which the corresponding query message was received. In a seventh step, the first automation component that ultimately receives the response message provides or outputs information about the automation component that is the cause of the process disturbance based on the content of the response message. The method thus forwards the query message until the automation component causing the disturbance returns a response message along the same path. This allows for decentralized error analysis even with changes in the facility topology, without new project planning.

[0011] The object is also achieved by a system comprising a plurality of automation components for operation in an industrial automation system having a plurality of linked automation components, wherein the or each automation component comprises an evaluation device, wherein the evaluation device is configured to determine whether at least one automation component located upstream of the link and / or at least one automation component located downstream of the link sends a query message to at least one second automation component located upstream or downstream of the link, depending on the type of process disturbance, and upon receipt of the query message, the evaluation device determines, based on locally stored or measured characteristic parameters, whether the automation component is the cause of the process disturbance. In this case, the automation component is configured to, in the affirmative case, send a response message to the inquiring automation component, and, in the negative case, forward the same or another query message to at least one automation component located upstream or downstream of the automation component, and accordingly forward the received response message to the automation component from which the relevant query message was received. If the automation component is the original sender of the query message, information about the automation component that is the cause of the process disturbance is provided or output based on the content of the relevant response message. By using automation components designed in this way, the advantages already discussed with respect to this method can be achieved.

[0012] Advantageous embodiments of the present invention are described in detail in the present invention. The features and advantages described here apply both to the method and to the automation component according to the present invention. Advantageous variants can be implemented individually or in combination with one another.

[0013] Advantageously, one of the automation components is identified as the first automation component, whose performance determines or limits the performance of the entire automation system ("bottleneck"; "bottleneck component"; "BN"). This automation component can usually be the first to detect a disturbance and can therefore be the first to trigger the analysis process. The selection of the first automation component can be made manually by the management. Advantageously, the component itself is determined independently, for example according to the machine type (for example a filling unit in the beverage industry). Another possibility is that one or each automation component queries the performance parameters of all automation components, such as the hourly throughput, based on a token by means of a query message forwarded in the network and automatically selects the automation component with the lowest performance parameter. It is also possible that several bottleneck components are defined in the facility network. For example, it can also be determined that the last component "downstream" assumes this role as a default value.

[0014] For a simple structural analysis, in a first step the automation components arranged upstream and / or downstream can be determined based on the data channels of adjacent automation components or based on the material input and / or material output interfaces of these automation components.

[0015] Alternatively or additionally, in a first step, upstream and / or downstream automation components can be determined based on the test subject running through the automation device. The test subject can record the stations it passes through, thereby recording the automation components. The automation components can also register the presence of the test subject and record each of them with a timestamp. In the latter variant, communication between the automation components is necessary to derive the topology. In the first variant, the information recorded by the test subject must ultimately be made available or transmitted to the automation components in the network.

[0016] Advantageously, if a branch includes multiple automation components located upstream or downstream of a link, multiple parallel query messages are sent in the second step, wherein the corresponding multiple response messages are combined into a common response message by the automation component that sent the parallel query messages. This allows analysis of branched automation devices or networks.

[0017] In case the query message reaches the last automation component in the link, it is responded to with a response message in the opposite direction of the link.

[0018] Advantageously, if the cause of a future process disturbance is foreseeable based on local characteristic parameters, a warning message is sent by a local analysis device of one of the automation components to at least one of its neighboring automation components. This message is advantageously forwarded to the bottleneck component or another selected automation component and issued or otherwise processed by it.

[0019] At least in the case of multiple branches, the query message and the response message advantageously each include a separate token. Alternatively or additionally, a unique ID (e.g., of the first automation component) and / or a timestamp can also be used. The timestamp also allows for timeout control to account for lost messages.

[0020] Preferably, in the event of a change in the topology of the industrial automation device, at least the first step is performed again on each automation component. This can also be provided for each restart of the installation. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] An embodiment of the method according to the invention is explained below with reference to the accompanying drawings, which also serve to explain the automation component according to the invention.

[0022] Here it is shown:

[0023] Figure 1 shows the prior art with central error analysis,

[0024] Figure 2 A schematic diagram showing an industrial automation device with linked automation components, and

[0025] Figure 3 shows the query and response messages in accordance with Figure 2 The spread starts from the bottleneck unit in the device. DETAILED DESCRIPTION

[0026] Figure 1 A typical apparatus for error analysis is schematically shown, wherein a computer for error analysis (on the left side of the diagram) is connected to the data network of a distributed industrial automation system (shown on the right side of the image). The prior art proposes that the computer record all status and operating information of individual automation components (not shown individually), derive the cause of the fault from this data, and output or report it (via an alarm, an HMI device, etc.).

[0027] Figure 2 An automated system, such as a filling facility, is shown structurally. Arrows indicate material flow. A bottleneck BN is a component that limits the performance of the facility, such as a packaging machine. Other automated components are arranged upstream and / or downstream of the bottleneck BN (not shown), such as conveyor belts T-1 and T-4, a unit M-2 for merging materials ("merging"), a unit S-5 for separating material flows ("splitting"), and generally, units C-3a, C-3b, C-4, and C-5. In the example shown, there is a starvation, i.e., a material shortage, at the bottleneck BN. The numbers in the reference numerals indicate how far the automated component, or generally, the element, is located in the "upstream" direction (in the direction of material flow) relative to the bottleneck BN.

[0028] Technical problems (intrinsic errors), material shortages in the inflow (starvation), or obstructed material output (blockage) are essentially the causes of component downtime. Furthermore, some components can only experience disturbances without inherent errors due to the interaction of multiple external factors. Examples of this are material consolidation and material distribution, where external disturbances (shortages, traffic jams) are sometimes "required" at two or more input / output nodes in order to account for downtime without inherent disturbances. This necessitates a "memory" for performing RCA, meaning that it is not sufficient to initiate independent analyses for all connected components. Instead, a method must be found to combine the results of analyses on different "paths," even when performing RCA in a decentralized manner. This occurs in the case of "starvation," where material flows to components that flow together, or in the case of "blockage," where material flows are separated.

[0029] To automatically determine Figure 2In the facility structure outlined in [1], components (e.g., machines, conveyors, etc.) that are directly connected ("linked") to one another in the material flow communicate their presence to one another using the available communication channels (automation data networks). To this end, all components integrated into the analysis have a computing unit that both performs the analysis and provides the required communication interfaces. Programmable logic controllers or separate computers, already present in the individual stations, can serve as computing units or "platforms." Existing data lines or communication connections introduced for this purpose can be used for communication.

[0030] In this example, this self-discovery is achieved via a communication channel set up for this purpose. Here, each interface implemented via the material flow is assigned a communication interface that is directly connected to each other at the components involved in the material flow. Therefore, each component knows which components it is connected to in the facility in terms of material flow technology and via which communication interfaces it can send queries to adjacent components. In an alternative method, a specially marked product (e.g. a bottle with an RFID tag) that can be recorded by all existing components is introduced into the material flow. As soon as this product arrives at a component, the component reports the arrival of the marked product to all other components in the form of a broadcast, along with a unique ID for the component and, if necessary, time information (time stamp). The facility structure related to the material flow is given directly by the order in which the components report the arrival of the marked products, and each component can deduce the components connected to it.

[0031] Using the method described as an example, each component can also determine the direction of material flow, i.e., via which directly connected adjacent component the bottleneck is reached or via which adjacent component the material exits. After the discovery phase, the logical overall structure of the facility is present in sufficient form in the RCA and implicitly enables error predictions (early warnings) between the relevant machines; this knowledge is distributed among the automation components. If the facility structure changes during operation, a new facility model does not need to be created; it is automatically updated using the same mechanism used to generate the original facility model.

[0032] The RCA calculation is essentially based on processing status information about the machines in a production facility, e.g., whether the machine is operating normally, has a technical defect, is lacking input material (starvation), or has a blocked output channel (blockage). More generally, other machine parameters (e.g., throughput) can also be taken into account. In individual cases, this can also be master data (e.g., startup time after a stoppage), especially when no measured values are available. In the decentralized RCA calculation concept shown, all data is also preferably stored locally on the machine.

[0033] Each machine should "remember" its state history over time. Since there is not necessarily an external database or external central computer responsible for the calculation, all data required for the calculation must be saved and updated in the machine or local computing unit.

[0034] The starting point for RCA is always a stoppage in one or more bottleneck machines. Since the machine itself knows from which direction the problem is coming (material inflow or outflow, starvation or blockage), it knows which machine it must "respond" to, or in the case of branch machines, must "respond" to, in order to ultimately reach the machine causing the problem.

[0035] For an example of the message traffic generated in Figure 3 This example involves Figure 2 The structure shown.

[0036] Thanks to the given communication path (determined from the facility structure), the bottleneck BN can, in the event of a material shortage, turn to the machine (here: conveyor belt) T-1 ("upstream", i.e. opposite to the material flow path), which together with its own current parameters relevant for the situation, gives them the responsibility for initiating all necessary further steps.

[0037] Component T-1 then checks whether there are inherent disturbances that could cause a bottleneck stoppage within the time window defined by its own characteristics and, if necessary, those of the preceding component. For example, a conveyor belt stoppage lasting more than 5 seconds within the last 60 seconds.

[0038] If not, component T-1 switches to component M-2, and so on. Ultimately, as with conventional RCA, the machine causing the bottleneck can be identified and indicated in the facility using appropriate means. SCADA data points, HMI panels, warning lights, and the like are all conceivable. Crucially, all characteristic parameters must be located solely within the machine itself, and every calculation performed there.

[0039] In this example, it is now assumed that components C-5 and C-4 are responsible for the bottleneck outage, wherein both do not produce their rated power before component M-2 in separate branches of the facility and provide material to bottleneck BN with insufficient total throughput.

[0040] Figure 3The diagram shows the paths of search messages (solid arrows) and associated result messages (dashed arrows) in a decentralized RCA. Each message consists of a unique token with the result. It doesn't matter whether the token also has storage space for the result or intermediate results, or whether these results are attached to the corresponding token. In a branchless system, the token itself is less important and can be omitted in some cases. However, in a branching system, a token or other unique identifier is important to merge messages and their results from different branches.

[0041] In the figures, the numbers 1, 2, or 3 are marked on the components in the upper left corner, indicating the result associated with the respective token of the incoming message. In practice, the corresponding result often also describes a specific performance parameter and its source, for example, "C-6: Throughput; 80%-1000 per hour; Error: neg." In practice, absolute identifiers are used instead of or in addition to the relative position "C-6." For simplicity, the examples shown here only distinguish between three states: 1: "Token with undefined result"; 2: "Token with result: the link is at least partially responsible"; and 3: "Token with result: the link is not responsible at all."

[0042] Each component has knowledge of its neighboring components based on its own topological investigation and therefore also has information about which connected components are being queried for the current bottleneck stoppage. Components that must track multiple lines are assigned "tokens." These tokens contain the following information: - Token ID (a unique numerical value, such as a GUID - device identification number) - Current search status (in the illustrated state, the bottleneck is starving in the case of M-2) - Scope for subsequent response units. In our case, if a component is found upstream of M-2 (i.e., in the opposite direction of the material flow) that could explain the starvation state of at least one of at least two lines, it then registers its unique ID at that point. "Merging" components, where separate material flows are brought together, can then determine whether all lines explain the state and, from this, conclude whether one or more of the units that responded accordingly are valid root cause candidates.

[0043] The message process is as follows Figure 3 Here, the message path of the token in the search direction is marked with a solid arrow, while the feedback path is represented by a dotted arrow.

[0044] The order of search in the example shown is as follows: the search continues linearly until component M-2, where no token is needed. Component M-2 requires that both paths must have interference in order for the interference to be accounted for at component M-2. Therefore, component M-2 generates separate tokens for the following two paths so that it can later be checked whether the sum of the results can account for the interference. The token numbered 1 (shown in the upper left corner of the component) is passed linearly until C-5, where the component has inherent interference.

[0045] The result returns to component M-2 along the same path. The token labeled 2 first arrives at component C-3b; this process occurs in parallel with the sending of the first token 1. Although component C-3b is connected to two components, C-4 and S-5, via the split point S-5, at least one interference path is sufficient for illustration. A new token 3 is generated and passed to component C-6 via component S-5. There is no interference at component C-6. Since component C-6 is the last component, token 3 is marked as not responsible and returned to component C-3b. At the same time, token 2 is directed to component C-4. There is inherent interference. This is indicated in token 2 or the message marked with it, and the message with this token is directed to component C-3b. At component C-3b, at least one line interference is detected (C-4, notified by token 2), and this result is forwarded to component M-2. The two tokens 1 and 2, and the messages forwarded with them, at least generally explain the downtime, because, for example, the messages from both branches indicate that the required amount of material has not been fully delivered. Components marked with a token will be considered the “root cause,” i.e., the cause of the interference.

[0046] The functions required for the described method and their basic parameters can be configured as PLC function blocks in a plant or component, ie they can be provided at the time of planning the installation.

[0047] The method described here also enables error prediction, known as early warning, which is triggered not only by the bottleneck (BN), but also by all other units or components that have inherent errors. Through dynamic "self-discovery" of the facility structure, ideally, each unit knows in which flow direction the bottleneck (i.e., the unit critical to throughput) is located and, therefore, in which direction the early warning analysis must be performed. If this knowledge is unavailable for some reason, the machine that is currently down or about to be changed can also report this fact in all flow directions.

[0048] Compared to the traditional performance of RCA (central), the algorithm is now executed in a distributed manner across multiple computing units. The proposed method for decentralized coordination of topology determination and execution of the actual RCA algorithm (including early warning) has the advantage of "plug and play" (i.e. self-configuration) of RCA and the possibility of early warning (EW-early warning).

[0049] Due to the dynamic self-discovery of facility components, manual modeling of the facility structure is no longer necessary. RCA can thus be used immediately. In the event of a dynamic reconfiguration of the facility (e.g., by reconfiguring, adding, or removing components), the selected method for self-discovery of the facility structure can be re-implemented locally. RCA can thus be used again immediately after reconfiguration.

[0050] The data relevant to RCA can be evaluated locally on or near the component (data-related or spatially close). All component-specific data is available here. This data does not need to be reported to a higher-level system (e.g., as a continuous stream). The available computing power and storage capacity required for the overall analysis scale automatically and linearly with the added components. This means RCA scales automatically as the automation installation grows.

Claims

1. A method for identifying an automation component (BN, ..., C-6) causing a process disturbance in an industrial automation device having a plurality of linked automation components (BN, ..., C-6), in, A process disturbance is determined in a first automation component (BN) and is checked at the first automation component by a first local evaluation device. It is characterized by: In a first step, at least one automation component (BN, . . . , C-6) located upstream of the link and / or at least one automation component (BN, . . . , C-6) located downstream of the link is determined by each automation component (BN, . . . , C-6). In a second step, depending on the type of process disturbance, the first automation component (BN) sends a query message to at least one second automation component (BN, . . . , C-6) arranged upstream or downstream of the link. In a third step, a local evaluation device of the second automation component (BN, . . . , C-6) is used to determine, based on locally stored or measured characteristic parameters, whether the second automation component (BN, . . . , C-6) is the cause of a process disturbance, wherein, in the affirmative, In a fourth step, a response message is sent to the first automation component (BN), and wherein, in the negative case, In a fifth step, the second automation component (BN, ..., C-6) recursively sends the same or another query message to at least one third automation component (BN, ..., C-6), which is located upstream or downstream of the second automation component (BN, ..., C-6), and processes the query message in a similar manner at the third automation component. In a sixth step, the response message received by the automation component (BN, ..., C-6) is forwarded in each case to another automation component (BN, ..., C-6) from which the automation component (BN, ..., C-6) receiving the response message received the associated query message, and In a seventh step, the first automation component (BN) that finally receives the response message provides or outputs information about the automation component (BN, . . . , C-6) that is the cause of the process disturbance, depending on the content of the response message.

2. The method according to claim 1, characterized in that An automation component (BN, . . . , C-6) whose performance determines or limits the performance of the entire automation device is determined as the first automation component (BN).

3. The method according to claim 1 or 2, characterized in that In the first step, an upstream and / or downstream automation component (BN, . . . , C-6) is determined based on a data channel or based on a material input interface and / or a material output interface of this automation component (BN, . . . , C-6).

4. The method according to claim 1 or 2, characterized in that In the first step, the automation components (BN, . . . , C-6) arranged upstream and / or downstream are determined based on the test body passing through the automation device.

5. The method according to claim 1 or 2, characterized in that In the case where a branch includes multiple automation components (BN, ..., C-6) located upstream or downstream of the link, multiple parallel query messages are sent in the second step, and the corresponding multiple response messages are combined into a common response message in the automation components (BN, ..., C-6) that sent the parallel query messages.

6. The method according to claim 1 or 2, characterized in that In case the query message reaches the last automation component (c-5, C-6) in the link, this last automation component is responded to with a response message in the opposite direction of the link.

7. The method according to claim 1 or 2, characterized in that If the cause of a future process disturbance can be foreseen based on the local characteristic parameter, a warning message is sent by the local evaluation device of one of the automation components (BN, . . . , C-6) to at least one adjacent automation component (BN, . . . , C-6).

8. The method according to claim 1 or 2, characterized in that At least in the case where there are multiple branches, the query message and the response message each include a separate token.

9. The method according to claim 1 or 2, characterized in that In the event of a change in the topology of the industrial automation system, at least the first step is performed again at each automation component (BN, . . . , C-6).

10. A system having an automation component (BN, ..., C-6) for operation in an industrial automation installation having a plurality of linked automation components (BN, ..., C-6), It is characterized in that The automation component (BN, . . . , C-6) has an analysis device, wherein the analysis device is configured to: - determining at least one automation component (BN, . . . , C-6) situated upstream of the link and / or at least one automation component situated downstream of the link, - depending on the type of process disturbance, sending a query message to at least one second automation component (BN, . . . , C-6) arranged upstream or downstream of the link, - upon receiving a query message, the evaluation device decides, based on locally stored or measured characteristic parameters, whether the automation component (BN, . . . , C-6) is the cause of a process disturbance, wherein in the affirmative case a response message is sent to the inquiring automation component (BN, . . . , C-6), and wherein in the negative case the automation component (BN, . . . , C-6) is configured to send the same or a further query message to at least one further automation component (BN, . . . , C-6) situated upstream or downstream of the automation component, - forwarding the received response message in each case to another automation component (BN, ..., C-6) from which the automation component (BN, ..., C-6) received the associated query message, and In case the automation component is the original sender of the query message, providing or outputting information about the automation component (BN, . . . , C-6) that is the cause of the process disturbance, depending on the content of the associated response message.

Images