Computers chem. Engng, Vol. 18, Suppl., pp. S307-S311, 1994 0098-1354/94 $6.00+0.

00
Printed in Great Britain. All rights reserved Copyright © 1993 Pergamon Press Ltd

METHODOLOGY OF PROCESS DESIGN

V.J. POHJOLA, M.K. ALHA and J. AINASSAARI

University of Oulu, Linnanmaa

SF-90570 Oulu, Finland

ABSTRACT

Methodology of process design is presented as a procedural model of how process design is done.
Design project, represented as an object, acts as an adaptive controller of design process by updating
its own attributes. Performance driven strategy of process design is introduced and implies
description of process related concepts at various levels of abstraction. Object taxonomy of
declarative process knowledge is built upon a linguistic definition of process concept.

KEYWORDS

Process design, Methodology, Procedural model, Object taxonomy, Design strategy

INTRODUCTION

For systematizing process design, both declarative knowledge describing the design target - the
process itself - and procedural knowledge describing how to design, should be formalized. The
chemical engineering approach to systematizing process design should start from understanding the
process and especially the phenomena to be controlled. This is an approach opposite to those
pursuing domain independent design theories. In the latter, design is seen as a mapping from
function space onto attribute space (Chandrasekaran, 1990; Takeda et al., 1990). Design
specification is given as a functional description of the desired artifact, while the result of the design
activity is described in terms of structural properties (attributes) of the artifact. The structure should
be such that the resulting behavior of the artifact matches with the given functionality. Process differs
from other artifacts (like chair, house etc.) in that its behavior does not follow straight from the
structure, but, after the structure has been fixed, there are still lot of degrees of freedom to affect the
behavior. These result from the presence of various phenomena and a multitude of ways to control
them to achieve the desired purpose.

This paper attempts to show that a proper linguistic definition of process facilitates picking up the
relevant process related concepts and their semantic links as building blocks in formalizing
declarative process knowledge as an object taxonomy. Furthermore, the paper tries to make it evident
that procedural process design knowledge, represented as methods of objects, can be formalized into
a task hierarchy to serve as a process design methodology, and that this formalism is greatly dictated
by the object taxonomy.

8307
S308 European Symposium on Computer Aided Process Engineering-3

PROCESS AS AN OBJECT

Definitjon of process

The following high level linguistic definition of process has been tested by the authors in various
contexts and is a starting point for building object taxonomy

"(Chemical) process is control of (physico-chemical) phenomena for a purpose"

The three key concepts introduced can be defined further. Control divides into boundary and
interaction through the boundary. Thus, by definition, a phenomenon without a boundary around
. and without an interaction through it is not a process. Boundary may be real, like an interface (as in
equipment), to serve as a physical constraint, or fictitious to serve as a mathematical constraint for
modeling purposes. Interaction refers to material flow, energy flow, information flow, cash flow etc.
The existence of a boundary generates the other structural elements of process, namely interior and
exterior. Exterior is everything outside the boundary and includes environment and other processes.
Interaction takes place between interior and exterior. By phenomenon one refers to any spontaneous
event taking place in material to be processed in the interior. There are phenomena also in the
exterior but these are either uncontrolled or under control in other processes. Purpose explains why
we aim at contrOlling phenomena. It can be material conversion or energy conversion for making
money, for safety, or for environment protection. Thus, by definition, control of phenomena
without a purpose is not a process. Purpose tells which are the desired phenomena. State of material
dictates which are the phenomena to occur, that is, what is the rate of each individual phenomenon,
desired or undesired. Control of phenomena takes place thus indirectly through affecting their rates
by adjusting the state of the material in the interior. How well we manage in controlling phenomena
for a purpose is measured by evaluating the performance of the process using criteria like
profitability, safety etc.

Process object

