METHOD FOR AUTOMATICALLY CREATING A SKILL INTERFACE, COMPUTER PROGRAM PRODUCT AND DEVICE

Description

[0001] OPC Unified Architecture (OPC UA) is a standard for data exchange, for example in an industrial plant, as a platform-independent, service-oriented architecture (SOA). OPC UA was published, among other places, in the IEC 62541 series of standards.

[0002] OPC UA information models play an increasingly important role as a uniform interface for monitoring and controlling machines and systems, particularly in industrial manufacturing.

[0003] These information models are often based on OPC UA Companion specifications. For example, the "OPC UA Companion Specification for Robotics" (OPC UA Robotics for short) offers a standardized information model that can uniformly represent all robot-related data, regardless of manufacturer or location. This enables asset management, condition monitoring, predictive maintenance, and vertical integration – anytime, anywhere in the world, and regardless of manufacturer or robot type.

[0004] In various specifications (e.g., PackML - Packaging Machine Language), state machines are an important tool for uniformly representing and controlling the behavior of machines and systems. Typically, these models can now be instantiated in an OPC UA server that runs directly on the controller (PLC - Programmable Logic Controller or SoftPLC - Programmable Logic Controller).

[0005] To enable control of the PLC by an external system, the state machine must be represented by a standardized (OPC UA) information model, which is then placed on an OPC UA server and made accessible to an OPC UA client. The client can then read the current state and trigger state changes via method calls. Engineering this information model, which represents the state machine of the machine or plant, is usually very complex and is generally performed manually. This requires detailed knowledge of the modeling of the state machine in the OPC UA information model as well as of the functionality of the state model within the PLC program.

[0006] While some engineering support is now possible for newly programmed systems (e.g., through automatic model generation and connection with the PLC code), the situation is considerably more complicated for so-called "brownfield" systems.

[0007] This refers to systems with an existing software and architecture concept, where newly developed software must be integrated into this existing framework. Unlike a completely new development (also called greenfield development), further development must adhere to existing structural constraints. Often, the precise functionality of the control program is unknown or even inaccessible. Implementing a state machine that models this behavior is either very complex or even impossible.

[0008] Besides standards like PackML, interfaces for calling skills are also an important use case. A "skill" is generally understood to be the ability of a resource to perform specific functions, such as executing a particular step in a production process. Skills consist of a skill service (the function) and the skill interface (the associated interface). Skills can also be used to describe a production process, for example, one carried out on an automation system. The goal is to identify the resources suitable for each step of the production process based on the required capabilities, rather than having to specify the actual production resources.The economically viable retrofitting of such skills and especially their interfaces to existing systems is, as described above, an unresolved problem today due to the high manual effort required.

[0009] Currently, the only way to retroactively implement skill interfaces is through manual engineering and creation of the information model using tools like "UaModeler" or "SiOME." While the latter tool offers limited capabilities for automatically creating information models from PLC code, for this function to be used in the intended application, the PLC code would have to already reflect the model to be created in exactly the same structures. This is unrealistic in a brownfield environment.

[0010] The creator would therefore need to know the entire workings of the state machine in order to correctly model each state and transition with method calls and references. Systems that analyze the behavior of a plant aim to parameterize models that are intended to optimize or control the plant.

[0011] The purpose of the invention is to automatically map the behavior of states and transitions in an information model as a skill interface.

[0012] The problem is solved by a method according to the features of claim 1.

[0013] The problem is solved by a computer program product according to the features of claim 7.

[0014] The problem is further solved by a device according to the features of claim 13. Advantageous embodiments of the invention are specified in the dependent claims.

[0015] The method described below aims to automatically create an information model for a brownfield plant or machine without requiring the user to have detailed knowledge of the control code of the controllers involved. This information model is intended to be used as a skill interface, enabling, for example, an OPC UA client to uniformly monitor the states of skills, trigger skill execution if necessary, and receive feedback.

[0016] The invention is further illustrated in an advantageous embodiment in the figures, which show: Figure 1: State graph and separation into subtrees; Figure 2: Process steps without overlap; Figure 3: Differentiation as a result of the division; Figure 4: Skill-State Machine; and Figure 5: Machine-State Machine with two skills.

[0017] The Figures 1 to 3They demonstrate the separation and labeling of subtrees using a very simple state graph. Phase 1: Recording the states of the system

[0018] To do this, all states that the system can assume are first recorded by observing accessible variables.

[0019] This can be done, for example, using the method for automatically labeling signatures with signals from automation systems, analogous to the method described in EP 3579072 A.

[0020] First, a state time series recorded for a plant is quantized so that all states included in the time series have a duration exceeding a predefined minimum time. Then, plant states are determined based on state changes in at least one time series. Specifically, the segments of a recorded, synchronous data time series between the locations of two successive plant states are identified and assigned a identifier that defines a plant state with a signature.

