A framework for work process modeling in the chemical industries

A framework for work process modeling in the chemical industries

Computers and Chemical Engineering 35 (2011) 679–691 Contents lists available at ScienceDirect Computers and Chemical Engineering journal homepage: ...

662KB Sizes 1 Downloads 155 Views

Computers and Chemical Engineering 35 (2011) 679–691

Contents lists available at ScienceDirect

Computers and Chemical Engineering journal homepage: www.elsevier.com/locate/compchemeng

A framework for work process modeling in the chemical industries Manfred Theißen, Ri Hai, Wolfgang Marquardt ∗ AVT – Process Systems Engineering, RWTH Aachen University, Germany

a r t i c l e

i n f o

Article history: Received 22 December 2009 Received in revised form 27 October 2010 Accepted 29 October 2010 Available online 5 November 2010 Keywords: Work process modeling Design process Operational process Modeling language Modeling tool Ontologies

a b s t r a c t During the life cycle of a chemical product and its associated production process, diverse types of work processes are performed, such as design and operational processes. In this contribution, a framework for the modeling of work processes in the chemical industries is presented which comprises an iterative modeling procedure, an extensible modeling language for work processes, and software tools for its practical application. The framework supports the iterative creation of work process models for diverse applications such as work process simulation or enactment and the subsequent export of the models in suitable application tools. Ease of use has been a key design criterion for the framework. Internally, the framework builds on semantic technologies to provide substantial support for model checking and model transformations. © 2010 Elsevier Ltd. All rights reserved.

1. Introduction During the life cycle of a chemical product, several types of work processes are performed, including design processes (e.g., the development of the chemical product, the conceptual design of an associated production process, and the specification of operating procedures for a chemical plant) and operational processes (e.g., the start-up of a continuous plant or the operation of a batch plant). The human actors of industrial design and development processes typically originate from various disciplines, such as chemistry, chemical engineering, or civil engineering, and they perform diverse roles (e.g., technical, managerial, and supervisory). As a result, each stakeholder possesses a personal view and understanding of the design process. Some actors, in particular those in managerial and supervisory roles, are acquainted with the process as a whole, but are unfamiliar with the details of the process. Such detailed knowledge is distributed among the stakeholders. This lack of common understanding hinders collaboration across organizational and disciplinary boundaries as well as over the lifecycle of the product and its associated production plant, and therefore leaves significant room for improvement. In order to achieve a common understanding, simple semi-formal representations of work processes are required, which can easily be edited and understood by all stakeholders, independent from their disciplinary and educational backgrounds. A drawback of semi-formal models is their limited utility for computer-based applications such

∗ Corresponding author. Tel.: +49 241 80 96712; fax: +49 241 80 92326. E-mail address: [email protected] (W. Marquardt). 0098-1354/$ – see front matter © 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.compchemeng.2010.10.012

as analysis, simulation, or enactment. Hence, formal, machineinterpretable models are essential, but their creation is difficult, time-consuming, and requires expert skills. Consequently, a framework is required for the creation of formal work process models by means of an incremental approach with active participation of all stakeholders. In this contribution, we present a framework for work process modeling, comprising a modeling procedure, a modeling language, and modeling tools. The modeling procedure describes the iterative creation of work process models required for diverse applications. In Section 2, we give an overview on the procedure. As argued in Section 3, both the modeling procedure and the characteristics of the diverse types of work processes in chemical engineering result in several requirements for an adequate modeling language. Some existing modeling languages are shortly reviewed in Section 4. We will see that these languages partially meet the requirements, but none of them, to our knowledge, fulfills the requirements in a comprehensive manner. The Work Process Modeling Language (WPML) is introduced in Section 5. The language has been developed by our group based on existing approaches such as the C3 notation for weakly structured cooperative work processes (Killich et al., 1999) and the activity diagram of the Unified Modeling Language (UML) (Object Management Group (OMG), 2009). WPML provides the building blocks to represent work process models and comes with an intuitive visualization similar to that of UML activity diagrams. The language can be extended with domain- and applicationdependent concepts to create a complete meta-model according to the users’ needs.

680

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691

Software tools are a prerequisite for the practical application and validation of the framework. In particular, the Work Process Modeling System (WOMS-plus) has been built, a user-friendly WPML editor, and several exemplary tools for model transformations which enable the reuse of WPML models in other applications. Section 6 gives an overview on the architecture of the software tools. Some examples for model transformations are reviewed in Section 7. 2. Work process modeling 2.1. Work processes and business processes Work process is a term rarely used in comparison with the more common term business process, a buzzword of the last decade of the Twentieth Century. What has led us to prefer the less biased work process is the ambiguity of the term business process. Davenport (1993), an early protagonist within the Business Process Reengineering (BPR) community, defines a business process as a “structured, measured set of activities designed to produce a specified output for a particular customer or market.” An even more general definition is proposed by Rummler and Brache (1995): a business process is a series of steps designed to produce a product or service. The Workflow Management Coalition, a group of vendors, users, researchers, and consultants of workflow management (WM) technology, states that a business process is a “set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure.” Hence, there is consensus in that a business process is composed of smaller elements called activities, steps, or procedures; in the following, these elements are referred to as actions. However, the various definitions of a business process give varying descriptions of the interrelations between the actions, which range from series to less restrictive sets. In practice, BPR and WM focus on recurrent processes on the operative level, i.e., processes that are completely predetermined and can be planned on a detailed level, such as the processing of a claim in an insurance company. In consequence, common usage of the term business process is narrowed to highly structured processes as indicated in the definition by Rummler and Brache (1995) (series of steps), even if other definitions impose less restrictions. To characterize a work process, we borrow from a definition of business processes given by Sharp and McDermott (2001). A work process is a collection of interrelated actions in response to an event that achieves a specific result. This event represents the circumstances that trigger the work process. For instance, a management decision to build a chemical plant triggers the execution of a work process whose (ideal) result will be a plant ready for operation. Within the overall work process, the completion of certain subprocesses triggers the execution of other sub-processes, e.g., the completion of conceptional design triggers the basic engineering process. Note that this definition does not impose any restrictions on the relations between the actions in a work process. Thus, a business process in the colloquial meaning, i.e., a process that can be described by procedural rules, is a special type of a work process. 2.2. Modeling procedure Given the importance of work process models for applications like BPR, WM, and enterprise resource planing, diverse modeling procedures for their creation have been developed (e.g., Davis, 2001; Georgakopoulos, Hornick, & Sheth, 1995; Guha, Kettinger, & Teng, 1994; Phalp, 1998; Phalp & Shepperd, 2000; Sharp & McDermott, 2001). Most procedures comprise some common steps, often to be executed in an iterative manner:

Fig. 1. Modeling procedure for work processes.

1. The first step is typically the definition of modeling goals and scope. 2. Then, if applicable, the as-is process is captured and modeled, i.e., the process as it is currently performed, including its limitations and shortcomings. If no as-is process exists, a first draft of the desired to-be process is created instead. 3. The process is analyzed and an improved to-be process is specified. 4. The improved process is implemented. When a modeling procedure is applied, several models (or model versions) are created with different levels of detail, formalization, and generality. The level of detail refers to the amount of information captured, whereas the level of formalization refers to the representation of this information (e.g., by means of textual comments or by using some modeling elements with well-defined semantics). The level of generality refers to the number of work processes that are represented by a model. For instance, we can distinguish a model of a concrete design project for a polymerization plant, a more general model describing the typical steps to design a polymerization plant, and even more general guidelines for process design such as the established procedure proposed by Douglas (1988). A further distinction can be made with respect to the quality of the work processes represented by different models. Obviously, the successful application of a modeling procedure should lead to a better process in the real world. Based on the existing approaches, we have specified a generic modeling procedure that emphasizes the four-dimensional space in which work process models can be located (detail, formalization, generality, process quality). The main steps of the procedure are given in Fig. 1: Set Scope. First, the scope of the model to be created must be set. In particular, an adequate level of generality, of detail, and of formalization for the work process model must be chosen. Create sound and complete model. Then, a model of the work process in consideration is created according to the constraints set in the first step. In some cases, it may be useful to do several iterations of the first two steps before proceeding to the analysis phase. For instance, in case of a complex design process, it is useful to start with some concrete design projects (lowest level of generality) and then to merge these models into a more general model—rather than to begin directly with the more complex general case. In case an analysis method is applied that requires some formal work process

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691

