Method for checking an industrial plant, computer program, computer-readable medium and system

Description

[0001] The invention relates to a method according to claim 1 for checking an industrial plant, in particular an automation plant.

[0002] Furthermore, the invention relates to a computer program according to claim 14, a computer-readable medium according to claim 15 and a system according to claim 16.

[0003] An automation system consists of many different individual components whose interaction enables the solution of the automation task. These individual components can be hardware components, software components, or combined hardware and software components.

[0004] Especially during the commissioning of a system, checking for errors is a key aspect in ensuring compliance with the necessary safety requirements. However, the interaction of the large number of individual components can lead to dependencies, and thus additional causes of malfunction that could not be considered when testing the individual components. To the applicant's knowledge, a comprehensive review of possible dependencies with a large number of individual components is currently not possible or would require considerable effort.

[0005] Another problem is that currently, only those test scenarios considered during engineering are executed. This means, in particular, that potential failures in the overall system that are beyond the comprehension of individual engineers often go undetected. Furthermore, many pre-planned and programmed responses to error situations are not even tried during commissioning and testing due to time or effort constraints. As a result, it is often only when a real failure occurs during operation that we learn how the system actually behaves and whether the standards applied were sufficient.

[0006] Simulation tools are known that can be used to simulate industrial plants and their behavior. Within the framework of such tools, it is possible to deactivate or manipulate individual components and observe the effects, which, to the applicant's knowledge, is currently only done intentionally and manually. SIMIT from the applicant is a purely exemplary simulation tool or platform for industrial, technical plants (see, for example, https: / / new.siemens.com / global / de / produkte / automatisierung / industrie-software / simit.html).

[0007] Also well known is the tool "Chaos Monkey", used by Netflix to regularly deactivate random instances of a software service in order to test a redundant server architecture and verify that a server failure does not have a noticeable impact on customers (see, for example, https: / / github.com / Netflix / SimianArmy / wiki / Chaos-Monkey).

[0008] The publication US 2011 / 0288846 A1 - Kihas "Technique and tool for efficient testing of controllers in development (H-ACT Project)" shows the automated test of a control device, whereby input variables for the test are randomly generated or varied.

[0009] The publication US 9,134,726 B2 - Colombo et al. "METHOD FOR CONFIGURATION SOA-BASED AUTOMATION DEVICES AND FOR DEVELOPING AN ORCHESTRATION MACHINE, PRODUCTION METHOD AND PRODUCTION SYSTEM IN SERVICE-ORIENTED ARCHITECTURE HAVING EMBEDDED SERVICE ORCHESTRATION ENGINE" shows a configuration tool for an automation system consisting of a number of mechatronic components.

[0010] The publication US 2007 / 0162894 A1 - Noller et al. "METHOD OF AND SYSTEM FOR DYNAMIC AUTOMATED TEST CASE GENERATION AND EXECUTION" discloses an automated test system in which modular software is tested in multiple test runs, with the order of execution of the software modules being changed randomly in each case.

[0011] Based on the prior art, it is an object of the present invention to provide a method for testing an industrial plant, in particular an automation plant, which enables particularly high reliability and, at the same time, particularly comprehensive testing of even complex plants.

[0012] This object is achieved in a method of the type mentioned at the outset in that real components of a provided real system and / or data originating from such components and / or simulated components of a provided simulated system and / or data originating from such components are manipulated, particularly during operation, using a computer program comprising at least one random algorithm in such a way that error situations are caused in the real and / or the simulated system based on randomness. Two or more components of the system and an edge device are connected to one another via a communication network, particularly in the form of a bus, and data that is to be sent from at least one component to at least one further component via the communication network is manipulated by the computer program running on the edge device before being transferred to the communication network.

[0013] The applicant has found that by using a random-based, tool-supported chaos method, a particularly comprehensive, reliable testing of even complex industrial plants is possible with comparatively little effort, both during a simulation phase and during commissioning, in particular of a real, physical plant.

[0014] Since, according to the invention, components of a system and / or data derived from them are manipulated randomly, the resulting error scenarios are not limited to scenarios specifically selected or considered by an operator or engineer, as is the case with the state of the art. Rather, virtually any scenario can be caused and thus covered. This makes it possible for the first time to find errors or failure causes in an industrial system that were not or could not have been considered during engineering and / or that arise from the complexity of the system. This represents a significant advantage over the state of the art.

