Workflow and CIMOSAâbackground and case study

Computers in Industry 40 Ž1999. 197–205 www.elsevier.nlrlocatercompind

Workflow and CIMOSA—background and case study Markus Dickerhof b

a,)

, Milena M. Didic

b,1

, Ulrich Mampel

a,2

a Forschungszentrum Karlsruhe, Postfach 3640, D-76021 Karlsruhe, Germany Escuela de Ingenierıa Facultad de Ingenierıa, ´ Quımica, ´ ´ UniÕersidad de Costa Rica, San Pedro de Montes de Oca, San Jose, ´ C.A., Costa Rica

Abstract For an enterprise engineering application in a low-volume microsystems production we used the two Reference Architectures: CIM Open System Architecture ŽCIMOSA. and Work Flow Management Coalition ŽWfMC.. We applied the emerging WFMC standard to the microsystems worklist processing to design the workflow system InfoFlow. For the manufacturing activities of the workflow participants we used the appropriate CIMOSA constructs on the level of Machine Functional Operations fitting into the WFMC architecture. The paper describes the relation between the two reference architectures comparing their concepts and constructs. The application shows that both concepts bring benefit to the enterprise engineering task and to a large degree complement each other. q 1999 Elsevier Science B.V. All rights reserved. Keywords: Enterprise engineering; Workflow; Workflow Management Coalition; CIMOSA

1. Introduction Within the field of microsystems technology, the research work at the Forschungszentrum Karlsruhe focuses on the development of new methods of microstructuring and the optimisation of known techniques as the basis for the production of micro actuators, micro sensors and complex microsystems. The research work aims also at developing new processes and materials, finding new ways of designing microstructures and standardising the processes of industrial microstructure manufacturing. To improve the transfer of research results into marketable products, a low-volume production is set up for industrially interesting components. The so)

Corresponding author. E-mail: [email protected] E-mail: [email protected] 2 E-mail: [email protected] 1

called ‘Technikum’ aims at demonstrating the manufacture of micro components and microsystems in a production-oriented manner and delivering demonstrators of microsystems to industrial partners. By applying the Business Process Engineering Groupware and Workflow we are supporting the production planning and quality management of low-volume production. The work is carried out within the framework of the research project DARIF, the German acronym for ‘Methods and tools for decentralised work and information structures based on business processes’. DARIF has been launched under the German Programme PRODUCTION 2000 and is supported by the German Ministry for Research and Education w3x. The structure of the paper is as follows. Section 2 summarises briefly the relations between workflow and CIMOSA. The build time functions and the architecture of our workflow system called InfoFlow

0166-3615r99r$ - see front matter q 1999 Elsevier Science B.V. All rights reserved. PII: S 0 1 6 6 - 3 6 1 5 Ž 9 9 . 0 0 0 2 4 - X

198

M. Dickerhof et al.r Computers in Industry 40 (1999) 197–205

are described in Section 3. The run-time functions are presented in Section 4. Section 5 summarises the approach and Section 6 gives conclusions of the research work. 2. Relations between workflow and CIMOSA Founded in 1993, the Workflow Management Coalition ŽWfMC. is a non-profit international organisation of workflow vendors, users and analysts committed to establish standards for workflow terminology, interoperability and connectivity. The WfMC’s workflow approach roughly presented in Fig. 1 w5x has several similarities with the CIMOSA concepts. It defines: Ø Build-time functions for modelling the workflow process and its constituent activities, Ø Run-time control functions for managing the workflow processes in an operational environment and various activities to be handled as part of each process, Ø Run-time interactions with human users and IT application tools for processing various activity steps. These can be compared with the CIMOSA Buildtime and Run-time environments which are very well summarised in the ENV Žnumber to be assigned. on Enterprise Model Execution and Integration Services ŽEMEIS..

The diagram in Fig. 2 summarises the key components, their relations and terminology used in the WFMC Reference Model w6x. The WfMC and CIMOSA w1x terminologies are compared in Table 1 w7x. As an example: According to the WFMC terminology, the workflow microsystem application called InfoFlow w2x can be defined as: The computerised execution of the Business Process which is necessary to fulfil an order for a microsystems product. In the CIMOSA terminology it would be: Execution of a Business Process Žwhich is necessary to fulfil an order for a microsystems product. through the CIMOSA Integrated Infrastructure Services.

