HACIA UM SISTEMA DE MANUFACTURA MODULAR Y COORDINADO CON ORIENTACIÓN A SERVICIOS

JOSÉ ISIDRO GARCIA MELO
Mechanical Engineering School, University of Valle, Cali, Colombial. Jose.i.garcia@correounivalle.edu.co

FABRÍCIO JUNQUEIRA
Escola Politécnica, University of São Paulo, São Paulo, Brazil. fabri@usp.br

PAULO EIGI MIYAGI
Escola Politécnica, University of São Paulo, São Paulo, Brazil. pemiyagi@usp.br

ABSTRACT: Nowadays, there is a trend for industry reorganization in geographically dispersed systems, carried out of their activities with autonomy. These systems must maintain coordinated relationship among themselves in order to assure an expected performance of the overall system. Thus, a manufacturing system is proposed, based on "web services" to assure an effective orchestration of services in order to produce final products. In addition, it considers special functions, such as teleoperation and remote monitoring, users' online request, among others. Considering the proposed system as discrete event system (DES), techniques derived from Petri nets (PN), including the Production Flow Schema (PFS), can be used in a PFS/PN approach for modeling. The system is approached in different levels of abstraction: a conceptual model which is obtained by applying the PFS technique and a functional model which is obtained by applying PN. Finally, a particular example of the proposed system is presented.

KEYWORDS: manufacturing system, distributed system, web service, teleoperation.

RESUMEN: Actualmente, una tendencia es la reorganización industrial en sistemas geográficamente dispersos, en la ejecutando sus actividades con autonomía. Estos sistemas deben establecer relaciones coordinadas a fin de asegurar el funcionamiento general del sistema. Así, este trabajo propone un sistema de manufactura basado en "web service" para asegurar una efectiva orquestación de servicios para producir productos finales. Adicionalmente, es considerado funciones especiales, tales como teleoperación y el monitoreo remoto, solicitaciones online de usuarios, entre otras. Considerando el sistema propuesto como un sistema a eventos discretos (DES), técnicas derivadas de la rede de Petri (PN), incluyendo las de Production Flow Schema (PFS), pueden ser utilizadas en un abordaje PFS/PN para modelado. El sistema es abordado en diferentes niveles de abstracción: uno conceptual, el cual es obtenido aplicando técnicas PFS, y un modelo funcional, el cual es obtenido aplicando PN. Finalmente, el trabajo presenta un ejemplo del sistema propuesto.

PALABRAS CLAVE: Sistema de manufactura, sistema distribuído, Web Service, teleoperacion.

1. INTRODUCTION

Recently, the demands on manufacturing enterprises have strongly increased to face global competitiveness and to obtain a quickly response to changes in customer requests. As a result, these enterprises are continuously reviewing and updating their structures to improve their flexibility, reconfigurability and interoperability [1]. In general, the new structures need to deal with heterogeneous systems and their communication incompatibility.

It due to the diversity of involved resources (devices, protocols, programs) implement in the manufacturing process. This increases the complexity of the overall system. Thus, specialists indicate a modular approach based on the definition of functionalities [2]. Here, the term functionality represents a set of operations in the same scope. In this sense, service-oriented architecture (SOA) has emerged as a way to implement distributed computing system, where a functionality of each module can be requested from other modules as a service, either locally or remotely, over a communication network [3].

These systems encapsulate several productive modules that work coordinately in an autonomous way to produce a final product.

These modules can be installed in a distributed and geographically dispersed configuration [6]. In this context, this research presents architecture for the integration and coordination of manufacturing systems in a service-oriented approach. The characterization of this architecture can be divided into two main steps. First, the plants and set of machines that compose the manufacturing system must be structured as modules, and their functional operations are grouped according their functionality that represents the module service. In this sense, a module can offer several services. Second, in accordance to the overall manufacture process (to produce a final product), a service is defined to integrate and coordinate different manufacturing system modules involved. The resulting system is called coordinated teleoperative manufacturing system (CTMS). In other words, it defines a hierarchical structure to reach a service orchestration of manufacturing modules. In fact, this system is being implemented based on an advanced Internet infrastructure provided by the FAPESP TIDIA/KyaTera program [7]. This program considers a collaborative environment based on a Fiber-to-the-Lab network with at least 1.2 Gbps-speed average. This research addresses the problem of characterization of CTMS with remote monitoring and control of manufacturing processes without time constraint. In this sense, initially, the solution adopted in this work considers a coordinated transnational architecture. The proposal also considers new challenges for the monitoring and teleoperation of the different activities involved with coordinated, distributed and dispersed manufacturing systems. The term teleoperation represents a human operators' support in situations such as: conflicts arbitration, definition of productive activities to be executed, among others. Nonetheless, the CTMS involves different kinds of functions and activities, and their modeling and analysis are not trivial.