model, it may also be useful to create a semi-formal model in a first iteration and to formalize it in a second iteration. Analyze work process. An analysis of the work process, e.g., by means of a simulation, can reveal weaknesses or deficiencies which should be eliminated in a further modeling step to improve process quality. Implement work process. Finally, the work process is implemented. Further modifications of the model may be necessary depending on the kind of implementation (e.g., important parts of a work process to operate a chemical plant can only be automated if a formal representation of the work process is available). As an example, we consider the application of the generic procedure to the specification of operating procedures for a batch plant: 1. First, a chemist describes the basic actions to produce a certain chemical product by means of a simple model. 2. The model is forwarded to a chemical engineer, who adds details that are relevant for implementing the production process in an industrial scale. For instance, the chemist may have scheduled the addition of two reactants A and B, but not prescribed their order. The engineer exports the model in a simulation tool and performs simulation runs with different alternatives to add A and B. He finds the optimal order with respect to heat build-up and extends the model accordingly. 3. The model is handed over to an automation engineer who exports it to his SFC editor where he adds details specific to the automation of the process. He also adds textual instructions for the plant staff directly in the model, which is then transformed in a text file and handed over to the staff. A more detailed discussion of the generic modeling procedure and its application to design processes is given by Theißen, Hai, and Marquardt (2008b). 3. Requirements for a modeling language The modeling procedure suggests the iterative creation of work process models on different levels of detail, formality, and generality. In principle, different modeling languages could be used, each of them tailored to a certain phase or iteration in the procedure. A drawback of this approach would be the need for several model transformations between the phases and an immense learning effort for any user to get acquainted with several languages. Instead, a single modeling language is advantageous which can easily be adapted to the different phases of the modeling procedure and to the characteristics of the work process in consideration. 3.1. Expressiveness The need to model work processes on different levels of detail and generality results in certain requirements for the expressiveness of the language, i.e., the potential to represent different aspects of or views on a work process. The focus of this contribution is on behavioral and, to a lesser extent, functional aspects. Further aspects of expressiveness have been discussed elsewhere and are only touched on here, such as the actors performing a work process, the technical resources required for the execution (Eggersmann et al., 2008), or complex decisions that are typical for work processes like engineering design (Theißen and Marquardt, 2007, 2009). 3.1.1. Behavioral aspects The core aspect of most work process models is process behavior, i.e., the dependencies between the elementary actions with respect to causal conditions (e.g., if action A is executed, then action

681

B must also be executed) and temporal restrictions (e.g., B is executed after A is finished). Existing modeling languages often force the modeler to create a complete behavior specification from the beginning of the modeling process. As an example, we consider Aspen Batch Process Developer (Aspen Technology, 2009), an engineering software tool for the simulation of batch operational processes in a chemical plant. In industrial practice, this tool is also often used as a modeling tool to create a first draft of batch processes, although it is essentially a simulation tool. At the early stage of a development project, several details of a batch process are still undefined. For instance, a chemical engineer may be provided with the information that a reactor should be charged with two reactants A and B, and that the order of the two steps is still undefined. When creating a model in the tool, the engineer is forced to specify a certain order because the underlying modeling language does not allow to omit that information. In consequence, the work process model is likely to be enriched with uncertain or even accidental content, while feasible alternatives are excluded. During the design of an operational process, incomplete behavior specifications are useful intermediate steps on the way towards a complete specification, which is finally required to operate a chemical plant. In case of work process models of engineering design processes, complete behavior specifications are infeasible in general because design is an inherently creative process and cannot be predetermined. In consequence, a modeling language needs to allow work process models with an incomplete behavior specification. In particular, there is a need for two kinds of abstraction (Eggersmann et al., 2008). Structural abstraction refers to the freedom to omit information about the conditions under which an action is performed, and temporal abstraction refers to the freedom to omit information about the temporal relations between actions if they are performed (e.g., by permitting a temporal overlap of two subsequent actions). 3.1.2. Functional aspects According to the definition of a work process, the function of a work process is to create a specific result. However, most modeling languages focus on the behavioral aspect of a work process and pay little attention to the representation of the function of an entire work process or of the actions within it. Usually, the functional aspect is exclusively specified by means of auxiliary constructs such as textual annotations. Textual descriptions of functional aspects are advantageous in the early stages of a modeling process because a modeler can phrase a text more easily than choose some specific modeling concept and insert it into a model. There are also model applications in which any functional representation beyond textual descriptions has no additional benefit; an example is the model of a simple operational process for a lab-scale plant, which will only serve as a reference for the assistant who will execute the process. However, explicit representations of functional aspects enable more advanced applications of work process models, including automatic model checks and model transformations for target applications that strongly depend on functional aspects. In Section 6.3, these benefits are discussed in detail. 3.2. Formalization Formal representations facilitate advanced applications of work process models like automatic model checking or the derivation of implicit knowledge from explicitly defined knowledge. The obvious prerequisite for a formal work process model is a formal modeling language, i.e., the semantics of the modeling elements must be defined formally. At the same time, a modeling language should

682

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691

not compel the user to a certain level of formalization, but provide modeling elements required for the level of formalization that is imposed by the intended application of the model. In particular, this means that it should be possible to represent some aspects formally, while other aspects are represented informally, e.g., by means of simple textual annotations.

4. Modeling languages for work processes There is a wide range of modeling languages for work processes, and a complete review of the existing approaches is beyond the scope of this contribution. Instead, some representative languages are discussed and evaluated with respect to the requirements above. As this contribution does not focus on a certain application domain or type of work processes (e.g., design or operational processes), only generic modeling languages are considered here. For an overview on modeling languages for operational processes and for design processes, see Hai, Theißen, and Marquardt (submitted) or Hai, Theißen, and Marquardt (2010); the latter publication also covers modeling languages for design processes. The activity diagram of the Unified Modeling Language (UML) (Object Management Group (OMG), 2009) is probably the bestknown graphical modeling language for work processes. The language specification comprises typical modeling elements like actions and control flows as well as concepts to represent parallel or alternative branchings of the control flow. The behavioral semantics of UML activities is defined by an informal textual description of the token flow in an activity diagram, that is, the activity diagram is interpreted (but not defined) as a kind of Petri net. Petri nets are a family of graphical modeling languages (e.g., see Jensen, 1997; Petri, 1962). Their strengths are an inherent support for concepts like concurrency and resource allocation and a formal mathematical foundation, which eliminates any ambiguity and allows the application of Petri nets for the automated analysis and execution of work processes. The direct application of Petri nets to model complex work processes is often not practical, but they have been applied to specify the semantics of other modeling languages. Störrle and Hausmann (2005), for instance, propose a formal behavioral semantics of (a subset of) UML activities by means of a well-defined translation to Petri nets. The semantics of Yet Another Workflow Language (YAWL) (van der Alst & ter Hofstede, 2005) is based on a direct mapping of its modeling elements to Petri nets. The Process Specification Language (PSL) (National Institute of Standards and Technology (NIST), 2000) is an ontology-based language for the automatic exchange of information about work processes between different applications. The semantics of PSL is defined explicitly in first order logics. As an application example, Bock and Gruninger (2005) have published an outline of a formal specification of UML activities by means of PSL. The graphical representation and semantics of the Business Process Modeling Notation (BPMN) (Object Management Group (OMG), 2006) are similar to that of UML activity diagrams. Even though its name suggests a focus on business processes, the language is rather generic and allows representing different types of work processes. In particular, BPMN addresses the creation of process models for workflow execution and automation. IDEF0 (National Institute of Standards and Technology (NIST), 1993) is also widely used for work process modeling, especially manufacturing processes. IDEF0 contains a set of generic modeling concepts and allows a structured representation of functions, activities, and processes. Temporal relations between actions are not included in IDEF0. Thus, several of the existing modeling languages enable the representation of process behavior, but only a small subset provides a