3. Build-time of the microsystem application The main purpose of the described microsystem application is to support the users by: Ø supplying work instructions and production plans defined by the quality management, Ø collecting production process data, Ø employing quality assurance system, Ø providing access to other relevant computer-based information and tools used in the manufacturing context. The resulting InfoFlow architecture is based on the Intranet ŽFig. 3..

Fig. 1. The WFMC framework for workflow systems.


199

Fig. 2. The WfMC Generic workflow product structure.

In InfoFlow the Business process models, data models and data collection are stored in SQL data bases. The InfoFlow Manager uses a Groupware tool ŽMicrosoft Exchange. for the enactment of the workflow logic Žmodel execution in CIMOSA ontology.. The Worklist Handler is based on the MS Exchange Web Client Žrealised as Active Server Page. and presents work-checklists to workflow participants, so that they have the appropriate access via WEB browser. The activity related work instructions and applications are included via hyperlinks to production planning and test plan modules for each activity of the Business Process. The Business Process Preparation of Substrate consists ultimately of more than a hundred different activities. For the current pilot phase only the subset of activities presented in Fig. 4 is used.

Fig. 4 shows the Window in MS Project providing an model overview and the presentation of a macro ŽWindow ‘New work item’ Žin German... The InfoFlow models are specified in two compatible ways: Ø Model layout and its Macros, supporting the model definition on the Design Level, Ø SQL tables in a model base ŽImplementation Level.. All implemented applications as well as the information necessary have to be linked in the form of hyperlinks in order to be ready for their execution during the run-time. Due to the manufacturing context of our application, many shop floor operations are involved. Since the WFMC architecture mainly deals with document processing, no equivalent to the Machine Dialogue

200


Table 1 Comparison of the WfMC and CIMOSA components and terminologies WfMC

CIMOSA

Workflow Workflow process Workflow process activity Work item Not defined Invoked application Transition Workflow relevant data Workflow application data Workflow participant Human System Organisational unit Organisational role Administration and control Workflow enactment engine

Domain process Business process Enterprise activity Human functional operation Machine functional operation Application functional operation Procedural rule System management data Object views Dialogue entity Human dialogue entity System Management Entity Organisational unit Organisational role System management services Business service interpretation engine Script to be executed by the Dialogue Service Control engine of the dialogue service

Worklist Worklist handler

The Table 2 presents the list of CIMOSA Machine Functional Operations w4x for our case study. 4. Run-time of the microsystem application During run-time of the application, the models defined above are executed. For the model execution InfoFlow uses the InfoFlow Manager together with the Exchange Server Žsee Fig. 3.. Communication and dialogue between workflow participant is supported by the Internet Information Server ŽIIS.. The user interface to the worklist and work items in InfoFlow is provided by the Intranet services, and especially through the Outlook web access. All activities are represented as public folders in the Exchange Server, to which the InfoFlow manager sends messages. For a specific workflow participant the relevant folders can be assembled in a specific place in a box, nearby herrhis mail. In the different folders the work items are represented by mail messages which are presented to the workflow participant as specific forms. 4.1. Example of the workflow for one actiÕity

Service of CIMOSA is defined in the WFMC Reference Architecture. Therefore, we switch to CIMOSA for describing the machine-oriented operations.

When the workflow participant opens the worklist in his folder, the execution of a sequence of Enter-

Fig. 3. The InfoFlow.


201

Fig. 4. Definition of workflow activities.

prise Activities Žand Functional Operations. takes place. The workflow participant has first to confirm that he has read the information presented to him in the ‘infosystem’ documentation. In the Spincoating case, the ‘infosystem’ consists of four objects: Work Plan, Data Input, Specification and History. The corresponding activities and their execution are described in a text document, whose link is stored in the data base. Its content can be displayed by clicking the Workplan button. The document contents had to be acknowledged and certified by the quality management prior to being attached to the Enterprise Activity. Order planners are not allowed to change the document contents. It can only be supplemented by order-related

comments added in the instantiation process and displayed in the remark field of the worklist. Table 2 Machine functional operations in InfoFlow Substrate taking Prebake 1 of substrate Prebake 2 of substrate

Descum at P300