Therefore, a procedure for CTMS characterization is presented here. The characterization task is based on the specification of CTMS as a discrete event system (DES); then, techniques derived from interpreted Petri net (PN) are considered for system modeling, and analysis [8]. PN is a graphical and mathematical modeling technique, characterized by their ability to handle operation sequence, parallelism, conflict and mutual exclusion [9]. PN has been used for modeling dynamic systems in a wide range of areas. In [10], an environment for distributed modeling and simulation of productive system was proposed. In [11], it was used to specify a distributed system protocol. In [12], a technique based on PN called "open workflow net" is presented, which simplifies the WSs definition, integration, and coordination. In [13], open workflow nets are used to represent both basic and structured activities of standard coordination of WSs, called business process execution language (BPEL).

This work is organized as follows. In section 2, the framework adopted for the development of this work is described. Section 3 presents the proposal for the CTMS modeling procedure. In section 4, an example illustrates the proposed procedure. Finally, in section 5, the main conclusions are presented.

2. ARCHITECTURE DESCRIPTION

The architecture considered is based on SOA, promoting interactions among customers, teleoperator, and resources involved in a distributed manufacturing system, as shown in Fig. 1.

Figure 1. Architecture for coordinated teleoperative manufacturing systems (CTMS)

The "request manager" service is a WS that exposes the functionality to manage customer requests. In fact, it interacts with the "customer´s interface", the "integration and coordination" service, and other entities such as "database" and "request observer" in order to schedule the "customer" requests.

The "request observer" ensures that the number of customer orders being processed do not exceed the number of resources available in the CTMS.

The "database of CTMS" is an entity that stores information about: "customers", "customer" requests, tracking "customers" requests. This information allows scheduling "customer" requests and tracks their execution.

The "integration and coordination" service is a WS that orchestrates the involved WSs to produce a final product.

The "teleoperative manufacturing system" service exposes each manufacturing system module of CTMS. This service encapsulates several components, such as: "teleoperative productive system" service, "teleoperators", "teleoperator´s interface", "teleoperative" service, "supervisory control", "local control", "database of system module" and "devices".

The "teleoperative productive system" service is a WS. It exposes the productive functionality of manufacturing system module that represents its service, and enables a loosely interaction, by command messages, between the manufacturing module and the "integration coordination" service.

The "teleoperators" are special users that interact by the "teleoperator´s interface". They can choose between two operational modes for the "devices" under their responsibility: teleoperation or monitoring modes. Teleoperation mode means that the "teleoperator" can interact with the "devices" from a remote location to decide about their next actions. On the other hand, in the monitoring mode, "teleoperators" are passive elements, and the decisions are previously programmed in the "teleoperative" service.

The "teleoperative" service is a WS which exposes the teleoperation functionality. It permits "teleoperators", geographically dispersed, to manage the execution productive process. In this sense, a loose interaction between "supervisory control" and "teleoperators" allows managing the execution of the module productive process.

The "supervisory control" is a task controller that interacts with the "teleoperative productive system" service, "teleoperative" service, and "local control", to manage the productive activities, according to the operational mode.

The "database of system module" is the entity that stores information about each manufacturing system module, such as: execution of module productive process, "devices", and "tele-operators". This information is used in all the process steps, for example, to estimate process time and maintenance time. Moreover, its main purpose is to be a gateway between fast Internet operations (activities that take milliseconds or seconds to be performed) and productive operations (activities that take minutes or hours to be performed). The characterization of database is out of scope due the fact that temporal constraints are not considered here.

The "devices" are control elements at shop floor level such as sensors and actuators that allow developing manufacturing activities.

3. MODELING PROCEDURE APPROACH

The procedure is divided into two parts. The aim of the first one is modeling and analysis procedure to define the services, or functionalities perfectly defined, of autonomous sub-systems (modules) that integrate the CTMS. This part of the procedure is composed of five stages (Fig. 2).

Figure 2. Procedure to model the services of each CTMS modules

. Stage A1: Scope about each manufacturing system module
At this stage, the functional characteristics of each manufacturing system module is identified and documented initially in an informal mode. The information collected is used to make a preliminary analysis and to identify relevant data from each module. In this sense, the aim here is getting knowledge about the manufacturing system to define its limits without a formal representation.

