Manfred Theißen

Design Process Modeling in Chemical Engineering

In this contribution, a methodology for modeling, improving, and implementing design processes in chemical engineering is presented. The methodology comprises a semiformal modeling language for design processes, complemented by a modeling procedure describing the efficient creation of design process models. The methodology inherits from some approaches developed in the domain of business process reengineering and work-flow management, but has been extended considerably to meet the requirements imposed by the creative character of design processes. Two case studies demonstrating the successful application of the procedure for design processes in different industrial settings are discussed.

Ontology-Based information management in design processes

Abstract Engineering design processes are highly creative and knowledge-intensive tasks that involve extensive information exchange and communication among diverse developers. In such dynamic settings, traditional information management systems fail to provide adequate support due to their inflexible data structures and hard-wired usage procedures, as well as their restricted ability to integrate processes and product information. In this paper, we advocate the idea of Process Data Warehousing as a means to provide an information management and integration platform for such design processes. The key idea behind our approach is a flexible ontology-based schema with formally defined semantics that enables the capture and reuse of design knowledge, supported by advanced computer science methods.

Work Process Models

Empirical studies are a prerequisite for creating meaningful models of work processes, which can be used to analyze, improve, and automate design processes. In this contribution, a modeling procedure is presented, which comprises the creation of semi-formal models of design processes, their analysis and improvement, and finally the formalization of the models as a prerequisite for the implementation of supportive software tools. Several modeling languages have been created for representing design processes, including the C3 language for participative modeling of design processes on a semi-formal level and a Process Ontology for the formal representation of design processes.

Computer-Assisted Work Process Modeling in Chemical Engineering

The transfer project aims at the integrative modeling, analysis, and improvement of a variety of work processes in the life cycle of a chemical product across disciplinary and institutional boundaries. A methodology is elaborated for the creation of conceptual, coarse grained models of work processes originating from empirical field studies in industry and their subsequent enrichment and formalization for computer-based interpretation and processing.

Scenario-Based Analysis of Industrial Work Processes

In this section, the modeling procedure for design processes introduced in Subsect. 2.4.2 is discussed from a more application-oriented point of view. The Workflow Modeling System WOMS, which has been developed for the easy modeling of complex industrial design processes, is described. Many case studies have been performed during the elaboration and validation of the modeling methodology and the tool, several of them in different industrial settings. In this contribution, some case studies are described in more detail. Two of them address different types of design processes. A third case study, demonstrating the generalizability of our results, deals with the work processes during the operation of a chemical plant.

Integrated Application Domain Models for Chemical Engineering

A comprehensive summary of the application domain models presented in this chapter is given, and their integration into a common framework is discussed. Other existing application domain models of comparable scope are reviewed and compared to the models presented herein.

Decision process modeling in chemical engineering design

Abstract Documenting the rationale in design processes is commonly accepted to be rewarding, but rarely done in practice due to the required time and effort. We propose an integrated approach to work process and decision modeling, characterized by both an improved usefulness of the models and less effort for their creation.

Integrated Modeling of Work Processes and Decisions in Chemical Engineering Design