Gold plating Inspection of plating results before resist removal Resist inspection Wet-chemical removal of thin resists E-beam exposure Characterisation by means of microscope Post-exposure bake Transfer of titanium membrane Development of thin resist film SEM-examination Lithography inspection

202


Fig. 5. InfoFlow Worksteps.

In the Spincoating activity, the following work items of the Workplan are included ŽFig. 5.: Ø Prepare the resist in a roll edge bottle, put it beside the spincoater and heat the bottle to the correct temperature Žif necessary.. Ø Retrieve the desired layer thickness from the worklist and determine the spin parameter by the comparison of the retrieved thickness with the trend chart of the respective resist. Ø Program the machine controller according to the parameters. Ø Apply the substrate, cast the resist centrally, and start the program immediately. Ø After the end of the program, bake the substrate. The relevant baking conditions for the particular resist can be retrieved from the information system of the routing card, too. Since there are no entries to be made, the Data Input button is not activated in the Spincoating activity. By clicking the Specification button, the workflow participant will access the Spincoating user interface. Hershe will also receive information about the spincoater documentation and the materials used. The History button offers additional information about the order status and about the execution remarks of former activities. This information is very helpful to gain knowledge about a product. In a low-volume production facility, especially in the microsystem environment not every case can be foreseen or discussed. Many participants are also experts in related production steps. The display of history

information allows them to check the process in general, to compare the results with their expert knowledge and if necessary to react in a specific manner. Therefore, the acknowledgement of history data by the workflow participant can be regarded as an additional quality control loop. After the completion of the activity, the workflow participant confirms the execution according to the ‘work order specification’ and sends a message to the InfoFlow manager by pushing the Send button on the form. The InfoFlow Manager then stores the information input from the workflow participant in the workflow data base and sends the messages to the succeeding activity folders or participants.. As an Intranet user, the workflow participant can access various information from his worklist via activity-specific hyperlinks. Finally, the workflow participant can complete the current session in two ways: 1. Finishing the activity due to the specification 2. Suspending the activity In the second case, all involved participants and the responsible administrator are informed.

5. WFMC, CIMOSA and InfoFlow After presenting the build- and the run-time functions, the relations to the Interfaces of the WfMC Reference architecture are shown in Fig. 6. On Interface 1 the process definition tools provide the functionality of the build-time environment. They


203

Fig. 6. The InfoFlow functions in the WfMC Reference Architecture.

provide the enterprise engineering capabilities for the application. Interfaces 2 and 5 are both linking to run-time functionality. Whereas the administration and monitoring tools are providing planning and manufacturing control information for the operation, the client application are directly linked to the functional operation as, e.g., described in Section 4.1. With the components and terms of the CIMOSA Integrated Infrastructure Services, the InfoFlow architecture can be presented as the configuration shown in Fig. 7. The functions on the Interfaces 1, 5 and 2 in the Fig. 6 relate to the Model Generation, System Management Services and Dialogue Services ŽFig. 7., respectively. The Model Enactment Services in Fig. 6 correspond to the Business Services in Fig. 7. The CIMOSA Communication and Information Services presented in Fig. 7 have no explicit counterparts in the Fig. 6 so far. According to the WfMC: ‘‘This area will require further specification work. The direct interface of application data is typified by email driven workflow systems. Conventions will need to be adopted Žor developed. for transferring or retaining the data type information, for example by

the use of X.400 body type identifiers or the Internet MIME mechanism’’ w6x. The definitions of Business Processes and activities are similar in both reference architectures. A workflow activity as well as a CIMOSA Enterprise Activity requires resources to support their execution. Resource View and Resource Management are obvious; CIMOSA describes both explicitly; WfM Coalition only implicitly. The CIMOSA Organisation View is similar to the respective WfMC specification. The Worklist Handler in the WfMC corresponds to the Human, Application and Machine Presentation ŽDialogue. Entities in CIMOSA. The enactment of a workflow model by the workflow engine does not differ from the model execution by the CIMOSA Business Service Interpretation engine. However, WfM engines are distributed per se, a distributed CIMOSA model interpretation has not been developed so far. Moreover, since the WfMC Reference Model exclusively deals with models ready for operation, it should be clear that the WfMC model description approach can only be compared with the Implemen-

204