[0015] The task of the computer program, which is also referred to below as a chaos software tool, and which in particular forms or represents a runtime tool, is preferably to boycott the (real and / or simulated) system or parts / components / data thereof in an arbitrary or random manner. Preferably, selected, in particular previously defined, error scenarios are to be implemented randomly. The chaos software tool is designed accordingly for this purpose. It is in particular a computer program or a collection of computer programs with corresponding program code resources.

[0016] The method according to the invention can be implemented both for testing a physically existing plant and for a plant simulation, such as a digital twin. Of course, a combination is also possible, for example, where both a real plant (or at least parts of it) and a simulation (or parts of it) that may be carried out during operation are randomly "boycotted" in the manner according to the invention. If both a real and a simulated plant are provided, components of both plants and / or associated data can be manipulated in the manner according to the invention.

[0017] The method according to the invention also offers a significant advantage during the acceptance of a plant. It can be used to demonstrate the stability and safety of a plant by randomly generating fault scenarios and observing that they do not lead to an unsafe state.

[0018] Manipulating a component also includes, in particular, changing it from an on state to an off state. Deactivating a component therefore also constitutes manipulation.

[0019] A preferred embodiment of the method according to the invention is characterized in that the effects of the manipulation on the real and / or the simulated system, in particular its operation, are recorded or observed, and the real and / or the simulated system and / or its control is adapted as required, in particular detected errors are rectified.

[0020] A plant can be monitored during and / or after the inventive "boycott," and any errors or "teething problems" that arise during this process can be eliminated—if necessary. The invention makes it possible to eliminate errors resulting from random factors, especially before production begins, which has a significantly positive effect on the fault tolerance, stability, and maintainability of a plant during operation.

[0021] The reaction of the system being tested to the randomly generated errors or error scenarios can be recorded electronically, for example, using the Chaos software tool. Alternatively or additionally, it is also possible for the system's reaction to be observed by a person.

[0022] In a further preferred embodiment of the method according to the invention, it is provided that a set of rules is created or provided to describe components of the system to be considered or to be considered for the inspection, together with information on the behavior of the components and / or on the connectivity of the components and / or on safety aspects relevant to the components, and the random error situations are caused by the computer program with reference to the set of rules. The behavior of components can be described, for example, as their start and stop behavior as well as their good and incorrect behavior. The computer program can access the set of rules and / or apply the set of rules.

[0023] Since industrial (automation) systems are usually not homogeneously constructed, but are composed of a large number of different individual components and their connections to one another, it has proven particularly suitable to first create a set of rules to describe, in particular, the hardware and / or software components and their behavior.

[0024] If a set of rules is provided, this can advantageously include: Information on which error cases can occur in the respective component, preferably classified according to error types, and / or information on how error cases can be technically triggered and / or simulated, in particular by the computer program, and / or a set of error algorithms with associated parameters that represent different scenarios that preferably differ in terms of which error types and / or components should be taken into account, and / or how many errors may occur simultaneously, and / or what the time behavior of the system and / or a control program is and / or how long an error situation should last, and / or how quickly the next error situation should be caused after a previous error situation.

[0025] The error algorithms can then be randomly selected, in particular by the Chaos software tool.

[0026] In particular, the number of error algorithms can be used to vary, for example, which error types or components should be taken into account, how many errors may occur simultaneously, what the timing behavior is (e.g. sporadic, cyclical, permanent, ...), how long an error situation should or may last, how shortly after resetting one situation the next should or may be triggered, etc.

[0027] For components of an industrial automation system and the associated error cases or states as they are recorded or can be contained in a set of rules for a given system, the following are purely examples: A switch in an intralogistics system with the error cases: 1) closed blocked, 2) open blocked, 3) inverted behavior, 4) time-delayed behavior, 5) clock-shifted behavior

[0028] A light barrier on a conveyor belt with the error states: 1) always on, 2) always off, 3) flickering, 4) bouncing.

[0029] A barcode reader in a sorting system with the following error states: 1) Carrier does not trigger, 2) Barcode is not readable, 3) Barcode is misread, 4) old "buffered barcodes" report, 5) bounce.

[0030] It should be noted that a real plant can include both purely hardware- and purely software-based components, as well as components that combine (special) hardware and software. The components of a simulated plant are usually in the form of software or software modules, which represent or "digital replicas" of real components.

[0031] For example, an error algorithm can represent the case or scenario in which an existing switch is opened and closed several times in succession.

[0032] An error algorithm can also represent a random generator that, for example, opens and closes a switch from time to time.

