Method, computer program product, and apparatus for automatically creating a skill interface

Abstract

Automatically create an information model for the user with state diagrams for individual skills and general machine behavior or error cases. This greatly reduces the engineering effort for implementing the skill interface later on and in many cases enables an economically feasible implementation right from the start.

Description

TECHNICAL FIELD

[0001] The present invention relates to a method, a computer program product and a device for automatically creating a skill interface, in particular to a method for automatically creating a skill interface for a skill or production step performed in an automation system and a computer program product for performing the method. BACKGROUND

[0002] OPC Unified Architecture (OPC UA) is a standard for data exchange, for example in industrial facilities as a platform-independent, service-oriented architecture (SOA). Furthermore, OPC UA is published in the IEC 62541 standard series.

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

[0004] The basis of the information models is usually formed by OPC UA companion specifications. For example, the "OPC UA Robotics Companion Specification" (short: OPC UA Robotics) provides a standardized information model which enables all robot-related data to be presented in a uniform manner, regardless of manufacturer and location. As a result, it is possible to implement facility maintenance, status monitoring, preventive maintenance and vertical integration at any time, anywhere in the world and independently of manufacturer and robot type.

[0005] In different specifications, such as PackML - Packaging Machine Language, state machines are an important means of uniform mapping and controlling the behavior of machines and systems. Usually, it is now possible to instantiate these models in OPC UA servers running directly on the controller (SPS - Programmable Logic Controller, PLC or SoftPLC - Programmable Logic Controller).

[0006] In order to enable the SPS to be controlled by external systems, the state machine must be mapped using a standardized (OPC UA) information model, which is then placed on an OPC UA server and made accessible to OPC UA clients. The clients can then read out the current state and initiate a state change by means of a method call. The engineering of the information model mapping the state machine of a machine or facility is usually very time-consuming and is usually carried out manually, here requiring detailed knowledge about the modeling of the state machine in the OPC UA information model and about the functioning of the state model in the PLC program.

[0007] While it is now possible to provide a certain degree of support for new systems to be programmed by engineering (for example by automatically generating models and interconnecting them with the PLC code), in this case the so-called "brownfield" installations are significantly more complex.

[0008] Thus, the installation means that the new developed software has to be integrated into the existing software and architecture concept using existing software and architecture concepts. In contrast to a completely new development, also called greenfield development, the further development has to comply with the structural framework conditions. Usually, the exact working principle of the control program is unknown or not accessible at all. If state machines for the mapping behavior are to be implemented, this is very complex or not possible at all.

[0009] In addition to standards such as PackML, the interface to the skills is also an important application case. Here, by the term "skill", the ability of a resource to perform a specific function, for example to implement a specific step of a production process, is generally understood. The skill consists of a skill service (function) and a skill interface (associated interface), and the skill can also be used to describe a production process, for example a production process carried out on an automated plant. The aim is to identify, based on the required abilities, resources suitable for each step of the production process from the skills, instead of having to name the actual production resources. As described above, due to the large amount of manual work, the economically reasonable subsequent implementation of these skills and, in particular, their interface in existing plants, is currently an unsolved problem.

[0010] Currently, the only way to subsequently implement the skill interface is to create the information model and manually engineer using tools such as "UaModeler" or "SiOME". Although the latter tool can automatically create an information model from the PLC code to a limited extent, the PLC code in which the model to be created must already be accurately mapped to the same structure in order to be able to use this function in the application case considered. This is not realistic in the case of brownfield cases.

[0011] The creator therefore needs to know the entire working principle of the state machine, so that it can correctly model each state and transition using method calls and references. Systems that analyze the behavior of a plant aim to parameterize a model that is intended to optimize or control the plant. SUMMARY

[0012] It is an object of the present application to automatically map the behavior of states and transitions in an information model to a skill interface.

[0013] This object is achieved by a method according to the application.

[0014] This object is achieved by a computer program product according to the application.

[0015] This object is further achieved by an apparatus according to the application.

[0016] Advantageous design features of the application are specified in the individual embodiments.

[0017] Herein, a method is proposed for automatically creating a skill interface for a skill or production step performed in an automation system, the skill being understood as the ability of a resource to perform a function,