formal foundation. There is also insufficient support for behavioral abstraction. The functional aspect of work processes is understandably more or less neglected by these generic languages.1 5. The Work Process Modeling Language (WPML) The Work Process Modeling Language (WPML) has been designed to address the weaknesses of the existing modeling languages. One goal of the language is to give a formal definition of several concepts of the C3 notation for cooperative work processes (Eggersmann et al., 2008; Killich et al., 1999). C3 (cooperation, coordination, and communication) is a simple graphical modeling language developed in CRC 476 IMPROVE, a joint research project of computer scientists, engineers, and experts from industrial ergonomics aiming at substantial support of design processes by information technology (Nagl & Marquardt, 2008). The original focus of C3 was on the requirements imposed by weakly structured design processes. In addition to conventional modeling concepts for predetermined processes, C3 provides concepts for temporal and structural abstraction. In several academic and industrial case studies, the language has proven to be an adequate language to represent not only design and development processes, but also operational processes (Theißen et al., 2008b; Theißen, Hai, Morbach, Schneider, & Marquardt, 2008). 5.1. Overview on WPML A modeling language for work processes provides the building blocks which are used (instantiated) to represent work processes. Thus, also the term meta model is sometimes used for a modeling language as it is a model of the instance models. WPML is a domain-independent language, i.e., it is suited to represent any kind of work process (e.g., design processes, business processes, and production processes) in any domain (e.g., chemical or mechanical engineering). The language does not contain elements specific to a domain—such as a modeling element to describe the charging of a chemical reactor. As such elements are nevertheless required for certain applications, WPML can be extended with domain-specific concepts. In the following, we will denote the domain-independent core of WPML as a modeling language, whereas WPML, enriched with one or more domain-specific extensions, will be referred to as a meta model. WPML itself and optional domain-specific extensions are implemented in the Web Ontology Language (OWL) (World Wide Web Consortium, 2004a), a formal language for knowledge representation, which is based on the Resource Description Framework RDF (World Wide Web Consortium, 2004b), a language for the description of directed graphs with typed arcs. The standard serialization format for OWL and RDF is XML; however, in the following we use a simplified and more readable representation called Manchester OWL Syntax (Horridge & Patel-Schneider, 2008). We also use a UML class diagram to visualize relations such as inheritance between OWL classes, although there are some important semantic differences between UML and RDF/OWL. 5.1.1. Modeling language The upper part of Fig. 2 shows a simplified meta model for operational processes in chemical engineering. The meta model is organized in two logical packages (modules). To each module, a prefix is assigned for easier reference. We omit the prefix when the module is clear from the context.

1 However, UML provides a set of special action types to model typical functions of software, such as the setting of a variable value.

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691

683

Notation name (prefix)

specialization (owl:subclassOf)

module

instantiation (rdf:type)

property (e.g., an owl:objectProperty)

Work Process Modeling Language (wpml) isComposedOf

WorkProcessModel

from

Meta model

isDescribedBy

ActionRefinement

WorkProcessNode

isRefinedBy

isConstrainedBy

WorkProcessElement

Action

Constraint

WorkProcessArc from exactly 1 to exactly 1

to

ControlNode

ControlFlow

inv(from) exactly 1 ControlFlow hasFunction inv(to) exactly 1 ControlFlow

Function

StrictControlFlow

Operational Process (op)

OperationalFunction

Instance model in concrete WPML syntax

Instance model in abstract syntax (RDF graph)

TemperatureValue

endTemperature

TemperatureChange

Charging

wpml:hasFunction

charging1

a1

rdfs:comment

Charge reactor

wpml:from cf1

120° C

op:end Temperature

wpml:to temperatureChange1

wpml:hasFunction

a2

rdfs:comment

Increase temperature up to 120° C

a1: Charge reactor

Notation wpml:Action

wpml:StrictControlFlow

Charging

id: rdfs:comment function class name 1 - function property name 1 : property value ...

a2: Increase temperature up to 120° C TemperatureChange - endTemperature: 120° C

Fig. 2. The fundamental classes of WPML (module wpml) and an exemplary extension for operational processes (module op) are the meta model of a simple instance model, which is represented in both abstract (RDF) and concrete syntax.

On top, the core module of WPML (wpml) is shown, including its fundamental classes. A WorkProcessModel is a graph that isComposedOf WorkProcessElements, which can be subject to Constraints. The elements are either nodes (WorkProcessNode) or arcs (WorkProcessArc), the latter directing from exactly one node to exactly one node. The only arc type discussed here is the ControlFlow, including a special version called StrictControlFlow; the semantics of different control flows will be introduced below. As for the nodes, we distinguish Actions and ControlNodes. Actions represent the steps in a work process. The diagrams shows two restrictions for Action instances. An Action must be the

from node of exactly 1 ControlFlow, i.e., each Action must be the origin of exactly one ControlFlow. Similarly, the second restriction states that each Action must be the target of exactly one ControlFlow. To an Action, an ActionRefinement can be assigned, which is basically a reference to a WorkProcessModel describing the internal behavior of the Action. An Action refined this way roughly corresponds to a CallBehaviorAction in UML. In addition, Actions can be linked to the Functions they fulfill. The WPML core only provides a general Function class, which can be subclassed in domain-specific extensions. ControlNodes are used to model concurrency, execution conditions, etc. The most important ControlNodes in WPML directly

684

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691

Table 1 Subclasses of ControlNode. Class

Symbol

InitialNode FinalNode



DecisionNode



MergeNode



ForkNode JoinNode

Restrictions inv(from) exactly 1 ControlFlow and inv(to) exactly 0 ControlFlow inv(from) exactly 0 ControlFlow and inv(to) exactly 1 ControlFlow inv(from) min 1 ControlFlow and inv(to) exactly 1 ControlFlow inv(from) exactly 1 ControlFlow and inv(to) min 1 ControlFlow inv(from) min 1 ControlFlow and inv(to) exactly 1 ControlFlow inv(from) exactly 1 ControlFlow and and inv(to) min 1 ControlFlow

a1: Create BFD duration: [2 ... 4] cf1 cf2

cf3

end-start: [1 … 2]

a2: Outsource PFD creation

cf4

cf5

a3: Create PFD (reaction unit)

a4: Create PFD (separation unit)

correspond to the control nodes of UML activities; they are given in Table 1. 5.1.2. Extending WPML with domain concepts Below the wpml module, Fig. 2 shows the op module as an exemplary extension of WPML to represent operational processes in chemical engineering. To this end, subclasses of the general wpml:Function are introduced to describe the functions of typical steps in an operational process. In this simplistic example, only two concrete functions are defined: the TemperatureChange, which can further be specified by an endTemperature, and the Charging of some tank or reactor. 5.1.3. Instance model To demonstrate the application of the meta-model to represent a work process on the instance layer, a simple example is given in the lower part of Fig. 2 in both abstract and concrete syntax. The abstract representation shows an RDF graph, whose nodes are instances of the classes introduced above. Two Actions a1 and a2 are connected by a StrictControlFlow cf1.2 Both a1 and a2 are linked to explanations in natural language by means of rdfs:comment, a predefined property in RDF. Part of the information in these explanations is given in a formalized way by linking the Actions to instances of Charging and TemperatureChange, the latter specified by a TemperatureValue for the endTemperature. Although the abstract syntax emphasizes the relation of the instance model to the metamodel, its verbosity is obviously not suited for complex industrial work processes. Therefore, a more readable concrete syntax has been defined for WPML based on that of C3 and UML activity diagrams. In the figure, its usage is exemplified for the same instance model. 5.2. A simple WPML model A simple, but complete example of a WPML WorkProcessModel in concrete syntax is shown in Fig. 3. The IDs in the model (a1, cf1,...) are given for easier reference in the text; their appearance in a WPML diagram is optional. The model describes a development process for chemical processes in an R&D department on a very coarse-grained level. The first Action a1 is to create a block flow diagram (BFD) of the chemical process. An admissible duration range for this Action of 2–4 time units—say weeks—is given. Next, more detailed process flow diagrams (PFD) must be made for the different parts of the BFD. As indicated by the DecisionNode, this can either be done by a contractor or in the same R&D department. For the former case, only a single Action a2 is given (Outsource PFD creation); further details on how the PFDs are created are left to

