Dynamic process management for engineering environments R.J. Mentink’, F.J.A.M.van Houten’(l), H.J.J.Kals’(1) ’Laboratory of Design, Production and Management, Faculty of Engineering Universlty of Twente, Enschede, the Netherlands
m c t The research presented in this paper proposes a wncept for dynamic rocess management as part of an inte rated a proach to engineering process support. The theory of informaion mans ement is the starting point for B deve opment of a process management system based on evolution of informakm wntent. The use of an ontology enables the formalization of information content. Based on this ontology, trsnsition relations and task definitions can be instantiated. A methodology for the generation of task networks is presented. From these networks, process models can be derived in the form of task chains.
R
P
Keywords: Engineering, Process management, Information management
1 INIRODUCTION With increasing wmplexrty of both products and product development processes, the management of these processes is bewming ever more challenging. The current trend towards increasingly concurrent exewtion of processes further increases the need for communication and information sharing. Engineers require tools that aid them in navigating the available information, as well as, the available process-steps. The range of applications that are developed under the umbrella of Computer Supported Collaborative Work (CSCW) is quite extensive. However, wntemporary sothare solutions for process management that are applied in collaborative environments generally diminish the Rexibillty in the exewtion of engineering processes. The use of predefined scenario’s and process models for the control of unstructured processes contributes greatly to this problem, as can be concluded from literature [I] [2]. The need for dynamic process models that can be generated at, what is traditionally called, run-time is apparent. Furthermore, in order to be able to improve the efficiency of process exewtion it is important to use historic process information in the generation of new process-models. Finally, in order to best support an engineer during the exewtion of his tasks it will be important to be able to give insight in the consequences of decisions. 2 WORKFLOW MANAGEMEHT Both industry and academia are investing in the development of workflow management systems. The development of workflow management systems started some twenty years ago. This development has led to a variety of systems that mostly constitute domain specific solutions for process automation. It is generally accepted that workflow management systems should provide Rexibillty [3] [4],However, the inabilityto deal with changes still limits the application of today’s workflow management systems [q,Furthermore, wrrently there is no generally a m p t e d classification of workflows available. However, one of the most widely used classifications, first proposed in [6] distinguishes among ad-hoc workflows,
administrative workflows, and production (or transactional) workflows. In workflows are also characterized along a wntinuum from human-oriented to system-oriented. In human-oriented workflows, human agents cooperate in the wordination and exewtion of tasks, while system-oriented workflows are highly automated and involve the exewtion of complex sothare tasks, with little human intervention. Van der Aalst proposes another classification of the workflow specbvm [q.Here a distinction is made between unshuctured, information centric approaches and struuctured process centric ones.
m
Collaborative engineering processes can be characterized as unstructured and information centric by nature. Workflow management solutions for this type of processes should in terms of classification be sought among the ad-hoc solutions. However the wmplexrty of the processes involved renders the currently available solutions inept. The support of these engineering activities and the workflow functionallty that we are proposing to this end, belongs in the domain of CSCW as depicted in Figure 1, 2.1 Workflow modeling In general the dominant feature determinhg the (in-)flexibillty of a workflow management system is the process model that is employed. As a result, a large portion of the research and development eRort is directed towards expanding process models, in order to enable process
-I um-
R hf-m
m
c
RDEcrr
m
Figure 1, The workflow specbvm (redrawn from
c
[q)
model extensions, exception handling and adaptations. Many workflow management systems inwrporate an application specific workflow language, which is oRen represented by means of a graphical interface. Numerous approaches to workRow modeling can be found in literature (see [2] [q),However, some modeling techniques stand out for their suitability for workflow analysis, such as, workflow graphs [8] and workflow nets [q,The models created with these techniques can be easily transformed into mathematical process representations. This facilitates the verification of the w r r e h e s s of workflow process models, for example, by detection of dead locks or synchronisation faults. Workflow management for engineering environments Workflow solutions for engineering environments are scarce because of the dynamic nature o f the processes involved. However, in recent years there have been a few initiatives to develop solutions in this field. At Daimler-Chrysler the WEP-model was developed (WEP = Workflow for Engineering Processes) [g]. The WEP-model inwrporates the definition of alternative p r o a m branches in orderto be able to define process alternatives. However, this approach still requires the definition of every exception on beforehand or, if unforseen, aRer its ocwrrence as a disturbance to the workflow process. Wth respect to the afore mentioned classifications, this system can be characterized as an adaptive workflow management system by means of exception handling. In another research effort, the SIMNET project [lo] has evaluated the possibilities for product-data driven engineering workflows. The SlMNET project introduced engineering workflow as a wmbination of both 'classical' and product data wntrolled workflow. The product data wntrolled workflow is defined using a set of 'product defining parameters'. This set of parameters has to be defined for each product development project. The parameters are used to provide a link between the product, processes and people involved in the workflow. The SIMNET project does present an alternative approach for the workflow support of engineering a m e s . However, the use of 'arbitrarily' selected parameters, that have to be defined for every new project, requires wnsiderable structuring on beforehand. As a result, the procedural character of traditional workflow management is transferred to the parameter negotiation phase. Nevertheless, another interesting aspect of the SlMNET mncept is that the parameters can also be used to define engineering change propagation, albeit limited to the predefined parameter network only. 29
3
ENGINEERING PROCESS SUPPORT
3.1 Information Management A concept for information management in manufacturing [ I l l has been developed at the author's laboratory This research provides the basis for the Engineering Process Support (EPS) wncept that is presented in this paper. The main wnstituents of information management are three information structures (for order, product and resource information). They provide a robust and transparent way of dealing with information in the manufacturing environment. Emphasis is placed on the formalization of information content u t i l i n g ontology. Wthin the ontology, a distinction is made between relations of 'state' and relations of 'bansition'. The representation of both information structures and ontology is realized by utilizing wnceptual graphs.
In the research presented in this paper, transition relationships are used to rewrd the evolutionary dependencies between information entities, for example, how an enbty has been generated 'based on' or 'in wmpliance with' another entity. The approach to stationary and transition relationships differs from the approach presented in [Ill,in which transition relationships are registered between different types of information entities in the ontology. In the latter approach, the transition relationships form the foundation for process wntrol. Here, the ' f a d that, for example, a 'production plan' presupposes a 'process plan' would be included in the ontology and implies that the tasks that are able to generate 'production plans' must always precede the tasks that are able to generate 'process plans'. However, such a generalization on how different types of information entities depend on each other cannot be made. For this reason, transition relationships must not be defined in the ontology, as unilateral dependencies between specific types of information entities. The ontology must only specrfy the meaning of the types of transition relationships that may exist in the swpe o f the ontology. In the information structures, these transition relationships can be applied to record the evolution of sets of specific information entities.
39
Engineering p r o w support concept
The engineering process support (EPS) wncept is aimed at wordinating and supporting activities based on evolving information wntent. The wncept is divided in three main functional components, which address. process management, decision support and knowledge management respectively. There is a strong wrrelation between these three components, for example, between process management and knowledge management, where historic process information aids the wnstruuction of new process models. A prerequisite for the realization of the wncept presented in this paper is the availabilty of an integrated representation of the relevant information in a manufacturing environment. A methodology enabling the integration of information, by translating information from various information sources into a representation based on an ontology is described bywjnker [12].
As stated in section 3.1, the use of transition relationships enables the representation of the evolution of information content. This evolution is a direct consequence of the exewtion of engineering processes. The abilty to link process steps (tasks) to steps in information evolution subsequenw creates the possibilty to perform process management based on information evolution, as will be explained in section 4 . Furthermore, the introduction of transition relationships in a product information structure enables its use as a process information structure as well. As a result, a product information structure contains
Figure 2.
The architecture for EPS related to Information Management and Engineering Workbenches.
information that describes the process history, represents decision paths and impliatiy captures engineering rationale. In rewgnizing the fact that process information can now be distilled from the product information structure, it bewmes possible to analyze historic process information and use these anatyses in future process instances. As the above points out, the use of the IM-wncept and the definition of transition relations in information structures creates integral possibilities for. process management, decision support and 'knowledge' management as wmponents of an integral approach to engineering process support. EPSArchiteehrre For the development of the EPS wncept an architecture has been defined (see Figure 2). The EPS functionalty is depicted here with respect to the information management functionalrty and the engineering (task) workbenches [12]. The information management functionalty provides a m s s to the integrated information and signals changes in its wntent. The engineering workbenches are the platform through which the task suggestions, decision support functionalty, customized information and s o b a r e tools are presented to the engineers. 3.3
The EPSfunctionalty is divided inthree main components. The propagator enables the calculation of propagation effects of changes in or additions to the information structures as well as the ontology. This functionality can be employed to calculate the effect of both actual as well as hypothetical changes. Consequentiy, the utilization of the propagator as a decision support tool is possible. The history manager provides the capabilty to analyze past product information structures. Based on both structural and transitional relations it can deduce and wmpare process steps and process paths. These evaluations can be utilized as reference knowledge in the generation of new process models. The process manager represents the heart of the engineering workflow support functionalty. Here, process models are generated, tasks are selected, and progress is monitored.
4 PROCESS MODELING IN THE EPS CONCEPT The process modeling functionalty is part of the 'process manager' wmponent (Figure 3). The process modeling functionalrty itsetf is demmposed into 'Goal setting', Task network generation' and Task chain selector'. The methodology that has been developed for the generation of process models is based on linking task definitions to information content. 4.1 Tasks Wthin this research, a task is defined as a systematic set of defined work to be done or undertaken in order to arrive at a specified result and to achieve a directed, predictable and desired evolution inthe information wntent. Atask can be defined independent of the level of aggregation, from which it is reasonable to argue that a task can wnsist of (sub-]tasks that together can realize the work of the super task. As a result, task wmposition and dewmposition,
Figure 3 . Process Manager, functional wmponents.
allows the realization of process managementfunctionalty across different levels of aggregation. W h respect to information management, the exewtion of a task can be seen as a transition from a state established by a certain information wntent to another state, established by an evolved information wntent with added value. Consequentiy, a task can be seen as a process that needs and yields information. A Task instance is formalized as a set of information entities, within the resource information structure. In wnwrdance with the information management wncept [ I l l , this implies that in the ontology a task-blueprint' is available to aid in the definition of newtasks. This subset of the ontology is referred to as 'task ontology. As stated in the above, a task can be defined by the information it needs (input) and the information it yields (output). As a result, a task definition will specrfy the types of information entities together with their relations, for both input and owut The subset of a resource information structure that encompasses all task instances is referred to as the 'task structure'. Tasknelworks The individual task definitions can be linked to form task networks by mapping their respective inputs and outputs. In theory, when this is done for all tasks that have been defined within a manufacturing system, the resulting network will represent all possible process paths available to that system. As a practical application this linking of tasks enables the generation of specific goal oriented task networks. Such a network is represented as a graph consisting of tasks and information entities and it defines all possible pathsfrom the process goal to the current state in information wntent. In fact, these graphs can be regarded as a simplified form of the workflow graphs mentioned in section 2 . 1 , 49
The use of an ontology enables the expression of process goals in terms of types of information entities. Furthermore, the application of different levels of abstraction in the ontology acwmmodates the definition of structures wncepts that are relevant for a specific manufacturing environment [12]. For example, a process goal can be expressed in terms of a product taxonomy, which is a structured representation of the ontology that is applicable to a certain product family Network generation The process goal is used as the starting point for the generation of a task network. The network is wnstructed by reasoning back towards the current information wntent of the product information structure, thus realizing an information pull methodology for process modeling. The methodology is best explained with the aid of the definitions below in wmbination with Figure 4 . 4.3
The set C,with elements C,represents the wrrent information content of the product information structure The set Gs, with elements k,, represents the 'Goal' for step S The set Ts, with elements Ts,, represents the applicable tasks for step S. The graph P is defined by Gs,,and TsJ P represents the network that will enwmpass all task chains that are available to get from the current information state to the goal state The set N, with elements NT(s,,)represents the Task output elements that do not appear in G(s1)
I
L w p (untll all C, WE In P): Fw S,(I: D,..,n): Add a,, (I: D,..,n) to P Fw B,, (I: D,..,n}: Select sll Tssks for wMeh a,, Is output Lstm unlqueTssksT,, Add T ,, ta P Fw T,,(k D,..,n): F h d Y,, Add &,cl'to P
Figure 4. Network generation, graphical representation and algorithm. The generation of the task network (P) is divided in a number of discrete steps (S). For every step a temporal The tasks that can process goal is specified (Gs). contribute to reaching this goal are added to the graph P. Next, the input specifications of these newly selected tasks are defined as the new process goal (%+I).
m
In the resulting network (graph P), an optimal path can be found by applymg a network planning algorithm, for example the A' algorithm. However, in orderto enablethis, the tasks in the network have to be valuated and assigned 'wst' and preference parameters. Both operational information, (such as, resource availabilty) as well as historic information is used to define these parameters. For example, mean task exewtion times, SUCCBSS rate, etc. can be distilled from historic information shctures. Concurrent activities bewme apparent as a result of the process modeling methodology, since multiple branches to the wnent information wntent will appear. The first task(s) in the task chain are presented to the appropriate engineers through their workbenches. When tasks are executed, information is generated and as a result the state of the information structure changes. Consequenb, the current task chain will be evaluated to determine if it is still the optimal process solution. This illustrates the manner in which the process model reacts to the evolution of the information wntent. The process models are generated and evaluated at run-time. 4.4 Customirable control The choice of wntrol strategy applied to the proposed process models is as flexible as the process models themselves. However, there is a tradeoff betweenflexibilty and possibiltyfor wntrol and monitoring of activities within the wncept. On one end ofthe specbvm a fully suggestive implementation is possible that offers engineers task lists with alternatives, but does not enforce any specific wurse of action (much like a car navigation system). This situation inherenb offers little possibility for direct wntrol. On the other end, a situation where activities are imposed rather then suggested dearly yields less flexibilty, yet offers direct wntrol. The EPS wncept allows for the wstomization of the level of wntrol fitting the needs of the manufacturing environment. 5 CONCLUDING REMARKS Control and support of design and engineering processes requires a flexible system that is able to monitor and act on the evolution of information wntent. The wnent generation of workflow management systems is still inept in dealing with dynamic processes. The introduction of transition relationships between information entities enables the realization of process management, decision support and knowledge management functionalty on a
wmmon basis. The process modeling methodology presented here as part ofthe Engineering Process Support wncept introduces the possibility of dynamically generating process models based on the evolution of information wntent. These process models guide task exewtion on the basis of an information pull principle. The methodology allows for customization of the wntrol strategy. 6
REFERENCES Sadiq, S., Sadiq, W., Orlowska, M., 2001, Pockets of Flexibilty in Workflow Specification, ER 2001, LNCS 2224, pp, 513-526, 2001. Springer-Verlag Berlin Heidelberg. Myers, K.L., Berry, P.M., 1999, At the Boundary of Workflow and Al, In Proceedings of the M I - 9 9 , Workshop on Agent-Based Systems in the Business wntext, Orlando, Florida.
Klein, M., Dellarocas, C., Bemstein, A. (ads), 1998, Proceedings of the CSCW-98 Workshop, Towards Adaptive Workflow Systems, Seattle.
Han, Y., Sheth, A,, 1998, On Adaptive Workflow Modeling, In Proceedings of the 4th International Conference on Information Systems Analysis and Synthesis, pages 108-116, Orlando, Florida. Aalst van der, W.M.P., Himschall, A,, Verbeek, H.M.W., 2002, An Alternative way to analyze Workflow Graphs, Conference on Advanced Information Systems (CASE) 2002, volume 2348 of Lecture Notes in Computer Science, pages 535-552, Springer, Berlin, 2002. McCready, S., 1992, There is more than one kind of workflow s o b a r e , ComputerWorld, November 1992. Georgakopoulos, D., Homick, M., Sheth, A,, 1995, An Overview of Workflow Management. from Process Modeling to Workflow Automation Infrashcture, Distributed and Parallel Databases, vol. 3, n. 2. Sadiq, W., Orlowska, M.E., 2000, Analyang Process Models using Graph Reduction Techniques. Information Systems, 25(2).117-134. Beuter, T., Dadam, P., Schneider, P., 1998, The WEP Model. Adequate Workflow Management for Engineering Processes, Proc. European Conwnent Engineering Conference 1998, Erlangen-Nuremberg, Germany. [ l o ] Schmitt, R., G o b , M., Caskey, K., 2000, Methodology for linking engineering workflow to product data, Public deliverable n 0 . W of ESPRIT program EP26780, Siemens Verkehrstechnik GMBH. [ I l l Lutters, D., 2001, Manufacturing integration based on information management, PhD. thesis, Universty of Twente, Enschede, ISBN90-365-1583-1 [I21 Wjnker, T.C., 2003, Integration of information in manufacturing systems, PhD. thesis, Universty of Twente, Enschede, ISBN90-365-1867-9