[0018] The method has the following steps:

[0019] - detecting all states of the automation system during the implementation of the skill;

[0020] - creating a general state model consisting of the detected states and the relationships between the states;

[0021] - converting the state model into an information model; the conversion comprises the following steps:

[0022] - determining the initial state and the final state of the production step within the state model;

[0023] - deriving all sequences of states from the initial state to the final state of the required skill;

[0024] - separating all sequences of method steps that can also be associated with further skills;

[0025] - separating the error handling states of the skill; and

[0026] - connecting the information model to the controller of the automation system.

[0027] Furthermore, a computer program product is proposed for performing a method for automatically creating a skill interface for a skill or production step performed in an automation system, the skill being understood as the ability of a resource to perform a function,

[0028] The method has the following automatically performed steps:

[0029] - detecting all states of the automation system during the implementation of the skill;

[0030] - creating a general state model consisting of the detected states and the relationships between the states;

[0031] - converting the state model into an information model; the conversion comprises the following steps:

[0032] - determining the initial state and the final state of the production step within the state model;

[0033] - deriving all sequences of states from the initial state to the final state of the required skill;

[0034] - removing all sequences of method steps that can also be associated with further skills;

[0035] - removing the error handling states of the skill; and

[0036] - connecting the information model with a controller of the automation system.

[0037] Furthermore, a device is proposed which is suitable for carrying out this method.

[0038] The method described below serves the purpose of automatically creating an information model automation for a brownfield facility or machine without the user having to know the control code of the controller involved in detail. This information model is to serve as a skill interface so that, for example, an OPC UA client can monitor the skill status uniformly and, if necessary, trigger the execution of the skill and obtain the result feedback. BRIEF DESCRIPTION OF DRAWINGS

[0039] Furthermore, the application is illustrated in advantageous embodiments in the drawings, in which:

[0040] Figure 1 The separation in sub-trees is shown,

[0041] Figure 2 The method steps without intersections are shown,

[0042] Figure 3 The distinction of the results of the classification is shown,

[0043] Figure 4 The skill state machine is shown, and

[0044] Figure 5 The machine state machine with two skills is shown. DETAILED DESCRIPTION

[0045] Figures 1 to 3 The separation and identification of the sub-trees is shown according to a very simple state diagram.

[0046] Phase 1 : Detection of the state of the system

[0047] To this end, the total states that the system can have are first detected by observing the accessible variables.

[0048] This can be done, for example, by means of a method for automatically labeling signatures using signals from the automation system, similar to the method described in EP 3579072 A.

[0049] Here, the quantification of the state time series of the reference facility record is first adjusted so that all states included in the state time series have at least one state duration that exceeds a previously determined minimum time. Then, the facility state is derived on the basis of the state changes in the at least one state time series. Here, sections of the recorded synchronous data time series located between the positions of two consecutive facility states are derived and these sections are provided with an identifier indicating the determined signature of the facility state.

[0050] Subsequently, if the obtained set of states matches the desired granularity (i.e., the desired number of state classes), such as as described in EP 3 579 073 A, signatures are automatically combined (aggregated) using a method. As described above, segments of at least one synchronization data time series between two consecutive facility states are identified as signatures, wherein the duration of each resulting signature is compared with a minimum duration, and wherein, according to defined rules, signatures with durations less than the minimum duration are combined with adjacent signatures.

[0051] Then, a general state model is finally derived. Here, for example, a graph with states and relationships between states can be constructed by observing system behavior. This graph is then transferred to the information model using appropriate rules. For example, states are created as state objects, transitions are created as transition objects, relationships between states are created as connections, and actions that trigger specific reactions are created as methods.

[0052] Here, the system automatically identifies whether a state is in a waiting state or a transition state. Higher-level state machines are also identified and modeled accordingly. References and methods are also modeled in the information model.

[0053] In order to meaningfully perform these steps, the following prerequisites must be met:

[0054] It must be possible to access variables that clearly characterize the state of the facility / machine.

[0055] In most automation systems, this can typically be achieved using different methods, such as analyzing bus communication between controllers, communication to sensors, distributed peripherals and HMIs, or directly observing real-time variable values ​​in automation programs and control projects.