2 Note that the for the sake of simplicity the example is incomplete: there is no ControlFlow to a1, and there is no ControlFlow from a2.

Fig. 3. A simple WPML model describing part of a development process in an R&D department.

the contractor. The latter case is covered by two Actions a3 and a4, which, according to the ForkNode above them, must be both executed. They explicitly require that a PFD for the reaction unit (a3), and another for the separation unit (a4) are made. In WPML, like in other flow diagrams such as UML activity diagrams, ControlFlows express causal dependencies. A ControlFlow between two Actions states that if the first Action is executed, also the second one must be executed. Conventional languages only include a single control flow type, which, in addition to the causal dependency, expresses a temporal dependency, e.g., when the first Action is finished, the second starts.3 This is often an unacceptable restriction for models of design or development processes, where, for instance, some Actions may overlap or are even expected to overlap (concurrent engineering). The semantics of WPML is based on the idea to separate causality from temporal relations. Here, causality refers to the necessary and sufficient conditions for executing an Action. Causality in WPML is handled similar as in UML activity diagrams. The causal relations between the Actions in the example model are equivalent to those in the UML activity diagram we would get if we replaced the special WPML control flows by standard UML control flows. If the entire work process is executed, then a1 is executed. If a1 is executed, then either a2 or both a3 and a4 are executed. The most general type of a control flow in WPML (i.e., ControlFlow) does not impose any temporal relations between the Actions it connects. In the example, this would mean that a2 (or a3 and a4) could be executed even before a1. However, in real-world models one would normally avoid patterns with such uncommon semantics. To this end, there are several predefined types of ControlFlows in WPML which (in addition to causality) express typical temporal relations between Actions. In Fig. 3, two kinds of control flows are used. The StrictControlFlow corresponds to a conventional control flow in UML. It is drawn as a simple directed arrow like its UML equivalent, and it requires a preceding Action to be finished before a subsequent Action can start. The OverlappingControlFlow allows a subsequent Action to begin while its predecessor is still executed; it is drawn as a directed arrow decorated with a tilde symbol (∼).

3 It is often ill-defined whether the second Action starts immediately or whether there may be a temporal gap between the Actions.

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691

685

Table 2 Constraints for Actions (first section) and ControlFlows. For each Constraint, the definition of the fulfilled predicate is given, which indicates whether a Constraint c is fulfilled by a WorkProcessElementOccurrence o. Name

Attribute

fulfilled (c, o)

DurationConstraint StartTimePointConstraint EndTimePointConstraint

durations: DurationSet timePoints: TimePointSet timePoints: TimePointSet

duration(occursIn(o)) ∈ durations(c) start(occursIn(o)) ∈ timePoints(c) end(occursIn(o)) ∈ timePoints(c)

StartStartDurationConstraint StartEndDurationConstraint EndStartDurationConstraint EndEndDurationConstraint

durations: DurationSet durations: DurationSet durations: DurationSet durations: DurationSet

start(occursIn(to(o))) − start(occursIn(from(o))) ∈ durations(c) end(occursIn(to(o))) − start(occursIn(from(o))) ∈ durations(c) start(occursIn(to(o))) − end(occursIn(from(o))) ∈ durations(c) end(occursIn(to(o))) − end(occursIn(from(o))) ∈ durations(c)

The OverlappingControlFlows in the example do not directly connect Actions, but also control nodes such as the DecisionNode or the ForkNode. However, each OverlappingControlFlow is part of one or several control flow paths between Actions. For instance, the OverlappingControlFlow cf1 is the start of a path of two control flows from a1 via the DecisionNode to a2; the second control flow in this path is the StrictControlFlow cf2. By definition, the temporal restriction between a1 and a2 is the combination of all ControlFlows in the path. As an OverlappingControlFlow allows Actions to overlap, but does not force them to do so, the restrictions induced by the OverlappingControlFlow cf1 are subsumed by those of the StrictControlFlow cf2. The overall temporal restrictions of c1 and cf2 are equivalent to those of cf2. Hence, the model contains the statement that if a1 and a2 are executed, i.e., if the PFDs are created by a contractor, then there must be no temporal overlap with the creation of the BFD. Given the obstacles of concurrent engineering across organizational boundaries, this is a reasonable restriction. So far, we have neglected a Constraint on cf2. This Constraint, indicated by the label end-start [1 . . . 2], is a further restriction on the start and end times of a1 and a2. We require that the duration from the end of a1 to the start of a2 must be in the range from 1 time unit to 2 time units. Thus, the model specifies a minimum gap of 1 time unit between a1 and a2, which may be required for administrative tasks like the handing-over of the BFD and other documents to the contractor. The maximum gap of 2 time units represents an upper boundary for the delay between a1 and a2. We get similar statements for the other control flow paths starting at a1. If a1 and a3 are executed, i.e., if the PFD for the reaction unit is created in-house, then there may be a temporal overlap—because the most restrictive control flow is an OverlappingControlFlow—and if a1 and a4 are executed, then there may also be a temporal overlap.

5.3. Basic WPML modeling elements 5.3.1. Actions An Action represents the possible occurrence of a step when a work process is executed. Depending on the model, the number of occurrences of an Action may be determined a priori or not. In Fig. 3, a1 must occur exactly once, whereas a2 may occur or not. In case of a model with loops, an Action may also occur several times. To an Action, Constraints can be assigned that must be satisfied by all occurrences of the Action. The possible Constraints for Actions are listed in the first section of Table 2. A DurationConstraint, for instance, can be used to assign a set of durations to a certain Action. Then, for each occurrence of that Action, we require that its duration is in the duration set. In Fig. 3, valid durations of occurrences of a1 must be in the range from 2 to 4. StartTimePointConstraints and EndTimePointConstraints express similar restrictions for the absolute start and end times of an Action’s occurrences. They are useful to model concrete projects (e.g., project plans), but typically they are not applied in generalized models.

5.3.2. Control flows ControlFlows express causal and temporal restrictions between Actions. The occurrences of a ControlFlow can be restricted by one or more of the Constraints in the second section of Table 2. In Fig. 3 we have seen an application example of the EndStartConstraint which restricts the time gap between the end of the from Action and the start of the to Action, or, more precisely, the start and end of the occurrences of these Actions. The other Constraints express similar restrictions for the other combinations of start and end times. 5.4. Behavioral semantics of WPML Other than for UML activity diagrams, the behavioral semantics of WPML is defined in a formal way. In this subsection, we give an overview on the principles of the formal semantics of WPML, but skip some technical details. A complete formal specification is in preparation. 5.4.1. Modeling concepts Time points and durations. The concept of TimePoints and Durations has been adopted from PSL (National Institute of Standards and Technology (NIST), 2000). They give a formal specification of the intuitive understanding of time as a universal one-dimensional space which is sufficient for any human work process, and also for most technical work processes.4 Here, the existence of a strict total order before on TimePoints is essential. In particular, this means: • For two arbitrary TimePoints t1 and t2 exactly one of the relations t1 before t2 , t1 = t2 , or t2 before t1 holds. • The before relation is transitive, i.e., if t1 before t2 and t2 before t3 , then t1 before t3 . To every pair (t1 , t2 ) of TimePoints, a Duration is assigned via the duration function. The value of this function is • zero—a constant defined in PSL—if and only if the two TimePoints are equal, • positive if and only if t1 before t2 , • negative if and only if t2 before t1 .5 In the following, we will use a more intuitive and comprehensive notation, e.g., t1 < t2 instead of t1 before t2 , and similarly t1 ≤ t2 instead of t1 before t2 ∨ t1 = t2 . The duration function will be abbreviated using the minus symbol, i.e., we get simple symbolic equivalences such as t1 < t2 ⇔ t1 − t2 < 0. In the examples, we will represent TimePoints as real numbers, assuming that the before relation is isomorphic to the smaller-than relation of the numeric

4