[0021] Subsequently, the obtained state sets are adjusted to the desired granularity (i.e., the number of desired state classes), as described, for example, in EP 3 579 073 A, using a method for automatically aggregating signatures. Signatures, as described above, are determined as segments in at least one synchronous data time series between two successive plant states, whereby the duration of each determined signature is compared with a minimum duration, and a signature with a duration shorter than the minimum duration is aggregated with an adjacent signature according to a defined rule.

[0022] Finally, a general state model is derived. For example, a graph can be constructed by observing the system's behavior, containing states and the relationships between them. This graph is then transformed into an information model using appropriate rules. For instance, a state is defined as a state object, a transition as a transition object, a relationship between states as a relation, and an action that triggers a specific response as a method.

[0023] The system automatically detects whether a state is waiting or transitioning. Higher-level state machines are also recognized and modeled accordingly.

[0024] The references and methods are also modeled in the information model.

[0025] In order for these steps to be carried out effectively, the following prerequisites must be met: It must be possible to access the variables that uniquely characterize the state of the plant / machine.

[0026] This is usually possible in most automation systems through various methods, for example by analyzing the bus communication between controllers, the communication to the sensors, the decentralized peripherals and the HMIs, or by observing live variable values ​​directly in automation programs and control projects.

[0027] In order to correctly capture the states of the system, all states to be mapped must be traversed at least once.

[0028] This requirement can be met either by deliberately controlling the desired states or by monitoring the operation of the systems over a sufficiently long period. In the latter case, it is possible that some situations will still go undetected; these can then be detected later and handled separately. Details are described in Phase 3 of the procedure.

[0029] The result of Phase 1 is a general state model that describes the system's behavior, but does not yet allow for a more specific understanding of the situation or targeted control of behavior. Fundamental behaviors, such as the differentiation between waiting states, transitions (instantaneous transitions), intermediate states, and structures (e.g., sub-state machines), are already taken into account here. Phase 2: Differentiating the state model

[0030] Based on the general state model created in Phase 1, a differentiation can now be made.

[0031] If a skills interface is to be created for at least one production step, the next step is to define which production step this should apply to. To do this, the respective initial state A, C and corresponding final state B, D of the production step and the associated skill being sought must be specified in the state model.

[0032] This can be achieved, for example, by simply identifying (tagging) the situation during state monitoring in Phase 1. The start or invocation of production functions can be readily observed within a system (unlike internal processes in the PLC program) because automated systems involve communication between production and plant control. The start times of production steps can be determined by evaluating this communication. Alternatively, a user observing the system externally can also specify the start and end times of production steps.

[0033] This is particularly advantageous in brownfield analysis situations, as the user does not need to have more detailed knowledge, for example about variable assignments.

[0034] If there is already an (other) automatic control of the functions, this communication can also be used for tagging.

[0035] Additionally, normal production runs (i.e., successful production steps without errors) can be marked. If the production plant is one where successful execution of production steps is the norm (which is likely the case for the vast majority of plants), this can be automated by selecting the most frequent sequences. In contrast, errors or anomalies occur rarely.

[0036] Starting from a model thus determined, with unique identifiers for each state (i.e., each state is unique with respect to machine / plant behavior) and labeled start and end states for each skill, the following algorithm is executed. This procedure is described in the Figure 1 and 2The graph illustrates two skills: Skill 1 is represented by a path from node A, 131 to node B, 133. Skill 2 is represented by the path between node C, 122 and node D, 123. Nodes X, 112 and Y, 111 represent skill-specific errors.

[0037] Shown is a state graph with different states 111, ... 143, which are connected to form a graph.

[0038] Step 1: Remove all paths that, starting from the production step's starting point, can lead to the completion of the production step (possibly including error messages or interruptions) 12, Structure M0 Skill2, 13, Structure M0 Skill1.

[0039] The resulting section of the state model includes: the desired functional sequence, i.e., the actual skill, which is the path from node A to node B via nodes 122, 121, 123.

[0040] Furthermore, there are nodes that represent a so-called general machine behavior, i.e., process steps that can belong to several skills; in the example presented, these are nodes 141, 142, 143.

[0041] In addition, there are specific error cases X, 112, Y, 111 associated with the skill, and possibly other general error cases not detailed in this example.

[0042] Step 2 then leads to a mapping with individual graphs as shown in Figures 14, Good Case M1 Skill1, and 15, Good Case M1 Skill2, each representing a subgraph of the original graph. By extracting sequences of states from the sets of states found in Step 1, which describe the "good case," i.e., the normal execution of the skill, these subgraphs are generated. They comprise the normal sequence, or all possible sequences, of the individual steps of the desired production step from start A, C to goal B, D.