. Stage A3: Conceptual and functional modeling of each manufacturing system module
The modeling of each manufacturing system module represents all functional operations defined through the UML use case diagrams in the pre stage. It is systematically developed in accordance with a hierarchical approach using the PFS/PN methodology [14, 15]. Initially, using the PFS, a conceptual model is developed for each functional operation. It is mapped into the PFS activity. Then, gradually, a refinement is conducted to obtain its detailed functional model in an interpreted PN. To compose the PN models, the transition fusion approach is used [16].

. Stage A4: Model analysis
Aimed to validate and verify the functional requirements of the modules, the functional models in PN obtained at stage A3 are submitted to a structural and dynamic behavior analyses, based on PN properties. The properties investigated in the models are: deadlock, stability of its dynamic behavior, existence of specified states, for example, prohibited states, achievable and critically unreachable states, among others. Thus, this work explores a formal analysis techniques of PN combined with simulation techniques. Here, the software HPSim is used in the development of this work.

. Stage A5: Componentization
Once the manufacturing system module has been defined, the different activities can be arranged, according to their function, in components.

Next, the complementary part of the proposed procedure is presented. The focus here is the composition and coordination of different activity modules of the manufacturing systems that compose the CTMS. This part of the procedure is carried out in three stages (Fig. 3).

]]> Figure 3. Procedure to integrate and coordinate CTMS modules

. Stage B1: Definition of the composition and coordination process
This stage should consider the overall production process or, in other words, the sequence of operations from the customers' requests to the end of the process, to obtain the final product. This sequence of operations is exposed as a service, and for each manufacturing system module involved in the process, a functional operation is defined. The requirements of process flow are established using UML use case diagram for each coordinated functional operation.

. Stage B2: Functional modeling of composition and coordination process
Using the PFS/PN methodology, the functional composition and coordination model is obtained. Initially, each coordinated functional operation is mapped into an activity defined in PFS. Afterwards, through a refinement of the PFS model that is gradually conducted, its functional model in interpreted PN is derived.

. Stage B3: Model analysis
Once the functional models of CTMS are obtained, the structural and behavior analysis based on PN properties of these models are conducted in order to validate and to verify if the requirements and functionalities of CTMS are completed.

4. APPLICATION EXAMPLE

Figure 7. Refinement of the [telecommand request] activity

Figure 8. Refinement of the [teleoperation mode] activity

The "request observer" requests the "state request inquiry" functional operation. If the system has productive resources to meet a costumer request, the "coordination available" functional operation is used and an instance functional operation of "tracking request" is activated. To permit an incoming response message from "work- piece supply module", the "work-piece supply response" functional operation is available. In the same way "work-piece inspection response", "pallet transportation response", and "product assembly response" operations permit an asynchronous interaction with the actors: "work-piece inspection module", "pallet transportation module", and "product assembly module", respectively.

. Stage B2: Functional modeling of composition and coordination process
Initially, each functional operation is mapped into a PFS activity. For instance, Fig. 11 shows the "work-piece supply response" operation as [work-piece supply response] activity. It is activated when a response message from the "work-piece supply module" is received. In this sense, its first activity is [incoming work-piece supply response]. After that, the [sending correlation request] activity prepares and sends a request message to validate the incoming message.

Figure 11. Definition of the [work-piece supply response] activity

Then, the [work-piece supply response] activity waits for the response. If the message is validated, the next activity, [sending working-piece inspection request], is activated. Finally, a register of process execution is carried out with the activation of [sending tracking request] activity and sending its information through the [incoming tracking notification] activity.

The functional and interpreted PN model of [sending correlation request], [incoming correlation notification], and [correlations request] activities are shown in Fig. 12, where the requester transition (T1a) sends a correlation request for its paired requested transition (T1b). Then, a state for preparing the correlation is met (L2b). The incoming message is compared with the customer request being validated. This procedure is executed in the internal transition (T2b). The response is represented by the transitions pair (T2a, T3b), where T3b is a requester transition to send a notification message, and T2a is a requested transition to receive the message.

]]> Figure 12. Functional model of [sending correlation request], [incoming correlation notification], and [correlations request] activities

. Stage B3: Model analysis
Once the PN functional models of CTMS are obtained, an analysis of interactions is conduced. Considering specific scenarios, i.e., initial state (PN initial marking), the state space is obtained. The state space allows verifying the process definition, for example, if the process activity is properly performed, or identifies conflicts in messages broadcast. The validation of the model is carried out through structural analysis of the PN and simulation techniques using the HPSim tool.

5. CONCLUSIONS

6. ACKNOWLEDGMENTS