[0033] The chaos software tool can, using at least one random algorithm for one or more components, select an error algorithm from the rule set and, based on this, select an error situation or error state, and implement it in real life and / or in simulation to "boycott" the system accordingly. In particular, the chaos software tool can select and implement one of the preconfigured error situations represented by error algorithms, preferably at any time and / or independently of other aspects.

[0034] A further embodiment of the method according to the invention is characterized in that a safety device is assigned to the system or the system comprises such a device. The safety device is then preferably designed and / or configured to enable intrinsically safe operation of the system, at least with regard to some safety aspects. Furthermore, the safety device is preferably activated during the inventive testing of the system, so that if an error situation is triggered using the Chaos software tool that could lead to or does lead to a dangerous situation, it can or does transfer the system from the safety device to a safe state.

[0035] As a rule, a technical device used to establish a fail-safe state (fault-directed system or safety device) is designed according to the standard to operate independently of the normal automation unit and to be intrinsically safe. This means that even if the chaos software tool triggers an error situation that leads to a dangerous situation, a fault-directed system can detect this and bring a system into a fail-safe state. In combination with such a safety device, the use of the chaos software tool can be made particularly safe. A safety device can, for example, be one that complies with the EN 62061 standard.

[0036] In particular, in the event that the triggering of such "unsafe" or "dangerous" scenarios is nevertheless undesirable, for example because exiting from a fail-safe state can be costly, the rules can also take into account impermissible error states.

[0037] A further embodiment is accordingly characterized in that the set of rules includes or is expanded by prohibited error situations, and the computer program first randomly determines an error situation, compares the determined error situation with the error situations prohibited according to the set of rules, and only if no prohibited error situation was determined, triggers and / or simulates the error situation in the system; otherwise, a new random error situation is determined and again compared with the error situations prohibited according to the set of rules. This step can expediently be repeated as often as necessary until a non-prohibited error state is obtained randomly.

[0038] Furthermore, it can be stipulated that the rules for at least one component are and / or will be defined so that it may only be manipulated under certain conditions, in particular only under professional supervision and / or only at certain times. Particularly sensitive or particularly high-security components can also be exempted from random testing. On the other hand, it is of course also possible to specify for one or more components that they may be manipulated under any conditions, for example, at any time.

[0039] If it is intended that a set of rules is to be used, this can be loaded onto one or more components of the system.

[0040] The computer program must also be able to be loaded onto at least one component of the system. This can preferably be done together with a set of rules.

[0041] In another particularly preferred embodiment, an engineering tool is provided, which can be accessed or is accessed for the creation of the set of rules. The creation of the set of rules can be carried out, for example, by a developer, builder, and / or operator of a system to be tested using the engineering tool. In particular, data or information can be obtained or extracted from the engineering tool, on the basis of which a set of rules is then created. Purely as an example of an engineering tool, the applicant's so-called TIA Portal is mentioned (see in particular https: / / assets.new.siemens.com / siemens / assets / public.15414888 70.9bb07edc-ea5a-4128-99ff-7f9d4ae623db.7801-09-tia-p-ipdf-de-181029-1.pdf).

[0042] For or during the creation of the rulebook, it is very advantageous to have access to the system to be tested and / or (if available) a digital twin of the system. This is particularly important because the information about which actuators or sensors are installed in the system can usually be read or evaluated from the control program, such as a PLC program. Direct access to the system thus offers a particularly simple way to obtain information, including information about the structure and behavior of the system.

[0043] As already mentioned at the beginning, the method according to the invention is characterized in that two or more components of the system are connected to one another via a communications network, in particular in the form of a bus, and data that is to be sent from at least one component to at least one other component via the communications network is manipulated by the computer program before being transferred to the communications network. In this case, the manipulation preferably takes place immediately before the data is transferred to the communications network, whereby "immediately" is understood in particular to mean that the manipulation takes place the last step before "sending to the communications network."

[0044] If at least one component of the system is a programmable logic controller, in particular, data to be sent by it, in particular control data, can be manipulated, for example, at a cycle control point.

[0045] Furthermore, it can be provided that the computer program manipulates data in or from a system, in particular IO data, in accordance with the rules in order to apply the rules to a system to be tested.

[0046] Data manipulation to obtain random-based error situations is preferably done in such a way that all computer programs of a system that access IO data (e.g., control program(s) / HMI script(s), etc.) remain unchanged. In principle, different approaches are possible for this.

[0047] A pure software solution is provided, for example, by loading the Chaos software tool onto one or more existing devices with access to an existing communication network, such as peripheral device(s) and / or preferably programmable logic controller(s), preferably together with an applicable set of rules.