[0043] The states that belong to this normal sequence can be determined in various ways. They can either be identified during Phase 1 when selecting the skills. Alternatively, a specific sequence can be triggered and observed for each subset identified in Step 1.

[0044] All states that have been traversed now belong to the "good case" of the skill traversal and are included in subgraphs 12 and 13.

[0045] If this mapping is required for multiple production steps / skills, steps 1 and 2 are repeated for each desired skill.

[0046] Step 3: all structures found so far that represent "good cases" are now compared with each other.

[0047] If matches are found, these sequences or states are marked as shared functionality between different skills. (M2-Skill n-Skill m) In the example shown in the figures, these are nodes 141, 142, 143 (and the associated connections between them).

[0048] If, on the other hand, no common structures can be found between skills, they are functionally independent.

[0049] Step 4: Next, the "good cases" determined in step 3 are subtracted from the individual skill structure state graphs, i.e., the found substate graphs 14 and 15 are subtracted from the overall graph 11, and a comparison of all resulting state sets is performed again. In the example shown, 4 subgraphs remain: 21, 22, 23, and 24.

[0050] If matches are found, these areas are labeled as general machine behavior or general error cases. These are again nodes 141, 142, and 143, as in the example above. Figure 1 The case already described.

[0051] Areas for which no matches are found include, for example, skill-specific error cases X, Y or skill-specific machine behavior (e.g., setup routines) M4-Skill n.

[0052] The result of forming subsets and labeling the states in phase 2 is now used to build the desired information model.

[0053] Figure 3The initial graph is shown again, this time with the states marked accordingly. The two state sequences 121, 122, 123 and 131, 132, 133 for the two skills in question, with the initial and final states AB and CD respectively, are shown. The general machine behavior 141, 142, 143, which can be used by both skills, is also shown. Finally, (skill-specific) error routines 111 and 112 are shown. Thus, all identified states of the state graph are clearly assigned to one of the four categories.

[0054] Figure 4 shows a typical simplified state model for an example skill and Figure 5 The embedding of at least two skills into a machine state model. The discovered states can then be mapped onto this model using the rules described below. Either all states can be represented on one level, and the "standard states" (as in Figure 4) are specially marked or substate machines are formed which contain the additional fine-grained states if several found states correspond to a skill state.

[0055] For each Skill 400, there is a defined invocation sequence (M1-Skilln) as well as specific error or interruption sequences (M4-Skill n) shown in phase 2 of the Figure 2 , the states X and Y, 111, 112).

[0056] In Figure 4 The states of the "good case" scenario are generically represented in box 410. Starting from an idle state (11), the desired skill (400) transitions to an execution state (412). In the robot example, this could mean that the robot could begin processing a workpiece.

[0057] If necessary, the execution can be interrupted by holding the machine (416). This might be required, for example, if the machining process needs to be interrupted because the machining tool needs to be changed or for another reason. Once the process is complete, i.e., the workpiece has been fully machined, the workpiece can be removed from the holder (413) in a Completing state. The machine can then return to the initial Idle state (411) in a Complete state (414) to continue machining another workpiece. If an error occurs during the skill operation, a skill-specific error state (401, 402) is entered. The normal machining process can then be resumed by resetting the machine (415).

[0058] General machine behavior and general error routines form the framework for the proportion of skill calls (M3). This also makes it possible to distinguish when a skill is executed or can be called, and when it cannot.

[0059] In the Figure 5 In a Machine-State Machine 500, two skills 510 and 520 are executed in parallel. The state transitions of the skills are simplified but analogous to that in Figure 4 Case 410 is shown. However, the figure still shows two states 531, 532, which are used jointly by both skills and therefore represent the so-called general machine behavior.

[0060] To call skills, a method is created that triggers the transition from the initial state to subsequent transitions. If there are multiple subsequent states, the different variables of the state in each state are added as parameters to this call; that is, the system detects differences and automatically creates the method with the input variable.

[0061] The calls to Skill 1 and Skill 2, which share common processes (M2), are interlocked. For example, if there is a common structure M2-Skill 1 - Skill 2, Skill 1 and 2 cannot be executed in parallel.

[0062] Skills that do not share common structures, on the other hand, are algorithmically independent.

[0063] Finally, a separate exception state is introduced, which the system enters when a previously unknown combination of variables occurs. This indicates that the state is either new or was not detected in Phase 1. In both cases, the user can decide whether the procedure should be repeated with this additional state in order to include it in the solution.

[0064] This makes it possible to automatically generate an information model for observing machine behavior and calling skills, and to connect it to the machine's control system without the user needing detailed knowledge or understanding of the control program. For the skill triggering process, additional synchronization with existing call mechanisms for the corresponding function may be advisable. The method on the information model side is linked to the corresponding "method" function block in the PLC program; that is, which method function block should be called by the industrial controller when this method is invoked.

