A Workflow Formation Architecture for the Automotive Sector Sven Till
[email protected]
Rik Eshuis
[email protected]
Paul Grefen
[email protected]
Eindhoven University of Technology, Department of Technology Management Postbox 513, 5600 MB Eindhoven, The Netherlands Abstract Companies in the automotive sector have been forced to react on trends, such as an increasing globalization and decreased numbers of cars per type. This resulted in new forms of cooperations, called Networks of Automotive Excellence (NoAE). Interoperability between the parties within such networks is crucial. For parties to operate effectively together, they have to align their local workflows. This can be done by forming a global workflow which coordinates the local workflows. To overcome the current manual timeconsuming, expensive and error prone formation, we propose a functional architecture for automated workflow construction and evaluation. This architecture enables not only a fast and cheap formation of global workflows but also their evaluation. An example illustrates the architecture.
1. Introduction The main trend in the automotive sector is that the overall number of cars and car types produced is increasing, while at the same time the lifecycle of a car type is shortening [8]. To cope with this trend, OEMs are outsourcing more and more parts of their production towards their suppliers. Figures show that the suppliers have taken over more and more activities and responsibilities from the OEMs in each phase of the lifecycle of a car, including the design and development phases [12]. At the same time, OEMs also tend to reduce the number of their suppliers in order to diminish the organizational burden. This means, OEMs do not outsource small components or standardized parts, but whole systems or large modules to their suppliers (tier 1 suppliers). In addition, these suppliers themselves can outsource part of their production to suppliers at lower tiers (see Figure 2 in [8]) Suppliers are usually small- and medium-sized enterprises (SMEs), which are not able to deliver big modules or even complete systems as expected from the OEMs. However, SMEs can form networks on a project or order base. The objective of such Networks of Automotive Excellence
(NoAE) [3] is the organization of temporal cooperations between suppliers in the areas of development and manufacturing. NoAEs can develop and deliver components of a car that are larger than the ones a single supplier can provide. In such an automotive network, the expertise, competencies, and capacities of the suppliers are combined and coordinated. The formation of such a network is rather complex and triggers a lot of technical and business related issues. One main issue is the integration of all the business processes of the involved partners. This requires an alignment of the business processes and their corresponding workflows which are executed locally on the suppliers’ side. This alignment is done by forming a global, i.e. crossorganisational workflow, that connects all local workflows of the collaborating suppliers. According to the studies done within the European CrossWork project [7], so far, the formation is mainly done manually in workshops. This manual formation can be lengthy, and therefore rather costly. Moreover, the formed workflow which is described on paper can still contain errors, e.g. dead- or live-locks. Such errors are typically discovered during enactment of the global workflow. Repairing the workflow might be costly at that stage. In this paper, we propose a workflow formation architecture that can be used to (semi-)automate the formation of global NoAE workflows. This way, formation can be done in a cheap and fast way. Moreover, important requirements like absence of deadlock can be checked before the workflow is actually deployed. Related work. Many initiatives from industry and the research community have dealt with workflow formation issues. New technologies such as Web Services, new software engineering paradigms such as Service Oriented Architecture, and new languages such as the Business Process Execution Language - BPEL [4] and the eXchangeable Routing Language-XRL [17] have been developed in order to support the IT cooperations of organizations. Some projects have focussed on the special issues of workflow
formation and service composition, such as CrossFlow [10], Ambroszkiewicz [1], DySCo [13] and eFlow [5]. In some research projects, such as [1, 13, 5], services provided by companies are only considered as black boxes and their internal workflow structures, like internal tasks and their ordering, are ignored. Though the internal structure of a service is usually considered private by a company, when collaborating with other companies, it might be fruitful to disclose parts of this internal structure as a white box service [11, 6]. For example, by offering a white box service, consumers could receive some results already when they are produced, while consumers of a black box service have to wait for the entire internal workflow to finish before getting all results. Clearly, global workflows consisting of white box services are much faster and more controllable than those consisting of black-box services only. Other projects, for example CrossFlow [10], do consider white box services, but they assume that the service consumer can dictate the service provider the workflow structure it has to offer, i.e., the internal workflow structure of the provider has to adhere to the structure dictated by the service consumer. Advantage of this approach is that the process integration between parties becomes less complex and plannable in advance. However, the disadvantage is that the service provider might be forced to change its own workflow in order to comply to the workflow dictated by the service consumer. But such a forced change could be unacceptable for the provider, because it then has to change its internal process, while this optimised process is the main reason why the provider can do the job faster and cheaper than the service consumer in the first place. To summarize, the research up to now either neglected the internal structure of the workflow or it demanded a certain structure. Furthermore, a generic architecture for workflow formation has not been proposed. In this paper, we propose a generic functional architecture which first, supports the automation of workflow formation, including considering the internal structure of local workflows, and second, meets the requirements in the automotive sector. Structure. First, we give the context of workflow formation in form of a phase model. Then the workflow formation architecture is described and explained. In section 4 we give an illustrative example to show that the architecture works. We end with conclusions.
2. Phase Model Figure 1 shows a workflow formation cycle. The cycle consists of three phases. In the first phase, the requirements and constraints for the workflow formation are defined. The requirements contain the description of the workflow model elements which should be arranged and the con-
Requirement Definition
Workflow Formation
Workflow Enactment
Figure 1. Workflow Formation Cycle straints which restrict either single formation elements or the global workflow which is to build. The defined requirements are then used as input for the second phase - the workflow formation phase. In this phase, a new global workflow is formed, e.g. through orchestration or choreography. It is possible that the workflow formation is not achievable because of too restrictive requirements or missing information. Then this information is fed back to the first phase and the requirements have to be redefined. If the workflow formation is successful then the newly built global workflow is forwarded to the workflow enactment phase. The enactment is supported by information systems, such as workflow engines. The engines are configured based on the workflow specification. Is this not possible, e.g. because of missing functionality, then the workflow formation has to be executed again. During the enactment it can happen that the requirements or the environment, e.g. network members are replaced, change so much that the enactment cannot continue. Then, either in the case of small, repairable changes the formation phase is started again or in the case of fundamental changes the requirements definition phase has to start off. Necessary changes in the global workflow specification may not only be detected by exceptions but also through using process mining techniques [15] on data that are logged during the enactment. This workflow formation cycle model illustrates the context of the proposed workflow formation architecture. The architecture proposed in this paper supports the workflow formation phase and its interfaces towards the requirement definition and the workflow enactment phases. The next section shows details of the architecture and a refinement of the formation phase.
3. Workflow Formation Architecture Having set the context by explaining the workflow formation cycle, in this section, we explain our workflow formation architecture including two workflow formation subphases by giving first an overview and then describing each sub-phase in more detail in separate subsections.
3.1. Overview As mentioned earlier, any disturbance in the fragile development or production process has to be avoided. Otherwise, it comes to costly delays. This observation leads to
Workflow Formation
Formation requirements
Construction
Evaluation Strategy rules
Local requirements
Enactment
Strategy rules
Requirement Definition
Workflow Construction
Workflow Evaluation
Analysis Document
Plug-in
...
Plug-in
Evaluat. rules
...
Evaluat. rules
Pattern Repository
Global requirements
Creation/ Rewrite rules
Global Workflow
Figure 2. Workflow Formation Architecture an important requirement on our workflow formation. Any workflow which is intended to be enacted has to fulfill basic properties, such as deadlock freeness and other characteristics demanded by the involved parties. In order to meet such a requirement it is necessary to validate and to verify any workflow before it is enacted. To ensure this, we separate the workflow formation phase in two sub-phases: (1) the workflow construction sub-phase and (2) the workflow evaluation sub-phase. Based on this separation and by using a pipe and filter pattern we have developed an architecture supporting the overall workflow formation phase. The architecture is depicted in Figure 2. In addition to the two sub-phases, this figure shows the input and output elements representing the information which is exchanged between the workflow formation phase and the two adjacent phases within the workflow formation cycle shown in Figure 1. The workflow construction sub-phase takes the requirements defined in the requirement definition phase as input. The set of requirements contains local, global and formation requirements. Local requirements are concerned with all aspects of the local workflows of the involved suppliers. In contrast to this, the global requirements refer to demanded characteristics related to the global workflow newly to build. Formation requirements address demands on the formation process itself, such as being fast and that the evaluation does not need to be exhaustive. The workflow formation is based on a workflow construction module and databases, such as a set of creation and rewriting rules and a pattern repository. The formation itself is influenced and controlled by strategy rules stored in a rule- or database. If
the formation is unsuccessful then the workflow formation process goes back to the requirement definition. A successful formation results in a specification of the global workflow. However, before the workflow can be enacted it has to be verified and analyzed. The evaluation phase contains validation, verification and performance analysis steps. Examples are evaluating, whether the workflow can really lead to the demanded goal (e.g. by simulation), verifying the fulfillments of the global and local requirements, and calculating performance indicators, such as expected minimum duration time. It is also possible to analyse requirements which could not be considered during the workflow construction. For example, it might be, that time-related requirements can not be taken into account during the construction, because there are no rules for this aspect available. However, in the evaluation phase it is still possible to analyze time-related performance indicators, e.g. to identify the critical path within a workflow. Based on the evaluation results, the evaluation module decides whether the formed workflow is sufficient or not. • If the workflow is insufficient, then the evaluation results are fed back to the workflow formation module which in turn is started again. The feeding back is depicted in Figure 2 as a dashed line going from the workflow evaluation component to the workflow construction component. Furthermore, through this feed back technique it is possible to support generate-andtest methods within the workflow formation phase. • If the workflow is satisfactory, then the formation process is stopped, and the newly formed, global workflow and the analysis results are issued towards an enactment module. The analysis results can help the enactment module to schedule the tasks, to recognize unwanted situation and to avoid exceptions. For example, based on the critical path analysis results, an enactment module knows which tasks should not be delayed at all. And it can take this knowledge into account by the resource allocation or by the decision what to monitor explicitly. Further details for each of the sub-phases are described in the next sub-sections.
3.2. Construction Phase As mentioned above, in the requirement section we consider local and global constraints. Local requirements capture all aspects which are only related to one specific local workflow. The set of local constraints contains, for example, the input and output parameters of tasks, the partial order of or the control-flow between these tasks within one specific local workflow, or
the time duration of the local workflow. These local constraints can be expressed (at least partially) in languages such as XRL [17] with its extensions or BPEL [4]. Examples for such local constraints are: (1) a task A needs as input a data item XY provided by another party or (2) the two local task A and B can run in parallel. In contrast to the local requirements, the set of global requirements put universal constraints on the global workflow which connects all the local workflows. In addition, aspects such as monitoring and controlling can be covered in this set of constraints. The constraints are specified in business rules and stored in an instance file of a XML-based language, e.g. the E-contracting Markup language (ECML) [2] or the Rule Markup Language (RuleML) [14]. Examples for global requirements could be that the global workflow is deadlock free and its maximum duration is 10 days. The workflow construction sub-phase consists of a construction module, a storage containing strategy rules, and data components containing creation and re-writing rules and patterns. The construction module is a general engine which uses the rules and the patterns. One formation rule could state: if a data item x is a output parameter of a task A and the input parameter of a task B then add an ”A before B”-link. Rewriting rules become very important in cases where the subsequent evaluation module finds a conflict. In such cases, the construction engine applies rewriting rules in order to resolve the conflict or to optimize the workflow without starting from scratch. The formation engine can be steered by strategy rules. For example, with this mean a user can decide how many solutions are generated, and whether the targeted structure is flat or a hierarchy. What features are supported by the engine depends on the available rules. The term features refers here to aspects which can be included in the workflow construction by the engine. Some features can be seen as views or perspective on the global workflow, such as the construction of the control-flow or the data-flow. Other features make sure that requirements such as temporal constraints (e.g. maximum duration < 10 days), are already considered during the construction. The availability of a feature ”data flow” implies, that there are rules in the rule base which describe how to construct, at least partially, a workflow based on data requirements. The types of requirements differ from case to case. And overtime new types of requirements are captured in the requirement definition phase. The workflow formation architecture has to cope with these changes. It has to be flexible enough to take new types of requirements into account during the construction without a lot of programming effort. The separation of a general engine and a rule base leads to such a flexibility and extensibility. New global or local requirements can force a change in or an extension of the for-
mation method. This can be done by introducing new features by storing new rules into the rule base, so that the new requirements can be taken into account and fulfilled. This means three things, first, the intelligence lies in the rules and not in the engine, second, there is a direct relation between the types of requirements and the rule base, and third, the rule base is feature-dependent. At the end of the construction phase, the newly formed global workflow specified in a workflow language is forwarded to the workflow evaluation phase, more precisely to the workflow evaluation module.
3.3. Evaluation Phase The workflow evaluation module takes as input the global workflow specification and all defined requirements, and generates an analysis document. The actual analysis is done within plug-ins which are coordinated by the the evaluation module. The plug-ins can contain very different kinds of algorithms for analyzing workflows. They can perform static analysis such as done in Woflan [16] or dynamic analysis such as used in simulation approaches (e.g. in ExSpect-Simulation software [9]). Each plug-in has access to its own dedicated sets of data and rules. However, it is also possible that some plug-ins share their data and rules. Which plug-ins are executed depends on the requirements and on the strategy rules stored in a dedicated rule base. Based on the requirements it might be sufficient just to check the soundness of the workflow and that other local control-flow constraints are still hold. However, via the strategy rules a user can determine and influence the execution of the plug-ins and the termination of the evaluation. For example, a user may restrict the available time for the evaluation process. In that case the strategy would be to prefer static analysis approaches over dynamic ones, because the later ones take, in general, more time. Based on the defined requirements and the results returned by the plug-ins, the evaluation module decides whether a global workflow is accepted or declined. If the workflow is declined then information about conflicts, sub-optimalities and missed requirements are reported to the workflow formation module. If all requirements are satisfied, then an evaluation document and a complete specification of the global workflow are issued and forwarded to the enactment phase.
3.4. User Interaction In the ideal case, user interaction is not necessary in the workflow formation phase. The goal is to automate the formation as much as possible in order to be fast and to avoid errors. In the proposed architecture, a user can only influ-
Supplier SP1
DevG do; cd
box cdBox. For the assembling of the gear box within task AssB, both, the gearing and the surrounding box are needed.
ox cdB
CO
ProG AND
AND OrdB
x bo
AssB
do Bo x
Supplier SP2
control-flow
doBox
xy
CBO
data-flow
ox cdB
DevB
ProB
box
cd = CAD drawings; do = development order,
Figure 3. Example - Local Requirements ence the formation and evaluation ex-ante, via specifying the strategy rules and the requirements. However, an user interface could help, for example, in cases of missing data which can prevent a successful construction. In such cases, the system could interact with the user and try to generate a workflow eventually, instead of terminating the formation phase and going back to the requirement definition phase. Since the interaction with users can be quite complex, the issue should be considered separately and carefully designed. For the sake of space, user interfaces are not considered in this paper.
4. Example In this section, we show an example of how the proposed architecture can be used. The example describes the development of a gear box by suppliers on the request of an OEM. The supplier SP1 takes the order, but it is not able to develop the gear box by its own. SP1 develops only the gearing and outsources the development of the surrounding box for the gearing to a supplier SP2. The issue of finding the right partners is out of the scope of this paper. The requirements on the global workflow and on the formation are specified by the parties together in the requirement definition phase. The local requirements are provided by each party alone. In our example, the local requirements consist of (1) local control-flow structures public within the NoAE and (2) information about needed data items which have to be provided by other partners. The local requirements are depicted in Figure 3 and can be described textually as follows: • SP1 needs for the order checking CO the order do itself and the CAD drawing cd. Both data items are provided by the OEM. After CO, SP1 can start in parallel both, (a) the sequence consisting of the development DevG and the production of the gearing (task ProG) and (b) the ordering of the box surrounding the gearing .Task OrdB generates the box order doBox. An output of task DevG is the CAD drawings of the surrounding
• SP2 needs first the order doBox in order to check (task CBO) whether it can fulfill the requested development. For the development of the box itself (task DevB), it needs the CAD drawings cdBox. Afterwards, SP2 produces and delivers the box within the task ProB. The non-local requirements in our example are deadlock freeness and a global workflow which is as fast as possible. Moreover, the construction and evaluation should be done in a quick mode. All requirements are forwarded to the workflow formation phase. The workflow construction module analyzes the requirements. On the basis of the global requirement ”as fast as possible”, the module selects the strategy rule ”use parallelism of tasks where it is possible”. Furthermore, depending on the available features and the information given by the parties, the module decides which perspectives of the workflow are constructed, e.g. the control- and dataflow perspectives. Since the control-flow is the most essential one, we focus in the following on this perspective. The construction module chooses the creation rules based on the available local workflow information and the selected construction strategy. The rules determine which workflow elements or patterns are applied. Regarding our example, the construction module has to select a rule that can derive from input and output data the information which control-flow patterns should be applied. We assume here, that typical control-flow patterns, such as AND-split/merge etc., are stored in the pattern repository. Then, the following rule could be chosen by the module: ”IF task T has an outgoing data item which is requested by an external party, THEN • apply an AND-split pattern behind the task T • re-connect all outgoing control-flow links of T with the AND-split element • connect T with the AND element • add control-flow links between the AND-split and the tasks requesting the data element. The application of such creation rules results in a global workflow with a control-flow structure like shown in Figure 4. Also other perspectives, such as the data-flow, can be constructed in this way. The complete global workflow specification is stored in a file and forwarded to the evaluation module. First, the evaluation module analyzes the given requirements. As an result, the module knows the criteria for the selection of the plug-ins. In the example, these criteria are
Supplier SP1 do; cd
CO
DevG
AND
OrdB
AND
ProG
AND
AND
AND
AssB
[2] Supplier SP2 CBO
AND
DevB
ProB
control-flow
Figure 4. Control-flow Structure of Global Workflow
[3]
[4]
the ability to check deadlock freeness and to do the analysis fast. Based on the strategy rule, ”Static analysis methods are in general faster than dynamic methods.”, the module would chose a plug-in which supports static methods. A possible choice would be Woflan. If the workflow specification format is not supported by Woflan then the specification has to be transformed or mapped to a suitable format. The handling of the format issue will be part of a refinement of the architecture planned in our future work. In parallel to the checking of deadlock freeness, the evaluation module triggers a plug-in which is able to validate whether the local requirements are still hold in the global workflow. This can be done as follows: (1) Take the global workflow specification and remove links which are linked to external tasks.(2) Remove each split and merge element which has only one incoming and one outgoing link and rearrange the affected links accordingly. (3) Compare the remaining workflow parts with the local workflows. Temporal aspects cannot be evaluated in our example because necessary data are not provided. If the evaluation module could proof the deadlock freeness and the compliance of the global workflow with the local requirements then the results are stored in a document and the global workflow specification is forwarded to an enactment module.
5. Conclusion In this paper we have proposed both, a workflow formation cycle and a functional architecture for automated workflow formation. The interesting features of the architecture are its extensibility, and its fulfillment of the requirements from the automotive industry. In future, we plan to extend the architecture with explicit user interfaces and to refine the construction and evaluation modules, including algorithms, and to substantiate the interfaces between the components.
References [1] S. Ambroszkiewicz. Agent based approach to service description and composition. In W. Truszkowski, M. Hinchey,
[5]
[6]
[7] [8]
[9] [10]
[11]
[12] [13]
[14] [15]
[16]
[17]
and C. Rouff, editors, Innovative Concepts for Agent-Based Systems: First International Workshop on Radical Agent Concepts, volume 2564 of Lecture Notes in Computer Science, pages 135 – 149. Springer-Verlag, Oct 2003. S. Angelov and P. Grefen. Requirements on a B2B Econtrac language. Technical Report BETA Report WP 140, BETA Research Institute, Eindhoven University of Technology, Eindhoven, The Netherlands, May 2005. W. Becker. The Future of the European Manufacturing Industry, chapter The Network of Automotive Excellence as a Potential Response to Change in Development/ Production and Brand Policy. Springer, 2003. BPEL4WS. Homepage. http://www128.ibm.com/developerworks/library/specification/wsbpel/. last access April, 20 2005. F. Casati, S. Ilnicki, L. jie Jin, V. Krishnamoorthy, and M.-C. Shan. Adaptive and dynamic service composition in eflow. In CAiSE ’00: Proceedings of the 12th International Conference on Advanced Information Systems Engineering, pages 13–31, London, UK, 2000. Springer-Verlag. D. K. W. Chiu, S. C. Cheung, S. Till, K. Karlapalem, Q. Li, and E. Kafeza. Workflow view driven cross-organizational interoperability in a web service environment. Inf. Tech. and Management, 5(3-4):221–250, 2004. CrossWork. Project homepage. http://www.crosswork.info/. last access May, 10 2005. CrossWork Consortium. Intra- & inter-organisational business models. Technical report, CrossWork, 2004. Public deliverable to WP1 Business Model Development. ExSpect. ExSpecT - Executable Specification Tool. http://www.exspect.com/. last access June 10, 2005. P. Grefen, K. Aberer, Y. Hoffner, and H. Ludwig. Crossflow: Cross-organizational workflow management in dynamic virtual enterprises. International Journal of Computer Systems Engineering, 15(5), Sept. 2000. P. Grefen, H. Ludwig, and S. Angelov. A three-level framework for process and data management of complex eservices. International Journal of Cooperative Information Systems, 12(4):487–531, 2003. R. Kurek. Erfolgreiche Strategien fu¨ r Automobilzulieferer. Springer Berlin, 2004. G. Piccinelli and L. Mokrushin. Dynamic e-service composition in DySCo. In International Conference on Distributed Computing Systems Workshop, pages 88–93, 2001. RuleML Initiative. RuleML - Rule Markup Language. http://www.ruleml.org/. last access June 6, 2006. W. M. P. van der Aalst, B. F. van Dongen, J. Herbst, L. Maruster, G. Schimm, and A. J. M. M. Weijters. Workflow mining: a survey of issues and approaches. Data Knowl. Eng., 47(2):237–267, 2003. H. M. W. Verbeek, W. M. P. V. D. Aalst, and A. Kumar. Xrl/woflan: Verification and extensibility of an xml/petri-netbased language for inter-organizational workflows. Inf. Tech. and Management, 5(1-2):65–110, 2004. XRL. XRL-eXchangeable Routing Language. http://is.tm.tue.nl/staff/anorta/XRL/xrlHome.html. last access June, 27 2004.
