The Integration of Product Data and Workflow Management Systems in a Large Scale Engineering Database Application R McClatchey1, Z Kovacs1, F Estrella1, J-M Le Goff2, G. Chevenier2, N Baker1, S Lieunard3, S Murray3, T Le Flour3 & A Bazan3 1
Faculty of Computer Studies & Mathematics, University of West of England Frenchay, Bristol BS16 1QY FAX: (44) 1179 763860 Email:
[email protected] 2
PPE Division, CERN, Geneva, 1211 Switzerland FAX No: (+41) 22 767 4400 Email:
[email protected] 3
LAPP, IN2P3, Annecy-le-Vieux, France FAX No: (+33) 04 50 27 9495 Email:
[email protected]
Abstract At a time when many companies are embracing business process re-engineering and are under pressure to reduce "time-to-market" the management of product information from creative design through to manufacture has become increasingly important. Traditionally design engineers have employed Product Data Management systems to coordinate and control access to documented versions of product designs. However, these systems provide control only at the collaborative design level and are seldom used beyond design. Workflow management systems, on the other hand, are employed to coordinate and support the more complex and repeatable work processes of the production environment. Most commercial workflow products cannot support the highly dynamic activities found both in the design stages of product development and in rapidly evolving workflow definitions. The integration of Product Data Management with Workflow Management could provide support for product development from initial CAD/CAM collaborative design through to the support and optimisation of production workflow activities. This paper investigates such integration and proposes a philosophy for the support of product data throughout the full development and production lifecycle. Keywords: Workflow management, product data management, scientific application, Object databases.
1 Introduction In the process of product development, from design to implementation, management of product design information is paramount. This is especially true when manufacturers are having to optimise their process engineering so that product development times and "timeto-market" be reduced. As the complexity of products increases - these days composite products are being manufactured with hundreds of thousands of component parts - so does the requirement for the use of computerbased management products. Furthermore, distributed production of products requires that product data and documents be available across local- and wide-area networks and that there is coordinated access to the product data. Product data management (PDM) tools have been used for some time by manufacturing companies such as Mercedes-Benz and Ford to manage the data and documents accumulated in the design of their products. These systems are normally based on commercially available PDM systems such as Adra’s Matrix, IBM PM or Sherpa. The features of PDM systems include data vault and document management, product structure management, project programme management and workflow definition management [1]. PDMs have been successfully employed to control the data and documents emerging from the creative and collaborative stages of product design (e.g. CAD/CAM) where product structures
Detector Simulation Feasibility Study
CAD Tools: Euclide PDM
Mechanical Design Detector Analysis
&
Prototype(s)
WFMS Construction
Offline/Online Software
Operation & Maintenance
Figure 1 A typical product development lifecycle showing the role of CAD/ CAM tools, a PDM and a Workflow Management System (WFMS). tend to be hierarchical in nature and when access to documents needs to be controlled between groups of designers (using e.g. folder management). However, although PDM systems provide good support for product documents and data particularly at the early stages of design, their use in supporting the unstructured processes inherent in product development is somewhat limited [2]. Also PDM systems provide few facilities for activity definition and no facilities for the enactment of production activities. Workflow management systems [3], on the other hand, allow managers to coordinate and schedule the activities of organisations to optimise the flow of information or operations between the resources of the organisation. Commercial workflow management systems and research products are becoming available for the storage of workflow-related information and in the capture of audit trails of workflow operations. These systems seem to be appropriate tools for supporting the enactment of defined workflow operations. Workflow systems are weak at handling the dynamic evolution of process definition which occurs during the design process and can occur even during the enactment of workflow processes. Typically, in manufacturing systems, engineers use a PDM and production managers use Production Planning Systems and/or workflow management software. Design control and production control are separated and there is little or no cross-talk between the two. This despite the fact that design changes need to be reflected quickly into the production environment to reduce development time. The provision of continuity from design to production through the provision of consistent part data is therefore a high priority. The integration of PDMs with workflow management software to provide consistency and continuity seems appropriate. In manufacturing systems the
PDM can then manage the definitions of the product and workflow data and the Workflow software can cater for the instantiation, scheduling and enactment of those definitions. Up to now this marriage has only been proposed for the capture of design information in manufacturing [4]. This paper outlines how PDM and Workflow management systems can be integrated to facilitate the support of the full product development lifecycle in manufacturing from design through to operation of (versions of) the final production line. The example used in this paper draws on experience in the development of a workflow system for a scientific application which is being carried out at CERN, the European Centre for Particle Physics. The CRISTAL system [5] is being developed to manage the data collected and dynamic processes invoked in the construction and assembly of the Compact Muon Solenoid (CMS [6]) experiment due to be run at CERN from 2004 onwards. The nature of the construction of CMS is heavily constrained by time and budget, is research-based (and thus apt to evolve rapidly) and is highly distributed. It is thus a challenging environment to investigate PDM and workflow integration. Further detail on CRISTAL can be found in [5 &7].
2 Product Breakdown Structure (PBS) and PDM The development lifecycle of a large high-energy physics detector is much like any other large-scale construction activity in that it follows a design-prototypeimplement cycle (see figure 1). Since the nature of detector construction is highly dependent on state-of-the-art materials and techniques it does differ from industrial production in that it is highly iterative and consequently dynamic in execution. At the outset of the development a
PartDefinition
CompositeMember
CompositePartDefinition ElementaryPartDefinition
Figure 2 The product breakdown structure in the CRISTAL data model study is carried out (on the basis of some simulations) control and minimise the impact of material, product and which accesses the feasibility of detector construction. The process changes that occur in complex manufacturing simulation studies provide the predicted behaviour of the lifecycles. PDMs comprise a set of integrated applications detector materials under operational conditions and are thus that improve the efficiency of people and processes dependent on the state of technology at the time of involved in the design, production and assembly of system simulation. Similarly the mechanical design of the detector parts. is somewhat dictated by the choice of materials as well as A product breakdown structure (PBS) approach to physics considerations. The overall performance of the design is also advocated by Bachy & Hameri [11] in the detector is highly dependent on its design and therefore any design of the LHC [12] accelerator. According to [11], any changes in design need to be permeated through from PDM system used for the engineering of large-scale one-ofconceptual design to physical construction as quickly as a-kind facilities should hold the descriptions of both the possible. The importance of rapidly reflecting design PBS and the work breakdown structure (WBS) in addition changes in production activities is typical of many to the assembly breakdown structure (ABS). The PBS saves examples of manufacturing engineering. Reduction in the information pertaining to projects, sub-projects, time between design and production is critical to reducing documents, items etc. The WBS holds information about product development times and "times-to-market". the organisation of tasks (or activities) to be performed and Typically CAD/CAM systems (e.g. Euclide at CERN) the resources required for each task. The ABS holds data are employed by mechanical engineers to specify the about how component parts (and composite parts) are design of detector components. As a consequence of this assembled to form the overall final product (CMS in approach engineers tend to have a part-oriented view of the CRISTAL). The ABS and WBS define the activities which construction process. Conceptual design is a collaborative enable the engineers to build the production line and the activity with designers checking-out and checking-in production line can be viewed as a collection of (versioned) documents and diagrams of components under a policy of workflows. The ABS and WBS hold the definitions of the configuration management [8]. The database (and data production line and can be mapped onto workflows (see vault) aspects of a PDM lend themselves well to this following section). creative design process (figure 1). Product breakdown (in Essentially the purpose of building a PBS for industrial industry often referred to as "Bill Of Materials" (BOM)) is applications in a PDM is to facilitate the capture of a design often strictly hierarchical in form and attributes can be hierarchy of parts. This enables the design of individual assigned to each part or sub-part. Objects located in the product constituents and provides a structure for ordering product hierarchy can go through several stages of and cost tracking. As the product becomes more complex in development so that "state" can be assigned to a part and structure, however, a parts explosion can take place in the can be managed by the PDM. PDM and data management becomes a problem. In the The advantages of using a PDM are well-documented example of CRISTAL, the CMS detector will be elsewhere [1,9 & 10]. With a PDM data is centralised, constructed from millions of individual parts many of versioned and can be used for tracking design in a which will be identical in nature. It is simply infeasible to environment which supports collaboration on creative enter and manage these parts individually in the PDM. work. PDM systems provide a change management service Instead, a concept of meta-data management can be which can be used by engineering applications to assess, followed to alleviate this problem where definitions of parts
PDM: CERN Engineering data management system for Design PBS Product Breakdown Structure (Part Specification)
ABS Assembly Breakdown Structure (Part Specification)
WBS Work Breakdown Structure (Task Specification)
Mapping from Design to Production
WfMS: CRISTAL Production management facility Production Workflow definition (Workflow models)
Production Workflow instances (Workflow enactment)
Centralised database for models
Distributed databases for production data
Figure 3 The relationship between CRISTAL and PDM (a PDM). The PDM constitutes a centrally-available product description and the WfMS constitutes the actual processes required to produce the final product(s). are captured in the PDM and instantiations of these the product lifecycle (see figure 1) and to facilitate quality definitions are (re-)used to form the PBS. Figure 2 shows an control and production management. OMT [13] object model of the product breakdown structure The main components of a workflow management which underlies CRISTAL. A part definition is the entry system are a workflow application programming interface point for all the information required to produce, build and and a workflow enactment service. The workflow characterise any part of a detector which has been application programming interface allows for the registered in the system with that definition. Part definitions specification of workflows and workflow activities (which are either elementary or composite in nature. Composite may be composite in nature) and for the specification of parts are made up of other parts and the CompositeMember activities to resources (people, machines etc.). The object reflects membership of a part in a composite. workflow enactment service consists of an execution In implementing this meta-data management the tree interface and an execution service provided by a so-called representation of assembly breakdown is transformed into workflow engine. The engine is the component that a graph representation. Individual parts (of the same type) executes the static workflow (production) descriptions are then associated with common definitions which which were defined through the programming interface and provides ease of data management and it is still possible to provides run-time services capable of managing and derive the full tree structure for assembly from the graph executing those instances. Workflow products normally representation. subsume both the specification and enactment of workflows. Therefore to achieve integration between the PDM and 3 Integrating PDMs with Workflow Manageworkflow components of CRISTAL, the PDM can be used ment to store a sets of definitions (or a design model) of both the A workflow management system (WFMS) [3, 14] is a parts and the tasks that need to be executed on the parts. The system that completely defines, manages and executes workflow definitions are mapped onto the WBS/ABS and workflows through the execution of software whose order the workflow instances can therefore be derived from their of execution is driven by a computer representation of the definitions residing in the PDM. The PDM acts as the workflow logic. Workflows are collections of human and reference database both for the activation and enactment machine based activities (tasks) that must be coordinated in services of the production workflow system and for other order that groups of people can carry out their work. In systems (e.g. mechanical engineering) and manages CRISTAL it is the workflow system that “glues” together (versions of) the PBS, the ABS and the WBS. the different organisations, operators, processes, data and The CRISTAL system sits alongside the PDM and centres into a single coordinated managed production line. allows for the execution of tasks upon parts (see figure 3). CRISTAL is used to support information collected during It manages the execution of the tasks and collects the output the prototyping, construction and maintenance activities of of the resultant measurements and tests. CRISTAL is, in
StartConditions&Locations
WorkflowModel
PartDefinition
PartCompositeMember
CompositePartDefinition
WFCompositeMember CharacteristicElementDefinition
ElementaryWorkflowModel
ElementaryPartDefinition
CompositeWorkflowModel
Figure 4 The PDM data model for CRISTAL effect, the execution (or enactment) service of instances of are used to support production in a distributed environment. the workflows as defined in the WBS and ABS parts of the Workflow (activity) definitions can be either elementary or PDM. As a consequence of this, CRISTAL will need to be composite in nature. Composite workflow activities can be able to access the PDM for part definitions and tolerances composed of several other workflow definitions and the and for the specification of detector assembly sequences. membership of a workflow definition in a composite All the engineering drawings, blueprints, construction workflow has been modelled. Physical characteristic procedures, part definitions and part nominal values elements (such as dimensional measurements of parts) are together with the workflow definitions and their captured as a consequence of the execution of an compositions will be stored in the Product Data manager. elementary workflow definition. CRISTAL consequently integrates a production data This method of integrating PDM and workflow management and workflow management facility and through the definition of a common data model allows other controls and tracks parts through the manufacturing life links to be made between the workflow model and the cycle from a PDM-resident design to the final construction product data model. For example, links can be made to and assembly of the detector. allow version management of different product data model In the same way that the PBS has been modelled in the (as proposed by [4]) or to the assignment of workflows to CRISTAL data model, the workflow definitions (ABS/ parts for tracking part maintenance. WBS) of CRISTAL can also be modelled. Figure 4 shows the overall data model. Each part definition has at most one 4 Handling Versions of Production workflow definition assigned to it. Workflows can be reused for several part definitions. A part definition is an The specifications of industrial manufacturing item of the PBS, the workflow definition is the workflow production lines are required to evolve over time. The meta-object (ABS/WBS) or process definition which must processes (or workflow activities) which need to be be executed when a part with that definition is registered in executed to constitute the production line may change in the CRISTAL system. A workflow meta-object is an order or in specification New activities may be inserted into ordered collection of workflow activities definitions which the production line or existing activities may be amended or will be executed on every part registered in the CRISTAL deleted. In addition to this new products may be specified system with this corresponding part definition. Each which may follow an existing production line or may workflow activity definition corresponds to a subrequire a completely new specification of the production workflow meta-object which is the sub-process to be line. executed to satisfy this definition. The production line in CRISTAL (the detector There are a set of so-called start conditions and production process) is the set of workflow activities which locations required for each assignment of a workflow has to be executed on all the parts constituting the detector definition to a part definition. These are essentially the part for construction. The overall production coordinator objects and locations required as prerequisites for the monitors the detector production process and, if necessary, initiation of a workflow on a part definition. The locations amends its definition via the PDM. Such actions will
Detector Production Scheme
Detector Production Scheme Current Version
Detector Production Scheme New Version
Detector Production Scheme Old Version
becomes becomes describes Detector Production Process
Detector Production Scheme History
Figure 5 Versioning strategy for the Detector Production Scheme inevitably result in reallocation of tasks and parts and will require new versions of the detector production process. CRISTAL and the PDM must therefore be able to cope with multiple versions of part definitions, task assignments and production processes and allow seamless navigation between these parts and processes. The strategy used in CRISTAL is based on version management of the objects as defined in the PDM to enable the automatic computation of the amended workflows and the consequent allocation of parts to workflows. The detector production process is completely described in the current version of the so-called Detector Production Scheme (see figure 5). Amendments to be applied to the Detector Production Process are described in the new version of the Detector Production Scheme. When they take effect, the new version of the Detector Production Scheme becomes the current version and the current version is moved to the version history. At any time there can be at most one new and current version of the Detector Production Scheme. Online, the Detector Production Process is not versioned, it is amended to correspond to the new version of the Detector Production Scheme. Any version in the version history can be browsed. These mechanisms ensure that any changes to the specification of the production processes can be folded through to the active detector production.
5 Conclusions and project status CRISTAL development was initiated in early 1996 at CERN and a prototype capture tool was developed to allow existing aspects of CMS construction to be incorporated in
an object database. The second phase of prototyping and technology evaluation was initiated in the summer of 1996 and development of this prototype is well under way based on a commercial PDM. Cadim [15] is the commercial product selected by the PDM task force [9, 16] at CERN to support the PDM functionalities required for the LHC accelerator and experiments. All the PDM functionalities required by CRISTAL will be put in Cadim. The PDM is used in CRISTAL to store the full specification for detector production. It will contain all the definitions of individual parts and will describe what is to be built and how it is to be built. The PDM specifications are defined and held centrally. The workflow specification is derived from the PDM specification (PBS/ABS/WBS). It will define the process of part characterisation and the complete assembly process from single parts to full-scale detector. In essence, the PDM is used as the schema of the workflow metaobjects. The CRISTAL project has elsewhere shown the viability and importance of adopting a dynamic objectoriented approach to the development of complex system software in a rapidly changing application environment and where many implementation choices need to be deferred [5]. Since the project’s inception a considerable amount of interest has been generated in meta-models and meta-object description languages [17]. Work is in progress within the OMG on the Meta Object Facility (MOF) [18] which is expected to manage all kinds of meta-models which are relevant to the OMG Architecture. Two which are of particular significance to the CRISTAL project are the Manufacturing’s Product Data Management Enablers[19] and Work Flow Facility[20, 21] meta-models. The second
phase of the project aims to adopt this more open architectural approach in the hope that it will produce a more adaptable system capable of interoperating with future systems. This meta-modelling approach will facilitate further integration between product data management and workflow management thereby providing consistency between design and production and speeding up the process of implementing design changes in a production system.
6 Acknowledgements The authors take this opportunity to acknowledge the support of their home institutes. In particular, the support of P Lecoq, J-L Faure and J-P Vialle is greatly appreciated. The help of N.Baker, A. Bazan, T Le Flour, F. Estrella, S. Lieunard, D. Rousset, E. Leonardi, G. Barone, G. Organtini and W. Harris in creating the CRISTAL prototypes is also recognised. References [1] M. Philpotts "An Introduction to the Concepts, Benefits and Terminology of Product Data Management", Industrial Management & Data Systems, 1996 4 pp11-17 [2] P. Pikosz & J Malmqvist, "Possibilities and Limitations when Using PDM Systems to Support the Product Development Process" Proc of NordDesign’96, Helsinki, Finland. [3] D. Georgakopoulos, M. Hornick & A. Sheth., "An Overview of Workflow Management: from Process Modelling to Infrastructure for Automation", Journal of Distributed and Parallel Database Systems 3 (2), April 1995, pp119-153. [4] J. Ramanathan "Process Improvement and Data Management", IIE Solutions, 1996 28 12 pp24-27. [5] J-M Le Goff et al., "CRISTAL - Co-operating Repositories and an Information Systems for Tracking Assembly Lifecycles". CERN CMS NOTES 1996/003 and 1997/104.
IEEE Basque International Workshop on Information Technology (BIWIT), Biarritz, France July 1997. [8] P.H. Feiler., "Configuration Management Models in Commercial Environments", Technical Report, CMU/SEI-91TR-7, ESD-91-TR-7, March 1991. http://www.sei.cmu/~case/ scm/abstract/abscm_models_TR07_91.html [9] A. P. Hameri., "EDMS - Concepts, Motivations and Basic requirements". Proceedings of the CERN School of Computing 96, CERN 96-08. [10] P. Pikosz & J Malmqvist, "Strategies for Introducing PDM Systems in Engineering Companies". Proc of the 4th ISPE Int Conf on Concurrent Engineering, Rochester, USA, 1997. [11] G. Bachi & A. P. Hameri., "What to be Implemented at the early Stages of a Large-Scale Project". CREN MT/95-02 (DI) LHC Note 315. [12] “The Large Hadron Collider Accelerator Project”, CERN AC93-03 1993 [13] J. Rumbaugh et al.,"Object-Oriented Modelling and Design", Prentice Hall Inc., 1991 [14] T. Schall., “Workflow Management Systems for Process Organisations”, Lecture Notes in Computer Science 1096 Springer Verlag 1996 [15] Cadim: a PDM product developed by Eigner & Partner, URL=http://www.ep-ka.de/ [16] CEDAR Project Home Page, URL=http://cadd.cern.ch/ cedar/ [17] R. Laddaga & J. Veitch Guest Editors, "Dynamic Object Technology", Communications of the ACM May 1997 Vol.40, No 5, pages 37-69 [18] Object Management Group Publications, Common Facilities RFP-5 (Meta-Object Facility TC Document cf/96-02-01 R2, 5/ 13/96 [19] Object Management Group Publications, Product Data Management Enablers RFP, Manufacturing Domain Task Force Document mfg/96-08-01
[6] CMS Technical Proposal. The CMS Collaboration, Jan. 1995. ftp://cmsdoc.cern.ch/TPref/TP.html
[20] W. Schulze, K. Meyer-Wegener, M. Bohm: "Services of Workflow Objects and Workflow Meta-Objects in OMGcompliant Environments", OOPSLA’96 Workshop on Business Object Design and Implementation, October, 1996, San Jose, CA
[7] R. McClatchey et al., "Object Databases in a Distributed Scientific Workflow Application". In Proceedings of the 3rd
[21] Object Management Group Publications, Workflow Facility, Draft Request for Proposal, v 1.0 Document cf/97-03-14