[0048] A software- and hardware-based solution is also conceivable. For example, a system, preferably specifically developed for this purpose, which may include or be provided by a PC, particularly an industrial PC, can be connected to a communications network of a system to be tested. The Chaos software tool is then already present on the system, and only the ruleset still needs to be loaded onto it.

[0049] Depending on which of the variants mentioned is implemented, the data, especially IO data, can be manipulated according to the rules, for example as follows.

[0050] On a programmable logic controller in particular at the cycle checkpoint, as the last step before sending to the bus.

[0051] On a peripheral device, for example, before writing an actuator and after reading a sensor to / from the respective IO module.

[0052] In the case of a software and hardware solution, the traffic of the communication network itself (e.g., the bus) is preferably monitored, and the corresponding data, especially IO data, is manipulated at the protocol level. To this end, the network topology is expediently configured or selected in such a way that any IO communication only takes place using a system on which the Chaos diagnostic tool is preferably present or installed, and in particular, passes through the system, thus ensuring access to all relevant data.

[0053] For this purpose, a system according to the invention can be used, which is described in more detail below.

[0054] Particularly preferably, regardless of how the manipulation takes place, it takes place transparently for all participants in the communication network / bus of a system, i.e. they can be used unchanged.

[0055] Furthermore, it is possible to include standardized tests, such as those already performed according to the state of the art, particularly in the development of systems, in addition to the random-based verification according to the invention. Unit tests are purely exemplary of standard tests.

[0056] The information, especially compiled into a set of rules, can be used by the computer program. The computer program can, for example, run on an edge device connected to the system being tested and / or a digital twin of such a system, and / or be part of a system simulation.

[0057] In a further embodiment, the computer program can issue an instruction to a user that includes a manipulation action to be performed manually by the user. This represents a possibility for implementing error scenarios that cannot be triggered or caused (purely) electronically. An example of an instruction or "manipulation suggestion" for a person is that a workpiece that has already passed through a station is removed from the conveyor belt and placed back on at a different location.

[0058] It can also be provided that the computer program, as an alternative or in addition to a real system, manipulates a simulated system and realizes at least one error situation that could not be triggered electronically in a real system corresponding to the simulation. An example of such an error situation is a workpiece falling off a conveyor belt or becoming jammed. This cannot be realized, or cannot be easily realized, using pure software commands, data manipulation, or intervention in a power supply. In order to be able to cover and take such scenarios into account, it can be very advantageous to provide a simulated system or a digital twin of a system.

[0059] Another subject of the invention is a computer program comprising program code means for carrying out the steps of the method according to the invention.

[0060] The computer program according to the invention can comprise a plurality of modules, for example a tool or a module for creating a set of rules, in particular an engineering tool, and a runtime tool or a runtime module, which is preferably configured to manipulate real components of a provided real system and / or data originating from such components and / or simulated components of a provided simulated system and / or data originating from such components using at least one random algorithm, in particular during ongoing operation, in such a way that error situations are caused in the real and / or the simulated system based on randomness. The runtime tool can in particular be the chaos software tool.

[0061] It should be noted that, as an alternative to representing only a module, i.e. only a part of an embodiment of a computer program according to the invention, the chaos software tool can also form such a module.

[0062] The invention further relates to a computer-readable medium comprising instructions which, when executed on at least one computer, cause the at least one computer to carry out the steps of the method according to the invention.

[0063] The computer-readable medium can be, for example, a CD-ROM or DVD, or a USB or flash memory. It should be noted that a computer-readable medium is not exclusively understood to mean a physical medium, but can also be in the form of a data stream and / or a signal representing a data stream.

[0064] Finally, the invention relates to a system for carrying out the method according to the invention, comprising at least one connection, in particular for connection to a communication network, at least one processor and at least one memory on which a computer program according to the invention is stored.

[0065] A system according to the invention preferably has at least one network port for connecting to a communication network of an industrial plant, such as a bus system. It is further preferably configured such that it can "listen in" on fast data traffic, for example, via PROFINET, and / or communicate with an engineering tool, preferably an engineering tool that is or has been used for planning the plant(s) to be tested. Accordingly, it preferably has at least one interface for connecting to such a tool.

[0066] The system according to the invention can also be provided by a so-called edge device. An edge device is characterized in particular by having cloud access, i.e., preferably, at least one interface for connecting to a cloud. For example, a digital twin of a system can be available in a cloud. The digital twin can then also be manipulated via a computer program according to the invention, particularly present on the edge device.