[0056] In order to correctly detect the system's state, all states to be mapped must be run at least once.

[0057] This prerequisite can be met either by selectively controlling the desired state or by observing the system's operation over a sufficiently long period. In this case, it is possible for a state to remain undetected until it is later detected and handled separately. See stage 3 of the method for details.

[0058] The result of Phase 1 is a general state model that describes the system's behavior, but it does not provide a more specific understanding of the situation or allow for targeted control of the behavior. Here, basic behaviors such as waiting states, transitions (instantaneous transitions), transition states, and structures (e.g., sub-state machines) have been considered.

[0059] Phase 2: Differentiation of State Models

[0060] Based on the general state model created in phase 1, it is now possible to differentiate.

[0061] If a skill interface is to be created for at least one production step, it is first determined which production step a skill interface should be created for. For this, the respective initial states A, C and the assigned final states B, D of the production step and the assigned required skills must be specified in the state model.

[0062] This can be done, for example, by simply recognizing (marking) the cases during the state detection in phase 1. The start or invocation of a production function can be well observed in the system (compared to internal processes in the PLC program) since the automation system involves communication between production control and facility control. The time of the start of the production step can be determined by evaluating this communication. Alternatively, a user who only observes the system from the outside can specify the start and end times of the production step.

[0063] This is particularly advantageous in the case of brownfield analysis, since the user does not need any more detailed knowledge of this, for example, knowledge about variable assignments.

[0064] If there is already an automatic (other) actuation of the function, this communication can likewise be used for marking.

[0065] Furthermore, here it is possible to mark the normal operation (i.e. a successful production step without errors). If it is a production facility in which the successful execution of a production step is the norm (which is the case for the vast majority of facilities), this can be achieved automatically by selecting the most frequent sequence. In contrast, errors or exceptions occur rarely.

[0066] Starting from the model thus derived, each state has a clear identifier (i.e. each state is unambiguous in terms of machine / facility behavior) and for each skill the start and end states are marked, the following algorithm is executed. This measure is exemplary shown in Figure 1 and Figure 2 In the figures, two skills are implemented, skill 1 is represented by the 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 errors specific to the skill.

[0067] Shown is a state diagram with different states 111,... 143, which are connected to each other to form a graph.

[0068] Step 1: Cut out all paths from the start of the production step that can lead to the completion of the production step (possibly with error messages or interruptions) 12, structure MO skill 2, 13, structure MO skill.

[0069] The thus obtained sections of the state model comprise the expected functional sequences, i.e. the actual skills, which are the paths from node A via nodes 122, 121, 123 to node B.

[0070] There are also nodes which represent so-called general machine behavior, i.e. which can be associated with method steps of multiple skills, in the given example these are nodes 141, 142, 143.

[0071] Furthermore, there are also special error cases X, 112, Y, 111 which are assigned to the skills, and possibly also other general error cases which are not shown in detail in the present example.

[0072] Step 2 then leads to a mapping to individual graphs, as shown in 14, good case Ml skill 1, 15, good case Ml skill 2, which each represent subgraphs of the original graph. The subgraphs are produced by extracting state sequences from the state sets found in step 1, which describe "good cases", i.e. normal execution of the skills, and comprise all possible sequences or normal sequences of the individual steps of the required production steps from start A, C to target B, D.

[0073] Here, it is possible to derive which states belong to the normal sequences in different ways. This can already be done in step 1 when the skills are selected. Alternatively, it is possible to again trigger and observe sequences specifically for each subset found in step 1.

[0074] All states which have been run are now associated with the "good case" of the skill run and are contained in the subgraphs 12, 13.

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

[0076] Step 3: Compare the currently all discovered structures representing "good cases" with each other.

[0077] Here, if a consistency is found, the sequences or states are marked as shared functionality between different skills. (M2 skill n skill m)

[0078] In the example shown in the attached drawing, these are nodes 141, 142, 143 (and the assigned connections between them).

[0079] Conversely, if there is no common structure between the skills, then they are functionally independent.