This is not true for processes that are subject to considerable relativistic effects. positive and negative are two predicates defined in PSL. A predicate is a function whose range is the set of the two Boolean constants {True, False}. 5

686

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691

wpo1

wpo3 ao1 [2; 5]

ao1 [2; 3] cfo1:cf1 - cf2

ao3

ao2 ao2 [3; 6]

0

4 8 order of timepoints

wpo2

cfo1:cf1 – cf3 – cf4

cfo2:cf1 – cf3 – cf5

ao3 [1; 6]

ao4 [4; 7]

ao1 [2; 5]

0

4 8 order of timepoints

0

4 8 order of timepoints

ao1

ao1

ao3

ao2 ao2 [5; 8]

ao4

wpo4

ao1 [2; 4] cfo1:cf1 - cf2

ao1

ao1

0

4 8 order of timepoints

cfo1:cf1 – cf3 – cf4

cfo2:cf1 – cf3 – cf5

ao3 [3; 6]

ao4 [4; 7]

ao4

Fig. 4. Four examples of WorkProcessOccurrences of the WorkProcessModel in Fig. 3. All of them are causally valid, but only wpo2 and wpo4 are temporally valid.

representations. However, it should be noted that there is no special ‘zero’ TimePoint, as it might be suggested by this notation. Time Point Sets and Duration Sets. A TimePointSet is a set of TimePoints. So far, two types of TimePointSets are provided by WPML:

occursIn, whose range is TimeInterval. A TimeInterval is specified by two functional properties start and end, the range of both properties is TimePoint. We will represent TimeIntervals in the form [start, end], and we require that for any TimeInterval, its start must be before its end,

• the TimePointEnumeration, whose instances are specified by the enumeration of all TimePoints contained. For their representation, we use the standard notation for sets, e.g., {1.2, 3.4, 2.12}; • the TimePointRange, whose instances are specified by a first and a last TimePoint. Both limits can be inclusive or exclusive (attributes firstIsInclusive and lastIsInclusive). A TimePointRange contains the TimePoints ‘between’ these two limits, e.g.,

∀i : TimeInterval(i) ⇒ start(i) < end(i).

∀r, t : TimePoint(t) ∧ TimePointRange(r) ∧

firstIsInclusive(r) ∧ lastIsInclusive(r) ⇒ (t ∈ r ⇔ (first(r) ≤ t ∧ t ≤ last(r))).

(1)

The simplified representation for a TimePointRange including both limits is [first . . . last], e.g., [ − 3 . . . 1.5]. For an exclusive limit, a parenthesis is used instead of a bracket, e.g., ( − 3 . . . 1.5]. Similarly, a DurationSet is a set of Durations. The DurationEnumeration and the DurationRange are defined analogously to the TimePointSets, and the same notation is used. In Fig. 3, there are two examples of DurationRanges. The duration given for a1, which is formally the durations attribute of a DurationConstraint assigned to a1 (cf. Table 2), and the end-start label of cf2, which visualizes the durations attribute of an EndStartConstraint assigned to cf2. 5.4.2. Auxiliary objects Occurrences are not modeling elements of WPML, but auxiliary objects to define the behavioral semantics of the language. A WorkProcessOccurrence represents a possible occurrence of an entire WorkProcessModel. It contains ControlFlowOccurrences and ActionOccurrences, both subclasses of WorkProcessElementOccurrence. All Occurrences have an isAnOccurrenceOf property. For a ControlFlowOccurrence, isAnOccurrenceOf refers to one or more ControlFlows. For ActionOccurrences, isAnOccurrenceOf is functional and its range is Action.6 ActionOccurrences have a functional property

6 A functional property is a property that assigns exactly one value to each element of the domain. Here, this means that an ActionOccurrence isAnOccurrenceOf exactly one Action.

(2)

Fig. 4 shows four exemplary WorkProcessOccurrences of the WorkProcessModel in Fig. 3. wpo1 contains two ActionOccurrences ao1 and ao2. The digits in the IDs of ActionOccurrences have been chosen according to the IDs of the Actions in the WPML model. Between ao1 and ao2, the ControlFlowOccurrence cfo1 is shown, which isAnOccurrenceOf the ControlFlows cf1 and cf2. Thus wpo1 represents an occurrence of the WorkProcessModel in Fig. 3 such that each a1 and a2 occur once; the other Actions do not occur. The ControlFlowOccurrence cfo1 keeps references to the ControlFlows in the path we have ‘followed’ from a1 to a2. We say that a WorkProcessOccurrence is causally valid if its topology can be generated by ‘following’ the ControlFlows in the corresponding model. Here, topology refers to the coupling of ActionOccurrences and ControlFlowOccurrences and the values of their isAnOccurrenceOf property. In Section 5.4.3, the criterion for causal validity is discussed in detail. According to Fig. 4, ao1 of wpo1 occursIn in the TimeInterval [2;3], ao2 in [3;6]. These TimeIntervals are also visualized in the Gantt chart on the right hand side of wpo1. The duration of Action a1 is constrained to be in the TimeRange [2..4]. As the duration of the TimeInterval [2;3] is 1, this constraint is not satisfied by ao1. We define a WorkProcessOccurrence as temporally valid if all occurrences contained satisfy all constraints. Hence, wpo1 is not temporally valid, in contrast to wpo2. In Section 5.4.4, we have a closer look at temporal validity. 5.4.3. Causal validity By an approach similar to that of Störrle and Hausmann (2005) for UML activity diagrams, a transformation of WPML models in Petri nets is defined. The Petri net dialect chosen is the colored hierarchical Petri net as defined by Jensen (1997). However, statetransition nets are sufficient to describe most properties of the transformation, which allows us to use this simpler and more readable Petri net variant in the following discussion. The relevant part of the state-transition net corresponding to the WPML model in Fig. 3 is shown in Fig. 5. Each Action and each ControlFlow is transformed in a transition (denoted by a1,... a4, cf1,... cf5). The DecisionNode has become a place with two outgoing

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691

687

In case of a WPML model with loops, there can also be an infinite number of valid topologies.

a1

5.4.4. Temporal validity The definition for temporal validity of a WorkProcessOccurrence can be formalized in a straightforward approach. By definition, a single WorkProcessElementOccurrence is temporallyValid if and only if it satisfies all Constraints of all WorkProcessElements it is an occurrence of,

cf1

cf3

cf2

cf4

cf5

a2

a3

a4

∀o : WorkProcessElementOccurrence(o) ⇒

...

...

Fig. 5. Transformation of the WPML model in Fig. 3 in a state-transition net.

arcs. There is no element in the Petri net directly corresponding to the ForkNode; it is represented indirectly by the fact that there are two outgoing arcs from transition cf3. It can easily be verified that the net represents the causal dependencies of the Actions as discussed above. The topmost place, representing the StartNode of the WPML model, contains a single token. The only active transition is a1; the firing of the transition represents an occurrence of Action a1. Then, only cf1 is active, i.e., we have to ‘follow’ the ControlFlow cf1. When cf1 has fired, both transitions cf2 and cf3 are active. If cf2 fires, a2 will fire next, which is interpreted as an occurrence of Action a2. Alternatively, cf3 can fire, which will eventually lead to the firing of both a3 and a4 (in an undefined order). It should be noted that the order, in which the transitions in the Petri net fire, must not be interpreted as the execution order of the Actions. The Petri net is more complicated than it would have to be if we were only interested in the occurrences of Actions. If we removed all transitions labeled cf... (except cf3) and merged the superfluous places, then still either a2 or both a3 and a4 would fire. But, the explicit transformation of ControlFlows in transitions allows to keep track of the ControlFlows we follow in the corresponding WPML model. Thus, the firing of Action transitions provides information about ActionOccurrences, and the interim firing of ControlFlow transitions provides information about ControlFlowOccurrences. We define a WorkProcessOccurrence as causally valid if its topology can be generated in a simulation run of the Petri net transformation of the corresponding WPML model.7 According to this criterion, all WorkProcessOccurrences in Fig. 4 are causally valid. wpo1 and wpo2 have the same topology; they correspond to the case that each a1 and a2 occur once. wpo3 and wpo4 describe the case that each a1, a3 and a4 occur once. By a state-space analysis of the Petri net, we can verify that there are no other valid topologies than those of wpo1/wpo2 and wpo3/wpo4.8