[0067] Further features and advantages of the present invention will become clear from the following description of embodiments of the invention with reference to the accompanying drawings, in which, in a purely schematic representation, Figure 1 an industrial automation system being tested according to an embodiment of the method according to the invention; and Figure 2 a control of the system FIG 1 which is connected to sensors / actuators and which triggers a fault situation based on randomness using a chaos software tool.

[0068] The Figure 1 shows a purely schematic partial representation of an industrial, technical automation system in which goods or objects not further shown in the figure are produced or further processed automatically.

[0069] In the Figure 1Some components of the automation system 1 are shown as examples, specifically a bus 2, a production line stage 3, an assembly module 4, and a transport module 5. The production line stage 3, the assembly module 4, and the transport module 5 each comprise actuators and sensors as well as their own controller. The production line stage 3, the assembly module 4, and the transport module 5 are each connected to the bus 2. The bus connection 6 is indicated schematically by a line. Data can be transmitted between connected devices via the bus 2 in a conventional manner.

[0070] Also shown is an edge device 7, which represents an exemplary embodiment of a system according to the invention. This comprises a processor, a memory, and an interface for connection to a communications network, specifically the bus 2 of the system 1, via which the components can exchange data. In the present case, the edge device 7 is an industrial PC. A chaos software tool 8 is stored on the edge device 87. In the exemplary embodiment described here, the chaos software tool 8 forms one of two modules of an exemplary embodiment of a computer program according to the invention.

[0071] The second module is provided by an engineering tool 9, in which a user (not shown in the figures) can create a set of rules 10 for describing the system 1 and a digital twin 12 of the system 1 available in a cloud 11. In this case, the engineering tool 9 is the TIA Portal, which originates from the applicant. This is to be understood merely as an example, and in principle, other engineering tools can also be used.

[0072] The engineering tool 9 is connected to the edge device 7 in such a way that a rule set 10, after being created by a user, can be transferred to the edge device 7. A corresponding interface is available between the edge device 7 and the engineering tool 9.

[0073] The edge device 7, on the other hand, has access to the cloud 11, in which the digital twin 12 of the automation system 1 is available.

[0074] Elements provided with the reference number 13 in Figure 1 indicate that by means of the edge device 7, specifically using the chaos software tool 8 stored thereon, error situations 13 can be or will be triggered both in the real automation system 1 and in the digital twin 12 in the cloud 11.

[0075] To check the automation system 1 and the digital twin 12, an embodiment of the method according to the invention is carried out.

[0076] In this case, real components 2-6 of the provided real plant 1 and data originating from such as well as simulated components of the provided simulated plant 12 and data originating from such are manipulated using the chaos software tool 8, which for this purpose comprises at least one random algorithm, during the ongoing operation of the plant 1 and the twin 12 in such a way that error situations are caused in the real plant 1 and the simulated plant 12 based on randomness.

[0077] It should be noted that a real system 1 can comprise both purely hardware- and purely software-based components, as well as components that have a combination of (special) hardware and software. All of these types of components can be or are randomly checked. The components of a simulated system are usually in the form of software or software modules, which form representatives or "digital images" of real components. All of these types of components can be randomly "boycotted" within the framework of the method according to the invention. Furthermore, it should be noted that in addition to the Figure 1 Components 2-6 shown purely as examples can of course be used to manipulate other components of system 1.

[0078] The inventive causation of random errors is carried out by recourse to the rule set 10, which is to be created accordingly beforehand in a first step.

[0079] The rules 10 are, because industrial automation systems 1 are usually not homogeneous in structure, but, as stated in the Figure 1 The example shown is composed of a large number of different individual components 2-56 and their interconnections, to describe the hardware and software components 2-6 of both the real automation system 1 and the digital twin 12 and their behavior.

[0080] Rulebook 11 describes components 2-6 of Annex 1 and its twin 12, along with information on the behavior of the respective component, its connectivity, and safety aspects relevant to the respective component 2-6. In the context of the exemplary embodiment described here, component behavior refers to the start and stop behavior as well as the good and bad behavior.

[0081] Rules 10 also include information on which error cases can occur in the respective components 2-6, whereby the error cases are classified according to error types, as well as information on how error cases can be technically triggered and / or simulated by the Chaos Software Tool 8.