[0080] Step 4: The "good cases" determined in step 3 are then subtracted from the respective skill structure state graph, i.e. the found sub state graphs 14, 15 are subtracted from the overall graph 11 and the complete state set thus obtained is re-compared. In the shown example 4 sub graphs 21, 22, 23, 24 remain.

[0081] Here, if a consistency is found, these areas are marked as general machine behavior or general error cases. Here, this again involves the nodes 141, 142, 143, as Figure 1 already described in the case of the state graph 11.

[0082] Areas where no match is found are for example skill-specific error cases X, Y or skill-specific machine behavior (e.g. setup routines) M4-Skill n.

[0083] The result of the formation of the subsets and the state characterization in phase 2 is now used to build the required information model.

[0084] Figure 3 The initial graph is now shown again, but now with the respective marked states. Two state sequences 121, 122, 123 and 131, 132, 133 show the required two skills with initial and final states A-B and C-D, respectively. There are general machine behaviors 141, 142, 143, which can be used by both skills in common. And there are (skill-specific) error routines 111, 112. Thus, all derived states of the state graph are clearly associated with one of the four categories.

[0085] Figure 4 A typical simplified state model for an exemplary skill is shown, and Figure 5 the embedding of at least two skills in a machine state model is shown. The found states can be mapped to this machine state model using the rules described below. Here, all states can be shown on one level and "standard states" (as in Figure 4 ) are marked in particular, or if multiple found states correspond to one skill state, a sub state machine is formed, which contains additional states of fine granularity.

[0086] Here, for each skill 400, there is a defined sequence of calls (M1-Skill) as well as specific error or interruption processes Figure 2 shown in phase 2 of the M4 skill n, states X and Y, 111, 112).

[0087] In Figure 4 , the states of the good cases are shown in a box 410. Starting from the idle state Idle 11, the desired skill 400 enters the execute state Execute 412. In the example of a robot, he can start to process a workpiece.

[0088] If necessary, execution can be paused in the middle of Hold 416. This can be necessary, for example, if the machining has to be interrupted because the machining tool has to be changed or for other reasons. Once the process is complete, i.e. the workpiece has been completely produced, the workpiece can then be removed from the holder, for example in the finished state 413, in order to then transition via the idle state to the start state Idle, 411 in the finished state 414, in order to continue with the machining of another workpiece. If an error occurs in the skill, the skill-specific error state 401, 402 is entered, from which the normal processing can be resumed again by means of a reset facility, reset 415.

[0089] The general machine behavior and the general error routine form the framework of the part of the skill invocation (M3). It is therefore also possible to distinguish when a skill is executed, invoked or when it is not invoked.

[0090] In Figure 5 , two skills 510, 520 are executed in parallel in the machine state machine 500. The state sequence of the skills is simplified but similar to the case 410 shown in Figure 4 Figure 2 Figure 4 Figure 5 Figure 4 Figure 2 Figure 4 Figure 5 Figure 4 Figure 2 Figure . However, the diagram also shows two states 531, 532 which are used by both skills and thus represent so-called general machine behavior.

[0091] A method is created which invokes the skill, which triggers the transition from the initial state to the subsequent transition. If there are multiple subsequent states, the different state variables there are added as parameters to this invocation, i.e. the system recognizes the difference and automatically creates the method with the input variables.

[0092] The invocation of the skills Skill 1 and Skill 2 with a common used flow (M2) are locked to each other. For example, if there is a common structure M2-Skill 1-Skill 2, Skill 1 and 2 cannot be implemented in parallel.

[0093] Conversely, skills without a common structure are algorithmically independent.

[0094] Finally, a special exception state is also introduced which the system takes when a hitherto unknown combination of variables occurs. This shows that the condition is new or was not detected in phase 1. In both cases, the user can decide whether this additional state should be used to re-run the method in order to include it in the solution.

[0095] This enables the automatic generation of information models for observing behavior and invoking skills and connecting them with the controller of the machine without the user having to know or understand the control program in detail. Here, for the interlinking of the triggering of a skill, it makes sense to additionally compare with the already existing invocation mechanisms of the respective function. Here, the approach on the information model side is interlinked with the respective "method" function block in the PLC program, that is to say, if a method is invoked, the function block of the method is invoked by the industrial controller.

