WEB BASED INTEGRATION INFRASTRUCTURE, FOR REMOTE RENT A FACTORY André Quintã, José P.O. Santos University of Aveiro / Dept. of Mechanics / 3800 Aveiro, Portugal, Tel.: +351 34 378169, Fax: +351 34 370953, email:
[email protected],
[email protected];
Abstract: Nowadays, the enterprises outsource components to others, but they have not full control about delivery times, neither about components quality or defined specifications inspection during their production, because they have no remote monitoring or controlling services available in the others shop floor enterprises, even in enterprises of the same group. Moreover, when their shop floor resources are fully allocated, an enterprise should be able to rent others shop floors enterprises (human and machines), controlling them as do in its own shop floor, using for example a simple Web interface. However our goal is not the WEB itself but the remote control of FMS, enabling their rent to others "Remotely Rent Factories”. Keywords: Flexible Manufacturing System, Remote Control, Communication Protocol, Integration, Enterprise Integration, Computer Controlled Systems
1.
INTRODUCTION
In order to Remotely Rent a Factory, this paper proposes an Integrating Infrastructure based on “web client/server architecture”, specific messages and communication rules. This approach allows the control of the shop floor resources, in a coordinated way, from a Web-Browser (Netscape, IExplorer). In turn, the remote factory should have a Web-Server which will provide all the tool and services necessary to the client control the shop floor. In this way, the client engineering department should be able to send production orders, ex: part programs to others shop floors, it could also "to see" and “to receive” remotely information, in real time, about remote production failures, resources production rates, acting immediately if necessary. To Remotely Rent a Factory, three main issues should be addressed: ● In order to support interaction between the remote factory and the clients, multiple Integrating infrastructures (networks, operating systems, network programs, and control protocols) could be used. ● Also, several modelling languages could be used to build factory models, describing shop floor activities, resources, materials and resources dependencies, production dates. The production models developed with an Enterprise Modelling
Language (EML) should have enough formalism to support its own remote execution, from a PC, enabling the real time control of shop floor activities. ● The remote factory should also provide a User interface that supports the client access to factory resources. The interface could be more or less user-friendly, providing tool to develop and execute the models to control the factory in real time. The Integrating Infrastructures, the Modelling Languages and many others enterprise components are addressed by Enterprise Modelling Architectures such as PURDUE, CIMOSA, GERAM. However none of them propose any specific Integration Infrastructure because there are many application scenarios. Several papers addressed the remote control and monitoring of one industrial process: robot, electricpneumatic systems or others. Some of these papers will be here briefly described: (Matysec et. al. 2002) presented an example of a “… monitoring and control system using the TCP/IP network protocol”. In its third section was presented “the structure of transferred data”. (Neto et.al.2000) presented the remote control of industrial processes”, in this case the industrial process was an “electric-pneumatic system for
quality control supervised by personal computer which analysis quality of scheduling performance”. It is possible to use a normal phone line or a Telnet service to access information and to control this process. It is also possible to access a WEB camera to see the process.
modelling language. The models developed, can be used to remotely control the shop floor operations by means of an Integration Infrastructure. However, this FMS was not initially designed to achieve the objective presented in this paper and must be “updated” to overcame several constraints.
(Vale et. al. 2000) presented a “Robot Concurrent Remote Operation Through Internet” describing “a client server architecture for the remote operation of a mobile platform by multiple users using Internet”. This paper addresses three main issues in the remote operation of robots: the user robot interface, the communication channel and the concurrent operation of robot for multiple users.
To propose an Integration Infrastructure several studies were made namely a first approach was presented in (Santos et. al 1996) paper, addressing the “…Integrating Infrastructures for manufacturing: a comparative analysis”. This paper presented a “an overview of the evolution of manufacturing systems integrating infrastructures and standards, ranging from network standards such as OSI1, MAP2 and CNMA3, that essentially support hardware integration, distributed platforms like OSF/DCE4 and OMG/CORBA5 promoting industrial applications integration, up to integration frameworks like (CIMOSA 1996)6 which try to encompass all the aspects linked to business integration. This overview has a particular emphasis on the integrating infrastructure concepts towards enterprise integration. The advantages and constraints of a CIMOSA integrating infrastructure implementation using OSF/DCE was also presented and discussed.”
(Delgado et al. 2004) presents the monitoring of a remote facility, using a simple web based interface instead of the usual monitoring and supervision system (SCADA). The authors present there a nice step towards an integration of a remote factory into web, which goes in the same direction of the "rent a factory" concept. For academic purposes, the authors of this paper propose to their students the development one small integration infrastructure. This integration infrastructure should enable the remote control of one shop floor resource, from a standard WebBrowser (IExplorer or Netscape). To reach this objective, each group of two students must develop: the necessary webpages, showing the control panel of the resource and one Web-Server (VBasic). This Web-Server also converts the Web messages into messages that can be received and executed by the shop floor resource. This Web-Server is physically connected to the shop floor resources via RS232, Ethernet, DDE, TCP/IP, or by I/O lines. When the resource is controlled by a PLC the students also develop the PLC program. However this approach does not allow an integrated and coordinated control. In this case the user must have one Web-Browser for each shop floor resource and step by step “manually” coordinate all the resources. Therefore, the problem is: “Which Integration infrastructure - II should be used to remotely control shop floor resources in a coordinate way?” This paper is organized as follow: the second section presents an overview about the previously implemented FMS architecture and simultaneous provides the background to understand their constraints (section 3). In section 4 will be presented the new proposed integration platform. Section 5 will presents conclusions and further work.
In (Santos et. al 1997b) it was presented a first approach to a Common Functional Operation -CFO Library, based on the CIMOSA integration infrastructure. (Santos et. al 1998) presented a paper entitled “Manufacturing device integration builds on shop floor functional operations. This paper addressed the “…Integrated management and control of shop floor devices in manufacturing, using advanced infrastructures built on computers and communication networks. The integration infrastructure encompasses the Functional Operations - FO, and the communication integrating services provided by CFO layer were adequately refined. The lower-layer, is responsible for the FO message transmission to/from shop floor devices. The CFO layer hides the diversity of the industrial network protocols, providing a common standard interface to the upper-layer. The CFO behaves in fact as a virtual circuit, transmitting the FO messages in a confirmed mode through the underlying communication networks. This integration Infrastructure was implemented as a software Library so-called Functional Integration Operation Platform- FIOP. Nowadays, there are several modelling languages supporting the enterprise activities design 1
Open System Interconnection (OSI) based. Manufacturing Automation Protocol (MAP). 3 Communication Networks for Manufacturing Application (CNMA), It is not yet a standard. 4 Open Software Foundation/Distributed Computing Environment (OSF/DCE). 5 Object Management Group/Common Object Request Broker Architecture (OMG/CORBA). 6 Open System Architecture for CIM (CIMOSA). 2
2.
PREVIOUS WORK
Using a set of shop floor resources was developed in Aveiro a Flexible Manufacturing System FMS. The shop floor operations are defined in the central computer of the shop floor, using a specific
(organization, planning, etc.), namely shop floor activities. However, it is not easy to translate these specifications into shop floor orders, directly reusable to shop floor resources control. These specifications consist usually in textual or graphical reports, being adapted by the shop floor operators, therefore consuming same time to be manually implemented.
shop floor orders and network messages are created internally by the EMT using the FOIP. The models developed during the design phase can be immediately executed by the EMT, without any further modifications, which enables an easy and fast transition from the design to the execution phase, reducing the time usually consumed adapting design specifications into shop floor orders.
A specific modelling language was presented in (Santos et.al 2000a) and was designed to be “an enterprise modelling language (EML) for modelbased shop floor control. To introduce a new computer executable modelling language several modelling frameworks were analysed namely the CIMOSA and (GERAM 1997) frameworks. This language covers the different life cycle phases of enterprise modelling: design, implementation and operation, allowing an easy and fast transition from each phase to the next. In the operation phase the models can be used to control and monitor (on-line) the enterprise resources behavior. It presents an example of an operational model, based on the proposed EML, for real-time enterprise activity control. Despite the fact that the proposed modelling language does not intend to be a full CIMOSA compliant language, it could easily be a first step in that direction. It tries to validate this hypothesis by showing how a CIMOSA model (functional view), could be built based on the proposed EML”
The EMT encompassing the EML and the FIOP can be better presented relating it with the reference architecture GERAM, and the EMT integration platform FOIP with the EMEIS standard.
This approach allows the remote control of the shop floor resources, in a coordinated way, and therefore the shop floor production integrated control.” These
Enterprise models are developed using EMT, that in turn implement the semantic and syntax defined by the Enterprise Modelling Languages - EML. The EMLs contain generic modelling constructors describing enterprise tasks, resources, etc. The GERAM does not propose any specific modelling language, but can encompass the EML used by the proposed EMT. As presented in figure 1 the proposed EMT allows the enterprise models development (production models) using a specific Enterprise Modelling Language - EML. EEMs Methodologies (CIMOSA,...)
GERA concepts
PEMs reusable reference models
EML (Enterprise Modelling Language) This EML is used by the modelling Tool -EMT
GEM meaning
EMOs
Implemented in Support
Proposed EMT (Enterprise Modelling Tool) EMD Used to build
FOIP (Functional Operation Integration Platform) The FOIP provides the models execution services (MXS) and generic information technologies (IT)
(Santos et.al. 2000b) proposed “an Enterprise Modelling Tool -EMT for model-based shop floor control. The EMT enables the design and execution of production models describing shop floor operations and procedural rules. The EMT encompasses an Enterprise Modelling Language EML and the so-called FOIP. The EMT was developed over a simulation program entitled “Simulation Production and Logistic - Simple++”. An integration Infrastructure allowing the execution of shop floor models to control actual shop floor devices was also developed. The EMT intents to reduce the models design time and their shop floor execution. The EMT also intents to allow the realtime shop floor control. To achieve these objectives the EMT encompasses two different but interconnected environments: the design and the execution environments: ● During the model design, the user can use several libraries provided by the EMT and a specific Enterprise Modelling Language - EML, already presented in (Santos et.al 2000a), to build production models describing the enterprise activities. ● During the model execution phase, the EMT reads the model, and, automatically generates shop floor orders, as well as network messages to carry on these orders, to the enterprise resource, using the Integration Infrastructure CFO&FO.
The reference architecture GERAM (figure 1) organizes nearly all the existing enterprise integration knowledge built in several reference architectures, such as CIMOSA, GRAI (Douneingts et al, 1993), and PERA (Williams, T. J. 1994). Each of these architectures tries to model specific aspects of the same reality, being better suited to model some aspects of the enterprise processes and activities than others. GERAM encompasses nine major components: concepts, methodologies, modelling languages, tools, reusable partial and particular models, implementation modules and enterprise operating systems, figure1.
EMD (Enterprise Model Design) Thes EMD describe the enterprise operations and procedural rules
Instantiated to implement
EOS Enterprise operating systems
Fig. 1. Positioning EMT in GERAM context
This specific EML aims at describing enterprise operations, but further enabling remote control and monitoring of the operations over an integrating infrastructure.
software developed by us over the simple++ to implement the EMT-Client side. Another problem is the distance, because the DDE used by the FIOP is not design for worldwide communication.
To undertake enterprise models design (EMDs) for a particular enterprise using EMLs and EMTs, different approaches, steps and enterprise engineering methodologies (EEMs) can be followed. GERAM also proposes the definition of reusable models for a specific type of enterprises (partial enterprise models - PEMs) helping to develop new models for a particular enterprise.
Nowadays, everybody has a Web-Browser on his computer so the best solution is to implement the EMT-Client services on the WEB. The FOIP implementation on WEB is another advantage because the distance between the client and the shop floor is no more a problem; everybody, anywhere in the world will be able to access the EMT-Server. When contacted, the EMT-Server will provide the Browser of the client with the interface, the tools, and the services needed to control the shop floor resources in an integrated manner.
GERAM, also, intents to reuse implemented enterprise modules (EMOs), already developed, to support models operations for a particular enterprise. The so-called EMOs can cover: reusable design schemes, physical resources or integrating services. Integrating services are provided by information technology (IT) infrastructures such as the FOIP, used by the proposed EMT. The integrating infrastructure of EMT, so-called Functional Operations Integration Platform - FOIP (Santos et al, 1997a; 1997b; 1998) was implemented as a software package which provides communication and model execution services, acting in fact like an Enterprise Model Execution Integrated Services – (EMEIS 1995) platform. The figure 2 presents the model execution, in laboratory, using two computers and one milling centre. The EMT–Client side was implemented using the Simple ++. The EMT-server was implemented in VBasic and receives the EMT-client messages converting and sending them to the resource controller. The communication between the EMTClient and the EMT-Server was based on Windows Dynamic Data Exchange (DDE) protocol. EMT - Client
EMT - Server
PP&C
Design
Milling center M1
PP&C
Execution
I/O
program
FO CFO
FO& CFO Server
CNC - PLC
M1
Data acquisition board (Local control)
Model
Windows Dynamic Data Exchange - DDE
4.
PROPOSED INTEGRATION INFRASTRUCTURE
The full EMT-Client implementation on WEB, encompassing the EML and the EMT services are now being developed and will presented in a future paper. This paper presents the new integration platform encompassing some FO and a small WEB interface. Using this interface and the FO proposed, the client could describe simple shop floor operations sequences using several resources in a coordinated way.
4.1 Integration Infrastructure Architecture Using the proposed Integration Infrastructure, the FMS become accessible form any part of the world with out the need of a specific controller application, it’s enough a computer connected to the Internet and a Web-Browser , figure 3. The Integration Infrastructure architecture includes a Web-Server that makes available the control and monitoring of all manufacturing resources through a Web-Browser like the IExplorer, Netscape or other. The Web-Server is also a FMS-Controller, it receives the manufacturing-orders through the web and directs them to the respective resources. Web Browser World
Web Server/FMS Controller TCP/IP
Fig. 2. Model execution scenario Local controllers
3.
CONSTRAINTS
As described above the EMT allows the control of our academic FMS but several constraints were identified. First of all, one hypothetical client needs to buy the simple++ program, and buy all the
RS232, DD Resources
Fig. 3. Integration Infrastructure
Because each resource uses different communication protocols and messages syntax sometimes it is necessary to use Local-Controllers. Each LocalController is responsible to translate the FMSController orders into resource specific orders.
4.2 Web-Server/FMS-Controller The implemented Web-Server/FMS-Controller application was developed in Visual Basic. The main task of this application is the routing of web messages to the several Local-Controllers. The FMSController application makes available a TCP/IP server to the Local-Controllers. Therefore, each Local-Controller must establish a TCP/IP connection with the FMS-Controller. Therefore, the communication between the FMS-Controller and the local’s resources controllers is fulfilled trough the TPC/IP connection and uses a specific pre-defined protocol of messages (figure 3).
The webpage presents the FMS layout and the state of each resource. Each resource is represented trough different colors, green to ready, yellow to busy and red to error. Each resource image has also link to a page that reports the technical characteristics and refers to more detailed information, like actual position or error discrimination. The webpage also shows the intermediate buffers, working table, conveyors pallets, and others places available on shop floor where the pieces can be placed, machined, assembled, etc. Using this WEB interface the client can define FO sequences and multiple material trajectories through the shop floor.
In future the FMS-Controller will support automatic scheduling optimization and multiple remote users.
Several FOj can be physically executed by one shop floor Resource (Ri) and during its execution each FO can assume several states (FOj.St): idle, processing, error, successfully completed. The FOs are grouped in two kinds of operations, produce and transport (Bauer 1994). The produce operations have the code PgmStart and are defined with the name of the program witch the resource must execute. The transport operations have the code MovTo and are defined with the start and end point.
4.3 Local-Controller
4.5 Integration Infrastructure messages
The Local-Controllers application allows the communication between each resource and the FMSController. These applications were developed in agreement with each particular resources communications capabilities, serial RS232/RS485, DDE, I/O or USB. Some resources have TCP/IP communications capabilities that allow the resource to communicate directly to the FMS/Controller (TCP/IP server) without the need of a LocalController application.
Figure 5 shows an example of a FO sequence. In order to execute this small example the web user most describe the operations sequence on the webpage table, according to the following rules: the first column is automatic created and is not editable, the second column respects to the resource ID (Ri) in agreement to the FMS layout image on the top of the webpage, figure 5. For the robot manipulator 1, the ID is R1, for the CNC milling center 1 the ID is M1 and so on. The FO is described on the third column, using the codes MovTo to transport and PgmStart to produce. The MovTo code is defined with the start and end point, the PgmSart is defined with the program name to be executed.
4.4 Webpage. When the client, using its Web-Browser, accesses the factory Web-Server it answers with an initial webpage developed in html, figure 4.
WebSrv/FMS Controller Web Browser
R1
Get HTTP...
Robot Index.Htm
Connect ConnectAck
Milling Center Connect
Shoop Floor Operations Sequence
ConnectAck
# 001 002 003 004 005
Ri R1 M1 R1 C1 R2
FOj MovTo(P1,P2) PgmStart(Part1.ISO) MovTo(P2,P3) MovTo(P3,P5) MovTo(P5,P8)
St Completed Processing Idle Idle Idle
#1 Processing
DataAck
#1 Completed
Move
MovTo(P1,P2)
MovToAck #2 Processing
DataAck
Fig. 4. Webpage interface
Fig. 5. Communication messages example
Milling
PgmStart(Part1.ISO)
In the example the FO MovTo(P1,P2) relative to R1, means transport a part from the Warehouse 1 (P1) to the CNC milling center (P2). When the user press the execute button, the operations sequence table is send to the Web Server/FMS Controller that distributes the FO messages to the respective resource controller according to the FO precedence’s. Actually is not yet possible to change the FO precedence’s, by default each FOj as FOj-1 as precedence. Every FO messages have a acknowledgement reply that leads to a update of the FO sates on the webpage table, figure 5. All the messages flow is made according with a preestablish protocol. The message send to the resource is the same as the FOj on the table. When the resource local application receives a FOj it starts the job execution and reply with an acknowledgement message (DataAck), when the Web-Server/FMS Controller receives this acknowledgement it change the FO statej to “Processing”. When the resources end the job, it sends another acknowledgement message (Ex. MovTo Ack OK) and the Web-Server/FMS Controller updates the sate to “Completed Succefully”, and stars the FOj+1. 5.
CONCLUSIONS
The integration infrastructure presented, is working and supports the remote control of several shop floor resources in a coordinated way, from a WebBrowser. However further work is necessary to a client be able to use our shop floor as it uses his own shop floor. Namely it should be analysed and chosen or proposed new modelling languages and scheduling algorithms that should be implemented by the FMSServer enabling: ● The creation of complex models describing the simultaneous production of several products and components. ● The reception of production models from several remote users, and the automatic rescheduling of the production orders in the shop floor.
REFERENCES Bauer, Bowden, Duggan and Lyons (1994). Shop Floor Control Systems, from design to implementation – Chapman&Hall. Esprit consortium AMICE (1996). CIMOSA Open System Architecture for CIM. Springer, Berlin. EMEIS-CEN Report/TC 310 (1995). CIM Systems Architecture, Enterprise model execution and integration services (EMEIS), Annex E: CIMOSA ’s Framework for integrating Infrastructure. CR 1832:1995, Feb.
GERAM IFIP–IFAC Task Force, (1997). Generalised Enterprise Reference Architecture and Methodology – GERAM, Version 1.5. Matsysek,M; P.Neumann and M. Adamek. (2002). The Modified Monitoring ans Control of a Fermentor System via the Network TCP/IP Protocol. In: 5th Portuguese Conference on Automatic Control, Aveiro, Portugal, September 5-7, 2002, pp. 36-39 Neto, R.; Alves, João; Alves, Jorge; Carvalho, A.; Fonseca, I.; Miguel, N.; Emílio, E.; Fachada, H. (2000). Remote Control of Industrial Process. In: 4th Portuguese Conference on Automatic Control, Guimarães, Portugal, October 4-6, 2000, pp. 476-481 Santos, José. P. O., and Ferreira, João J., and Mendonça, José M. (2000a). A modelling language for the design & execution of enterprise models. In: International Journal of CIM. Vol.13, Nº 1, pp. 1-1 to 1-10 Santos, José. P. O., and Ferreira, João J., and Mendonça, José M. (2000b). From shop floor simulation to shop floor control, a model-based Approach, In: ASIM conference, Berlin 2000 Santos, José P. O., J.J. Pinto Ferreira, José M. Mendonça (1998). Manufacturing Device Integration Builds on Shop Floor Functional Operations. In: INTEGRATION INFRASTRUCTURE-International Conference on Engineering Design and Automation EDA'98, Hawaii-EUA. Santos, José. P. O., João J. Ferreira, José M. Mendonça (1997a). Distributed Platforms for Shop Floor Communications. In: IFAC/IFIP/CTI Conference on Management and Control of Production and Logistics, Campinas, Vol II, pág. 628-634. Santos, José. P. O., João J. Ferreira, José M. Mendonça (1997b). Infra-Estruturas de Suporte a Modelos Executáveis para Controlo da Produção. In: Congresso Ibero - Americano de Engenharia Mecânica – CIDIM’97, 3th, CubaHavana, pp. 4-168 4-174. Santos, José P. O., João J. Ferreira, José M. Mendonça (1996). Integrating Infrastructures for Manufacturing a Comparative Analysis. In: Reengineering for Sustainable Industrial Production, IFIP / CHAPMAN &HALL, ISBN 0412 79950 2, 1997, pp.308-321. Vale, Alberto; Inácio, Paulo; Antunes, Nuno; Sequeira, João; Ribeiro, Maria Isabel, (2000). Robot Concurrent Remote Operation Through Internet. In: 4th Portuguese Conference on Automatic Control, Guimarães, Portugal, pp. 447-452 Delgado, Rui; Santos, Gustavo; Cardeira Carlos; Loureiro, Rui; Leichsenring, Otto (2004). Web Based Supervision of Remote Units. Submitted : 6th Portuguese Conference on Automatic Control , Faro, Portugal, June 7-9.