Object is an ordered chunk of knowledge. The declarative knowledge is ordered as a list of attributes
and their values. The procedural knowledge encapsulated in an object is a set of methods mainly
intended for manipulating values of its own attributes. There are many ways to build an object
hierarchy (Stephanopoulos et al., 1990; Marquardt, 1992). In the following the formalism for
declarative process knowledge is based on the concepts introduced above (Objects in italics).

Process 1
Attribute: YlliJ.!e.:.
Purpose Process purpose
Structure Process structure
State Process state
Performance Process performance
Is-abstracted-by Process 2
Is-detailed-by Process 3

The value of each attribute is an object itself having its own list of attributes with values. For instance:

Process structure
Attribute: Value:
Topology Process topology
Unit structure Process unit structure
Process topology
Attribute: ~
Nodes List of Process instances
Links List of Interaction relation instances
 European Symposium on Computer Aided Process Engineering-3 S309

that the latter can be defined as an attribute of the former. The object formalism for process design
knowledge is as follows

Process design project 1

Attribute: ~
Purpose (of Activity) Process design purpose
Target (of Activity) Process 1
Strategy Process design strategy
Scope (of Activity) Process scope
Result (of Activity) Process 2
Resources Project resources
Performance (of Project) Project performance
Superprojects Project 2 .. .
Subprojects Project 11 .. .
Parallel projects Project 21 .. .
Method: Argument:
Set Scope Process design strategy
Act (Generate Result) Process scope
Evaluate Project Process design purpose,Process 2J'roject resources

Lower level activities in a Process design project can be represented by the same formalism. Thus,
for instance, kinetic modeling can be seen as a Kinetic model design project with Kinetic model as a
Target and Data production and Parameter estimation as Subprojects.

Process design methodology

Process design methodology is a procedural model for how design is done. It can be represented as a
task hierarchy in the form of an object flow diagram. The object flowing through the task hierarchy
is Process design project. Process design can be defined as an activity for finding a value for
attribute Target, that is, values for attributes of the Process instance under design.

Process design project is started by creating a Project instance. Some of the values of project
attributes are always known at this step. These initial values may either remain unchanged or become
updated as the project advances. The values of the dynamic attributes are set by the methods of
Project. Set Scope defines the aspect of the design target which is relevant at the current design
phase. What is relevant is decided on the basis of design strategy. For process design, performance
driven strategy has been suggested (pohjola, 1991; Pohjola and Alha, 1991). For lower level activities
of a process design project other strategies may be more appropriate.

Performance driven strategy. Process performance is evaluated by measuring how well the process
purpose is achieved. This is done by applying various performance criteria. Process evaluation can
be defined as finding values for attributes of Process performance instance. Process performance has
attributes Performance and Performance relation. The value of the former, which is the measure of
the goodness of the process, is obtained by solving the latter, the solution algorithm being a method
of Process performance. For obtaining a solution, the value of Performance relation must be
available. This value is Performance relation instance with an attribute list identical to that of
Process. Structure of Performance relation is its functional form (operators and terms) and State is
the values of its terms. The structure of the relation in the form of a set individual performance
relations with respect to each criteria and an aggregation operator acting upon these relations must
be available as an initial design knowledge for applying the strategy. The numerical values of the
terms can be obtained only after Structure and State of Process have been fixed. Performance driven
strategy implies that domain knowledge is available, first, to fix the weights of the criteria and,
second, to pick up the dominant terms into the relation. This knowledge together with structurally
defined performance relation are inputs to method Set Scope. The resulting level of abstraction of
Performance relation will next determine the levels of abstraction of Process structure and Process
state. Making decisions upon these objects and then solving Performance relation is what we call
process synthesis, process analysis and process evaluation, respectively. These are done under
S310 European Symposium on Computer Aided Process Engineering-3

Process unit structure

Attribute: ~
Boundary Process boundary
Interior Process interior
Exterior Process exterior
Interaction Process interaction

Each unit structural object can be described by the same attribute list as the process object:

Process interior 1
Attribute: ~
Purpose Process interior purpose
Structure Process interior structure
State Process interior state
Performance Process interior performance
Is-abstracted-by Process interior 2
Is-detailed-by Process interior 3

where, for instance, interior structure divides into interior topology and interior unit structure with
the latter having the following form

Process interior unit structure

Attribute: ~
Material Material
Phenomenon Phenomenon

Material and Phenomenon, again, have the same attribute list as Process. Accordingly, the structure
of both Material and Phenomenon divides into topology and unit structure. The formalism repeats
itself even at lower levels of object hierarchy. For instance chemical reaction, representing a
Phenomenol! instance, owns an attribute Rate, which has Rate instance as its value with an attribute
Rate relation which on its turn has Topology and Unit structure as its attributes. Topology is an
important attribute specifying which lower level units an object is disaggregated in and thus
describing the abstraction level of the object (see Fig.I).

Topology
Unit structure
PRI
PRO

Interior
Boundary
Exterior

Semantic links:
PRO is-composed-oJ {Boundary, Interior, Exterior, Interaction}
PRI is-disaggregated-ill {PRII, PRI2, PRI3, PRI4}
PRO is-detailed-by PRI
PRI is-abstracted-by PRO

Fig. I. Unit structure and Topology of Process object and the related semantic links.

PROCESS DESIGN PROJECT

Project as an object

Process design is a project. In fact any activity under process design can be described as a project.
The procedural knowledge related to an activity can be represented as a set of methods in Project
object. Methods of Project act as control agents for methods in the Target of Activity in the sense
 European Symposium on Computer Aided Process Engineering-3 S311

method Act (which could also be named as Generate Result or Carry Out Design). After process
evaluation and the subsequent project evaluation the design cycle ends and a decision upon starting a
new cycle is made. The next cycle is started by setting a new scope.

Oruect flow diagram. In the following, methodology of process design is illustrated by a procedural
model depicted as an object flow diagram

Instantiate Project

Get Purpose Get Strategy etc. (Get initial values of Project attributes)

Get Purpose Get Structure etc. (Get initial values of Process attributes)

Instantiate Process Perfonnance

Instantiate Process performance relation

Get Purpose Get State etc.

Instantiate Process performance relation structure

(Get initial values of Process performance

relation structllre attributes)

(Find dominant terms of Process performance

relation)
(Get values of Process structure attributes)

(Get values of Process state attributes)

(Get values of Process perfornul1Ice attributes)

Fig.2. A high level procedural model of process design.

Acknowledgements. This work is part of the project 'Computer Aided Reactor Design 2'(CARD-2)
financed by the Technology Development Centre of Finland (TEKES).

REFERENCES
Chandrasekaran, B. (1990). Design Problem Solving: A Task Analysis. AI Magazine, Winter 1990,
pp. 59 - 71
Marquardt, W. (1992). An Object-oriented Representation of Structured Process Models. European
Symposium on Computer Aided Process Engineering 1 (ESCAPE-I), 24-28 May, 1992, Elsinore,
Denmark. S329 - S336
Pohjola, V.J. (1991). Methodology of Process Design. Finnish Chemical Congress, 12 - 14
November, 1991, Helsinki, Finland. See also: (1992). Kemia- Kemi, 12, pp. 351 -354
Pohjola, V.J. and M.K. Alha. (1991). Methodology of Process Design, Report, University of Oulu,
Department of Process Engineering, Oulu
Stephanopoulos, G., O. Henning and H. Leone. (1990). MODEL.LA. A Modeling Language for
Process Engineering - I. The Formal Framework. and MODEL.LA. A Modeling Language for
Process Engineering - II. Multifaceted Modeling of Processing Systems. Computers chem.
Engng., ll, pp. 813-869
Takeda, H., P. Veerkamp, T. Tomiyama and H.Yoshikawa. (1990). Modeling Design Processes. AI
Magazine, Winter 1990, pp. 37 - 48