[0096] The above-described procedure enables the automatic mapping of behavior or the conversion of a state model derived therefrom into a uniform OPC UA information model. Here, compared to the manual creation, there are many advantages summarized.

[0097] The automatic interlinking of the information model with the control variables is enabled.

[0098] Data consistency between the information model and the control variables is ensured (especially in the event of changes). The proposed approach can be used several times at different points in time without having to use existing data in a very complex manner.

[0099] Due to the automatic generation of the information model, no additional engineering effort is required from the user. No above-average knowledge about the facility and contained skills is required.

[0100] Also, no understanding of the semantics of the control code is required.

[0101] No analysis of the control code is required for the application of the method, which is both time-consuming and prone to errors.

[0102] The method is independent of the control manufacturer and the programming language, and also because a standardized approach is used to change from a waiting state to a transition state. The distinction between waiting states and transition states is achieved automatically and based on rules.

[0103] The system automatically creates an information model for the user, which has a state diagram of the individual skills and the general machine behavior or error cases. This greatly reduces the engineering effort for the subsequent implementation of the skill interface, and in many cases, it even enables an economically viable implementation right from the start (in some cases, otherwise a complete or extensive reimplementation of the automation functions would be required).

Claims

1. A method for automatically creating a skill interface for a skill or production step performed in an automation system, the skill being understood as the ability of a resource to perform a function, the method having the following steps: - detecting all states of the automation system during the implementation of the skill; - creating a general state model consisting of the detected states and the relationships between the states; - converting the state model into an information model; the conversion comprising the following steps: - determining the initial state and the final state of the production step within the state model; - deriving the complete sequence of states from the initial state to the final state of the required skill; - separating the complete sequence of method steps that can also be associated with a further skill; - separating the error handling states of the skill; and - connecting the information model to the controller of the automation system. In order to detect the states to be mapped, each state must be driven and executed at least once with purpose.

2. The method of claim 1, wherein, In order to detect the states to be mapped, the automation system is observed during the period in which each state is executed at least once.

3. The method according to claim 1 or 2, characterized in that, Within the state model at least two skills / production steps are identified, wherein the sequence of method steps of a first skill that can also be associated with a further skill is achieved by comparing the consistency of the derived state graph of the first skill with the derived state graph of the second skill, and the thus derived sequence of states is marked and removed from both state graphs.

4. The method according to claim 1 or 2, characterized in that, By driving the skills with purpose and identifying the states, the initial state and the final state of the production step are derived.

5. The method according to claim 1 or 2, characterized in that, The information model is formed according to the standard OPC-UA.

6. The method of claim 1 or 2, wherein, 7. A computer program product for performing the method according to claim 1 for automatically creating a skill interface for a skill or production step performed in an automation system, the skill being understood as the ability of a resource to perform a function, the method having the following automatically performed steps: - detecting all states of the automation system during the implementation of the skill; - creating a general state model consisting of the detected states and the relationships between the states; - converting the state model into an information model; the conversion comprising the following steps: - determining the initial state and the final state of the production step within the state model; - deriving the complete sequence of states from the initial state to the final state of the required skill; - removing the complete sequence of method steps that can also be associated with a further skill; - removing the error handling states of the skill; and - connecting the information model to the controller of the automation system. In order to detect the states to be mapped, each state must be driven and executed at least once with purpose. In order to detect the states to be mapped, the automation system is observed during the period in which each state is executed at least once.

8. The computer program product of claim 7, wherein, Within the state model at least two skills / production steps are identified, wherein the sequence of method steps of a first skill that can also be associated with a further skill is achieved by comparing the consistency of the derived state graph of the first skill with the derived state graph of the second skill, and the thus derived sequence of states is marked and removed from both state graphs.

9. The computer program product of claim 7 or 8, wherein, ​ 10. The computer program product of claim 7 or 8, wherein, ​ 11. The computer program product of claim 7 or 8, wherein, By performing the skills and recognizing the states with the aim, the initial state and the final state of the production step are derived.

12. The computer program product of claim 7 or 8, wherein, The information model is formed according to the standard OPC-UA.

13. A device suitable for performing the method according to any one of claims 1 to 6.

Images