7

The necessity to trace the transitions fired by each token individually is one reason to use a more expressive Petri net variant than state-transition nets. 8 A state-space analysis yields information about all states (markings) a Petri net can reach from a state.

(3)

The definitions of the fulfilled predicate for the different Contraints are given in Table 2. An entire WorkProcessOccurrence is temporallyValid if all WorkProcessElementOccurrence it contains are temporallyValid,

∀w : WorkProcessOccurrence(w) ⇒

...

(temporallyValid(o) ⇔ (∀e, c : occurrenceOf(o, e) ∧ isConstrainedBy(e, c) ⇒ fulfilled(c, o))) .

(temporallyValid(w) ⇔ (∀o : contains(w, o) ⇒ temporallyValid(o))) .

(4)

5.5. Additional WPML modeling elements So far, we have focused on the basic modeling elements of WPML. These elements are sufficient to define the basic behavioral semantics of the language. In this section, some additional elements are briefly introduced. 5.5.1. Control flow types In the introductory example, we have already mentioned the different types of control flows. They are defined as subclasses of ControlFlow that are subject to some predefined Contraints defined in analogy to the time interval relations by Allen (1983). As an example, the BeforeConstraint is an EndStartDurationConstraint with a durations range of (zero...max), i.e., it enforces a positive time gap between two ActionOccurrences. Similarly, the MeetsConstraint is an EndStartDurationConstraint allowing durations in {zero}; it forces a subsequent ActionOccurrence to begin at the same time the preceding ActionOccurrence ends. A StrictControlFlow is a ControlFlow that is constrained by the conjunction (or-combination) of the BeforeConstraint and the MeetsConstraint. Hence, in simple terms, a StrictControlFlow disables a subsequent Action to start before a preceding Action ends. The predefined control flow types are syntactic sugar, i.e., they do not affect the expressiveness of WPML. They are rather useful auxiliaries for recurrent patterns in work process models. 5.5.2. Resources The execution of an Action can require the availability of Resources such as human actors or tools. A Resource as defined in WPML cannot be involved in more than one ActionOccurrence at the same time. This imposes restrictions on the occurrences of Actions relying on the same Resource. The formal semantics of Resources is based on ResourceRestrictions that can be assigned to Actions. In concrete WPML syntax, ResourceRestrictions are represented by grouping Actions in ‘swimlanes’ (the preferred option for human actors) or by tool symbols pinned on the Actions. 5.5.3. Decomposition The possibility to decompose large models in manageable parts is a prerequisite for dealing with complex work processes. To this end, an Action in WPML can refer to a WorkProcessModel that describes the internal behavior of the Action (cf. the isRefinedBy

688

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691

Fig. 6. Overview of the tool architecture.

property in Fig. 2). The semantics of a model with such refinements is equivalent to that of a model in which the refined Actions are replaced with the referenced WorkProcessModels. 6. Software tools Substantial tool support is a prerequisite for the practical application of the modeling procedure. Fig. 6 gives an overview on the overall architecture, comprising several open-source software systems and own developments by our group. The following discussion is organized ‘chronologically’, that is, we first describe the creation of a domain-specific extension of WPML by an expert, then the usage of this extension by a non-expert (i.e, a non-expert of knowledge representation). Finally, we have a closer look at model transformations. As an application scenario, we consider the creation of a first draft of an operational process in WPML and the subsequent transformation of the model into a simulation model for Aspen Batch Process Developer. The relevant components of the architecture are explained as required. 6.1. Extending WPML with domain-specific concepts As WPML itself does not provide any domain-specific modeling concepts for operational processes, it must be extended by an appropriate OWL module. This task requires an expert (or a group of experts) with a background in both chemical engineering and knowledge representation, called knowledge engineer in the following. Protégé (Stanford Center for Biomedical Informatics Research, 2008) is a well-established and mature OWL editor which saves the knowledge engineer from the manual manipulation of verbose RDF/XML files. The knowledge engineer will create a new OWL module for operational processes (module op, cf. Fig. 2), define the classes and properties required (e.g., TemperatureChange, endTemperature), and establish their rela-

tions with existing WPML elements (op:OperationalFunction is an owl:subclassOf wpml:Function). Probably, part of the semantics cannot be encoded in OWL, but must be represented by rules, which can be integrated in the OWL module as textual annotations.9 If a transformation of WPML models in an application format is planned, it will also be implemented by the knowledge engineer, for instance in XSLT (World Wide Web Consortium, 2007), the standard for the transformation of XML documents in other (not necessarily XML) formats. 6.2. Work process modeling with WOMS-plus Given that WPML instance models are technically OWL modules, they could in principle be created in a general-purpose OWL editor like Protégé. But, without WPML-specific adaptations, such tools would provide no graphical representation at all or only in a rudimentary way, similar to the abstract syntax in Fig. 3. Therefore, the Work Process Modeling System WOMS-plus has been developed by the authors. Based on the intuitive concrete syntax of WPML, WOMS-plus provides a user-friendly interface for manipulating the abstract RDF graphs. In a typical session, a user (process engineer) would import the WPML extensions adequate to the modeling task at hand, e.g., the op module for operational processes. When the user has inserted an Action into the model, he is free to add further information. He may be content to give a textual annotation (Increase temperature up to 120 ◦ C). Alternatively, he can select one of the Function classes of the op module, which are offered by

9 Unfortunately, the built-in rule reasoner of Jena does not yet support SWRL (World Wide Web Consortium, 2004c), a proposed standard for OWL rules. Instead, rules must be represented in a Jena-specific format. The WOMS-plus server ensures that the rules are loaded into the rule reasoner. This is apragmatic work-around to avoid the creation of separate rule files.

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691

WOMS-plus in a list field. If he chooses the TemperatureChange, the tool will show a text field for the endTemperature, which the user can fill—or not. From the user’s point of view, WOMS-plus is a generic modeling tool for WPML which can easily be adapted for certain types of work processes by means of configuration files in OWL. The functionality of WOMS-plus builds on the Jena Semantic Web Framework (Hewlett Packard, 2009), which provides the core functionality to work with RDF and OWL models. We have extended Jena with the capability to act as a server, which allows WOMSplus to access the required functionality of Jena. When the user does a modification of a WPML model in WOMS-plus, it is sent via the WOMS-plus server to the model store in Jena. The model store contains an RDF graph, whose subgraphs encode the asserted knowledge (the vocabulary, axioms, and rules of WPML and the optional extensions, and the assertions of the WPML instance model) and part of the derived knowledge. The latter is generated by Pellet, a state-of-the-art OWL reasoner (Clark & Parsia, 2009) that is closely integrated with Jena, and by the built-in rule reasoner of Jena. Both reasoners directly act on the model store. Each modification of the asserted knowledge can result in modifications of the derived knowledge. The WOMS-plus server ensures the transmission of the modifications to WOMS-plus, which informs the user accordingly, e.g., about newly available attributes (the endTemperature of a TemperatureChange Action) or about semantic problems in case a model check fails. In real-time mode of WOMSplus, this update is executed after each semantic modification of the model.10 If complex extension modules or instance models are loaded, the real-time mode can lead to unacceptable reaction times of the user interface. Therefore, a lazy mode has been integrated, which runs through the update loop only on explicit request by the user. 6.3. Model transformations Obviously, automatic model transformations require explicit transformation rules. In general, a transformation comprises a semantic transformation and a syntactical transformation. The semantic transformation affects the mapping of modeling concepts of the source language to those of the target language. In the application scenario, the process engineer wants to transform the WPML model into a simulation model for Aspen Batch Process Developer (BPD for short in the following). Given the WPML instance model in Fig. 2 as the transformation source, information about the BPD equivalents of Action, TemperatureChange, and Charging is required. BPD does not support an abstract ‘general’ process step. In consequence, transforming an Action without any explicit Function information is not possible. For a Charging Action, BPD provides an appropriate concept. This is not the case for a TemperatureChange Action. Instead, BPD distinguishes heating and cooling. A TemperatureChange Action can only be transformed if it can be identified to be either a heating or cooling. To deal with such complications, conventional approaches like XSLT or hard-coded transformation utilities rely on complex procedural rules (such as nested if clauses) that are hard to maintain. The syntactical transformation refers to the format in which the modeling concepts are represented, for instance in a binary file, a structured text file, or an XML document. Conventional transformation techniques, at least when applied in a naive manner, tend to merge semantic and syntactical transformations, thus still increasing the complexity of the solution. We argue that the semantic technologies applied in the framework provide substantial support for model transformations and

