Patent Application
20100292810
The invention relates to a method for orchestrating of services of a service-oriented automation system, with system components offering services representing their functionality and services querying other system components, with the behavior of the automation system being governed by orchestration of the services of the system components by means of an orchestration machine and to an orchestration machine for orchestrating of services of a service-oriented automation system, comprising system components like intelligent mechatronic components, control components and/or decision components (DSC), each of which provides a set to services which represents their internal functionalities and is queried by other system components.
One method for orchestration of a service-oriented automation system and an orchestration machine is described in an article by F. Jammes, H. Smith et al.: “Orchestration of service-oriented manufacturing processes,” IEEE 2005, vol. 1, pages 617 to 624. A typical feature of a service-oriented automation system is that various processes are compiled and executed to form a complex process of higher order. This pattern is repeated at various levels, namely composition of field devices for formation of machines, compositions of machines for formation of work cells and work paths, composition of machine-level processes for formation of fabrication systems and plants. As soon as the process is compiled as a complete ecosystem of services, it is desirable that the complexity linked with the coordination of atomic services assigned to the processes is encapsulated in a single service interface.
The practice of sequential and synchronized execution of services related to a closed business or fabrication process is called orchestration in the technical vocabulary. An orchestration machine implements the application logic that is necessary to orchestrate atomic services and proves a high-level interface for the combined services (processes).
The combining and orchestrating of web services has attained especial significance in recent times. In this connection, a goal is pursued of forming complex processes by combination of web services that are applicable via multiple hierarchical levels.
To provide flexibility, it is recommended that a web services orchestration description (model-based orchestration) be used, which describes the operational sequences of the modeled system. These orchestration descriptions can be interpreted in real time by machines which interpret the operational sequence in real time, to avoid the use of ad-hoc, hard-coded implementations.
At present, principally two specifications for orchestration of web services are known, one being the Business Process Management Language (BPML), the other the Process Specification Language (PSL), especially for representation of fabrication processes. In industry, however, the Business Process Execution Language for Web Services (BPEL4WS) has often been used, which is also known under the abbreviations WS-BPEL or BPEL.
However, one disadvantage of orchestration machines obtainable currently is that they are designed for enterprise-level systems. These implementations run on top of an application server and occupy storage areas around 10 MB. For service coordination at the device level, the orchestration machine must in fact run in an embedded device with limited resources.
Based on this, the problem that is the basis for the current invention is to further develop a method for orchestration of a service-oriented automation system and an orchestration machine in such a way that it is compact and can be run at the device level. The problem is solved according to the invention among other things by using the orchestration machine on service-oriented-system-tailored high-level Petri nets, and that the orchestration of the services at the device level is done via interpretation and execution of various HLPN models that depict the behavior of the automation system and/or of the system components.
Service-oriented automation systems relate to distributed and reconfigurable automation systems, whose behavior is governed by the orchestration of services, with system components such as manufacturing components, intelligent decision mechanisms and control devices, which offer services that make available their automation functionalities as service, and are queries by other components.
Services are orchestrated at the device level via computing units as in microcontroller-integrated orchestration machines which use a type of high-level Petri nets (HLPN) tailored to service-oriented systems, which function a HLPN interpreters or as an installed auto-run-capable HPLN control module, for execution of I-ILPN models which depict their behavior. For this, preferably provision is made that the orchestration machine is integrated in a computing unit like the microcontroller of a system component like a mechatronic component and/or a logic control component, and that the HLPN model of the automation system is interpreted and listed by the orchestration machine.
Additionally, the procedure is distinguished in that the orchestration machine is integrated in a computing unit of a control component at the device level like the gripper of a robot or parts of a transport system at the machine level like a set of devices, especially a robot or complete transport mechanism and/or at the cell level like a set of machines that form a complete manufacturing or assembly system, and that a previously compiled HLPN model of the automation system is executed in the control component.
Preferably the Petri net is described via XML, which can be interpreted via the control mechanism of the device or compiled through out-of-network guidance and then can be loaded onto the device.
In connection to interpretation or compilation, the Petri net description is converted into data structures, preferably in the form of matrices, which can be manipulated by the program for control of the service and I/O level.
Preferably the description also includes which services are made available or queries, read or written to the I/Os, and the analysis information actuated for the Petri net.
In addition, the problem is solved by an orchestration machine that is distinguished in that the orchestration machine is designed as an HLPN machine integrated in a computing unit of at least one system component at the device level, which interprets and executes HLPN models of the automation system.
Additionally, the invention relates to the field of industrially distributed control and defines an orchestration machine for orchestration of services, at the device level, in service-oriented-based automation systems.
The orchestration machine uses a type of high-level Petri nets (HLPN) tailored to service-oriented systems, with the advantage of its high-performance mathematical basis made use of to represent dynamic, distributed and event-oriented systems in which simultaneity and parallelism, synchronization, resource sharing, non-synchronized exchange of events and mutual inhibition are decisive.
Preferably an orchestration machine is implemented at the device level, especially into a control or computation unit of a controller like the microcontroller of the device. The orchestration machine preferably has a modular design and can execute and interpret various Petri net models, with the behavior of the device being depicted. For simpler devices, the high-level Petri net model, due to hardware limitations, can preferably be integrated directly into the control. The orchestration machine can be designed as an HLPN control module capable of running automatically in a computing unit like a microcontroller, PLC or IPC of a system component, for executing the HLPN models of the automation system. Additionally, provision is made that a control system comprises a logical control component and/or a decision component and/or a mechatronic component, which are linked with each other via a communication network, with the orchestration machine for coordination and aggregation of services of additional components embedded in the logical control component, and with the orchestration machine knowing the HLPN model of the automation system.
The orchestration machine can be implemented in a controller of a device, i.e., at the device level, if this device contains more than one service and the services must be orchestrated.
Additionally, a prerequisite for implementation is that the device contains a corresponding infrastructure, i.e., a data processing unit like a microcontroller.
Preferably, the mechatronic component as well as the logical control component has a logical controller, which is defined as an HLPN interpreter, to orchestrate services at the device level. A simpler component may comprise pre-compiled HLPN nets instead of an HLPN interpreter.
As an alternative, an orchestration machine may also be implemented in a controller of a device, i.e. at the device level. With this, the machine comprises multiple devices which offer the functionalities as services which must be orchestrated. The machine itself also must contain a hardware infrastructure in the form of a data processing unit like a microprocessor, PLC or IPC.
Additionally, the orchestration machine can be implemented in a controller of a complete manufacture and/or assembly system. In this case, the system consists of multiple machines, with manufacture and/or assembly functions of the machines being offered as services that must be orchestrated. A further prerequisite is that the manufacturing and/or assembly system has hardware infrastructure in the form of a computer unit like a microcontroller, PLC or IPC.
One additional preferred embodiment form may contain the system of multiple orchestration machines, with multiple orchestration machines integrated at a control level of the device (device level), at a control level of the machine (machine level) and/or at a control level of the system (system level).
If the orchestration machine services are orchestrated at the machine level, one of these services orchestrated by an orchestration machine could be the orchestration of a subset of services of a subset of devices. For the then-superior orchestration machine there is only one service to orchestrate, namely the service that is offered by another orchestration machine.
The invention differs especially from prior art in that an orchestration machine is implemented into a controller at the device level, for example integrated into a gripper of a robot or into a drive of a transport system, since the requisite computing capacity is present in the form of computing units like a microcontroller at the device level.
The simpler or the smaller the automation devices displaying the computing units that have the computing capacity, the simpler the orchestration can be carried out at the device level.
Further particulars, advantages and features of the invention are gleaned not only from the claims for these features to be gleaned by themselves and/or in combination, but also from the following description of preferred embodiment examples to be extracted from the drawings.
Shown are:
LCC and decision components DSC, which are connected with each other via a communication network KN and call network services via this or make them available.
The basis for the proposed control approach for the service-oriented automation system SOAS depicted in
The control of the service-oriented automation system SOAS is mainly dependent on the coordination of the distributed mechatronic devices SMC and other components in the system. In the case of the mechatronic devices, this includes the orchestration of their services S and also the coordination and synchronization of their I/Os.
The control itself can be differentiated as a local control LC via the mechatronic components SMC, the logical control components LCC as a collaborative control between components and an assembled control ALCC using special control services AS, usually for formation of higher-level services based on individual services.
The control system STS according to
An orchestration machine OE pertaining to this, which carries out the coordination and aggregation of services S, should be embedded in the LCC, with the entire artificial model MOD being known to it as an HLPN model of the production system.
In addition to the static controller LCC, which principally carries out a special logical or processing plan, the flexibility can be expanded by decision mechanisms. The decision itself can be made locally through the SMC and LCC components, or through the use of special decision components DCS for complex global behavior. For this purpose, the LCC control checks the decision finding components DSC that offer special services S, to select one of multiple options, as is indicated by the arrows P. Also it can force non-detected procedures into unforeseen states. An LCC and a DSC can be integrated as one component, which supplement one another, and operate together by exchange of services.
The mechatronic devices SMC, also designated as Smart Mechatronic Components, control their own behavior and can easily be combined to for more complex devices AC, which, combined with other devices, form the desired automation system. The mechatronic components SMC represent the integrated combination of device, control and communication. An SMC is structured into three different levels, as depicted in
Each SMC must encapsulate services S which the physical device SMC or the smart logical control can make available. Since these components include the concepts of the service-oriented systems, a technological solution depicts the usage of web services WS, in order to make them dialogue-capable. Web services WS are simple, economical, very widely obtainable interactional media between information systems. On the other hand, electronic devices are connected to an increasing degree with standard networks, with Ethernet and TCP/IP being very widely obtainable at many locations. A device profile DPWS for web services WS defines expansions which are necessary to use web services WS in electronic devices, with their specific limit conditions being allowed for: space specification (footprint), making available and fulfilling the most customary requirements, such as security, immediate operational readiness, asynchronous and event-oriented exchange.
An approach exists to define the logical control LC of SMC and LCC as an integrated interpreter I, to instrument services S at the device L, which handle a type of high-level Petri nets HLPN, which are tailored to service-oriented systems. Simpler devices can include already pre-compiled HLPN instead of an interpreter I, since the logic and communication themselves do not have to be altered during the run time.
It is important to point out that other control mechanisms can be used parallel via various devices. The condition is that communication via web services should ensure compatibility and that the logical control mechanisms used, in the present case Petri nets, must have access to the service-level DPWS, to use the facilities and to be capable of communicating with other components in the system.
The HLPN-based logical control machine or orchestration machine OE is embedded in microcontroller devices, with them carrying out the logical control behavior of the automation device or system. The machine OE can be integrated in an independent LCC or directly into the SMeCs for collaboration purposes. The machine carries out the logical control behavior of the LCC or SMC components, depicted via HLPN models, with the implementation of the services S being coordinated (and/or I/Os as per the level of granularity) which are made available through the components.
The approach uses HLPN as a description of control logic for several reasons:
The advantage of their high-performance mathematical basis to represent discrete, dynamic, distributed and event-oriented systems in which simultaneity and parallelism, synchronization, resource sharing, unsynchronized exchange of events and mutual exclusion are essential
Facilities complex in graphic modeling and comprehension
High-performance and effective control mechanism, since HLPN is to be depicted internally as a set of matrices and manipulated
Capability for adaptation of interfaces to I/Os and services through the description of transitions
Activating and synchronizing the run-time behavior of components
Coverage of conflicts that require a decision
Validation, analysis and simulation in the draft phase, with the results of this phase being able to be used for support of the decision mechanisms
Modular depiction, connectivity and aggregation of sub-models
Transparence: modules can be programmed in various methodologies, since the interaction pattern is defined and mutually form a standard pattern
Application examples:
Development of a control module for an automated feeding device, with reference to
Taken into account is the example of a feed unit FE with Transfer In and Transfer Out services TIS, TOS for connection with other feed units or transport systems, and an On-Position service OPS for displaying that a product such as a palette is at a place to be used by a machine or an operator. Said services are made available by the SMC and can be used by other components, but if needed, also external services may be consulted, such as that the Transfer Out service of the other feed unit must be queried to connect with other feed units.
In an initial phase, the HLPN model which depicts, edits, analyzes and simulates the behavior of the automation device, with a suitable high-level Petri net tool being used. As explained above, the automatic services run via a high-level Petri net control machine OE, but other forms of control mechanisms can also come into use. It depends on the developer or engineer, as to which available control machine is to be used, as long as it has the interface SI to the service level SL and thus permits compatibility.
Then the HLPN model is downloaded to the microcontroller MC, which then is interpreted and carried out by the HLPN machine OE, which is already embedded in the microcontroller device. The services orchestrate execution of the HLPN model by the machine OE as per the special behavior, with the service S made available via the SMC components being summoned. The system is easily and quickly able to be reconfigured and is only needed to alter the HLPN module, which depicts the new behavior of the automation device or system.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10 2007 051 683.7 | Oct 2007 | DE | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2008/064470 | 10/24/2008 | WO | 00 | 7/14/2010 |