[0082] In addition, the rule set 10 includes a set of error algorithms and associated parameters that represent various scenarios that differ in terms of which error types and components 2-6 should be considered, how many errors may occur simultaneously, what the timing is, how long an error situation should last, and how quickly the next error situation should or may be triggered after a previous error situation. The set of error algorithms can be used to vary which error types or components should be considered, how many errors may occur simultaneously, what the timing is (e.g., sporadic, cyclical, permanent, etc.), how long an error situation should last, and how shortly after the reset of one situation the next should be triggered.

[0083] In the present case, the rule 10 includes, among other things, that a Figure 1not further shown light barrier is present on a conveyor belt of the transport module 5 of system 1 and this is triggered by the error states 1) always on, 2) always off, 3) flickering, 4) bouncing Also listed is a barcode reader in a sorting system, in this case assembly module 4, which is characterized by the following error states 1) Carrier does not trigger, 2) Barcode is not readable, 3) Barcode is misread, 4) old "buffered barcodes" report, 5) bounce.

[0084] Rule 10 also includes the specification of prohibited error situations.

[0085] This is the case because system 1, specifically a programmable logic controller, includes a safety device.

[0086] The programmable logic controller 14 with the safety device 15 is in the Figure 1 not recognizable, but the Figure 2- each purely schematically as a block element - shown. It should be noted that in the Figure 2 the process at runtime R, i.e. the process during the ongoing operation of the system 1, 12, and below the upstream engineering E, specifically the creation of the set of rules 10, are shown and graphically separated from each other by borders with dashed lines.

[0087] The safety device 15, which can also be referred to as a failure system or F-system for short, is designed and configured to enable intrinsically safe operation of system 1, at least with regard to some safety aspects. Specifically, it serves to establish a fail-safe state (fault-directed system) and, according to the standard, in this case EN 62061, is designed to operate independently of the normal control system 14 and is intrinsically safe. In particular, it ensures that system 1 is transferred to a safe state if certain impermissible conditions are reached or certain parameters are exceeded.

[0088] The safety device 15 is activated during the inventive check of the system 1, so that if an error situation is triggered using the Chaos software tool 8 that could lead to or leads to a dangerous situation, the system 1 will automatically be transferred to a safe state.

[0089] In this case, the triggering of such "unsafe" or "dangerous" scenarios is nevertheless undesirable because exiting a fail-safe state is time-consuming and costly. To prevent such occurrences, the rules provide for 11 impermissible error states.

[0090] Specifically, a safety plan 16 of Annex 1, which meets the requirements of the standard EN 62061, was taken into account in its preparation. This is shown - again only schematically - in Figure 2 indicated, in which an arrow points from the safety plan 16 to the rules 10.

[0091] Furthermore, if necessary, the rule set 10 can specify for one or more components 2-6 that they may only be manipulated under certain conditions, for example, only under professional supervision and / or only at certain times. Particularly sensitive or particularly high-security components 2-6 can also be exempted from random testing per se. On the other hand, it is of course also possible to specify for one or more components 2-6 that they may be manipulated under any conditions, for example, at any time and / or without supervision.

[0092] It should be noted that for the creation of the set of rules 10, it is very advantageous if there is direct access to the system 1 to be tested and, if applicable, the digital twin 12—as is the case here via the TIA Portal 9. This is particularly true because the information regarding which actuators or sensors are installed in the system 1 can usually be read or evaluated from the program of the controller 14, the PLC program. Direct access to the system 1 thus offers a particularly simple way of obtaining information, among other things, on the structure and behavior of the system 1, as required for the set of rules 10.

[0093] Following the creation of the rule set 11 and its transfer to the edge device 7, the inventive, randomly based "boycott" of the system(s) 1, 13 can be carried out by the chaos software tool 8. In this case, the chaos software tool 8, specifically by recourse to or use of at least one random algorithm contained therein, selects an error algorithm from the rule set 11 that represents an error situation.

[0094] If the chaos software tool 8 randomly determines an error situation (i.e., selects an error algorithm), it is first compared with the error situations prohibited according to the rule set 10. For this purpose, the chaos software tool 8 includes a safety component 17 (see Figure 2). Only if no prohibited error situation was determined is the error situation triggered and / or simulated at system 1 and / or system 12; otherwise, a new random error situation is determined and again compared with the error situations prohibited according to the rule set 10. This is repeated as often as necessary until a non-prohibited error state is obtained based on randomness.

[0095] If a non-prohibited error algorithm is present, it is executed to trigger or implement the corresponding error situation or error. As an example, data is sent to bus 2 indicating or simulating the multiple opening and closing of a barrier.