10 For efficiency reasons, the model layout is handled exclusively by WOMS-plus. Simple modifications of the layout do not affect Jena.

689

reduce the effort for the specification of transformation rules considerably. By means of declarative assertions the relations between the source and target concepts can be represented in a straightforward manner. To this end, an additional startTemperature attribute is declared for the TemperatureChange. Then, a Heating can be defined as a TemperatureChange from a lower to a higher Temperature.11 Based on the definition, the reasoners can identify a certain TemperatureChange with appropriate temperature values as a Heating.12 This information can be included in the XML serialization of the WPML model. The further transformation of the model in the format of BPD is strictly syntactical and can easily be realized by means of XSLT.13 It is important to note that the definition of Heating is independent from any application. Several model transformations can build on the definition. Further, the reasoners can detect a semantic error in a WPML model containing a Heating from a higher to a lower temperature. 7. Tailoring to target applications The practical validation of the modeling framework in cooperation with partners from industry is currently in progress (Theißen, Hai, & Marquardt, 2008a). To this end, several case studies aiming at the modeling of design and operational processes in chemical engineering are performed. This section is about the models extensions and model transformations realized in the context of these case studies. 7.1. Model extensions Other than the simplistic op module used to illustrate the approach might suggest, the creation of domain-specific model extensions of WPML is by no means a trivial task. Two extension packages providing modeling elements to represent design processes and operational processes have been developed to support the case studies. Hai et al. (2010) give an overview on both of them, while Hai et al. (submitted) focus on operational processes. Both packages build on OntoCAPE (Marquardt, Morbach, Wiesner, & Yang, 2010; Morbach, Wiesner, & Marquardt, 2009), a comprehensive ontology for the CAPE domain, to enable the integration of work process models with the artifacts created in design processes, e.g., process flow diagrams or mathematical models. 7.2. Model transformations The industrial case studies in progress involve several model transformations that are briefly reviewed. Some of them are generic, others are only applicable for certain types of work processes. 7.2.1. Generic transformations Several transformations from WPML to CPN Tools (2009), a Petri net simulator implementing colored hierarchical Petri nets,

11 Strictly speaking, this definition of Heating is not possible in OWL. Instead, a rule must be used. 12 From the technical point of view, this approach for model transformation is a variant of the approach by Wiesner, Morbach, and Marquardt (this issue) for the integration of documents. In consequence, the knowledge that has been explicitly represented for the purpose of model transformations could be reused for model integration. So far, we have not explored this potential for synergy. 13 In general, RDF/XML does not constitute a suitable source format for XSLT because it allows several semantically equivalent, but syntactically different representations of the same RDF graph. XSLT, in contrast, heavily relies on the syntactical structure of an XML document. To overcome this issue, a normalized XML representation of the RDF graph is created.

690

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691

have been realized. A basic transformation results in a Petri net the state-space analysis of which yields the possible topologies of occurrences of the source model (cf. Section 5.4.3). It is of a more theoretical interest. More practical transformations aim at Petri nets that can be used to create complete and valid WorkProcessOccurrences of a WPML model, or, in simple terms, to simulate the model. Given the declarative semantics of temporal relations in WPML, the transformation of arbitrary WPML models with unusual time Constraints is not practical (and probably impossible14 ). Instead, we have taken a pragmatic approach based on the observation that realistic models typically fulfill some criteria that enable useful Petri net transformations. For two cases, such transformations have been implemented: • Models containing only StrictControlFlows can be transformed in a straightforward manner similar to the approach discussed in Section 5.4.3, but with simple extensions to cover temporal relations. • The second, more general case covers models whose ControlFlows are all subject to StartStartConstraints that exclude negative durations.15 The Petri nets created are considerably more complex than those in the previous case. In fact, this complexity was our motivation to define the temporal semantics of WPML by means of simple and clean axioms in first-order logics rather than by a Petri net transformation. The formal proof of the equivalence of the WPML source models and the complex Petri nets is beyond the scope of our work. 7.2.2. Transformations for operational processes A transformation of models of operational processes in simulation models for the Aspen Batch Process Developer has been implemented. The semantic transformation follows the approach sketched in Section 5.4.3. In a subsequent, purely syntactical transformation with XSLT, intermediate XML documents are created, which can easily be imported into the relational database in which BPD models are stored. The prototypical implementation is restricted to sequential Actions in the WPML source. The different Functions of operational Actions are converted into the appropriate types of unit procedures in BPD. For some exemplary Function classes, we have demonstrated the inclusion of their attributes (e.g, the end temperature for heating) in the target model. A further transformation of operational processes aims at a skeleton for Sequential Function Charts (SFC, IEC 61131-3), which can than be completed in a dedicated SFC editor. The implementation of the transformation is still in progress. 7.2.3. Transformations for design processes In cooperation with academic partners in the Transfer Center 61 “New Concepts and Tools for Process Engineering Practice”, the successor of the IMPROVE project (Nagl & Marquardt, 2008), a tool suite for the integrated modeling, simulation, and enactment of design processes has been created (Heer, Tackenberg, & Theißen, 2009). Tackenberg, Kausch, and Schlick (2009) and Tackenberg, Schneider, Schlick, and Kausch (this issue) propose an approach for the simulation of design processes, which generates a detailed project schedule based on a semi-formal description of a design project. Heer and Wörzberger (2009, this issue) describe a management tool for process enactment support, which includes a conventional workflow management system, and also supports a more flexible approach for managing engineering design processes.

14 One reason is the separation of causality and chronology. In principle, WPML allows control flows from later Actions to earlier Actions. 15 In this case, causality and chronology coincide.

The approach followed in the tool suite is to export WPML models into both the simulation tool and the management tool. In addition, the simulation results are made available to the management tool such that they can be used during process enactment to optimize task scheduling and resource management. However, the required transformations were implemented by our partners before the software infrastructure of the modeling framework described here was completed, and thus rely on conventional technology. 8. Conclusions We have presented a framework for work process modeling in the chemical industries. Currently, the framework’s usability in industrial settings is validated in cooperation with industrial partners. We expect that the framework will enable any stakeholder in an industrial work process to routinely create and utilize work process models with moderate effort. The framework can be applied to different types of work processes. If required, a meta-model for a certain application domain or process type can be created and seamlessly be integrated. This enables to reuse the framework in different situations and thus to reduce the cost and effort for introducing different frameworks into an organization. Further, the framework supports the creation of a single application-independent model which can be reused in different applications such as simulators and process enactment systems. Thus, the effort required for obtaining a simulation model and a model for process enactment of the same work process can be reduced. Obviously, such reuse of work process models requires the definition of suitable model transformations. Based on semantic technologies, the framework provides substantial support for the implementation of such transformations. To a certain extent, even the reuse of model transformations is possible. Some transformations of instance models—such as the transformation into a Petri net—are largely independent of the process types and can be defined based on the type-independent classes in the WPML module. Acknowledgments Claudia Tchemtchoua and Mohamad Ridwan Agustiawan have contributed substantially to the implementation of the diverse model transformations. The authors also acknowledge financial support from the German Research Foundation (DFG) under grant MA 1188/29-1. References Allen, J. F. (1983). Maintaining knowledge about temporal intervals. Communications of the ACM, 26(11), 832–843. Aspen Technology. (2009). Aspen batch process developer. http://www.aspentech.com/products/aspen-batch-plus.cfm Bock, C., & Gruninger, M. (2005). PSL: A semantic domain for flow models. Software and Systems Modeling Journal, 4(2), 209–231. Clark & Parsia. (2009). Pellet OWL Reasoner. http://clarkparsia.com/pellet/ CPN Tools. (2009). Department of Computer Science, University of Aarhus. http://www.daimi.au.dk/CPNTools/ Davenport, T. H. (1993). Process innovation. Boston: Harvard Business School. Davis, R. (2001). Business process modeling with ARIS: A practical guide. Berlin: Springer. Douglas, J. M. (1988). Conceptual design of chemical processes. New York: McGrawHill. Eggersmann, M., Kausch, B., Luczak, H., Marquardt, W., Schlick, C., Schneider, N., et al. (2008). Work process models. In: Nagl, M., & Marquardt, W. (Eds.), Collaborative and Distributed Chemical Engineering. From Understanding to Substantial Design Process Support. Results of the IMPROVE Project (Ch. 2.4, pp. 126–152). Berlin: Springer. Georgakopoulos, D., Hornick, M., & Sheth, A. (1995). An overview of workflow management: From process modeling to workflow automation infrastructure. Distributed and Parallel Databases, 3(2), 119–153.