[0065] The method described above enables the automatic mapping of behavior, or a derived state model, into a unified OPC UA information model. This offers several advantages over manual creation.

[0066] Automated linking of the information model with the control variables is enabled.

[0067] Data consistency between the information model and the control variables (especially during changes) is ensured. The proposed method can be applied multiple times at different times using the existing data without significant effort.

[0068] The automated generation of the information model eliminates any additional engineering effort for the user. No above-average knowledge of the system and the skills involved is required.

[0069] There is also no need to understand the semantics of the control code.

[0070] The control code does not need to be analyzed for the application of the procedure, which would be time-consuming and prone to errors.

[0071] The process is independent of the controller manufacturer and programming language, also due to the use of standardized methods for state changes from wait states. The distinction between wait and transition states is automated and rule-based.

[0072] An information model with state graphs for individual skills and general machine behavior or error cases is automatically generated for the user. This drastically reduces the engineering effort for the subsequent implementation of skill interfaces and would, in many cases, make an economically viable implementation possible in the first place (otherwise, a complete or extensive reimplementation of the automation functions would be necessary in some cases).

Claims

1. Method for the automated creation of a skill interface for a skill or production step carried out in a system, where a skill is understood as meaning the ability of a resource to perform functions, having the following steps: - detecting all states (111, ...143) of the system during the execution of the skill, - creating a general state model consisting of the detected states and relationships between the states, - transferring the state model into an information model, - defining a start state (A, C) and end state (B, D) of the production step within the state model, - determining all sequences of states (121, 122, 123, 131, 132, 133, 141, 142, 143) from the start state to the end state of the required skill, - separating all sequences of method steps (141, 142, 143) which can also be associated with further skills, - separating states for error handling of the skill (111, 112), and - interconnecting the information model with the control of the system.

2. Method according to Patent Claim 1, characterized in that each state must be activated and passed through at least once in a targeted manner in order to detect the states (111, ... 143) which are to be replicated.

3. Method according to Patent Claim 1 or 2, characterized in that the system is observed over a time period in which each state has been passed through at least once in order to detect the states (111, ... 143) which are to be replicated.

4. Method according to one of the preceding patent claims, characterized in that at least two skills / production steps are intended to be identified within the state model, wherein the sequence of method steps (141, 142, 143) of a first skill which could also be associated with further skills is performed by comparing matches in the determined state graphs of the first skill (12) with the determined sequence state graph of the second skill (13), and the state sequence determined in this way is marked and removed from both state graphs.

5. Method according to one of the preceding patent claims, characterized in that the start state and end state of the production step are determined by passing through the skill and identifying the states in a targeted manner.

6. Method according to one of the preceding patent claims, characterized in that the information model is formed according to the OPC-UA standard.

7. Computer program product for carrying out the method for the automated creation of a skill interface for a skill or production step carried out in a system according to Patent Claim 1, having the following steps carried out in an automated manner: - detecting all states (111, ...143) of the system during the execution of the skill, - creating a general state model consisting of the detected states and relationships between the states, - transferring the state model into an information model, - defining a start state (A, C) and end state (B, D) of the production step within the state model, - determining all sequences of states (121, 122, 123, 131, 132, 133, 141, 142, 143) from the start state to the end state of the required skill, - removing all sequences of method steps (141, 142, 143) which can also be associated with further skills, - removing states for error handling of the skill (111, 112), and - interconnecting the information model with the control of the automation system.

8. Computer program product according to Patent Claim 7, characterized in that each state must be activated and passed through at least once in a targeted manner in order to detect the states (111, ... 143) which are to be replicated.

9. Computer program product according to Patent Claim 7 or 8, characterized in that the system is observed over a time period in which each state has been passed through at least once in order to detect the states (111, ... 143) which are to be replicated.

10. Computer program product according to one of the preceding Patent Claims 7 to 9, characterized in that at least two skills / production steps are intended to be identified within the state model, wherein the sequence of method steps (141, 142, 143) of a first skill which could also be associated with further skills is performed by comparing matches in the determined state graphs of the first skill (12) with the determined sequence state graph of the second skill (13), and the state sequence determined in this way is marked and removed from both state graphs.

11. Computer program product according to one of the preceding Patent Claims 7 to 10, characterized in that the start state and end state of the production step are determined by passing through the skill and identifying the states in a targeted manner.

12. Computer program product according to one of the preceding Patent Claims 7 to 11, characterized in that the information model is formed according to the OPC-UA standard.

13. Device configured to carry out the method having the features according to one of Patent Claims 1 to 6.