[0096] Both components 2-6, 14 of the real system 1 and the digital twin 12 are manipulated, as are their data. It should be noted that the manipulation of a component also includes, in particular, the (accidental) shutdown of the component. In this case, data sent from the controller 14 of system 1 to actuators and data received from sensors are manipulated. It should be noted that the actuators and sensors of system 1 are Figure 1 not recognizable, but in Figure 2 are shown purely schematically by a block element provided with the reference numeral 18. Also in the Figure 2 is marked.

[0097] The Edge Device 7 monitors the data traffic in the communication network of System 1, i.e. the bus traffic, and random manipulation (also) of data takes place at the protocol level.

[0098] It should be noted that, alternatively or in addition to the edge device 7 monitoring the data and manipulating it at the protocol level, data manipulation is also possible on the PLC 14, in particular at the cycle checkpoint, and / or on peripheral / IO devices, in particular before writing to an actuator and / or after reading from a sensor. For this purpose, it is then specifically provided that the Chaos software tool 8 is or will be stored on the PLC 14 and / or the relevant peripheral / IO devices, expediently together with the rule set 10. Data manipulation preferably occurs as the last step before "sending on the bus." An additional edge device 7 can then be dispensed with.

[0099] The manipulation of the data takes place transparently for all network / bus participants.

[0100] Particularly in the simulated system 12, the chaos software tool 8 can also cause confusion by manipulating the data. The following is an excerpt from a purely exemplary set of rules 11 for a cloud service:

[0101] Included are the access data to the cloud portal and the service itself as well as the manipulation options, i.e. stopping the service, restarting it or using another backend service that is used for manipulation.

[0102] It can also happen that the Chaos software tool 8 issues one or more instructions to a user that include a manual manipulation action to be performed by the user. This represents a possibility for implementing error scenarios that cannot be triggered or caused (purely) electronically. An example of an instruction or "manipulation suggestion" for a person is that a workpiece that has already passed through a station is removed from the conveyor belt by the person and placed back at another location. Corresponding instructions can be issued to a user on a display device, such as a screen.

[0103] It can also be provided that the chaos software tool 8 realizes at least one error situation in the simulated system 12 that cannot be triggered electronically in the real system 1. An example of such an error situation is a workpiece falling off a conveyor belt or becoming jammed. This cannot be realized, or cannot be realized easily, by pure software commands, data manipulation, or intervention in a power supply. In particular, in order to be able to cover and consider such scenarios, it can be very advantageous to provide a system simulation 12 in addition to a real system 1, as is the case here.

[0104] The impact of each error situation triggered by the Chaos software tool 8 with reference to the rule set 10 on the operation of the real 1 and / or the simulated system 12 will be observed by a person and / or recorded electronically, in particular by the Chaos software tool 8. The real 1 system and / or the simulated system 12 and / or their control system (program) can be adapted as needed. In particular, errors or problems identified in this process, for example in the structure and / or the control software and / or the connection of components, can be remedied.

[0105] Using the random-based, tool-supported chaos method, a particularly comprehensive, reliable testing of even complex industrial plants 1 is possible with comparatively little effort, both during a simulation phase and during commissioning. Since, according to the invention, components 2-6, 14 of a plant 1 and / or data originating from them are manipulated randomly, the resulting error scenarios are not limited to scenarios specifically selected or considered by an operator or engineer, as is the case with the state of the art, but virtually any scenario can be caused and thus covered. This makes it possible for the first time to find errors or reasons for failure in an industrial plant 1 that were not or could not have been considered during engineering and / or that arise from the complexity of the plant 1. This represents a significant advantage over the state of the art.

[0106] Although the invention has been illustrated and described in detail by way of the preferred embodiment, the invention is not limited to the disclosed examples. The invention is defined in the appended claims.

Claims

1. Method for reviewing an industrial installation (1, 12), in particular automation installation, wherein real components (2-6, 14) of a provided real installation (1) or data originating therefrom or simulated components of a provided simulated installation (12) or data originating therefrom are manipulated with the use of a computer program (8), in particular during ongoing operation, in such a manner that error situations based on chance are caused in the real and / or the simulated installation (1, 12), characterised in that two or more components (2-6, 14) of the installation (1, 12) are interconnected via a communication network, in particular in the form of a bus, and data, which is to be sent by at least one component (2-6, 14) to at least one further component (2-6, 14) via the communication network, is manipulated before its handover to the communication network by the computer program (8), wherein the computer program (8) for manipulation of the data uses at least one random algorithm and is executed on an edge device connected to the communication network, in particular an industrial PC.

