- Email: [email protected]
A service- and multi-agent-oriented manufacturing automation architecture
Computers in Industry 63 (2012) 813–823
Contents lists available at SciVerse ScienceDirect
Computers in Industry journal homepage: www.elsevier.com/locate/compind
A service- and multi-agent-oriented manufacturing automation architecture An IEC 62264 level 2 compliant implementation Kevin Nagorny a,*, Armando Walter Colombo b,a,1, Uwe Schmidtmann a,2 a b
University of Applied Sciences, Emden/Leer, Constantiaplatz 4, D-26723 Emden, Germany Schneider Electric, Germany
A R T I C L E I N F O
A B S T R A C T
Article history: Received 28 January 2012 Received in revised form 20 July 2012 Accepted 1 August 2012 Available online 27 August 2012
This paper describes an approach for developing and implementing a service- and multi-agent-oriented manufacturing automation architecture, being particularly focused on functional features of the IEC 62264 L2 standard. The proposed SoA architecture facilitates managing and controlling networked smart automation components in a distributed manufacturing environment. The services, generated and exposed by automation components located on the levels 1 and 2 of the ISA’95-compliant enterprise architecture, are essential part of an ‘‘Automation Service Cloud’’, which is the result of the virtualization of the physical production environment. Moreover, these services can be accessed, requested and used by other components of these and upper levels, i.e., MES (Manufacturing Executing System) distributed components like a collaborative multi-agent-based manufacturing scheduling and dispatching system. Using the main characteristics of the service-orientation, the automation services can be composed and orchestrated in the cloud, creating emergent behaviors, which is a direct result of the virtualization, i.e., transforming the mechatronics/production layout into an automatically collaborative network. ß 2012 Elsevier B.V. All rights reserved.
Keywords: Service-oriented architecture Formal methods for industrial control systems Service orchestration Intelligent warehouse Interoperability in manufacturing automation
1. Introduction This paper describes an approach to realize a ‘‘Service- and Multi-agent-oriented’’, collaborative industrial manufacturing automation architecture, oriented to support structural connectivity and functional interoperability among devices and systems across a customizable Service-oriented enterprise architecture. From the functional point of view and taking into account standard enterprise architectures [15,50,51], the addressed architecture follows the level 2 designation of the ISA’95/IEC 62264 [7,14]. There are two major aspects that have been taken into account when the proposed architecture was initially designed and specified, one of these aspects is related to the necessity of structural (information, communication and control) connectivity among components inside a manufacturing environment. The other one addressed the functional interoperability (information exchange about management, control and supervision, among other functions) infrastructure behind the first one. The continued increasing demand for customized and sometimes extreme customized products (one product for each
* Corresponding author. Tel.: +49 4921 807 1955. E-mail addresses: [email protected], [email protected] (K. Nagorny), [email protected] (A.W. Colombo), [email protected] (U. Schmidtmann). 1 Tel.: +49 4921 807 1972. 2 Tel.: +49 4921 807 1833. 0166-3615/$ – see front matter ß 2012 Elsevier B.V. All rights reserved. http://dx.doi.org/10.1016/j.compind.2012.08.003
customer), for products, which are getting more and more complex and multifunctional and multi-application domain, derivate into shorter changeover times and product life cycles. This trend is also generating a continued transformation of the production environment, which evolved in a few couple of years from mass production to mass or extreme customization. This means, on one side, the increasing demand for continuously new products, following in same way the mode, requires a tremendous increase of efficiency and quality in the manufacturing process. As a direct consequence, conventional manufacturing structures are coming up to their limits, when customization is highly required [26,42,52] On the other side, the market and production trends cannot be sustained by continuing using current manufacturing structures, mainly based on sequential and line-oriented and hard-connected mechatronic layouts and hierarchical management and control systems. The trend can only be followed if the factory, the manufacturing system and its management and automation systems are enough ‘‘flexible’’ and ‘‘reconfigurable’’ [4,26,37–41]. Addressing specifically the management and automation issues associated to flexible and reconfigurable production systems addressed before, scientists and practitioners that work with conventional industrial implementations, are mainly following structures that follow the standard ISA-95 [6,7,13,14]. They are hierarchical built, which keep on splitting orders of the higher levels and pass these on to the lower layers. In a similar way, data acquisition, information processing and monitoring are also bottom-up hierarchical implemented. On that account no layer
814
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
is allowed to be left out because every level fulfills a certain task which is fitted to the next one. Business applications are executed in the layer on top (Enterprise Resource Planning [ERP]), below that the data (e.g. orders), which is passed on by the business layer, is scheduled and a production plan is created out of it (Manufacturing Executing System [MES] [31–35]). The production plan is handled on this level. Orders are split into many subtasks which are handled by different manufacturing cells (Supervisory Control and Data Acquisition [SCADA]) [5,27,36]. This generates some production sequences out of the subtasks which are executed by the controlling level. Information about the running production is collected bottom-up. Technically spoken, it is very difficult if not impossible to create a connection between the business layer and the production layer on the bottom (shop floor), because they are mainly based on different interfaces and technologies, both from communication but also information processing and control viewpoints. Summarizing both aspects, it is possible to identify the following set of restrictions that new automation architecture should address, both from logical and physical viewpoints [9,11,12]: Note: Structural/physical restrictions are identified by [P] and logical by [L]. P If a machine in the production line breaks down, the whole line has to be stopped. P High changeover times are a reason for the interruption of the production. P The workflow in line structures is dictated by the slowest machine. P Production units in the lines, which depend on each other, have to be equipped with buffers because of the different cycle times. P Flexible routing is not possible in conventional production lines and therefore, if redundant machines are part of the shop floor, they cannot directly be reached when another one breaks down. P&L It is difficult to extend production lines in a reasonable time and with controllable investment. L Due to hard and hierarchical linked control and automation programs, a dynamic reconfigurable layout and flexible and sometimes agile behaviors are not possible. L Information can only be exchanged between neighbor layers and many times using gateways to facilitate connectivity and interoperability. By analyzing latest research results, new innovative prototypes solving some of the issues addressed above, e.g., facilitating crosslayer connectivity and necessary interoperability among components located in different ISA’95 levels, have been reported e.g. (http://www.socrades.eu, [2,3,23–25], http://www.imc-aesop.eu, [27–29,54,55]). The Service-oriented Architecture proposed in this paper facilitates managing and controlling networked smart automation components in a distributed manufacturing environment, addressing the P and L restrictions and requirements. Following the SoAprinciples, manufacturing automation components are extended in their structures and functionalities by a web-service interface. This extension transform the component in a ‘‘Service, i.e., Client and Server’’, able to expose and or consume, to compose, to orchestrate web services inside the architecture [30]. The mechatronics/production layout has then be transformed into a collaborative network of operators [19,20,22,37]. Basically, the services, generated and exposed by the operators, automation components located on the levels 1 and 2 of the ISA’95compliant enterprise architecture, are essential part of an ‘‘Automation Service Cloud’’, which is the result of the virtualization of the physical production environment, i.e., the technological
formalization of the shop floor components as essential part of a Cyber-Physical System [30,43,47]. Moreover, these services can be accessed, requested and used by other components of these and upper levels, i.e., MES distributed components like a collaborative multi-agent-based manufacturing scheduling and dispatching system [16–18]. So for example, using the main characteristics of the service-orientation, the automation services can be composed and orchestrated in a Service Cloud [28]. As one of the major results of that composition and orchestration, new emergent behaviors are created and new properties and functions (not presented by the components itself) start being exposed by the whole production system-of-mechatronics-, control-, communication- and information processing-systems. The virtualization allows considering the manufacturing environment as a Systemof-Systems [24,30,44–46]. Section 2 overviews the major characteristics of a collaborative SoA-based manufacturing system and describes the major requirements for collaborative, reconfigurable automation architecture. Section 2 describes the characteristics of a SoA-based layered automation architecture mapped into the ISA’95 control hierarchy levels. Section 3 describes the major specifications of the components and functions located on the ISA’95 level 2, which are physical and logic represented in the Operator Layer of the architecture addressed in the section before, including a first description of the interfaces to the ISA’95 upper L3 and L4, and lower L0 and L1 levels. Section 4 presents a brief description of an implemented prototype in an industrial application scenario and Section 5 summarizes the paper and outlooks possible future works. 2. A Service-oriented ISA’95 architecture A Service-oriented automation architecture, following the basic ISA’95 specifications, is hierarchically built, BUT it has to facilitate in both, inside each layer but also cross-layer, structural connectivity and functional interoperability among the components. Fig. 1 (from [14]), shows the traditional hierarchical Control ISA’95 topology, mainly from Information Technology viewpoint, composed of 4 levels (see also [13] and the references here in). As depicted in Fig. 2, the architecture proposed in this work, called ‘‘Operator 2.0’’ is mainly composed of 5 physical layers, which are directly mapped to or composition from some of the physical components and functions identified in the levels of the standard shown in Fig. 1. The Hardware- and Stub Layers in Fig. 2 should be positioned on the ISA’95 level 1 of Fig. 1. The Operator Layer is containing functional and architectural components that should be positioned on the ISA’95 level 2. The layer identified with the Agent label in Fig. 2 represents mainly Scheduling and Dispatching functions and components, which are typically physical and logic functions and components located on the ISA’95 level 3, particularly those associated to Manufacturing Execution Systems (MES). Finally, the ERP (Enterprise Resource Planning) Layer of Fig. 2 corresponds physical and logically to the ISA’95 level 4. An important difference between the architecture depicted in Fig. 1 and the architecture shown in Fig. 2, one of the major outcomes of the work reported in his paper, is that Operator 2.0 use a unique ‘‘communication network’’ across the whole architecture, from the Stub Layer up. This fact, identified by red arrows showing the interfaces between neighbor layers, is facilitated by using a common Ethernet-based technology. Note: This is only possible on the Hardware Layer when heterogeneous mechatronics components are wrapped (see Section 4 for more explanations). The rest of this paper focuses on the major specifications and characteristics of components and functions located on the ISA’95 L2, modeled and exposed as ‘‘Services’’ inside the layer 2 of
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
815
3.2. Stub Layer (Level 1) This layer is above the Hardware Layer and includes stubs which are from the functional point of view wrappers for the components of a manufacturing system. The stubs convert proprietary interfaces into a unified protocol. If e.g. the controller of an industrial robot needs to be linked to a web-service, complications can occur in the segment of protocols which are usually proprietary protocols. Therefore a stub is developed for every component of the manufacturing system. The stub is responsible for the adherence of all original specifications of the component and it externally provides a Unified Interface. This interface makes it possible that every component of the same type, regardless of the provider, can be reached with the same protocol. A major requirement for the stub is that it should be running in a real-time operating system and should keep on respecting and following the hardware specifications. Note: A more extended specification and description of the stubs is out of the scope of this paper (see [1]).
Fig. 1. ISA’95 control hierarchy [14].
Operator 2.0, and the interfaces to the upper (L3) and lower (L1-L0) levels. 3. A Service-oriented ISA’95 L2 architecture After a brief overview about the Hardware and Stub Layers of the architecture Operator 2.0, this section explain the most important features and characteristics that have been specified and implemented in the Operator Layer (mapped into the ISA’95 L2/designation IEC 62264 of the architecture shown in Fig. 2). 3.1. Hardware Layer (Level 0-1) The Hardware Layer shows random components with proprietary interfaces which could be used in the manufacturing process (PLCs, IPCs, frequency converter, etc.).
3.3. Operator Layer (Level 2) The Operator Layer shown in Fig. 2 is a service-based multilayer structure responsible for virtualizing hardware components and exposing their functionalities as ‘‘Services’’. This means, the operators make it possible, to transform the shop floor components represented in the Stub Layer into a Service-oriented component inside an Information Infrastructure at the possible highest abstraction degree. The existence of many different Operators offer the possibility to cover different automation and control functions that are typically part of the ISA’95 L2, like Monitoring, Control, SCADA, etc. Following this form of thinking, the Operator Layer will allow populating an Automation Service Cloud [28], i.e., automation functions exposed as web services, as the major result of the ‘‘Virtualization’’ addressed above. Moreover, following the major
Fig. 2. Operator architecture – Operator 2.0.
816
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
characteristics of a typical SoA-Infrastructure, composition and orchestration of services, will also be implemented by such Operators, allowing the virtualized shop floor for exposing Emergent behaviors and functions not initially contained in the manufacturing components, e.g., simulation, energy efficient management, etc. Remark: A first brief explanation of the reasons for such a virtualization and particularly a first approach for migrating ISA’95-compliant architectures into a SoA-based infrastructure can be found in [28]. The specification and implementation of Operator 2.0 is one possible way to start performing this migration. The Operator Layer itself is subdivided into various sub layers, which will be described in the following sub-sections.
GET SE1 73 GET SE2 73 ...
3.3.1. Control-sub layer A direct communication between the Stub Layer and the Operator Layer takes place in the Control-sub layer. For this communication, the operator uses the protocol that has been unified through the stub. Therefore the operators use the unified protocol to communicate with all stubs. The Control-sub layer does not possess a dynamic behavior. But it is possible to define blocks of sequence (macros), which are executed each time that they are called/requested. Fig. 3 presents an example of those macros. Note: These macros can be described in a static configuration file or can be generate by the higher sub layers over the Control-sub layer interface during running time. As depicted in Fig. 2, the Control- and Model based-sub layers of the Operator Layer are vertically divided into segments. These segments represent the existence of two or more automation/ mechatronics devices/components on the shop floor. Moreover, the existence of two or more segments implies the existence of two or more Stubs. Following this logic structure, an operator can add various different hardware components and using the ‘‘Operator 2.0’’, it can offer the functionalities of those devices as services. In order to better clarify the importance of this vertical separation of sub layers, a small example is explained bellow. A device at the shop floor needs to be extended by an additional component/unit (complementary device) dedicated to perform energy measurement. This additional component will be linked to an operator associated to the device, located on the Operator Layer. It is addressed by a separate control instance and can give data of the current energy consumption, exposed as ‘‘service’’. Fig. 4 shows the part of the configuration file where many of these devices can be linked to one operator. 3.3.2. Model based interface-sub layer The sub layer ‘‘Model based interface’’ defines the procedure and identifies reachable states of a virtualized component. The following standard situation derived from functional aspects of the architecture gives the major reasons for implementing a Model-based Interface-sub layer. Due to the separation of the Service-sub layer and the Control-sub layer a chaotic communication with the hardware is foreseen. A failure mode can be set back in another defined state by a maintenance service in which errors are solved and an error-free state is recapitulated by the Model based-sub layer. Thereby the chosen model must support the communication with the basic services (s. Service-sub layer). As a result of the composition or orchestration of services facilitated by the ‘‘model based interface’’, functions like e.g. remote maintenance, which were not present in the automation system, can now by located in the Cloud and become possible as long as no manual interference is needed. Different algorithms can be used to control the hardware in this sub layer (e.g. a Dijkstra algorithm for the routing of pallets by a flexible transport system) [10], or formal methods like e.g. Highlevel Petri Nets (HLPN) [8].
SET M2 50 SET AK2 271 ...
Fig. 3. Macro in the Control-sub layer described in a configuration file.
In the last case, enabling and firing conditions of transitions in the HLPN model are connected with physical mechatronics units like sensors and actuators. Another useful modeling alternative is that transitions and places of the HLPN are linked to methods associated to ‘‘Services’’ (see Fig. 5) [48,49]. 3.3.3. Service-sub layer Generally spoken, all services in the Service-sub layer are modular. With JIT-compilers (just in time) it is possible to reload services (dynamic deployment) in running time. Operators do not have to be restarted to renew or add services to the component. Practically this possibility is decisive to guarantee a production flow without any interruptions. Moreover, services can be used by the pull-principle, what can also be event-based. Therefore clients can subscribe an event associated to a service. If the subscribed event occurs, the registered client will be informed. In contrary to the conventional pull-principle the network does not get overloaded with overhead. The Service-sub layer includes three different types of services: ‘‘Basic-’’, the ‘‘Special-’’ and the ‘‘Optional-’’ Services. Basic services are always provided by an operator, e.g., industrial components with sensors and actuators always need the following three basic services control, monitoring and maintenance. The second service type provides further functions. This can be a service for the simulation of the component for example or can be an energy management service which can monitor, control the energy consumption.
... ... ...
Fig. 4. Configuration file for many devices linked to one operator.
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
1 0 1 0 0 1 0;1 0 0;0 0 1;0 1 0 1 0 0;0 1 0;0 1 0;0 0 1 GET SE4 33 ... SET M1 50 ... ... Fig. 5. HLPN-model configuration for the Model-based Interface-sub layer.
The third type of services is represented by the ‘‘Optional Units’’. Depending on the model used on the ‘‘Model based interface’’-sub layer conflicts can appear which have to be solved by intelligent units in higher layers. For this case, the unit ‘‘Conflict Manager’’ is used. The ‘‘Model based interface’’-sub layer can be connected with another operator by using formal methods like High-Level Petri Nets (HLPN). For this purpose the unit ‘‘Global Binder’’ can be used. The unit ‘‘Orchestrator’’ can be used for a collaboration with different operators (different hardware types and different models on the ‘‘Model based interface’’-sub layer). The following sub-sections explain more deeply the functionality of some of the ‘‘Optional Units’’ and how they are related to e.g., the formalization behind the model-based interface. 3.3.3.1. Utilization of the optional unit ‘‘Global Binder’’ and ‘‘Conflict Manager’’. The ‘‘Global Binder’’ is responsible for the collaboration of various operators of the same type by linking the used formal method with the same formal method of another operator. There are two possibilities. One possibility is a manual link via a static configuration, in which the address of the operator, which has to be linked and the local-/global linking points, are described. This type of linking should especially be used when different hardware types are linked because in that case links depend on the individual component. Similar modules, which set up an ad-hoc connection by using embedded systems (see Fig. 3), are able to create a system of systems together which can logically be linked by algorithms. Fig. 6 shows a transport system in which each module possesses a hardware interface which established an ad-hoc connection by connecting with another module. Decisive Identifications IDs (e.g. Media Access Control MAC-addresses) and information are exchanged via the connection described before to identify their
817
neighbors. Now each local ‘‘Global Binder’’ connects the right interfaces of the model used in the ‘‘Model based interface’’-sub layer via an algorithm to create a module cluster. The linking interfaces are the transitions when regarding an HLPN. The ‘‘Conflict Manager’’ always has to be instanced when conflicts among, e.g., shared resources appear in the Cloud, formalized by conflicts among transitions in the HLPN-based model. A typical conflict situation on a manufacturing environment appears for example when a pallet on a transport system module can be further transferred to another module located to the left or to the right direction. This conflict is collected, virtualized and processed by the ‘‘Conflict Manager’’. When such a conflict arises intelligent units responsible for scheduling, dispatching or similar manufacturing execution functions are required, so that a right decision concerning the ongoing procedure can be done. Note: The ‘‘Model based interface’’-sub layer must determine the power of decision of the operator. 3.3.3.2. Utilization of the of the optional unit ‘‘Orchestrator’’. The ‘‘Orchestrator’’ is itself a ‘‘Service’’, able to link operators on the Service Cloud. It fulfills its functionality by composing services exposed by other operators. The composition of different service types like e.g. the composition of a high rack warehouse with a transport system-service can lead to a service which brings certain material to a certain place (only one order is needed). Furthermore one advantage of the orchestration on the Service Cloud is that orchestrators can function as unique programs executed on a high performance industrial PC (IPC) having complex links of many operators. 3.3.4. Interface and registration-sub layer Via the Configfile it is determined which services are populating the Cloud. All services, which should be loaded, are being instantiated and then they are registered in a local administration module of this sub layer. All services are reachable by an internal program via local IDs. The service is externally provided by its Name, which is embedded in the Uniform Resource Identifier (URI)formatted operator address. The methods associated to a service are managed internally by service-instances. URI-addresses are passed on to the service instances where they can be further managed. This sub layer manages clients (agents, operators and orchestrators), which call up the ordered services or link with ‘‘Optional Units’’ via the local administration. The operator registers as a client at a global administration level, which represents the function of ‘‘yellow-pages’’ to find services. In that case the global administration advices which component is the one signaling (which can only proceed via a definite ID). Furthermore the global administration advices which services are provided by the operator. The client can request the global administration to receive the address of a certain service. If a registered service is suitable the contact data is given back. Integration of ISA’95 L3 and L4 with the L2 of Operator 2.0 Agent Layer (level 3) Above the Operator Layer representing mainly components and functions of the ISA’95 L2, the Operator 2.0 architecture proposes the use of a Multi-agent-based system offering Scheduling, Dispatching and other Manufacturing Execution System operations/functions [16–18,21]. The main characteristics and specifications of this layer are objective of a future report. Nevertheless, it is important to recall here that operators and agents are integrated into one unified network. Fig. 7 shows the ‘‘Operator 2.0’’ architecture as a Cloud of ‘‘Services’’. All components in the Cloud are reachable because they belong to a unified network, independent of the physical position but facilitating a cross-layer collaboration. Analyzing in a deeply manner the structural relationship among the components of the architecture (virtualized in the Cloud), each hardware component
818
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
Fig. 6. Automatic graph generation with the use of physical ad-hoc connections explaining a possible use for the Global Binder.
is connected to a Stub which is converting the proprietary protocol to a unified symbolic language in a real-time environment. One or more Stubs are connected with one Operator which is able to expose the hardware features/characteristics and other functionalities as ‘‘Services’’ in the Service Cloud. The different operators are able to collaborate in two different manners, on one side using the model interface when they are using the same model and on the other side, by composition and other relationships among the services located in the Service Cloud. Independent Orchestrators in the Service Cloud, or Orchestrators that are included in Operators as Optional Unit, are able to orchestrate two or more ‘‘Services’’. As explained before, in the ISA’95 L3 are used intelligent agents, which are offering functions of a conventional Manufacturing Execution System (MES) like dispatching and scheduling. The addressed MES functionalities result from negotiations and collaborations among different agents. In this manner, production orders and scheduling re-scheduling decisions that result from those negotiations will be executed by the Operators and Orchestrators. 3.3.5. ERP Layer (level 4) At the top-level ISA’95 L4 is working an ERP-system which provides the interface to the Service Cloud and the Human Interface.
In the current implementation the ERP-system provides mainly functionalities to generate orders or get status information about the factory. 4. Prototype implementation 4.1. Prototype architecture ‘‘Operator 2.0’’ is being implemented in a prototype manner, following the schema depicted in Fig. 8. At the bottom is the Hardware Layer, which is technologically spoken ‘‘heterogeneous’’, mainly composed by industrial automation, mechatronics and production components, i.e., PLCs, I/O devices, Robot Controls, etc. All these components are having proprietary information-communication-control protocols and mainly unable to interoperate. This interoperability problem is talked by wrapping the components with the Stubs on the Stub Layer, using a unified protocol. Technically spoken, each component has to get a Stub for the unification. The Operator on the next upper layer use this unified protocol to control the hardware. The first major result of the implementation of the Stubs is the easy integration of Legacy Systems.
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
819
model, to be a part of the control logic or to perform e.g. modelbased monitoring or other supervisory control functionalities. The geometric symbols on the top of the Operator Layer in Fig. 8 represent the Service-Interface inside the Service Cloud. In this environment are the Agents and the interface to the ERP-system in the ERP Layer. 4.2. Use case application Application Scenario: Intelligent Warehouse/Distribution Center (e.g. Energy Efficient Automation of Warehouse and Material Flow Systems). 4.2.1. State-of-the-technic and state-of-the art
Fig. 7. Virtualization of a shop floor by Services in a Cloud.
On the hardware side at this layer, it is needed a gateway to unifying the communication network technology, for example, in the case that a component is providing only a Bus-interface, a gateway will facilitate the communication to the Ethernet network (basis technology of the Service Cloud). The unified protocols are used by the Operators on the Operator Layer. In Fig. 8 is possible to identify a HLPN as model of the shop floor (production hardware to be controlled, monitored, etc.). A major characteristic of this model is that it is connected over transitions with the Stubs. All the units and services inside the Operator Layer have the possibility to apply for a connection to the
- Currently Warehouse/Storage Systems are managed (monitored and controlled) in a centralized and rigid hierarchical manner. - Currently Warehouse/Storage Systems are managed following production specification requirements and not considering, e.g. Energy Consumption aspects. Two different systems not able to interoperate (Energy and Production Specifications belong to two orthogonal fields). - The exchange of information between warehouse and material flow, and manufacturing components, is performed using different communication protocols and information processing systems, when the warehouse is seeing as one of the components inside an ISA’95-compliant manufacturing enterprise architecture. Lack of structural but particularly functional interoperability. - Storage and material flow strategies are currently build to respond on a centralized and synchronous operation mode, generating strong requirements for commissioning functionalities and storage structure. - Manufacturing Execution System (MES) Functionalities associated to the Warehouse Storage and Material Flow Monitoring and Control are not direct technological linked to supervisory and
Fig. 8. Illustrate the use of the ‘‘Operator 2.0’’ architecture.
820
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
Fig. 9. Use of Operator 2.0 to integrate an ‘‘Intelligent Warehouse’’ into a SoA-based Enterprise Architecture.
control functions associated to the mechatronics components building the Warehouse and Material Flow Systems. 4.2.2. Progress beyond the state-of-art: addressing structural connectivity and functional interoperability Fig. 9 shows schematic the application of ‘‘Operator 2.0’’ to make feasible a cross layer connectivity and functional interoperability of an Intelligent Warehouse inside a SoA-based enterprise architecture. Warehouse as intelligent Module integrated into a Flexible Manufacturing Systems and able to structurally and functionally interact with the rest of modules following own and common goals. For example, ‘‘Energy Management-based Monitoring and Control’’ of Warehouse and Material Flow, integrated into the ISA’95 Enterprise Architecture. Warehouse as Mechatronic Module with Web Service-based ICCT (Information-Communication-Control-Technology) Interface (Wrapper), i.e., source of ‘‘Services’’ to be exposed and also capable of consuming ‘‘Services’’ exposed by other modules. Structural Connectivity and functional Interoperability of the Warehouse with other Devices and Systems inside the shop floor
and the whole ISA’95-compliant Enterprise Architecture, via Service Exposition, Service Consume, Service Orchestration and Multi-agent based negotiation. As a direct related-result to the characteristic addressed above, Warehouse and Material Flow functions exposed as Services (Intelligent Distribution Center as SoA-based Solution), which can be consumed, used by other components of the enterprise. Integration of the Warehouses into a Service-based Factory Cloud (see [56] and references therein), which is the result of the virtualization of the Flexible Manufacturing System. Remark: The Factory Cloud corresponds to the operator layer of the architecture shown in Fig. 2. 4.2.3. Real-world context, experiments and results - The Product to be manufactured generates the needs for transportation, production and storage and supply them associated to a unique-IP-Address, via web services inside an ISA’95-compliant enterprise architecture. - The Warehouse exposes its storage functionality as services inside the SoA-based enterprise architecture, being also identified by a unique IP-Address. Among others, component description,
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
-
-
-
-
location, main functions and structural characteristics are information contained in the set of services exposed via web technology inside an ISA’95-compliant enterprise architecture. Any mobile component, e.g., pallet that need to be stored is also exposing its characteristics, e.g., identification of product/part on it, work plan, etc. is also exposing those characteristics as services exposed via web technology inside an ISA’95-compliant enterprise architecture. Both, storage and pallets are now networked inside the SoAbased shop floor and the management and control of the material flow and storage functionalities are the result of composition/ orchestration of services. This orchestration function can be located in a centralized manner on Level 3 of the ISA’95 compliant enterprise architecture or being located embedded in the controllers/automation devices associated to the mechatronics components, i.e., pallet or warehouse, or deeper embedded into storage modules inside the warehouse. The warehouse is also built in a modular manner and each of its modules can also be separated and identified by an unique IPAddress and associated web services. Independent of the location and position of the Warehouse inside the enterprise architecture, it can be connected and can interoperate with any other component of the same architecture, being this communication done vie exposition, consumption, composition and/or orchestration of services.
Combining Energy Metering Services and Material Flow/ Storage Services will have big impact in generating energy efficient management and control strategies, which can be exposed as services and located anywhere in the service cloud behind the SoAcompliant ISA’95-architecture. As a direct result, just-in-time storage scheduling, customized local commissioning related to energy efficient processes is being performed. 4.2.4. Addressing sustainable interoperability, scalability, structural evolvability and emergent behaviors in the factory Next generation automation and control systems, like our ‘‘Operator 2.0’’, will stem upon an interoperable interconnection between service-, event- and knowledge-driven architectures implemented at the shop floor level, at the manufacturing execution level and at the enterprise applications level. Recent achievements in the three above research domains are being experimented and benchmarked in our real industrial settings to demonstrate their business benefits, not just from the economic viewpoint but in a more holistic technical sustainability sense. The ‘‘Operator 2.0’’ pillars respectively guarantee interoperability (both structural and functional) and scalability supported by the service-orientation and multi-agent negotiation. Due to the virtualization and abstraction of physical resources, modeling Factory tangible and intangible assets ‘‘as a Service’’, structural ‘‘Evolvability’’ like plug-in of new Mechatronic components or plug-out of dedicated systems is immediately translated into registration and exposition of ‘‘Services’’. Moreover, the capabilities offered by the Operator Layer, i.e., composition and orchestration of assets in complex aggregates and new manufacturing processes support the control and management of ‘‘Emergent’’ behaviors. This behaviors, not present in isolated components with autonomous behavior and self-management, result from the functional interoperability of the serviceoriented components in both inside the shop floor and cross-layer between the ISA’95 layers.
821
architecture, with major focused on functional aspects related to the ISA’95 Enterprise Architecture (IEC 62264 L2) standard. The proposed ‘‘Operator 2.0’’ architecture facilitates managing and controlling networked smart automation components in a distributed manufacturing environment. The services, generated and exposed by automation components located on the levels 1 and 2 of the ISA’95-compliant enterprise architecture, are essential part of an ‘‘Automation Service Cloud’’, which is the result of the virtualization of the physical production environment. The Layer 2 (Operator Layer) of the architecture is extended with a model-based interface. Using High-level Petri Nets (HLPN) as model of the shop floor (production hardware to be controlled, monitored, etc.), transitions and firing-modes of transitions have the possibility to be connected to wrappers (Stubs) located on the layer bellow (ISA’95 L1). All the units and services inside the Operator Layer have the possibility to apply for a connection to the model, to be a part of the control logic or to perform e.g. model-based monitoring or other supervisory control functionalities. The recent advent of Event-Driven Architectures (EDA), taking into account at the architectural level the ‘‘Event’’ concept and supporting suitable functionalities to collect, distribute and provide events to devices or services that need them, is conducting to an extension of the SoA paradigm with e.g., Complex Event Processing (CEP) capabilities. One of the future works planned in relation to Operator 2.0 is a more intensive research into the modeling and validation aspects associated the Event-driven characteristics of our Petri Net based orchestration inside the SoAbased architecture [53]. As a matter of fact, CEP is indirectly addressed by the Model-based interface of Operator 2.0. A Petri Net-based Service Orchestration/Composition behaves inherently in an Event-driven manner, supporting both a more heavily use of distributing processing and particularly an asynchronous processing and reasoning-based control, monitoring and management functionalities. The services located in the Automation Service Cloud can be accessed, requested and used by other components of these and upper levels, i.e., MES (Manufacturing Executing System) distributed components like a collaborative multi-agent-based manufacturing scheduling and dispatching system. Using the main characteristics of the service-orientation, the automation services can be composed and orchestrated in the Cloud, creating emergent behaviors, which is a direct result of the virtualization, i.e., transforming the mechatronics/production layout into an automatically collaborative network. The tests and application results of a first prototype implementation are promising. The distributed Service-oriented ‘‘Operator 2.0’’ architecture allows the virtualization of a shop floor, making feasible to proceed controlling, monitoring, etc. heterogeneous mechatronics components, all mapped into an Information Processing Cloud (Service Cloud). Further steps in the development of the architecture are among others, the integration of Engineering Tools, commercial MES and ERP systems. Moreover, having implemented and put the ‘‘Operator 2.0’’ in place, the creation of new category of Services increasing the degree of functional interoperability between more enterprise systems is foreseen, e.g., Energy Services, Simulation Services, ERP-Services structurally and functional linked to the Multi-agent layer, etc. Acknowledgments
5. Conclusion This paper describes the principal characteristics and features of a service-oriented control and production management
The authors would like to thank the partners of the EU FP7 IP IMC-AESOP project (www.imc-aesop.eu) and the members of the I2AR Institute (www.i2ar.de) for the fruitful discussions.
822
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
References [1] U. Schmidtmann, G. Kreutz, M. Barkhoff, K. Virkus, T. Sto¨ckmann, M. Jovic, Microprogrammable hardware abstraction layer for flexible automation, in: IEEE ETFA’09, 22–25 September, (2009), pp. 1–7. [2] A. Cannata, M. Gerosa, M. Taisch, SOCRADES: A framework for developing intelligent systems in manufacturing, in: IEEE Industrial Engineering and Engineering Management IEEM 2008, 8–11 December, (2008), pp. 1904– 1908. [3] A.W. Colombo, SOCRADES: Steps Towards the Factory of the Future, Projects Magazine EU, British Publishers Inc. 12, 2009 pp. 20–23 http://viewer.zmags. com/publication/4c086127#/4c086127/1. [4] H.K. Shivanand, M.M.B.H.K.S.V. Koti, Flexible Manufacturing System, New Age International (P) Ltd, 2006. ¨ berwachung und Steuer[5] J. Lunze, Automatisierungstechnik: Methoden fu¨r die U ung kontinuierlicher und ereignisdiskreter Systeme, Oldenbourg, 2008. [6] M. Georgoudakis, C. Alexakos, A. Kalogeras, J. Gialelis, S. Koubias, Decentralized production control through ANSI/ISA-95 based ontology and agents, in: IEEE Int. Workshop on Factory Communication Systems, 2006, 374–379. [7] C. Alexakos, M. Georgoudakis, A. Kalogeras, K. Charatsis, J. Gialelis, S. Koubias, A model for the extension of IEC 62264 down to the shop floor layer, in: IEEE Int. Workshop on Factory Communication Systems, 2006, 243–246. [8] T. Murata, Petri nets: properties, analysis and applications, Proceedings of the IEEE 77 (April (4)) (1989) 541–580. [9] D.P. Garg, C.D. Poppe, Coordinated robots in a flexible manufacturing work cell, in: Proc. of the IEEE/ASME Int. Conf. on Advanced Intelligent Mechatronics, 2001. [10] B. Liu, S.-H. Choo, S.-L. Lok, S.-M. Leong, S.-C. Lee, F.-P. Poon, H.-H. Tan, Finding the shortest route using cases, knowledge, and Djikstra’s algorithm, IEEE Expert 9 (October (5)) (1994) 7–11. [11] A. Cichocki, Workflow and Process Automation: Concepts and Technology, Kluwer International Series in Engineering and Computer Science; Kluwer Academic Publishers, 1998. [12] A. Desrochers, Modelling and Control of Automated Manufacturing Systems, IEEE Computer Society Press 90, 1989. [13] THE WBF BOOK SERIES-APPLYING ISA 95. Implementation Experiences. Wbf Book Series, World Batch Forum, Wbf, Momentum Press, 2010. [14] D. Brandl, P. Owen, A Tutorial on the ANSI/ISA95 Enterprise/Control BR&L Consulting. www.brlconsulting.com/. . ./2003-09%20IEE%20. . . 6 January 2001 – Dennis Brandl Peter Owen. BR&L Consulting Eli Lilly & Co. 2. [15] I. Delamer, J.L.M. Lastra (Eds.), Factory Information Systems in Electronics Production, Tampere University of Technology Press, 2010 (Chapter 11). [16] V. Marˇı´k, V. Vyatkin, A.W. Colombo (Eds.), Holonic and Multi-Agent Systems for Manufacturing. LNCS vol. 4659, Lecture Notes in Artificial Intelligence, Springer Verlag, 2007. [17] S. Bussmann, N. Jennnings, M. Wooldridge (Eds.), Multiagent Systems for Manufacturing Control. A Design Methodology, Springer Verlag, 2004. [18] J.L.M. Lastra, A.W. Colombo, Engineering framework for agent-based manufacturing control, The International Journal of Intelligent Real-Time Automation, Engineering Applications of Artificial Intelligence 19 (6) (2000) 625–640. [19] Collaborative Manufacturing Management Strategies. ARC White Paper. Gorbach and Mick 2002. ARC Advisory Group. [20] Collaborative Automation: The Platform for Operational Excellence. ARC White Paper. Polsonetti 2003. ARC Advisory Group. [21] P. Leita˜o, A.W. Colombo, F. Restivo, ‘‘An approach to the formal specification of holonic control systems’’. Holonic and multi-agent systems for manufacturing, Lecture Notes in Computer Science 2744 (2003) 1090, http://dx.doi.org/10.1007/ 978-3-540-45185-3_6. [22] R. Harrison, A.W. Colombo, Collaborative automation from rigid coupling towards dynamic reconfigurable production systems, in: Proceedings of the 16th IFAC World Congress, vol. 16 (1), 2005, p. 1570. [23] G. Caˆndido, A.W. Colombo, J. Barata, F. Jammes, Service-oriented infrastructure to support the deployment of evolvable production systems, IEEE Transaction on Industrial Informatics 7 (November (4)) (2011) 759–767. [24] M.J.J.M. Mendes, P. Leita˜o, F. Restivo, A.W. Colombo, A. Bepperling, Engineering of service-oriented automation systems: a survey, International Journal of Digital Manufacturing 1 (1) (2008) 33–38. [25] M. Taisch, A.W. Colombo, S. Karnouskos, A. Cannata, in: M. Taisch, A.W. Colombo (Eds.), SOCRADES Roadmap: An Executive Summary, EU Press, 2009. [26] A.W. Colombo, S. Karnouskos, Towards the factory of the future: a serviceoriented cross-layer infrastructure, in: The European Telecommunications Standards Institute (ETSI) Book on: ‘‘ICT Shaping The World – A Scientific View’’, John Wiley and Sons, 2009 April (Chapter 6). [27] S. Karnouskos, A.W. Colombo, Architecting the next generation of servicebased SCADA/DCS system of systems, in: Proc. of the 37th IEEE Annual Conf. on Industrial Electronics (IECON’11), Melbourne, Australia, 7–10 November, 2011. [28] J. Jens Eliasson, R. Kyuasakov, J. Delsing, J. Nessaether, A.W. Colombo, F. Jammes, S. Karnouskos, C. Diedrich, A migration approach to a SOA-based architecture for next generation process control and monitoring, in: Proc. of the 37th IEEE Annual Conf. on Industrial Electronics (IECON’11), Melbourne, Australia, 7–10 November, 2011.
[29] A.W. Colombo, J. Delsing, S. Karnouskos, New automation and control paradigms for the supervision of very large process industrial systems, in: Special Session, Proc. of the 37th IEEE Annual Conf. on Industrial Electronics (IECON’11), Melbourne, Australia, 7–10 November, 2011. [30] L. Zhang, H. Guo, F. Tao, Y.L. Luo, N. Si, Flexible management of resource service composition in cloud manufacturing, in: IEEE Int. Conf. on Industrial Engineering and Engineering Management (IEEM), 7–10 December, (2010), pp. 2278– 2282. [31] Idoughi, M. Kerkar, C. Kolski, Towards new web services based supervisory systems in complex industrial organizations: basic principles and case study, Computers in Industry 61 (April) (2010) 235–249 [Online]. [32] http://www.mesa.org. [33] MESA International, MES Functionalities & MRP to MES Data Flow Possibilities, White Paper 2 (Pittsburgh: Manufacturing Execution Systems Assoc., 1997). [34] MESA International, MES Explained: A High Level Vision, White Paper 6 (Pittsburgh: Manufacturing Execution Systems Assoc., 1997). [35] M. Benaissa, A. Benabdelhafid, The integration of the supervision in the MES environment within the framework of the Extended Enterprise, in: A. Verbraeck, W. Krug (Eds.), Proc. 14th European Simulation Symposium, (c) SCS Europe BVBA, 2002. [36] Supervisory Control and Data Acquisition (SCADA) Systems. National Communications System (NCS), Technical Information Bulletin 04-1, Technical Report, October 2004. www.ncs.gov/. . ./tech_bulletins/2004/. [37] A.W. Colombo, R. Harrison, Modular and collaborative automation: achieving manufacturing flexibility and reconfigurability, International Journal of Manufacturing Technology and Management 14 (3/4) (2008) 249–265 (Inderscience Publishers). [38] R. Harrison, A.W. Colombo, A.A. West, S.M. Lee, Reconfigurable modular automation systems for automotive power-train manufacture, International Journal of Flexible Manufacturing Systems, Springer 18 (2006) 175–190. , http://dx.doi.org/ 10.1007/s10696-006-9008-y. [39] V. Malhotra, T. Raj, A. Arora, Reconfigurable manufacturing system: an overview, International Journal of Machine Intelligence 1 (2) (2009) 38–46. [40] A.I. Dashchenko (Ed.), Reconfigurable Manufacturing Systems and Transformable Factories, Springer, 2006. [41] H.A. ElMaraghy (Ed.), Changeable and Reconfigurable Manufacturing Systems, Springer Series in Advanced Manufacturing, 2009. [42] P. Kennedy, V. Bapat, P. Kurchina, In Pursuit of the Perfect Plant, Evolved Technologist, 2008. [43] J. Sztipanovits, J. Pereira, Industrial challenges in cyber-physical systems, in: 1st Int. Conf. on Cyber-Physical Systems (ICCPS 2010), April, 2010. [44] M. Jamshidi (Ed.), Systems of Systems Engineering. plus 0.5em minus 04em, November, CRC Press, 2008. [45] G. Lewis, E. Morris, P. Place, S. Simanta, D. Smith, L. Wrage, Engineering systems of systems, in: IEEE Int. Systems Conference (SySCon 2008), 7–10 April, 2008. [46] S. Simanta, E. Morris, G. Lewis, D. Smith, Engineering lessons for systems of systems learned from service-oriented systems, in: IEEE Int. Systems Conf. (SySCon 2010), 5–8 April, 2010. [47] A.W. Colombo, S. Karnouskos, J. Delsing, Learning from SoA-based principles to engineering large industrial systems of systems, in: Notes of the Complex Systems Engineering to Systems-of-Systems Workshop, July, European Commission, Brussels, Belgium, 2011. [48] J.M. Mendes, F. Restivo, P. Leitao, A.W. Colombo, Petri net based engineering and software methodology for service-oriented industrial automation, Emerging Trends in Technological Innovation, IFIP Advances in Information and Communication Technology, vol. 314, Springer, Boston, 2010, pp. 233–240. [49] J.M. Mendes, P. Leita˜o, F. Restivo, A.W. Colombo, High-level Petri nets for the process description and control in service-oriented manufacturing systems, International Journal of Production Research (May) (2011) (Manuscript ID: 575892, Taylor & Francis). [50] G.A. Rathwell, Design of Enterprise Architectures (see http://pera.net/Levels. html). [51] T. Williams, H. Li, PERA and GERAM – enterprise reference architectures in enterprise integration, in: J. Mills, F. Kimura (Eds.), Information Infrastructure Systems for Manufacturing II, IFIP, Published by Kluwer Academic Publishers, 1998. [52] M.J. Mendes, P. Leita˜o, A.W. Colombo, F. Restivo, Service-oriented control architecture for reconfigurable production systems, in: Proc. of the 6th IEEE Int. Conf. on Industrial Informatics (INDIN’2008), 2008, 744–749. [53] K. Feldmann, A.W. Colombo, Material flow and control sequence specification of flexible production systems using coloured Petri nets, The International Journal of Advanced Manufacturing Technology 14 (10) (1998) 760–774. [54] H. Panetto, A. Molina, Enterprise integration and interoperability in manufacturing systems: trends and issues, Computers in Industry 59 (September (7)) (2008) 641–646. [55] J.-Y. Chung, K.-Y. Lin, R. Mathieu, Web services computing––advancing software interoperability (Guest Editor’s Introduction), IEEE Computer 36 (October (10)) (2003) 35–37. [56] M.D. Dikaiakos, D. Katsaros, P. Mehra, G. Pallis, A. Vakali, Cloud computing: distributed Internet computing for IT and scientific research, IEEE Journal on Internet Computing 13 (October (5)) (2009) 10–13.
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823 Kevin Nagorny (M.Eng., 25), Research-Assistant at the University of Applied Sciences Emden-Leer. He studied Electrical and Automation Technology (B.Eng., 2009) at the University of Applied Sciences Emden-Leer (Germany), with a specific focus on technical computer science. After that he studied Industrial Informatics (M.Eng., 2011) at the University of Applied Sciences Emden-Leer (Germany) with a special focus to manufacturing systems. During and in between his studies, he worked as research assistant in the area of manufacturing (based on multi-agent technologies and service-oriented architectures but also on conventional systems) as concept and software developer. After his studies, he started work to continue a specializing in the manufacturing area. Armando Walter Colombo (Prof. Dr.-Ing., 52) joined the Department of Electrotechnic and Industrial Informatics at the University of Applied Sciences EmdenLeer, Germany, and became Full Professor in August 2010. He is also Edison Level 2 Group Senior Expert and Program Manager at Schneider Electric. He received the M.Sc. on Control System Engineering from the National University of San Juan, Argentina, in 1994, and the Doctor degree in Engineering from the University of Erlangen-Nuremberg, Germany, in 1998. He is a Senior Member of the IEEE and member of the Gesellschaftfu¨rInformatike.V. He has served/serves as Associated Editor of the IEEE Transactions on Industrial Informatics, IEEE Transactions on Automation Systems Engineering (IEEE T-ASE) and Associated Editor of the IFAC Associated Journal ATP-International.
823
Prof. Colombo is the co-leader of the ARTEMIS (European Embedded Systems Platform) Strategic Research Agenda - Sub-Program ASP4. Prof. Colombo is listed in Who’s Who in the World/Engineering 99-00/01 and in Outstanding People of the XX Century (Bibliographic Centre Cambridge, UK). Prof. Dr. rer. nat. Uwe Schmidtmann studied mathematics and physics at the Universities Clausthal and Go¨ttingen. In 1976 he received his Doctor degree in Applied Mathematics from the University of Go¨ttingen. From 1972 to 1978 he worked as an assistant at the University of Go¨ttingen and Frankfurt. From 1978 to 1985 he gained extensive practical experience in telecommunication systems as he worked for Telefonbau und Normalzeit (Frankfurt). Since 1985 he hold the position of a professor at the University of Applied Sciences Emden-Leer. His subject areas are operating systems, real-time systems and robotik. Dr. Schmidtmann is a director of the research Institut I2AR and has extensive experience in managing research projects in the field of flexible automation systems Real-Time Distributed Virtual Machine (RT-DVM, AGIP/EFRE-2002, 2002-2004), Digital Manufacturing – ‘‘Integration der CAD-PlattformePlan/LOGOCAD in die Automatisierungsplattform ems-drd und Entwicklungeiner Simulations- und Visualisierungsplattform’’ (ems-presenter, AGIP/EFRE-2004, 2004-2006), special research group ‘‘Applications of Cluster Computing’’, (Volkswagen-Stiftung ZN1770, 20042010) and collaborative systems ‘‘LeichtkonfigurierbarekollaborativeSysteme’’ (LK3S, BMBF FKZ-1717A07, 1004-2010). Dr. Schmidtmann is a long-time member of ACM (Association of Computing Machinery), GI (Gesellschaftfu¨rInformatik), GAMM (Gesellschaftfu¨rAngewandteMathematik und Mechanik) and IEEE (Institute of Electrical and Electronics Engineers). He participate in exploration of new agent platforms for reconfigurable, collaborative automation systems organized by IEEEIES TCIA (Technical Committee on Industrial Agents) and VDE/VDMA-FA 5.15.
Contents lists available at SciVerse ScienceDirect
Computers in Industry journal homepage: www.elsevier.com/locate/compind
A service- and multi-agent-oriented manufacturing automation architecture An IEC 62264 level 2 compliant implementation Kevin Nagorny a,*, Armando Walter Colombo b,a,1, Uwe Schmidtmann a,2 a b
University of Applied Sciences, Emden/Leer, Constantiaplatz 4, D-26723 Emden, Germany Schneider Electric, Germany
A R T I C L E I N F O
A B S T R A C T
Article history: Received 28 January 2012 Received in revised form 20 July 2012 Accepted 1 August 2012 Available online 27 August 2012
This paper describes an approach for developing and implementing a service- and multi-agent-oriented manufacturing automation architecture, being particularly focused on functional features of the IEC 62264 L2 standard. The proposed SoA architecture facilitates managing and controlling networked smart automation components in a distributed manufacturing environment. The services, generated and exposed by automation components located on the levels 1 and 2 of the ISA’95-compliant enterprise architecture, are essential part of an ‘‘Automation Service Cloud’’, which is the result of the virtualization of the physical production environment. Moreover, these services can be accessed, requested and used by other components of these and upper levels, i.e., MES (Manufacturing Executing System) distributed components like a collaborative multi-agent-based manufacturing scheduling and dispatching system. Using the main characteristics of the service-orientation, the automation services can be composed and orchestrated in the cloud, creating emergent behaviors, which is a direct result of the virtualization, i.e., transforming the mechatronics/production layout into an automatically collaborative network. ß 2012 Elsevier B.V. All rights reserved.
Keywords: Service-oriented architecture Formal methods for industrial control systems Service orchestration Intelligent warehouse Interoperability in manufacturing automation
1. Introduction This paper describes an approach to realize a ‘‘Service- and Multi-agent-oriented’’, collaborative industrial manufacturing automation architecture, oriented to support structural connectivity and functional interoperability among devices and systems across a customizable Service-oriented enterprise architecture. From the functional point of view and taking into account standard enterprise architectures [15,50,51], the addressed architecture follows the level 2 designation of the ISA’95/IEC 62264 [7,14]. There are two major aspects that have been taken into account when the proposed architecture was initially designed and specified, one of these aspects is related to the necessity of structural (information, communication and control) connectivity among components inside a manufacturing environment. The other one addressed the functional interoperability (information exchange about management, control and supervision, among other functions) infrastructure behind the first one. The continued increasing demand for customized and sometimes extreme customized products (one product for each
* Corresponding author. Tel.: +49 4921 807 1955. E-mail addresses: [email protected], [email protected] (K. Nagorny), [email protected] (A.W. Colombo), [email protected] (U. Schmidtmann). 1 Tel.: +49 4921 807 1972. 2 Tel.: +49 4921 807 1833. 0166-3615/$ – see front matter ß 2012 Elsevier B.V. All rights reserved. http://dx.doi.org/10.1016/j.compind.2012.08.003
customer), for products, which are getting more and more complex and multifunctional and multi-application domain, derivate into shorter changeover times and product life cycles. This trend is also generating a continued transformation of the production environment, which evolved in a few couple of years from mass production to mass or extreme customization. This means, on one side, the increasing demand for continuously new products, following in same way the mode, requires a tremendous increase of efficiency and quality in the manufacturing process. As a direct consequence, conventional manufacturing structures are coming up to their limits, when customization is highly required [26,42,52] On the other side, the market and production trends cannot be sustained by continuing using current manufacturing structures, mainly based on sequential and line-oriented and hard-connected mechatronic layouts and hierarchical management and control systems. The trend can only be followed if the factory, the manufacturing system and its management and automation systems are enough ‘‘flexible’’ and ‘‘reconfigurable’’ [4,26,37–41]. Addressing specifically the management and automation issues associated to flexible and reconfigurable production systems addressed before, scientists and practitioners that work with conventional industrial implementations, are mainly following structures that follow the standard ISA-95 [6,7,13,14]. They are hierarchical built, which keep on splitting orders of the higher levels and pass these on to the lower layers. In a similar way, data acquisition, information processing and monitoring are also bottom-up hierarchical implemented. On that account no layer
814
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
is allowed to be left out because every level fulfills a certain task which is fitted to the next one. Business applications are executed in the layer on top (Enterprise Resource Planning [ERP]), below that the data (e.g. orders), which is passed on by the business layer, is scheduled and a production plan is created out of it (Manufacturing Executing System [MES] [31–35]). The production plan is handled on this level. Orders are split into many subtasks which are handled by different manufacturing cells (Supervisory Control and Data Acquisition [SCADA]) [5,27,36]. This generates some production sequences out of the subtasks which are executed by the controlling level. Information about the running production is collected bottom-up. Technically spoken, it is very difficult if not impossible to create a connection between the business layer and the production layer on the bottom (shop floor), because they are mainly based on different interfaces and technologies, both from communication but also information processing and control viewpoints. Summarizing both aspects, it is possible to identify the following set of restrictions that new automation architecture should address, both from logical and physical viewpoints [9,11,12]: Note: Structural/physical restrictions are identified by [P] and logical by [L]. P If a machine in the production line breaks down, the whole line has to be stopped. P High changeover times are a reason for the interruption of the production. P The workflow in line structures is dictated by the slowest machine. P Production units in the lines, which depend on each other, have to be equipped with buffers because of the different cycle times. P Flexible routing is not possible in conventional production lines and therefore, if redundant machines are part of the shop floor, they cannot directly be reached when another one breaks down. P&L It is difficult to extend production lines in a reasonable time and with controllable investment. L Due to hard and hierarchical linked control and automation programs, a dynamic reconfigurable layout and flexible and sometimes agile behaviors are not possible. L Information can only be exchanged between neighbor layers and many times using gateways to facilitate connectivity and interoperability. By analyzing latest research results, new innovative prototypes solving some of the issues addressed above, e.g., facilitating crosslayer connectivity and necessary interoperability among components located in different ISA’95 levels, have been reported e.g. (http://www.socrades.eu, [2,3,23–25], http://www.imc-aesop.eu, [27–29,54,55]). The Service-oriented Architecture proposed in this paper facilitates managing and controlling networked smart automation components in a distributed manufacturing environment, addressing the P and L restrictions and requirements. Following the SoAprinciples, manufacturing automation components are extended in their structures and functionalities by a web-service interface. This extension transform the component in a ‘‘Service, i.e., Client and Server’’, able to expose and or consume, to compose, to orchestrate web services inside the architecture [30]. The mechatronics/production layout has then be transformed into a collaborative network of operators [19,20,22,37]. Basically, the services, generated and exposed by the operators, automation components located on the levels 1 and 2 of the ISA’95compliant enterprise architecture, are essential part of an ‘‘Automation Service Cloud’’, which is the result of the virtualization of the physical production environment, i.e., the technological
formalization of the shop floor components as essential part of a Cyber-Physical System [30,43,47]. Moreover, these services can be accessed, requested and used by other components of these and upper levels, i.e., MES distributed components like a collaborative multi-agent-based manufacturing scheduling and dispatching system [16–18]. So for example, using the main characteristics of the service-orientation, the automation services can be composed and orchestrated in a Service Cloud [28]. As one of the major results of that composition and orchestration, new emergent behaviors are created and new properties and functions (not presented by the components itself) start being exposed by the whole production system-of-mechatronics-, control-, communication- and information processing-systems. The virtualization allows considering the manufacturing environment as a Systemof-Systems [24,30,44–46]. Section 2 overviews the major characteristics of a collaborative SoA-based manufacturing system and describes the major requirements for collaborative, reconfigurable automation architecture. Section 2 describes the characteristics of a SoA-based layered automation architecture mapped into the ISA’95 control hierarchy levels. Section 3 describes the major specifications of the components and functions located on the ISA’95 level 2, which are physical and logic represented in the Operator Layer of the architecture addressed in the section before, including a first description of the interfaces to the ISA’95 upper L3 and L4, and lower L0 and L1 levels. Section 4 presents a brief description of an implemented prototype in an industrial application scenario and Section 5 summarizes the paper and outlooks possible future works. 2. A Service-oriented ISA’95 architecture A Service-oriented automation architecture, following the basic ISA’95 specifications, is hierarchically built, BUT it has to facilitate in both, inside each layer but also cross-layer, structural connectivity and functional interoperability among the components. Fig. 1 (from [14]), shows the traditional hierarchical Control ISA’95 topology, mainly from Information Technology viewpoint, composed of 4 levels (see also [13] and the references here in). As depicted in Fig. 2, the architecture proposed in this work, called ‘‘Operator 2.0’’ is mainly composed of 5 physical layers, which are directly mapped to or composition from some of the physical components and functions identified in the levels of the standard shown in Fig. 1. The Hardware- and Stub Layers in Fig. 2 should be positioned on the ISA’95 level 1 of Fig. 1. The Operator Layer is containing functional and architectural components that should be positioned on the ISA’95 level 2. The layer identified with the Agent label in Fig. 2 represents mainly Scheduling and Dispatching functions and components, which are typically physical and logic functions and components located on the ISA’95 level 3, particularly those associated to Manufacturing Execution Systems (MES). Finally, the ERP (Enterprise Resource Planning) Layer of Fig. 2 corresponds physical and logically to the ISA’95 level 4. An important difference between the architecture depicted in Fig. 1 and the architecture shown in Fig. 2, one of the major outcomes of the work reported in his paper, is that Operator 2.0 use a unique ‘‘communication network’’ across the whole architecture, from the Stub Layer up. This fact, identified by red arrows showing the interfaces between neighbor layers, is facilitated by using a common Ethernet-based technology. Note: This is only possible on the Hardware Layer when heterogeneous mechatronics components are wrapped (see Section 4 for more explanations). The rest of this paper focuses on the major specifications and characteristics of components and functions located on the ISA’95 L2, modeled and exposed as ‘‘Services’’ inside the layer 2 of
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
815
3.2. Stub Layer (Level 1) This layer is above the Hardware Layer and includes stubs which are from the functional point of view wrappers for the components of a manufacturing system. The stubs convert proprietary interfaces into a unified protocol. If e.g. the controller of an industrial robot needs to be linked to a web-service, complications can occur in the segment of protocols which are usually proprietary protocols. Therefore a stub is developed for every component of the manufacturing system. The stub is responsible for the adherence of all original specifications of the component and it externally provides a Unified Interface. This interface makes it possible that every component of the same type, regardless of the provider, can be reached with the same protocol. A major requirement for the stub is that it should be running in a real-time operating system and should keep on respecting and following the hardware specifications. Note: A more extended specification and description of the stubs is out of the scope of this paper (see [1]).
Fig. 1. ISA’95 control hierarchy [14].
Operator 2.0, and the interfaces to the upper (L3) and lower (L1-L0) levels. 3. A Service-oriented ISA’95 L2 architecture After a brief overview about the Hardware and Stub Layers of the architecture Operator 2.0, this section explain the most important features and characteristics that have been specified and implemented in the Operator Layer (mapped into the ISA’95 L2/designation IEC 62264 of the architecture shown in Fig. 2). 3.1. Hardware Layer (Level 0-1) The Hardware Layer shows random components with proprietary interfaces which could be used in the manufacturing process (PLCs, IPCs, frequency converter, etc.).
3.3. Operator Layer (Level 2) The Operator Layer shown in Fig. 2 is a service-based multilayer structure responsible for virtualizing hardware components and exposing their functionalities as ‘‘Services’’. This means, the operators make it possible, to transform the shop floor components represented in the Stub Layer into a Service-oriented component inside an Information Infrastructure at the possible highest abstraction degree. The existence of many different Operators offer the possibility to cover different automation and control functions that are typically part of the ISA’95 L2, like Monitoring, Control, SCADA, etc. Following this form of thinking, the Operator Layer will allow populating an Automation Service Cloud [28], i.e., automation functions exposed as web services, as the major result of the ‘‘Virtualization’’ addressed above. Moreover, following the major
Fig. 2. Operator architecture – Operator 2.0.
816
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
characteristics of a typical SoA-Infrastructure, composition and orchestration of services, will also be implemented by such Operators, allowing the virtualized shop floor for exposing Emergent behaviors and functions not initially contained in the manufacturing components, e.g., simulation, energy efficient management, etc. Remark: A first brief explanation of the reasons for such a virtualization and particularly a first approach for migrating ISA’95-compliant architectures into a SoA-based infrastructure can be found in [28]. The specification and implementation of Operator 2.0 is one possible way to start performing this migration. The Operator Layer itself is subdivided into various sub layers, which will be described in the following sub-sections.
3.3.1. Control-sub layer A direct communication between the Stub Layer and the Operator Layer takes place in the Control-sub layer. For this communication, the operator uses the protocol that has been unified through the stub. Therefore the operators use the unified protocol to communicate with all stubs. The Control-sub layer does not possess a dynamic behavior. But it is possible to define blocks of sequence (macros), which are executed each time that they are called/requested. Fig. 3 presents an example of those macros. Note: These macros can be described in a static configuration file or can be generate by the higher sub layers over the Control-sub layer interface during running time. As depicted in Fig. 2, the Control- and Model based-sub layers of the Operator Layer are vertically divided into segments. These segments represent the existence of two or more automation/ mechatronics devices/components on the shop floor. Moreover, the existence of two or more segments implies the existence of two or more Stubs. Following this logic structure, an operator can add various different hardware components and using the ‘‘Operator 2.0’’, it can offer the functionalities of those devices as services. In order to better clarify the importance of this vertical separation of sub layers, a small example is explained bellow. A device at the shop floor needs to be extended by an additional component/unit (complementary device) dedicated to perform energy measurement. This additional component will be linked to an operator associated to the device, located on the Operator Layer. It is addressed by a separate control instance and can give data of the current energy consumption, exposed as ‘‘service’’. Fig. 4 shows the part of the configuration file where many of these devices can be linked to one operator. 3.3.2. Model based interface-sub layer The sub layer ‘‘Model based interface’’ defines the procedure and identifies reachable states of a virtualized component. The following standard situation derived from functional aspects of the architecture gives the major reasons for implementing a Model-based Interface-sub layer. Due to the separation of the Service-sub layer and the Control-sub layer a chaotic communication with the hardware is foreseen. A failure mode can be set back in another defined state by a maintenance service in which errors are solved and an error-free state is recapitulated by the Model based-sub layer. Thereby the chosen model must support the communication with the basic services (s. Service-sub layer). As a result of the composition or orchestration of services facilitated by the ‘‘model based interface’’, functions like e.g. remote maintenance, which were not present in the automation system, can now by located in the Cloud and become possible as long as no manual interference is needed. Different algorithms can be used to control the hardware in this sub layer (e.g. a Dijkstra algorithm for the routing of pallets by a flexible transport system) [10], or formal methods like e.g. Highlevel Petri Nets (HLPN) [8].
Fig. 3. Macro in the Control-sub layer described in a configuration file.
In the last case, enabling and firing conditions of transitions in the HLPN model are connected with physical mechatronics units like sensors and actuators. Another useful modeling alternative is that transitions and places of the HLPN are linked to methods associated to ‘‘Services’’ (see Fig. 5) [48,49]. 3.3.3. Service-sub layer Generally spoken, all services in the Service-sub layer are modular. With JIT-compilers (just in time) it is possible to reload services (dynamic deployment) in running time. Operators do not have to be restarted to renew or add services to the component. Practically this possibility is decisive to guarantee a production flow without any interruptions. Moreover, services can be used by the pull-principle, what can also be event-based. Therefore clients can subscribe an event associated to a service. If the subscribed event occurs, the registered client will be informed. In contrary to the conventional pull-principle the network does not get overloaded with overhead. The Service-sub layer includes three different types of services: ‘‘Basic-’’, the ‘‘Special-’’ and the ‘‘Optional-’’ Services. Basic services are always provided by an operator, e.g., industrial components with sensors and actuators always need the following three basic services control, monitoring and maintenance. The second service type provides further functions. This can be a service for the simulation of the component for example or can be an energy management service which can monitor, control the energy consumption.
Fig. 4. Configuration file for many devices linked to one operator.
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
The third type of services is represented by the ‘‘Optional Units’’. Depending on the model used on the ‘‘Model based interface’’-sub layer conflicts can appear which have to be solved by intelligent units in higher layers. For this case, the unit ‘‘Conflict Manager’’ is used. The ‘‘Model based interface’’-sub layer can be connected with another operator by using formal methods like High-Level Petri Nets (HLPN). For this purpose the unit ‘‘Global Binder’’ can be used. The unit ‘‘Orchestrator’’ can be used for a collaboration with different operators (different hardware types and different models on the ‘‘Model based interface’’-sub layer). The following sub-sections explain more deeply the functionality of some of the ‘‘Optional Units’’ and how they are related to e.g., the formalization behind the model-based interface. 3.3.3.1. Utilization of the optional unit ‘‘Global Binder’’ and ‘‘Conflict Manager’’. The ‘‘Global Binder’’ is responsible for the collaboration of various operators of the same type by linking the used formal method with the same formal method of another operator. There are two possibilities. One possibility is a manual link via a static configuration, in which the address of the operator, which has to be linked and the local-/global linking points, are described. This type of linking should especially be used when different hardware types are linked because in that case links depend on the individual component. Similar modules, which set up an ad-hoc connection by using embedded systems (see Fig. 3), are able to create a system of systems together which can logically be linked by algorithms. Fig. 6 shows a transport system in which each module possesses a hardware interface which established an ad-hoc connection by connecting with another module. Decisive Identifications IDs (e.g. Media Access Control MAC-addresses) and information are exchanged via the connection described before to identify their
817
neighbors. Now each local ‘‘Global Binder’’ connects the right interfaces of the model used in the ‘‘Model based interface’’-sub layer via an algorithm to create a module cluster. The linking interfaces are the transitions when regarding an HLPN. The ‘‘Conflict Manager’’ always has to be instanced when conflicts among, e.g., shared resources appear in the Cloud, formalized by conflicts among transitions in the HLPN-based model. A typical conflict situation on a manufacturing environment appears for example when a pallet on a transport system module can be further transferred to another module located to the left or to the right direction. This conflict is collected, virtualized and processed by the ‘‘Conflict Manager’’. When such a conflict arises intelligent units responsible for scheduling, dispatching or similar manufacturing execution functions are required, so that a right decision concerning the ongoing procedure can be done. Note: The ‘‘Model based interface’’-sub layer must determine the power of decision of the operator. 3.3.3.2. Utilization of the of the optional unit ‘‘Orchestrator’’. The ‘‘Orchestrator’’ is itself a ‘‘Service’’, able to link operators on the Service Cloud. It fulfills its functionality by composing services exposed by other operators. The composition of different service types like e.g. the composition of a high rack warehouse with a transport system-service can lead to a service which brings certain material to a certain place (only one order is needed). Furthermore one advantage of the orchestration on the Service Cloud is that orchestrators can function as unique programs executed on a high performance industrial PC (IPC) having complex links of many operators. 3.3.4. Interface and registration-sub layer Via the Configfile it is determined which services are populating the Cloud. All services, which should be loaded, are being instantiated and then they are registered in a local administration module of this sub layer. All services are reachable by an internal program via local IDs. The service is externally provided by its Name, which is embedded in the Uniform Resource Identifier (URI)formatted operator address. The methods associated to a service are managed internally by service-instances. URI-addresses are passed on to the service instances where they can be further managed. This sub layer manages clients (agents, operators and orchestrators), which call up the ordered services or link with ‘‘Optional Units’’ via the local administration. The operator registers as a client at a global administration level, which represents the function of ‘‘yellow-pages’’ to find services. In that case the global administration advices which component is the one signaling (which can only proceed via a definite ID). Furthermore the global administration advices which services are provided by the operator. The client can request the global administration to receive the address of a certain service. If a registered service is suitable the contact data is given back. Integration of ISA’95 L3 and L4 with the L2 of Operator 2.0 Agent Layer (level 3) Above the Operator Layer representing mainly components and functions of the ISA’95 L2, the Operator 2.0 architecture proposes the use of a Multi-agent-based system offering Scheduling, Dispatching and other Manufacturing Execution System operations/functions [16–18,21]. The main characteristics and specifications of this layer are objective of a future report. Nevertheless, it is important to recall here that operators and agents are integrated into one unified network. Fig. 7 shows the ‘‘Operator 2.0’’ architecture as a Cloud of ‘‘Services’’. All components in the Cloud are reachable because they belong to a unified network, independent of the physical position but facilitating a cross-layer collaboration. Analyzing in a deeply manner the structural relationship among the components of the architecture (virtualized in the Cloud), each hardware component
818
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
Fig. 6. Automatic graph generation with the use of physical ad-hoc connections explaining a possible use for the Global Binder.
is connected to a Stub which is converting the proprietary protocol to a unified symbolic language in a real-time environment. One or more Stubs are connected with one Operator which is able to expose the hardware features/characteristics and other functionalities as ‘‘Services’’ in the Service Cloud. The different operators are able to collaborate in two different manners, on one side using the model interface when they are using the same model and on the other side, by composition and other relationships among the services located in the Service Cloud. Independent Orchestrators in the Service Cloud, or Orchestrators that are included in Operators as Optional Unit, are able to orchestrate two or more ‘‘Services’’. As explained before, in the ISA’95 L3 are used intelligent agents, which are offering functions of a conventional Manufacturing Execution System (MES) like dispatching and scheduling. The addressed MES functionalities result from negotiations and collaborations among different agents. In this manner, production orders and scheduling re-scheduling decisions that result from those negotiations will be executed by the Operators and Orchestrators. 3.3.5. ERP Layer (level 4) At the top-level ISA’95 L4 is working an ERP-system which provides the interface to the Service Cloud and the Human Interface.
In the current implementation the ERP-system provides mainly functionalities to generate orders or get status information about the factory. 4. Prototype implementation 4.1. Prototype architecture ‘‘Operator 2.0’’ is being implemented in a prototype manner, following the schema depicted in Fig. 8. At the bottom is the Hardware Layer, which is technologically spoken ‘‘heterogeneous’’, mainly composed by industrial automation, mechatronics and production components, i.e., PLCs, I/O devices, Robot Controls, etc. All these components are having proprietary information-communication-control protocols and mainly unable to interoperate. This interoperability problem is talked by wrapping the components with the Stubs on the Stub Layer, using a unified protocol. Technically spoken, each component has to get a Stub for the unification. The Operator on the next upper layer use this unified protocol to control the hardware. The first major result of the implementation of the Stubs is the easy integration of Legacy Systems.
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
819
model, to be a part of the control logic or to perform e.g. modelbased monitoring or other supervisory control functionalities. The geometric symbols on the top of the Operator Layer in Fig. 8 represent the Service-Interface inside the Service Cloud. In this environment are the Agents and the interface to the ERP-system in the ERP Layer. 4.2. Use case application Application Scenario: Intelligent Warehouse/Distribution Center (e.g. Energy Efficient Automation of Warehouse and Material Flow Systems). 4.2.1. State-of-the-technic and state-of-the art
Fig. 7. Virtualization of a shop floor by Services in a Cloud.
On the hardware side at this layer, it is needed a gateway to unifying the communication network technology, for example, in the case that a component is providing only a Bus-interface, a gateway will facilitate the communication to the Ethernet network (basis technology of the Service Cloud). The unified protocols are used by the Operators on the Operator Layer. In Fig. 8 is possible to identify a HLPN as model of the shop floor (production hardware to be controlled, monitored, etc.). A major characteristic of this model is that it is connected over transitions with the Stubs. All the units and services inside the Operator Layer have the possibility to apply for a connection to the
- Currently Warehouse/Storage Systems are managed (monitored and controlled) in a centralized and rigid hierarchical manner. - Currently Warehouse/Storage Systems are managed following production specification requirements and not considering, e.g. Energy Consumption aspects. Two different systems not able to interoperate (Energy and Production Specifications belong to two orthogonal fields). - The exchange of information between warehouse and material flow, and manufacturing components, is performed using different communication protocols and information processing systems, when the warehouse is seeing as one of the components inside an ISA’95-compliant manufacturing enterprise architecture. Lack of structural but particularly functional interoperability. - Storage and material flow strategies are currently build to respond on a centralized and synchronous operation mode, generating strong requirements for commissioning functionalities and storage structure. - Manufacturing Execution System (MES) Functionalities associated to the Warehouse Storage and Material Flow Monitoring and Control are not direct technological linked to supervisory and
Fig. 8. Illustrate the use of the ‘‘Operator 2.0’’ architecture.
820
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
Fig. 9. Use of Operator 2.0 to integrate an ‘‘Intelligent Warehouse’’ into a SoA-based Enterprise Architecture.
control functions associated to the mechatronics components building the Warehouse and Material Flow Systems. 4.2.2. Progress beyond the state-of-art: addressing structural connectivity and functional interoperability Fig. 9 shows schematic the application of ‘‘Operator 2.0’’ to make feasible a cross layer connectivity and functional interoperability of an Intelligent Warehouse inside a SoA-based enterprise architecture. Warehouse as intelligent Module integrated into a Flexible Manufacturing Systems and able to structurally and functionally interact with the rest of modules following own and common goals. For example, ‘‘Energy Management-based Monitoring and Control’’ of Warehouse and Material Flow, integrated into the ISA’95 Enterprise Architecture. Warehouse as Mechatronic Module with Web Service-based ICCT (Information-Communication-Control-Technology) Interface (Wrapper), i.e., source of ‘‘Services’’ to be exposed and also capable of consuming ‘‘Services’’ exposed by other modules. Structural Connectivity and functional Interoperability of the Warehouse with other Devices and Systems inside the shop floor
and the whole ISA’95-compliant Enterprise Architecture, via Service Exposition, Service Consume, Service Orchestration and Multi-agent based negotiation. As a direct related-result to the characteristic addressed above, Warehouse and Material Flow functions exposed as Services (Intelligent Distribution Center as SoA-based Solution), which can be consumed, used by other components of the enterprise. Integration of the Warehouses into a Service-based Factory Cloud (see [56] and references therein), which is the result of the virtualization of the Flexible Manufacturing System. Remark: The Factory Cloud corresponds to the operator layer of the architecture shown in Fig. 2. 4.2.3. Real-world context, experiments and results - The Product to be manufactured generates the needs for transportation, production and storage and supply them associated to a unique-IP-Address, via web services inside an ISA’95-compliant enterprise architecture. - The Warehouse exposes its storage functionality as services inside the SoA-based enterprise architecture, being also identified by a unique IP-Address. Among others, component description,
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
-
-
-
-
location, main functions and structural characteristics are information contained in the set of services exposed via web technology inside an ISA’95-compliant enterprise architecture. Any mobile component, e.g., pallet that need to be stored is also exposing its characteristics, e.g., identification of product/part on it, work plan, etc. is also exposing those characteristics as services exposed via web technology inside an ISA’95-compliant enterprise architecture. Both, storage and pallets are now networked inside the SoAbased shop floor and the management and control of the material flow and storage functionalities are the result of composition/ orchestration of services. This orchestration function can be located in a centralized manner on Level 3 of the ISA’95 compliant enterprise architecture or being located embedded in the controllers/automation devices associated to the mechatronics components, i.e., pallet or warehouse, or deeper embedded into storage modules inside the warehouse. The warehouse is also built in a modular manner and each of its modules can also be separated and identified by an unique IPAddress and associated web services. Independent of the location and position of the Warehouse inside the enterprise architecture, it can be connected and can interoperate with any other component of the same architecture, being this communication done vie exposition, consumption, composition and/or orchestration of services.
Combining Energy Metering Services and Material Flow/ Storage Services will have big impact in generating energy efficient management and control strategies, which can be exposed as services and located anywhere in the service cloud behind the SoAcompliant ISA’95-architecture. As a direct result, just-in-time storage scheduling, customized local commissioning related to energy efficient processes is being performed. 4.2.4. Addressing sustainable interoperability, scalability, structural evolvability and emergent behaviors in the factory Next generation automation and control systems, like our ‘‘Operator 2.0’’, will stem upon an interoperable interconnection between service-, event- and knowledge-driven architectures implemented at the shop floor level, at the manufacturing execution level and at the enterprise applications level. Recent achievements in the three above research domains are being experimented and benchmarked in our real industrial settings to demonstrate their business benefits, not just from the economic viewpoint but in a more holistic technical sustainability sense. The ‘‘Operator 2.0’’ pillars respectively guarantee interoperability (both structural and functional) and scalability supported by the service-orientation and multi-agent negotiation. Due to the virtualization and abstraction of physical resources, modeling Factory tangible and intangible assets ‘‘as a Service’’, structural ‘‘Evolvability’’ like plug-in of new Mechatronic components or plug-out of dedicated systems is immediately translated into registration and exposition of ‘‘Services’’. Moreover, the capabilities offered by the Operator Layer, i.e., composition and orchestration of assets in complex aggregates and new manufacturing processes support the control and management of ‘‘Emergent’’ behaviors. This behaviors, not present in isolated components with autonomous behavior and self-management, result from the functional interoperability of the serviceoriented components in both inside the shop floor and cross-layer between the ISA’95 layers.
821
architecture, with major focused on functional aspects related to the ISA’95 Enterprise Architecture (IEC 62264 L2) standard. The proposed ‘‘Operator 2.0’’ architecture facilitates managing and controlling networked smart automation components in a distributed manufacturing environment. The services, generated and exposed by automation components located on the levels 1 and 2 of the ISA’95-compliant enterprise architecture, are essential part of an ‘‘Automation Service Cloud’’, which is the result of the virtualization of the physical production environment. The Layer 2 (Operator Layer) of the architecture is extended with a model-based interface. Using High-level Petri Nets (HLPN) as model of the shop floor (production hardware to be controlled, monitored, etc.), transitions and firing-modes of transitions have the possibility to be connected to wrappers (Stubs) located on the layer bellow (ISA’95 L1). All the units and services inside the Operator Layer have the possibility to apply for a connection to the model, to be a part of the control logic or to perform e.g. model-based monitoring or other supervisory control functionalities. The recent advent of Event-Driven Architectures (EDA), taking into account at the architectural level the ‘‘Event’’ concept and supporting suitable functionalities to collect, distribute and provide events to devices or services that need them, is conducting to an extension of the SoA paradigm with e.g., Complex Event Processing (CEP) capabilities. One of the future works planned in relation to Operator 2.0 is a more intensive research into the modeling and validation aspects associated the Event-driven characteristics of our Petri Net based orchestration inside the SoAbased architecture [53]. As a matter of fact, CEP is indirectly addressed by the Model-based interface of Operator 2.0. A Petri Net-based Service Orchestration/Composition behaves inherently in an Event-driven manner, supporting both a more heavily use of distributing processing and particularly an asynchronous processing and reasoning-based control, monitoring and management functionalities. The services located in the Automation Service Cloud can be accessed, requested and used by other components of these and upper levels, i.e., MES (Manufacturing Executing System) distributed components like a collaborative multi-agent-based manufacturing scheduling and dispatching system. Using the main characteristics of the service-orientation, the automation services can be composed and orchestrated in the Cloud, creating emergent behaviors, which is a direct result of the virtualization, i.e., transforming the mechatronics/production layout into an automatically collaborative network. The tests and application results of a first prototype implementation are promising. The distributed Service-oriented ‘‘Operator 2.0’’ architecture allows the virtualization of a shop floor, making feasible to proceed controlling, monitoring, etc. heterogeneous mechatronics components, all mapped into an Information Processing Cloud (Service Cloud). Further steps in the development of the architecture are among others, the integration of Engineering Tools, commercial MES and ERP systems. Moreover, having implemented and put the ‘‘Operator 2.0’’ in place, the creation of new category of Services increasing the degree of functional interoperability between more enterprise systems is foreseen, e.g., Energy Services, Simulation Services, ERP-Services structurally and functional linked to the Multi-agent layer, etc. Acknowledgments
5. Conclusion This paper describes the principal characteristics and features of a service-oriented control and production management
The authors would like to thank the partners of the EU FP7 IP IMC-AESOP project (www.imc-aesop.eu) and the members of the I2AR Institute (www.i2ar.de) for the fruitful discussions.
822
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823
References [1] U. Schmidtmann, G. Kreutz, M. Barkhoff, K. Virkus, T. Sto¨ckmann, M. Jovic, Microprogrammable hardware abstraction layer for flexible automation, in: IEEE ETFA’09, 22–25 September, (2009), pp. 1–7. [2] A. Cannata, M. Gerosa, M. Taisch, SOCRADES: A framework for developing intelligent systems in manufacturing, in: IEEE Industrial Engineering and Engineering Management IEEM 2008, 8–11 December, (2008), pp. 1904– 1908. [3] A.W. Colombo, SOCRADES: Steps Towards the Factory of the Future, Projects Magazine EU, British Publishers Inc. 12, 2009 pp. 20–23 http://viewer.zmags. com/publication/4c086127#/4c086127/1. [4] H.K. Shivanand, M.M.B.H.K.S.V. Koti, Flexible Manufacturing System, New Age International (P) Ltd, 2006. ¨ berwachung und Steuer[5] J. Lunze, Automatisierungstechnik: Methoden fu¨r die U ung kontinuierlicher und ereignisdiskreter Systeme, Oldenbourg, 2008. [6] M. Georgoudakis, C. Alexakos, A. Kalogeras, J. Gialelis, S. Koubias, Decentralized production control through ANSI/ISA-95 based ontology and agents, in: IEEE Int. Workshop on Factory Communication Systems, 2006, 374–379. [7] C. Alexakos, M. Georgoudakis, A. Kalogeras, K. Charatsis, J. Gialelis, S. Koubias, A model for the extension of IEC 62264 down to the shop floor layer, in: IEEE Int. Workshop on Factory Communication Systems, 2006, 243–246. [8] T. Murata, Petri nets: properties, analysis and applications, Proceedings of the IEEE 77 (April (4)) (1989) 541–580. [9] D.P. Garg, C.D. Poppe, Coordinated robots in a flexible manufacturing work cell, in: Proc. of the IEEE/ASME Int. Conf. on Advanced Intelligent Mechatronics, 2001. [10] B. Liu, S.-H. Choo, S.-L. Lok, S.-M. Leong, S.-C. Lee, F.-P. Poon, H.-H. Tan, Finding the shortest route using cases, knowledge, and Djikstra’s algorithm, IEEE Expert 9 (October (5)) (1994) 7–11. [11] A. Cichocki, Workflow and Process Automation: Concepts and Technology, Kluwer International Series in Engineering and Computer Science; Kluwer Academic Publishers, 1998. [12] A. Desrochers, Modelling and Control of Automated Manufacturing Systems, IEEE Computer Society Press 90, 1989. [13] THE WBF BOOK SERIES-APPLYING ISA 95. Implementation Experiences. Wbf Book Series, World Batch Forum, Wbf, Momentum Press, 2010. [14] D. Brandl, P. Owen, A Tutorial on the ANSI/ISA95 Enterprise/Control BR&L Consulting. www.brlconsulting.com/. . ./2003-09%20IEE%20. . . 6 January 2001 – Dennis Brandl Peter Owen. BR&L Consulting Eli Lilly & Co. 2. [15] I. Delamer, J.L.M. Lastra (Eds.), Factory Information Systems in Electronics Production, Tampere University of Technology Press, 2010 (Chapter 11). [16] V. Marˇı´k, V. Vyatkin, A.W. Colombo (Eds.), Holonic and Multi-Agent Systems for Manufacturing. LNCS vol. 4659, Lecture Notes in Artificial Intelligence, Springer Verlag, 2007. [17] S. Bussmann, N. Jennnings, M. Wooldridge (Eds.), Multiagent Systems for Manufacturing Control. A Design Methodology, Springer Verlag, 2004. [18] J.L.M. Lastra, A.W. Colombo, Engineering framework for agent-based manufacturing control, The International Journal of Intelligent Real-Time Automation, Engineering Applications of Artificial Intelligence 19 (6) (2000) 625–640. [19] Collaborative Manufacturing Management Strategies. ARC White Paper. Gorbach and Mick 2002. ARC Advisory Group. [20] Collaborative Automation: The Platform for Operational Excellence. ARC White Paper. Polsonetti 2003. ARC Advisory Group. [21] P. Leita˜o, A.W. Colombo, F. Restivo, ‘‘An approach to the formal specification of holonic control systems’’. Holonic and multi-agent systems for manufacturing, Lecture Notes in Computer Science 2744 (2003) 1090, http://dx.doi.org/10.1007/ 978-3-540-45185-3_6. [22] R. Harrison, A.W. Colombo, Collaborative automation from rigid coupling towards dynamic reconfigurable production systems, in: Proceedings of the 16th IFAC World Congress, vol. 16 (1), 2005, p. 1570. [23] G. Caˆndido, A.W. Colombo, J. Barata, F. Jammes, Service-oriented infrastructure to support the deployment of evolvable production systems, IEEE Transaction on Industrial Informatics 7 (November (4)) (2011) 759–767. [24] M.J.J.M. Mendes, P. Leita˜o, F. Restivo, A.W. Colombo, A. Bepperling, Engineering of service-oriented automation systems: a survey, International Journal of Digital Manufacturing 1 (1) (2008) 33–38. [25] M. Taisch, A.W. Colombo, S. Karnouskos, A. Cannata, in: M. Taisch, A.W. Colombo (Eds.), SOCRADES Roadmap: An Executive Summary, EU Press, 2009. [26] A.W. Colombo, S. Karnouskos, Towards the factory of the future: a serviceoriented cross-layer infrastructure, in: The European Telecommunications Standards Institute (ETSI) Book on: ‘‘ICT Shaping The World – A Scientific View’’, John Wiley and Sons, 2009 April (Chapter 6). [27] S. Karnouskos, A.W. Colombo, Architecting the next generation of servicebased SCADA/DCS system of systems, in: Proc. of the 37th IEEE Annual Conf. on Industrial Electronics (IECON’11), Melbourne, Australia, 7–10 November, 2011. [28] J. Jens Eliasson, R. Kyuasakov, J. Delsing, J. Nessaether, A.W. Colombo, F. Jammes, S. Karnouskos, C. Diedrich, A migration approach to a SOA-based architecture for next generation process control and monitoring, in: Proc. of the 37th IEEE Annual Conf. on Industrial Electronics (IECON’11), Melbourne, Australia, 7–10 November, 2011.
[29] A.W. Colombo, J. Delsing, S. Karnouskos, New automation and control paradigms for the supervision of very large process industrial systems, in: Special Session, Proc. of the 37th IEEE Annual Conf. on Industrial Electronics (IECON’11), Melbourne, Australia, 7–10 November, 2011. [30] L. Zhang, H. Guo, F. Tao, Y.L. Luo, N. Si, Flexible management of resource service composition in cloud manufacturing, in: IEEE Int. Conf. on Industrial Engineering and Engineering Management (IEEM), 7–10 December, (2010), pp. 2278– 2282. [31] Idoughi, M. Kerkar, C. Kolski, Towards new web services based supervisory systems in complex industrial organizations: basic principles and case study, Computers in Industry 61 (April) (2010) 235–249 [Online]. [32] http://www.mesa.org. [33] MESA International, MES Functionalities & MRP to MES Data Flow Possibilities, White Paper 2 (Pittsburgh: Manufacturing Execution Systems Assoc., 1997). [34] MESA International, MES Explained: A High Level Vision, White Paper 6 (Pittsburgh: Manufacturing Execution Systems Assoc., 1997). [35] M. Benaissa, A. Benabdelhafid, The integration of the supervision in the MES environment within the framework of the Extended Enterprise, in: A. Verbraeck, W. Krug (Eds.), Proc. 14th European Simulation Symposium, (c) SCS Europe BVBA, 2002. [36] Supervisory Control and Data Acquisition (SCADA) Systems. National Communications System (NCS), Technical Information Bulletin 04-1, Technical Report, October 2004. www.ncs.gov/. . ./tech_bulletins/2004/. [37] A.W. Colombo, R. Harrison, Modular and collaborative automation: achieving manufacturing flexibility and reconfigurability, International Journal of Manufacturing Technology and Management 14 (3/4) (2008) 249–265 (Inderscience Publishers). [38] R. Harrison, A.W. Colombo, A.A. West, S.M. Lee, Reconfigurable modular automation systems for automotive power-train manufacture, International Journal of Flexible Manufacturing Systems, Springer 18 (2006) 175–190. , http://dx.doi.org/ 10.1007/s10696-006-9008-y. [39] V. Malhotra, T. Raj, A. Arora, Reconfigurable manufacturing system: an overview, International Journal of Machine Intelligence 1 (2) (2009) 38–46. [40] A.I. Dashchenko (Ed.), Reconfigurable Manufacturing Systems and Transformable Factories, Springer, 2006. [41] H.A. ElMaraghy (Ed.), Changeable and Reconfigurable Manufacturing Systems, Springer Series in Advanced Manufacturing, 2009. [42] P. Kennedy, V. Bapat, P. Kurchina, In Pursuit of the Perfect Plant, Evolved Technologist, 2008. [43] J. Sztipanovits, J. Pereira, Industrial challenges in cyber-physical systems, in: 1st Int. Conf. on Cyber-Physical Systems (ICCPS 2010), April, 2010. [44] M. Jamshidi (Ed.), Systems of Systems Engineering. plus 0.5em minus 04em, November, CRC Press, 2008. [45] G. Lewis, E. Morris, P. Place, S. Simanta, D. Smith, L. Wrage, Engineering systems of systems, in: IEEE Int. Systems Conference (SySCon 2008), 7–10 April, 2008. [46] S. Simanta, E. Morris, G. Lewis, D. Smith, Engineering lessons for systems of systems learned from service-oriented systems, in: IEEE Int. Systems Conf. (SySCon 2010), 5–8 April, 2010. [47] A.W. Colombo, S. Karnouskos, J. Delsing, Learning from SoA-based principles to engineering large industrial systems of systems, in: Notes of the Complex Systems Engineering to Systems-of-Systems Workshop, July, European Commission, Brussels, Belgium, 2011. [48] J.M. Mendes, F. Restivo, P. Leitao, A.W. Colombo, Petri net based engineering and software methodology for service-oriented industrial automation, Emerging Trends in Technological Innovation, IFIP Advances in Information and Communication Technology, vol. 314, Springer, Boston, 2010, pp. 233–240. [49] J.M. Mendes, P. Leita˜o, F. Restivo, A.W. Colombo, High-level Petri nets for the process description and control in service-oriented manufacturing systems, International Journal of Production Research (May) (2011) (Manuscript ID: 575892, Taylor & Francis). [50] G.A. Rathwell, Design of Enterprise Architectures (see http://pera.net/Levels. html). [51] T. Williams, H. Li, PERA and GERAM – enterprise reference architectures in enterprise integration, in: J. Mills, F. Kimura (Eds.), Information Infrastructure Systems for Manufacturing II, IFIP, Published by Kluwer Academic Publishers, 1998. [52] M.J. Mendes, P. Leita˜o, A.W. Colombo, F. Restivo, Service-oriented control architecture for reconfigurable production systems, in: Proc. of the 6th IEEE Int. Conf. on Industrial Informatics (INDIN’2008), 2008, 744–749. [53] K. Feldmann, A.W. Colombo, Material flow and control sequence specification of flexible production systems using coloured Petri nets, The International Journal of Advanced Manufacturing Technology 14 (10) (1998) 760–774. [54] H. Panetto, A. Molina, Enterprise integration and interoperability in manufacturing systems: trends and issues, Computers in Industry 59 (September (7)) (2008) 641–646. [55] J.-Y. Chung, K.-Y. Lin, R. Mathieu, Web services computing––advancing software interoperability (Guest Editor’s Introduction), IEEE Computer 36 (October (10)) (2003) 35–37. [56] M.D. Dikaiakos, D. Katsaros, P. Mehra, G. Pallis, A. Vakali, Cloud computing: distributed Internet computing for IT and scientific research, IEEE Journal on Internet Computing 13 (October (5)) (2009) 10–13.
K. Nagorny et al. / Computers in Industry 63 (2012) 813–823 Kevin Nagorny (M.Eng., 25), Research-Assistant at the University of Applied Sciences Emden-Leer. He studied Electrical and Automation Technology (B.Eng., 2009) at the University of Applied Sciences Emden-Leer (Germany), with a specific focus on technical computer science. After that he studied Industrial Informatics (M.Eng., 2011) at the University of Applied Sciences Emden-Leer (Germany) with a special focus to manufacturing systems. During and in between his studies, he worked as research assistant in the area of manufacturing (based on multi-agent technologies and service-oriented architectures but also on conventional systems) as concept and software developer. After his studies, he started work to continue a specializing in the manufacturing area. Armando Walter Colombo (Prof. Dr.-Ing., 52) joined the Department of Electrotechnic and Industrial Informatics at the University of Applied Sciences EmdenLeer, Germany, and became Full Professor in August 2010. He is also Edison Level 2 Group Senior Expert and Program Manager at Schneider Electric. He received the M.Sc. on Control System Engineering from the National University of San Juan, Argentina, in 1994, and the Doctor degree in Engineering from the University of Erlangen-Nuremberg, Germany, in 1998. He is a Senior Member of the IEEE and member of the Gesellschaftfu¨rInformatike.V. He has served/serves as Associated Editor of the IEEE Transactions on Industrial Informatics, IEEE Transactions on Automation Systems Engineering (IEEE T-ASE) and Associated Editor of the IFAC Associated Journal ATP-International.
823
Prof. Colombo is the co-leader of the ARTEMIS (European Embedded Systems Platform) Strategic Research Agenda - Sub-Program ASP4. Prof. Colombo is listed in Who’s Who in the World/Engineering 99-00/01 and in Outstanding People of the XX Century (Bibliographic Centre Cambridge, UK). Prof. Dr. rer. nat. Uwe Schmidtmann studied mathematics and physics at the Universities Clausthal and Go¨ttingen. In 1976 he received his Doctor degree in Applied Mathematics from the University of Go¨ttingen. From 1972 to 1978 he worked as an assistant at the University of Go¨ttingen and Frankfurt. From 1978 to 1985 he gained extensive practical experience in telecommunication systems as he worked for Telefonbau und Normalzeit (Frankfurt). Since 1985 he hold the position of a professor at the University of Applied Sciences Emden-Leer. His subject areas are operating systems, real-time systems and robotik. Dr. Schmidtmann is a director of the research Institut I2AR and has extensive experience in managing research projects in the field of flexible automation systems Real-Time Distributed Virtual Machine (RT-DVM, AGIP/EFRE-2002, 2002-2004), Digital Manufacturing – ‘‘Integration der CAD-PlattformePlan/LOGOCAD in die Automatisierungsplattform ems-drd und Entwicklungeiner Simulations- und Visualisierungsplattform’’ (ems-presenter, AGIP/EFRE-2004, 2004-2006), special research group ‘‘Applications of Cluster Computing’’, (Volkswagen-Stiftung ZN1770, 20042010) and collaborative systems ‘‘LeichtkonfigurierbarekollaborativeSysteme’’ (LK3S, BMBF FKZ-1717A07, 1004-2010). Dr. Schmidtmann is a long-time member of ACM (Association of Computing Machinery), GI (Gesellschaftfu¨rInformatik), GAMM (Gesellschaftfu¨rAngewandteMathematik und Mechanik) and IEEE (Institute of Electrical and Electronics Engineers). He participate in exploration of new agent platforms for reconfigurable, collaborative automation systems organized by IEEEIES TCIA (Technical Committee on Industrial Agents) and VDE/VDMA-FA 5.15.