class relation generalization Notation Fig. 21.1: An integrated ontology for work processes and decisions Integrated Modeling of Work Processes and Decisions 271 A WorkProcess is Composed Of Work Process Elements, which form a network consisting of Work Process Nodes and Work Process Relations. Work Process Nodes comprise Action and Information elements. (An Action corresponds to an Activity in C3. The term Activity had been adopted from the terminology of the activity diagrams in UML 1.x. In the ontology, we have renamed Activity to Action in compliance with the terminology of UML 2.x.) In addition, there are Control Nodes such as Fork Nodes, which indicate the beginning of two or more control flows in parallel (the subclasses of Control Node are not given in the figure). Via the isRefinedBy relation, an Action can be linked to a subordinate WorkProcess which provides a more detailed representation of the Action on a finer level of granularity. Most Work Process Relations are binary Directed Work Process Relations characterized by a source node and a target node (relations hasSource and hasTarget). In a graphical depiction of a work process on the instance level in C3 notation, a Directed Work Process Relation is represented by an arrow from its source to its target; examples of Directed Work Process Relations include the Control Flow between Actions and/or Control Nodes and the Information Flow between Actions and Information elements. The Information Relation is a relation between two Information elements. The Synchronization of two or more Actions (not shown in the figure) is an example of a Work Process Relation which is not directed. P234: Design prod. proc. for PA6 Select mode of operation Continuous mode chosen Design reaction unit VK column ... Project P234 Design production process for PA6 Requirements for PA6 production process Process flow diagram of PA6 process P234: Select mode of operation Select mode of operation Continuous mode chosen Estimate reaction times Estimated reaction times isRefinedBy isRefinedBy Fig. 21.2: A simplistic model of a concrete design process 272 Marquardt & Theisen To illustrate the use of the process ontology, a simplistic model of a concrete design process for PA6 (polyamide6, a thermoplastic polymer) is shown in Fig. 21.2. On top, the overall WorkProcess “Project P234” is shown, which contains a single Action “Design production process for PA6” as well as two Information items: The “requirements” the chemical process must fulfill are the input of the design Action, whereas the “process flow diagram” is its output. The design Action itself isRefinedBy a more detailed WorkProcess called “Design production process for PA6”, containing further Actions like “Select mode of operation”, which generates the output Information “Continuous mode chosen”, and “Design reaction unit”, which is based on the chosen mode of operation. For the first Action, an even more detailed WorkProcess is shown, which indicates that some characteristic reaction times had been estimated before the mode of operation was chosen. Obviously, restricting the representation of a design process to the procedural aspect suffers from several deficiencies. The requirements for the chemical process are hidden within a simple Information element, although they are decisive for the progress of the design process. Also, no information is provided about the arguments that have let the designers choose a continuous mode of operation. In particular, it is unclear why the reaction times were estimated before deciding on the mode of operation. 4 An Ontology for Design Decisions The Decision Representation Language (DRL) by LEE (1990) is an expressive, but nevertheless intuitive graphical notation for such design rationale. Its ability for representing complex argumentations was decisive for choosing DRL as the foundation for the decision ontology described in this section. As shown in the lower part of Fig. 21.1, all classes of the ontology are derived from the abstract Decision Object. Instances of the five classes given in the left part of the figure, including the Simple Claim, form the nodes of a decision model. A DecisionProblem is a design problem that requires a Decision; the relation IsASubdecisionOf permits to decompose a Decision. Alternatives are the options meant to solve a DecisionProblem. The desired properties of Alternatives are represented by Goals, which can be decomposed by means of IsASubGoalOf. Two further relations, Achieves and IsAGoodAlternativeFor, are used to evaluate an Alternative with respect to a Goal or a DecisionProblem, respectively. Questions are issues to be considered in the context of a DecisionProblem. Finally, a Decision represents the selection of one Alternative, i.e., it Resolves a certain DecisionProblem. Any statement in a decision model which may be subject to uncertainty or to disaccord is represented by a Claim. Claims are either SimpleClaims or relation classes derived from the abstract IsRelatedTo. In fact, most of the relations between the elements introduced above are derived from IsRelatedTo, i.e., they are Claims. For the sake of clarity, the ranges of hasSource and hasTarget for these relation classes Integrated Modeling of Work Processes and Decisions 273 are given in textual form in Fig. 21.1. For example, in case of Resolves, the range of hasSource is Decision and the range of hasTarget is DecisionProblem. The graphical representation of Resolves on the instance layer is an arrow labeled “Resolves” from a Decision instance to a DecisionProblem instance. Four additional relation classes derived from IsRelatedTo (Supports, Denies, Presupposes, and Exceeds) permit to represent complex argumentations. Denies, in particular, can be used to negate any Claim. Continuous mode PA6 production process Annual capacity of PA6: 40000 t Purity of PA6: 0.99 Molecular weight of PA6: 18000 g/mol

An Introduction to Application Domain Modeling

This section serves as an introduction to application domain modeling. Firstly, we will motivate the objectives of modeling. Next, we will suggest definitions for different types of application domain models. Finally, a brief survey of the modeling languages applied throughout this chapter will be given.

An extensible modeling language for the representation of work processes in the chemical and process industries

Expressive models of the work processes performed in the chemical and process industries provide a basis for diverse applications like work process documentation, analysis, and enactment. In this contribution, we present a generic modeling language for different types of work processes to allow for their integrated representation in the life cycle of a chemical plant. Further, the generic language allows for extensions specific to certain types of work processes. For two important types - design and operational processes - such extensions have been elaborated. These extensions enable the adequate representation of the context of a work process that strongly depends on the process type: for instance, the specification of a chemical plant is a product of a design process, whereas the plant takes the role of a resource during an operational process. This contribution also briefly introduces a modeling tool developed by our group for applying the modeling language in industrial practice.