M. Theißen et al. / Computers and Chemical Engineering 35 (2011) 679–691 Guha, S., Kettinger, W. J., & Teng, T. C. (1994). Business process reengineering: Building a comprehensive methodology. Information Systems Management, 10(3), 13–22. Hai, R., Theißen, M., & Marquardt, W. (2010). An extensible modeling language for the representation of work processes in the chemical and process industries. In: Engels, G., Lewerentz, C., Schäfer, W., Schürr, A., & Westfechtel, B. (Eds.), Graph Transformations and Model Driven Enginering – Essays Dedicated to Manfred Nagl on the Occasion of his 65th Birthday (Vol. 5765 of LNCS). Berlin/Heidelberg/New York: Springer. Hai, R., Theißen, M., & Marquardt, W. (submitted). An ontology-based approach for operational process modeling. Advanced Engineering Informatics. Heer, T., Tackenberg, S., & Theißen, M. (2009). Integrated modeling, simulation, and enactment of design processes in chemical engineering. In World Congress of Chemical Engineering (WCCE8) Montreal. Heer, T., & Wörzberger, R. (2009). Support for modeling, enactment and monitoring of engineering design processes. In World Congress of Chemical Engineering (WCCE8) Montreal. Heer, T., & Wörzberger, R. (this issue). Support for modeling and monitoring of engineering design processes [Special issue Knowledge Management – WCCE congress papers]. Computers and Chemical Engineering. Hewlett Packard. (2009). Jena semantic web framework. http://jena.sourceforge.net/ Horridge, M., & Patel-Schneider, P. F. (2008). Manchester syntax for OWL 1.1. In K. Clark, & P. F. Patel-Schneider (Eds.), OWL: experiences and directions, fourth international workshop. Washington, DC. Jensen, K. (1997). Coloured Petri Nets. Basic concepts, analysis methods and practical use. Vol. 1. Basic concepts. Monographs in theoretical computer science. Berlin: Springer-Verlag [2nd corrected printing]. Killich, S., Luczak, H., Schlick, C., Weissenbach, M., Wiedenmaier, S., & Ziegler, J. (1999). Task modelling for cooperative work. Behaviour and Information Technology, 18(5), 325–338. Marquardt, W., Morbach, J., Wiesner, A., & Yang, A. D. (2010). OntoCAPE – A re-usable ontology for chemical process engineering. Berlin: Springer. Morbach, J., Wiesner, A., & Marquardt, W. (2009). OntoCAPE 2.0 – A (re)usable ontology for computer-aided process engineering. Computers and Chemical Engineering, 33, 1546–1556. Nagl, M., & Marquardt, W. (Eds.). (2008). Collaborative and distributed chemical engineering. From understanding to substantial design process support. Results of the IMPROVE project. Berlin: Springer. National Institute of Standards and Technology (NIST). (1993). Integrated definition for function modeling (IDEF0). Report No. NISTIR 183. National Institute of Standards and Technology (NIST). (2000). The Process Specification Language (PSL): Overview and version 1.0 specification (Report No. NISTIR 6459). Object Management Group (OMG). (2006). Business Process Modeling Notation (BPMN). http://www.omg.org/ Object Management Group (OMG). (2009). Unified modeling language (OMG UML), superstructure, version 2.2. http://www.omg.org/technology/ documents/formal/uml.htm Petri, C. A. (1962). Kommunikation mit Automaten. Schriften des IIM 2. Institut für Instrumentelle Mathematik. Phalp, K., & Shepperd, M. (2000). Quantitative analysis of static models of processes. Journal of Systems and Software, 52(2–3), 105–112.

691

Phalp, K. T. (1998). The CAP framework for business process modelling. Information and Software Technology, 40(13), 731–744. Rummler, G. A., & Brache, A. P. (1995). Improving performance: How to manage the white space on the organizational chart. San Francisco: Jossey-Bass. Sharp, A., & McDermott, P. (2001). Workflow modeling: Tools for process improvement and application. Norwood, MA: Artech House. Stanford Center for Biomedical Informatics Research. (2008). The Protégé ontology editor and knowledge acquisition system. http://protege.stanford.edu/ Störrle, H., & Hausmann, J. H. (2005). Towards a formal semantics of UML 2. 0 activities. In P. Liggesmeyer, K. Pohl, & M. Goedicke (Eds.), Software engineering. Vol. 64 of LNI, GI (pp. 117–128). Berlin: Springer. Tackenberg, S., Kausch, B., & Schlick, C. M. (2009). Organizational simulation of complex process engineering projects in the chemical industry. In World Congress of Chemical Engineering (WCCE8) Montreal. Tackenberg, S., Schneider, S., Schlick, C. M., & Kausch, B. (this issue). Simulation and optimization of process engineering projects in the chemical industry [Special issue Knowledge Management – WCCE congress papers]. Computers and Chemical Engineering. Theißen, M., Hai, R., & Marquardt, W. (2008a). Computer-assisted work process modeling in chemical engineering. In: M. Nagl, & W. Marquardt (Eds.), Collaborative and distributed chemical engineering. From understanding to substantial design process support. Results of the IMPROVE project (Ch. 7.3, pp. 656–665). Berlin: Springer. Theißen, M., Hai, R., & Marquardt, W. (2008). Design process modeling in chemical engineering. Journal of Computing and Information Science in Engineering, 8(1), 011007 (9 pages). Theißen, M., Hai, R., Morbach, J., Schneider, R., & Marquardt, W. (2008). Scenariobased analysis of industrial work processes. In: M. Nagl, & W. Marquardt (Eds.), Collaborative and distributed chemical engineering. From understanding to substantial design process support. Results of the IMPROVE project (Ch. 5.1, pp. 433–450). Berlin: Springer. Theißen, M., & Marquardt, W. (2007). Decision process modeling in chemical engineering design. In 17th European symposium on computer aided process engineering (pp. 383–388). Theißen, M., & Marquardt, W. (2009). Integrated modeling of work processes and decision in chemical engineering design. In C. M. Schlick (Ed.), Industrial engineering and ergonomics (pp. 265–279). Berlin: Springer. van der Alst, W. M. P., & ter Hofstede, A. H. M. (2005). YAWL: Yet another workflow language. Information Systems, 30(4), 245–275. Wiesner, A., Morbach, J., & Marquardt, W. (this issue). Information-integration in chemical process engineering based on semantic technologies [Special issue Knowledge Management – WCCE congress papers]. Computers and Chemical Engineering. World Wide Web Consortium. (2004a). OWL Web Ontology Language. Reference. Recommendation. http://www.w3.org/TR/owl-ref/ World Wide Web Consortium. (2004b). Resource Description Framework (RDF). http://www.w3.org/RDF/ World Wide Web Consortium. (2004c). SWRL: A semantic web rule language combining OWL and RuleML. [W3C member submission] http://www.w3.org/ Submission/SWRL/ World Wide Web Consortium. (2007). XSL Transformations (XSLT) Version 2.0. W3C Recommendation. http://www.w3.org/TR/xslt20/