2. Method according to claim 1, characterised in that the effect on the operation of the real or the simulated installation (1, 12) is recorded and the real or the simulated installation (1, 12), or the control thereof, is adapted as required; in particular, identified problems are rectified.

3. Method according to claim 1 or 2, characterised in that a policy (10) for describing components (2-6, 14), which are or can be taken into consideration for the review, of the installation (1, 12), together with details on the behaviour of the components or on the connectivity of the components (2-6, 14) or on safety aspects that are relevant for the components, is created or provided, and the error situations based on chance are caused by the computer program (8), falling back on the policy (10).

4. Method according to claim 3, characterised in that the policy (10) furthermore comprises: - details on which error cases can occur on the respective components, preferably classified by error type, or - details on how error cases can be technically triggered and / or simulated, in particular by the computer program, or - a number of error algorithms with associated parameters, which represent various scenarios, which preferably differ in which error types or components (2-6, 14) are to be taken into consideration, or how many errors are permitted to occur at the same time, or how the temporal behaviour is or how long an error situation is to persist, or how quickly the next error situation is to be caused subsequent to a previous error situation.

5. Method according to claim 3 or 4, characterised in that the policy (10) comprises prohibited error situations or is expanded with such, and the computer program (8) initially ascertains an error situation based on chance, aligns the ascertained error situation with the error situation that is prohibited according to the policy (10) and, only in the event that no prohibited error situation has been ascertained, triggers or simulates the error situation at the installation (1, 12), otherwise ascertaining a new random error situation and in turn aligning it with the error situations that are prohibited according to the policy (10).

6. Method according to one of claims 3 to 5, characterised in that in the policy (10), for at least one component (2-6, 14) it is stored that it is only permitted to be manipulated under certain conditions, in particular only with professional supervision and / or only at certain times.

7. Method according to one of claims 3 to 6, characterised in that the policy (10) and / or computer program (8) is loaded onto at least one component of the installation (1, 12).

8. Method according to one of claims 3 to 7, characterised in that an engineering tool (9) is provided, in which the policy (10) can be created or is created.

9. Method according to one of the preceding claims, characterised in that at least one component (2-6, 14) of the installation involves a controller (14), in particular a programmable logic controller, and data to be sent by this is manipulated at a cycle control point.

10. Method according to one of claims 3 to 8 and one of claims 1 or 9, characterised in that the computer program (8) manipulates the data according to the policy (10), in particular according to the details on how error situations can be technically triggered and / or simulated.

11. Method according to one of the preceding claims, characterised in that the installation (1) is assigned a safety facility (15) or the installation (1) comprises such, wherein the safety facility (15) is embodied or configured to enable an operation of the installation (1) which is at least intrinsically safe in relation to some safety aspects, and the safety facility (15) is activated during the reviewing of the installation (1), so that when, with the use of the computer program (8), an error situation is triggered which could lead or leads to a hazardous situation, the installation (1) is automatically transitioned into a safe state by the safety facility (15).

12. Method according to one of the preceding claims, characterised in that the computer program (8) outputs an instruction to a user, which comprises a manipulation action to be carried out manually by the user.

13. Method according to one of the preceding claims, characterised in that as an alternative or in addition to a real installation (1), the computer program (8) manipulates a simulated installation (12) and implements at least one error situation, which would not be able to be triggered in a real installation (1) corresponding to the simulation.

14. Computer program (8, 9) comprising program code means and at least one random algorithm, which is adapted such that it carries out the method from one of claims 1 to 13 when executed on a computer.

15. Computer-readable medium, which comprises the computer program according to claim 14.

16. System (7) for performing the method according to one of claims 1 to 13, comprising an edge device, in particular an industrial PC, with at least one connection, in particular for connecting to a communication network, at least one processor and at least one storage unit, the system with two or more components (2-6, 14) of an installation (1, 12) and the edge device, which are interconnected via a communication network, in particular in the form of a bus, characterised in that the computer program (8, 9) according to claim 14 is stored on the storage unit, the system (7) is embodied to carry out said computer program (8, 9), the computer program (8, 9) comprises at least one random algorithm and is configured to manipulate data originating from real components (2-6, 14) of a provided real installation (1) or data originating from simulated components of a provided simulated installation (12), based on chance, in such a manner that error situations care caused in the real and / or the simulated installation (1, 12), and it is provided that the data, which is to be sent from at least one component (2-6, 14) to at least one further component (2-6, 14) via the communication network, is manipulated before its handover to the communication network by the computer program (8).