Fig. 7. The InfoFlow architecture and CIMOSA.

tation Description Modelling Level and with the Integrating Infrastructure of CIMOSA.

6. Conclusions Introducing the workflow technology into the low-volume microsystems production, the emerging WFMC standard has been applied to the microsystems worklist processing to design the workflow system InfoFlow. For the manufacturing activities of the workflow participants, however, the appropriate CIMOSA constructs fitting into the WFMC architecture have been used. The semantic content and the application method performed on the level of individual constructs shows that a CIMOSA model can be migrated into the WfMC infrastructure for execution, while maintaining its semantic contents. More work is required, for

example, to develop a common enterprise modelling language for a ‘flexible’ model representation and to ensure an integrated semantically complete translation of enterprise process models into different infrastructures for model execution.

Acknowledgements The authors wish to acknowledge the contributions of their colleagues Franz-Josef Kaiser and Martin Schrempfer to both the concepts and the implementation of InfoFlow.

References w1x CIMOSA, Open System Architecture for CIM; ESPRIT Consortium AMICE, Springer, 1993, ŽISBN3-540-56256-7., ŽISBN 0-387-56256-7..


205

w2x M. Dickerhof, F.J. Kaiser, U. Mampel, M. Strempfer, InfoFlow - eine Workflowlosung im Internet, in: H. Kuhnle, ¨ ¨ K.-H. Sternemann, K. Harz ŽEds.., Herausforderung Geschaftsprozesse, LOGIS Verlag, 1998 ŽISBN 3-932298-05¨ 5. pp. 152. w3x H. Kuhnle, K.-H. Sternemann, K. Harz ŽEds.., Heraus¨ forderung Geschaftsprozesse, LOGIS Verlag 1998, ŽISBN 3¨ 932298-05-5.. w4x M. Dickerhof, Offene CIM-Architektur fur ¨ den Rapid Prototype einer automatisierten Prozeßsteuerung, Dipl. Arbeit, University of Karlsruhe, 1994. w5x Workflow Management: An Overview and Introductory Session, http:rrwww.wfmc.org w6x Lawrence P. ŽEd.., Workflow Handbook 1997, John Willey, 1997 ŽISBN 0-471 96947-8.. w7x M. Zelm, Vergleich der Sprachkonstrukte in ENV 122204, CIMOS und KODA, in: H. Kuhnle, K.-H. Sternemann, K. ¨ Harz ŽEds.., Herausforderung Geschaftsprozesse, LOGIS Ver¨ lag 1998, ŽISBN 3-932298-05-5., pp. 59

Milena Didic teaches process simulation and programming as well as topics related to environmental protection and conservation at the Chemical Engineering School, University of Costa Rica. Her interests are in design of distributed systems, enterprise engineering, workflow and clean manufacturing. After her graduation in Technical Physics and Nuclear Engineering, she worked, first in the area of laboratory automation and later on the research topics enterprise engineering and clean manufacturing in the Control Systems and Communication Department of the Institute for Applied Computer Science at the Forschungszentrum Karlsruhe, Germany. In the Esprit Projects VOICE on CIMOSA Industrial Validation, she was strongly involved in the realisation of CIMOSA model execution concepts and published various professional articles on this topic.

Markus Dickerhof studied Mechanical Engineering at the University of Karlsruhe. He prepared his diploma thesis in the ESPRIT Project VOICE II ŽRapid Prototype of an automated Process Control.. Since 1995 he has been working at the Institute for Applied Computer Science at the Forschungszentrum Karlsruhe ŽFZK.. Since 1997 he is responsible for the development of a process oriented workflow and information system in the FZK Microsystem technology Program. The system is currently installed in a low volume production at FZK.

Ulrich Mampel studied Chemistry and Biology at the University of Heidelberg. Between 1989 and 1996 he worked as scientific consultant at the Institute for Energy and environmental Research Heidelberg. Since 1996 he is an employee of Forschungszentrum Karlsruhe Technik und Umwelt. At the Institute for Applied Computer Science ŽInstitut fur ¨ Angewandte Informatik ŽIAI.. he was responsible for the federal funded project DARIF, where the research focus are methods and tools for decentralized working and information structures.

Workflow and CIMOSAâbackground and case study

Workflow and CIMOSAâbackground and case study

Suggest Documents