dynamic chemical process modelling and validation - j.p. schmal

8/10/2019 Dynamic Chemical Process Modelling and Validation - J.P. Schmal

1/408

DYNAMIC CHEMICAL PROCESS MODELLING ANDVALIDATION

THEORY AND APPLICATION TO INDUSTRIAL AND LITERATURECASE STUDY


2/408


3/408

DYNAMIC CHEMICAL PROCESS MODELLING ANDVALIDATION

THEORY AND APPLICATION TO INDUSTRIAL AND LITERATURECASE STUDY

Proefschrift

ter verkrijging van de graad van doctor

aan de Technische Universiteit Delft,

op gezag van de Rector Magnificus prof. ir. K. C. A. M. Luyben,

voorzitter van het College voor Promoties,

in het openbaar te verdedigen op maandag 20 januari 2014 om 15:00 uur

door

Johannes Pieter SCHMAL

scheikundig ingenieur

geboren te Purmerend.


4/408

Dit proefschrift is goedgekeurd door de promotor:

Prof. dr. ir. J. J. Heijnen

Copromotor: Dr. ir. P. J. T. Verheijen

Samenstelling promotiecommissie:

Rector Magnificus, voorzitter

Prof. dr. ir. J. J. Heijnen, Technische Universiteit Delft, promotor

Dr. ir. P. J. T. Verheijen, Technische Universiteit Delft, copromotor

Prof. ir. J. Grievink, Technische Universiteit Delft

Prof. dr. ir. A. C. P. M. Backx, Technische Universiteit Eindhoven

Prof. dr. ir. P. J. M. Van den Hof, Technische Universiteit Eindhoven

Prof. dr. P. D. Iedema, Universiteit van Amsterdam

Dr. ir. M. R. Westerweele, Mobatec

Prof. dr. ir. A. I. Stankiewicz, Technische Universiteit Delft, reservelid

Keywords: large-scale dynamic modelling, dynamic model validation, level of

detail

Printed by: Ipskamp Drukkers BV

Front & Back: Designed by T. Schmal-Muysken 2013

Figure next page 4 dimensional cube in 2-D (projection)

Figure last page 5 dimensional cube in 2-D (projection)

To understand the 4-D projection consider the following: a cube is

the 3-D equivalent of a square. In the cube we see a square in every

direction. As a consequence in a 4-D world we will see a cube in every

direction.

Copyright 2013 by J.P. Schmal

ISBN 978-94-6191-996-0

An electronic version of this dissertation is available at

http://repository.tudelft.nl/.
http://repository.tudelft.nl/http://repository.tudelft.nl/


5/408


6/408


7/408

CONTENTS

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Model building process. . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Embedding within INCOOP project . . . . . . . . . . . . . . . . . . . . . 6

1.4 Thesis work space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5 Approach, research questions and outline . . . . . . . . . . . . . . . . . 13

1.5.1 Derived research context questions . . . . . . . . . . . . . . . . . 14

1.5.2 Outline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5.3 Sketch of case studies considered . . . . . . . . . . . . . . . . . . 15

1.6 List of symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Model synthesis 21

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1.2 Goal and outline. . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2 Synthesis structure levels . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.1 Existing structure levels . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.2 Mathematical node levels . . . . . . . . . . . . . . . . . . . . . . 312.2.3 Discussion on structure levels . . . . . . . . . . . . . . . . . . . . 32

2.3 Synthesis echelon levels. . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3.1 Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3.2 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.3.3 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.3.4 Level of detail selection . . . . . . . . . . . . . . . . . . . . . . . 45

2.4 Results and discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.4.1 Effort & timing results for case study. . . . . . . . . . . . . . . . . 48

2.4.2 Level of detail selection . . . . . . . . . . . . . . . . . . . . . . . 532.4.3 Effective use of resources . . . . . . . . . . . . . . . . . . . . . . 55

2.5 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.6 List of symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3 The liquid filled tubular reactor: effects of model alternatives on computa-

tional performance 59

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.1.1 Modelling of a liquid filled tubular reactor. . . . . . . . . . . . . . 62

3.1.2 A meta-model for modelling. . . . . . . . . . . . . . . . . . . . . 63

3.1.3 Numerical issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

vii


8/408

viii CONTENTS

3.2 Alternative models for the liquid-filled tubular reactor . . . . . . . . . . . 70

3.2.1 A typical model . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.2.2 Model alternatives. . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.2.3 Boundary conditions (B0) . . . . . . . . . . . . . . . . . . . . . . 76

3.3 Exact definition of tests. . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.3.1 Test 1: effect of numerical settings. . . . . . . . . . . . . . . . . . 79

3.3.2 Test 2: model alternatives . . . . . . . . . . . . . . . . . . . . . . 83

3.3.3 Test 3: effect of assumptions. . . . . . . . . . . . . . . . . . . . . 85


3.4.1 Test 1: Numerical settings and boundary conditions . . . . . . . . . 87

3.4.2 Test 2: model representation . . . . . . . . . . . . . . . . . . . . . 88

3.4.3 Test 3: effect of assumptions. . . . . . . . . . . . . . . . . . . . . 91

3.4.4 Discussion on approach. . . . . . . . . . . . . . . . . . . . . . . 92

3.5 Conclusions and recommendations . . . . . . . . . . . . . . . . . . . . 94

3.6 List of symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4 Validation analysis and domains of dynamic process models 99

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.1.2 Existing methods. . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.1.3 Issues, goals and outline. . . . . . . . . . . . . . . . . . . . . . . 111

4.2 Validation analysis and validity domain determination. . . . . . . . . . . 114

4.2.1 Validation analysis - data analysis . . . . . . . . . . . . . . . . . . 114

4.2.2 Validity domain determination . . . . . . . . . . . . . . . . . . . 118

4.3 Dealing with large-scale systems . . . . . . . . . . . . . . . . . . . . . . 129

4.3.1 Model decomposition strategy and reduction technique. . . . . . . 129

4.3.2 Large-scale data analysis in the validation analysis level. . . . . . . 132

4.3.3 Large-scale validity domain determination . . . . . . . . . . . . . 133

4.4 Case studies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135


4.5.1 Data analysis on the validation analysis level . . . . . . . . . . . . 137

4.5.2 Validity domain determination . . . . . . . . . . . . . . . . . . . 144

4.5.3 Large-scale example: condenser. . . . . . . . . . . . . . . . . . . 149

4.5.4 General discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 149

4.6 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534.7 List of symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

5 Internal versus external heat integration 159

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

5.2 Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

5.3 Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

5.3.1 Model description . . . . . . . . . . . . . . . . . . . . . . . . . . 166

5.3.2 Steady-state HIDiC Design optimisation . . . . . . . . . . . . . . . 172

5.3.3 Operational optimisation of HIDiC and VR . . . . . . . . . . . . . 175

5.3.4 Dynamic operational optimisation model. . . . . . . . . . . . . . 178


9/408

CONTENTS ix


5.4.1 Case study results and discussion . . . . . . . . . . . . . . . . . . 178

5.4.2 Discussion on approach. . . . . . . . . . . . . . . . . . . . . . . 186

5.5 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

5.6 List of symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

6 Start-up optimisation with respect to safety & economics 195

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

6.1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

6.1.2 Existing approaches . . . . . . . . . . . . . . . . . . . . . . . . . 197

6.1.3 Issues, goals and outline. . . . . . . . . . . . . . . . . . . . . . . 198

6.2 Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

6.2.1 MP2 and MDP production plant. . . . . . . . . . . . . . . . . . . 200

6.2.2 Specific problems in the MP2 and MDP production plant . . . . . . 201

6.3 Heuristic approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2026.3.1 Heuristics for case study. . . . . . . . . . . . . . . . . . . . . . . 205

6.4 Modelling for start-up. . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

6.4.1 Model equations. . . . . . . . . . . . . . . . . . . . . . . . . . . 206

6.4.2 Handling of physical discontinuities. . . . . . . . . . . . . . . . . 207

6.4.3 Level of detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

6.4.4 Selection of base case and evaluation aspects . . . . . . . . . . . . 211

6.4.5 Initial and final conditions . . . . . . . . . . . . . . . . . . . . . . 211

6.4.6 Control related issues . . . . . . . . . . . . . . . . . . . . . . . . 212

6.4.7 Start-up schedule . . . . . . . . . . . . . . . . . . . . . . . . . . 214

6.5 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

6.5.1 Objective function. . . . . . . . . . . . . . . . . . . . . . . . . . 217

6.5.2 Manipulated variables. . . . . . . . . . . . . . . . . . . . . . . . 218

6.5.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

6.6 Numerical considerations. . . . . . . . . . . . . . . . . . . . . . . . . . 225


6.7.1 Start-up simulation of the base case . . . . . . . . . . . . . . . . . 228

6.7.2 Optimisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

6.7.3 Explanation of difference in reactor model. . . . . . . . . . . . . . 241

6.7.4 Numerical considerations . . . . . . . . . . . . . . . . . . . . . . 243

6.8 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

6.9 List of symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

7 Conclusions and recommendations 251

7.1 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

7.1.1 Synthesis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

7.1.2 Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

7.1.3 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

7.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255


10/408

x CONTENTS

Bibliography 259

A Design parameters open case-study (on CD only) 273

B Model synthesis (on CD only) 279

B.1 Terminology tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

B.2 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

C Liquid tubular reactor data (on CD only) 283

C.1 Model characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

C.2 Derivation of equation of volume change. . . . . . . . . . . . . . . . . . 284

C.3 Additional tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

C.4 Additional figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

C.5 Exact definition of models . . . . . . . . . . . . . . . . . . . . . . . . . 294

C.6 List of symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

D Validation (on CD only) 303

D.1 Wavelet example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303D.2 Simple example model to illustrate SI space . . . . . . . . . . . . . . . . 305

D.3 Model decomposition example. . . . . . . . . . . . . . . . . . . . . . . 307

D.4 PCA algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

D.4.1 Derivation of variance matrices . . . . . . . . . . . . . . . . . . . 309

D.5 Practical approximation to state estimation. . . . . . . . . . . . . . . . . 311

D.6 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

D.7 Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

D.8 Symbol list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

E Start-up model and optimisation (on CD only) 319

E.1 Detailed description of process. . . . . . . . . . . . . . . . . . . . . . . 319

E.2 Model equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

E.2.1 Conbreak_liq. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

E.2.2 Mixer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

E.2.3 Reactor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

E.2.4 Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

E.2.5 Phys_LiqEnth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

E.2.6 XC_conv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

E.2.7 CX_conv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

E.2.8 Tube & shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

E.2.9 Wall & Wall2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

E.2.10Tray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

E.2.11Condenser model . . . . . . . . . . . . . . . . . . . . . . . . . . 328

E.2.12Reboiler model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

E.2.13Phys_LiqDistr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

E.2.14Phys_LV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

E.2.15PIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

E.2.16P model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

E.2.17Over-all model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

E.2.18Initial conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . 337


11/408

CONTENTS xi

E.3 gPROMS code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

E.3.1 exported gPROMS file . . . . . . . . . . . . . . . . . . . . . . . . 339

E.3.2 exported gOPT file. . . . . . . . . . . . . . . . . . . . . . . . . . 365

E.4 Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

E.5 tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

E.6 List of symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

Acknowledgements 379

Summary 383

Samenvatting 387

Curriculum Vit 391

Index 392

Glossary 395


12/408


13/408

1INTRODUCTION

In this chapter we set the stage for our research, which focusses on dynamic modelling

of chemical processes. First we give some background information that illustrates the

scope and justification of this research. We introduce the terminology and the thesis work

space to indicate the language and boundaries of this thesis. We describe the research

context and related questions to indicate the intent of this research. We focus on first prin-

ciple models with empirical elements described by a set of integral-partial-differential-

algebraic equations. The stages that are considered in this work are synthesis of models,

evaluation and application. gPROMS was used to model all case studies in this work.

1.1.BAC KGRO UND

CHEMICAL processes are operating in a (global) dynamic market, where demands

need to be met and supplies need to be managed. Supply chain management and

optimization are therefore common practice. On top of that there is an interface with

people and society, which results in safety and health regulations for example.

The chemical process itself is usually described by a network of connected units,

called a flow sheet. Each unit itself can consist of a network of interconnected sub-units.

This decomposition of structure can continue for several levels. For example, the flow

sheet of a chemical plant can contain a distillation column, which in turn consists of a

tray section, reboiler and condenser. The tray section consists of trays and trays may

consist of a downcomer, plate and weir section.

Although chemical processes are traditionally designed to operate in steady-state, in

practice plants are rarely in a steady-state. This is caused by external and internal factors

that influence operation. For example changes in the market price and/or demand result

in changes in production or through-put. Catalyst deactivation is commonly counter-

acted to some extent by changing operating policies over time. Furthermore, even sim-

ple day and night rhythm causes changes in heat loss that need to be compensated. Fi-

nally, operator shift changes can sometimes be observed in the measurements, because

the shift causes small upsets to the plant.

1


14/408

1

2 1. I NTRODUCTION

Traditionally, market dynamics was sufficiently slow (weeks to months) to be able to

decouple the effect of market changes to the normal operation of the plant, which is usu-

ally in the order of seconds to hours. Due to increasingly optimized plants that are more

integrated, time scales of chemical plants have increased significantly (days to weeks).

At the same time market dynamics need to be reacted upon faster (days to months) to

keep a competitive edge. As a consequence market dynamics and plant dynamics arestarting to overlap to some extent. This means advanced control and dynamic real time

optimization are required.

The ever-increasing competition between companies and the tightening environ-

mental regulations have forced the chemical industry to improve their understanding

of their processes and optimize the processes to the fullest extent possible. This requires

the description of the key interactions in the chemical process. For complex structures

this can best be achieved by developing mathematical models.

Once mathematical models are available the economics, safety, operability and en-

vironment of a chemical process can be improved by means of rigorous model-based

optimization. This can be done for chemical plants that are to be built in the sense ofoptimizing the design of the chemical plant or for existing plant were the operation of

the plant or improvements to the plant can be suggested.

In all these cases mathematical models are invaluable for accurate representation of

these processes and thus for optimizing elements of the process. Klatt and Marquardt

[2009] state that model-based methods should form the basis of the process systems en-

gineering field and research on modelling methodologies should be of primary interest

to this field. Yet, as we shall discuss in more detail in chapter2the model building pro-

cess is still poorly understood.

1.2.MODEL BUILDING PROCESSAs indicated we only considermathematicalmodels in this thesis. A model is a descrip-

tion of reality capturing the essentials. By essentials we mean that we do not model

catastrophic events in a chemical plant like a major earth quake, which obviously ren-

ders the plant model useless. A model describes variations of variables as a function of

independent variables. The variables we are interested in need to be related to inputs

to the system, disturbances and outputs. In this thesis we consider disturbances to be

random signals with known or estimated frequency and amplitude (all other variables

are deterministic).

The choice of the variable space is related to the level of detail needed and the key

performance indicators of the model. The level of detail concerns, among others, choices

on relevant length and time scale and physical phenomena considered. The range of

length scale implies certain equations, e.g. density functional theory to special relativity

or in case of multi-scale modelling appropriate combinations thereof [see e.g.Buesser

and Grhn,2012]. Similarly the choice of time scales, e.g. nano-seconds to millennia,

determines whether we need dynamic momentum balances or climate change equa-

tions for example.

The model building procedure is similar to the design of technical artefacts in gen-

eral. Hence the modelling procedure reflects the steps of the generic design cycle [Dou-

glas,1988,Biegler et al.,1997,Seider et al.,2004,Swinkels et al.,2006], where we added


15/408

1.2.M ODEL BUILDING PROCESS

1

3

the last step:

1. Specifying the functional requirements.

2. Assessment of the existing domain knowledge.

3. Synthesis.

4. Analysis.

5. Evaluation.

6. Application.

We will discuss the synthesis, evaluation and application steps in this thesis. Gener-

ally some iteration is needed through these steps. For example, reaching the evaluation

stage for the first time may proof we did not meet the functional requirements for the

model accuracy. Hence we need to go back to synthesis, which may imply we need someadditional knowledge to come up with a more detailed model. After which we have to

re-do the evaluation to see if we met our functional requirements.

With respect to the synthesis of a mathematical model we have a number of options

which lie in different fields of research:

Data driven: fits through data points (identification methods, neural nets, black-

box models etc.).

Event/rule driven: rules determine what happens (agent based modelling).

Stochastic: probability models.

First principles: physical laws (Newton, mass, energy balances etc.).

Empirical: logic/experience based variable dependencies that have a more general

character than pure data driven models.

In this thesis we will focus on first principle models with some empirical compo-

nents. First principle models ensure more reliable extrapolation. Reliable extrapola-

tion is imperative if one assumes experiments to fit the model parameters were not per-

formed at the optimal point. For control the first principle demand is less stringent since

non-linear model predictive control (NL-MPC) will work with a restricted prediction and

control horizon. The restricted horizon means that it does not matter whether the model

predicts incorrect results outside the horizon. The longer the horizon, the more first

principles in general will be needed.

The nature of our model is such that we have a number of physical laws and some

empirical relations. Furthermore, we have balance equations, which describe the vari-

ation of differential state-variables in time and space, e.g. mass and energy balances.

Besides differential state variables we have inputs, disturbances and algebraic variables.

In figure1.1 we give a simplified overview of a chemical engineering model. We en-

larged two models with balance equations and algebraic equations. xrepresents the

differential state variables, ythe algebraic and/or measured variables, uthe inputs, d


16/408

1

4 1. I NTRODUCTION

Figure 1.1: Simplified typical chemical engineering model overview (x differential state variables, x timederivative of differential state variable, uinputs, yalgebraic variables, ddisturbances, pparameters, f and

hdifferential equations andgand kalgebariac equations).

the disturbances andpthe parameters. f, g, handkare functions. The models are gen-

erally connected and each model has its own set of equations. In most cases sub-models

are reused in a plant model, e.g. the model of a distillation column contains many tray

models that all have the same equations.

Non-linear dynamic models have been built for quite some time and consequently

abundant literature can be found on the subject [see e.g. Aris,2000,Marquardt,1995,Hangos and Cameron, 2001a, Zeigler et al., 2000]. Nonetheless a survey in industry

among different modellers revealed that a number of problems persist [Foss et al.,1998,

Cameron and Ingram,2008]. Especially first principle modelling is considered:

1. To a large extent intuitive.

2. Error prone.

3. Expensive (in fact it was estimated that black-box models can be made at a tenth

of the cost of a first principle model).

This thesis will try to address these three problems. We will try to develop an effective

model building approach that:

Gives sufficient insight to remove some of the intuition.

Reduces the chance of errors.

Reduces the model building time.

In particular intuition plays an important role to predict the effect of model choices on

the final outcome.


17/408

1.2.M ODEL BUILDING PROCESS

1

5

Figure 1.2: Applicability of model approach in model and process life.

Looking at the life of a process: 1) development 2) design 3) operation 4) revamp 5)

break-down. Similarly the model life concerns 1) development 2) design of experiments3) validation 4) usage 5) revamp. Here we do not cover all stages of the model life, we

discuss development, validation and usage (see figure1.2). We did do parameter esti-

mation, but used existing methods and will therefore not discuss this in this work. Ide-

ally models being developed in early stages of process life could be used in later stages

resulting in a more cigar like relation between process and model life as indicated by the

dashed line in figure1.2.Practice shows however that increased model accuracy is usu-

ally needed with process life, which results in different models being used in different

stages. An example of the latter is the use of rough estimates in design stage for eco-

nomics versus more detailed models for use in safety considerations during operation.

Validation is the comparison of model against experiments, usually accompanied byan indicator of how well the model and experiments agree. In model validation little

effort has been put in finding an area for which the model is validated. Some noticeable

exceptions will be discussed in chapter 4 [e.g.Kahrs and Marquardt,2007]. In general

comparison in a small part of the model space is considered sufficient for the model to

be labelled "validated". This label cannot be guaranteed anywhere outside the "line"

(scenario) that was used during experiments, but still the label "validated" gives a sense

of general reliability.

The two points of modelling and validating the model of a chemical plant are at the

core of this thesis and therefore the research context is:


18/408

1

6 1. I NTRODUCTION

Research context:

We want to find ways to improve the synthesis and evaluation

methods in modelling the dynamics of a (large-scale) chemical plant,

as to control model complexity and enhance the quality of model

predictions for operational and control purposes while effectively

using the resources for modelling efforts.

1.3.EMBEDDING WITHININCOOP PROJECTThe most important way economics, safety and environment of an existing chemical

plant can be influenced is by means of plant operation and control. No matter how well

the plant is designed, bad operation and control can cause extremely poor performance

or even disasters in some cases.

The ever-increasing competition between companies and the tightening environ-

mental regulations have forced the chemical industry to research the next generation

of control: non-linear model predictive control and dynamic real time optimisation (see

figure1.3). Since chemical processes are non-linear by nature and generally in a dy-

namic operation mode rather than in steady state, this step is both logical and necessary

for optimal operation.

The current state of the art control is linear model predictive control (MPC)and

steady state optimisation, although non-linear model predictive control (NL-MPC) and

dynamic real time optimisation are gaining ground. The measurements,y(t), and the in-

puts,u(t), from the plant are reconciled to find the actual state of the plant, x(t) (see fig-

ure 1.3). This information together with the used control inputs, u(t), is send to the MPC

and to a steady-state detector. The steady-state detector checks if the plant is in steady-

state and if so reconciles the data and starts the steady-state optimiser. The steady-state

optimiser calculates the optimal states,xss, and inputs, uss, and sends them to the MPC.

The MPC calculates trajectories to get to the optimal state and sends set points, S P(t),

to the basic control layer. The basic control layer, the distributed control system(DCS),

suppresses fast disturbances caused by for instance feed fluctuations.

The linear nature of MPC and the steady-state nature of current state-of-the-art plant

control implies linear models were mostly used in MPC, predominantly black-box mod-

els found by identification methods. Steady-state models used in steady-state optimisa-

tion are generally non-linear, but in most cases not too complex.

The next generation of control is non-linear and dynamic at all levels as indicated.

As a consequence the steady-state detector is no longer needed, the optimisation is run

dynamically in real time(DRTO,dynamic real time optimisation) and (non-linear) dy-

namic models are needed. The optimiser now sends optimised state and control trajec-

tories,x

(t) andu

(t), to theNL-MPCinstead of the optimal steady-state value.


19/408

1.3.E MBEDDING WITHININCOOP PROJECT

1

7

Figure 1.3: State of the art and researched plant control structure (SPset-point,xssoptimal steady-state valuesfor statevariables, uss optimal steady-state values for controls,ymeasurements, ucontrol values, xdifferentialstate variables,M PCmodel predictive control,DRTOdynamic real time optimisation,N L MPCnon-linearMPC,x(t) optimal time trajectories of state variables and u(t) optimal control trajectories).

In principle we could combine the NL-MPC and DRTO, but at present the decompo-

sition in MPC and DRTO is needed for a number of reasons:

The fastest dynamics covered by MPC ( 1 min.) do not allow for the solution ofthe full non-linear model in real time.

The objective function is different. In DRTO, it is usually an economic objective

and in MPC it is usually an error and state deviation combined with a penalty onthe control movement.

The range of time scales on which each area of control from DCS to scheduling level

is active on do not generally overlap too much. A typical example is given in figure 1.4

where we see the importance of each control area for different time scales/frequencies.

The absence of too much overlap makes the splitting up of the control structure a rea-

sonable approach.

A large part of the work presented in this thesis is based on experiences gained from a

European research project called INtegrated plant-wide COntrol and OPtimisation(IN-

COOP). The INCOOP consortium consisted of two large industries, Bayer and Shell, that

supplied the case studies and the testing facilities for the research, two software ven-

dors, IPCOS and MDC, that were responsible for the integration of tools and algorithms

developed, and three Universities, RWTH Aachen, TU Eindhoven and TU Delft, that de-

veloped the pilot elements for the next generation of control. Tousain[2002]investi-

gated dynamic optimisation in business-wide process control and was instrumental in

the early discussions of the project. Hessem[2004]developed the model predictive con-

trol and set-up the complete control architecture in collaboration with IPCOS. Van den

Berg[2005]investigated techniques to develop reduced models for use in MPC. Schlegel

[2005] developed an adaptive discretization method for the dynamic optimisation algo-

rithm. Kadam[2006]worked on the dynamic real time optimisation. Tyagunov[2004]


20/408

1

8 1. I NTRODUCTION

Figure 1.4: Typical time scale division for different control tasks in chemical engineering (DC Sdistributedcontrol system,M PCmodel predictive control andDRT Odynamic real time optimisation).

worked on the non-linear model predictive control algorithms. Finally, our task within

the INCOOP project was to model and validate a petro-chemical plant (figure1.5).

The model in this project was used for two main purposes: 1) as a test vehicle for the

new technology, replacing the actual plant in the test phase and 2) as a master model

from which reduced models for control and optimisation were derived. In figure1.3we

can see the role of the master model developed in this work. Correct representation

of the behaviour of the plant was therefore crucial for testing and validating the newtechnology.

1.4.THESIS WORK SPACEThe way we see the relation between plant operation, models and how they relate to this

thesis is given in figure1.6.

To indicate what is covered in this thesis and what is not we define the thesis work

space. We call thisspacesince it contains many different features related to one item:

the thesis. As indicated it is meant to identify boundaries, clarifying where the research

has been done and where it is believed to be valid. For example the thesis space consistsof the modeller himself, his knowledge and experience have a great influence on the

outcome of the model, but also the available/used software can pose serious restrictions

on the claims made [see e.g.Rizzo et al.,2006].

In similarity with the definition of a mathematical problem we try to define the work

space of this thesis (and its properties), its objects and operations on these objects.

Relevant to the model building process are:

1. Contractor/management.

2. Plant with all its restrictions (measurements, operating policies etc.).


21/408

1.4.T HESIS WORK SPACE

1

9

Figure 1.5: Simplified responsibility overview of INCOOP project in terms of parties involved.

Figure 1.6: Overview of the relations between modelling and operational tasks and elements covered in this

thesis (funct. req.functional requirements,knowl. ass.knowledge assessment and C ichapteri).


22/408

1

10 1.I NTRODUCTION

Figure 1.7: Simplified graphical overview of thesis space and the overlap with other relevant spaces.

3. Available data.

4. User of the model.

5. The intended application of the model.

6. Modeller with the modellers knowledge (on e.g. physics, mathematics, social skills

etc.).

7. Mathematics involved.

8. Model implementation.

The modeller has to deal with all these spaces (figure 1.7). Each space has its own desires,

needs and restrictions (properties), leading to a restricted model space for the modeller

to work in. To restrict the discussion of each space we will only describe that part of each

sub-space that is in the thesis space.

CONTRACTOR SPACE

The contractor spaceare the people and their attributes that decided and/or ordered

the building of the model (directly and indirectly). As a consequence they have a large

influence on the model goal.

In most cases the contractor has littlespecificknowledge of the physical space and

has general claims on goals with restrictions on budget and time. The contractor for the

real plant case study in this work was considered to be Shell. Regular meetings were held

with Shell. In this case the meetings where held with people with specific knowledge of

the process.

In the INCOOP project we had another contractor present in the sense of the EU.

Its goal was to facilitate a research project to investigate the next generation of control.

Little knowledge on the process or control was present by this contractor. It did enforce

restrictions on this work in the sense of time, budget, openness of some of the confiden-

tial work among others.


23/408

1.4.T HESIS WORK SPACE

1

11

PHYSICAL SPACE

The physical space consist of all physical attributes needed to model the plant. Most

clear examples of elements in this space are the plant, measurement devices etc. The

type of plant or available measurement devices all have an influence on the model.

In this thesis thephysical spaceconsists of two specific case studies (plants). One

case study is a real plant for which data was available. The exact process and data isconfidential, therefore a second open literature plant was used. Both case studies will be

introduced in section1.5.

DATA SPAC E

The data space concerns all data needed in the modelling process. This means signals

from the plant, physical property data, kinetic data, literature data, but also equipment

dimensions etc. Furthermore, data from similar plants or alternative physical property

data for instance can be considered part of this data space.

Physical property, kinetic and plant lay-out and dimension data were made available

by Shell. Operating strategies and design issues were also discussed. For estimation andvalidation roughly 400 signals were available from the plant with a sampling frequency

of 1/min over two periods of two months. From these data 18 days were chosen, nine for

estimation and nine for validation. Twenty parameters have been estimated.

USERS SPACE

Theuser spacecontains the people and their attributes that will use the model. Prefer-

ably the user space is part of the modellers space, however there will rarely be complete

overlap. The user generally has less knowledge on the model and software for instance.

The users of the model were the control people for non-linear control (be it via a

reduced model of the model reducer), the model reducer, the optimisation people (usingthe full model) and the plant people for scenario testing.

Contact with all these people was frequent and at least two times a year, but with

many much more frequent. The model was adapted as a consequence of these discus-

sions in different ways, from adding variables to allow for disturbances to reducing com-

plexity for speed. In particular a dilemma existed in reducing the number of variables

for speed versus the readability of the model. The latter reducing the changes of errors.

An extensive documentation has been supplied with the model to reduce misunder-

standings as well as document choices and assumptions.

APPLICATION SPACE

The application space is related to the intended use of the model. This not only implies

a certain variable space the model should be able to operate/predict in, but also the

models embedding in a software architecture for example.

In INCOOP the plant model should be able to predict/follow a specified scenario.

This scenario and the relation to the actual plant influenced the model building process.

Furthermore, the model should be able to interconnect to Matlab, which was used for

testing purposes of the next generation of control. This model was validated and let to

recommendations for improvements to the model.

Other applications considered in this thesis are design and normal operation optimi-

sation for steady-state production and simulation and optimisation of start-up. Typical


24/408

1

12 1.I NTRODUCTION

other applications for models not considered in this thesis are scenario testing, (batch)

recipe optimisation, operator training to name a few.

MODELLERS SPACE

Themodellers spaceconsist of all people that are needed to build the model and their

attributes (knowledge, experience etc.). This includes outside expert help for instance.The restrictions in knowledge of the people in the modellers space have an influence

on the model. Note that this can include knowledge acquired specifically for the model

building process.

The limitations of the modeller will later be quantified by so-termed lack-of-knowledge

assumptions that are documented and the decision tree which outlines the reason for

choices made.

In this work the modellers space consisted of control engineers, optimisation peo-

ple, plant managers and the modeller himself. Other people in the project were also in

contact with marketing people and sales managers.

MATH EM ATI CA L MO DE L SPAC E

Themathematical model spacecan best be described by the classification of models.

Models can be classified by means of their sort, type and solution environment. For

mathematical models the sort consists of: descriptive or predictive, indicating whether

the system is already there or needs to be built.

In this thesis we will focus on descriptive models mainly, since the plant that was

modelled for the project already existed. The literature case study is an example of a

predictive model.

In this thesis we are focussing on scales from meso to macro (or more precise cen-

timetres - metres), predominantly white models which have a non-linear, determin-istic, continuous, dynamic, non-causal, equation based both distributed (PDAE) and

lumped nature (DAE). The non-linear and dynamic choices are based on typical equa-

tions, typical times scales of relevance etc. The project asked for deterministic, contin-

uous, equation-based models for optimisation purposes explaining the focus indicated

above. More to the point we will not cover stochastic, discrete or rule based models in

this work.

Model validation is a crucial step in the model building process to increase confi-

dence in the model and prediction reliability. Nowadays model validation analyses are

commonly visual inspections of plant data against simulated data, sometimes with some

indicators like sum of squares or the integral square error. Furthermore, plants usually

operate in a limited window around the normal operating conditions. Failure mode test-

ing or testing for theoretical boundaries is not feasible for plant models. At best failure

mode testing has been done in a lab or possibly pilot scale for some unit operation mod-

els.

Although graphics can tell more than numbers, dynamic information is difficult to

abstract. Furthermore, very little attention is paid to the validity domain, i.e. where can

we trust the model. This is vital in optimisation studies where optimisers exploit the

designated area to the max. Although the modeller is usually quite aware of for what

conditions the model was validated for example, these conditions rarely get translated

into constraints for the optimiser or even the model itself.


25/408

1.5.APPROACH, RESEARCH QUESTIONS AND OUTLINE

1

13

Finally, simulating certain scenarios can help understand complex phenomena and

help to suggest changes. In particular we will show how modelling start-up can help to

increase the insight. Little information is available on the complex process of start-up,

which accounts for 46% of the accidents in the chemical industry[Batres et al.,1997,

Amundson et al.,1988].

MODEL IM PLEMENTATION SPACE

Themodel implementation spaceplays an underestimated role in the model process.

Foss et al. [1998] concluded from their field study: "Degree of sophistication and the tech-

nical set-up of a modelling tool heavily influences the modelling process of the modeller

in particular". Similarly,Rizzo et al.[2006]investigated four different software packages

to model the same system and concluded that the modelling software becomes part of

the model and of the calibration process.

In this thesis gPROMS developed by Process Systems Enterprise Ltd. has been used

as the modelling environment since it was set by the INCOOP project. For comparison

of the results Aspen simulations and plant data were available.At present for chemical engineering purposes a large number of dynamic simulation

software packages exist. Where Aspen, HYSYS and to lesser extent PROII and Unisim

dominate the steady state flowsheet market, the dynamic simulation software market

has not settled completely yet.

gPROMS is particularly suited for large-scale problems both steady state and dy-

namic and was thus an obvious choice for the INCOOP project. In particular since it is

engineered to be an open-platform and thus allows for easy coupling to other software

packages such as Matlab, excel or even CFD packages.

The computers used to model and document the model building process are another

part of the model implementation space. The computers used ranged from 800 MHz 256MB RAM to 3 GHz 1 GB RAM. Operating system was Windows 2000 in all cases. Were

relevant the exact computer used is mentioned.

1.5.APPROACH, RESEARCH QUESTIONS AND OUTLINEThorough research would demand investigations in the effect of variations in each of the

aforementioned spaces on our research questions. This is clearly not feasible within the

time span of one Ph.D. On the other side two specific case studies would only result into

restricted conclusions. The best we can do is to try to abstract more general conclusions

from the results of the two case studies besides the specific case conclusions. This in

turn means we can not make hard statements with respect to the research questions we

will pose in this section, rather make conclusions plausible.

Nonetheless we develop derived research questions and statements to answer these

derived research questions. A statement needs a test and a criterion/criteria to draw

conclusions. Again the model space is too large to allow for tests that systematically test

all possibilities in the space.

Before we discuss the research questions, we introduce our case studies. In this thesis

we are not only interested in accurately simulating and optimizing normal production

modes, but also for the special case of a cold start-up. The real plant case study is used as

a plant substitute during the testing phase of the advanced control structure consisting


26/408

1

14 1.I NTRODUCTION

of both NL-MPC and DRTO. The open-plant case study is used for optimisation of start-

up from the cold state.

1.5.1.DERIVED RESEARCH CONTEXT QUESTIONSWith regards to our research context: "We want to find ways to improve the synthesis

and evaluation methods in modelling the dynamics of a (large-scale) chemical plant, as

to control model complexity and enhance the quality of model predictions for operational

and control purposes while effectively using the resources for modelling efforts.", we can

ask ourselves several derived questions related to the steps in the model building pro-

cess.

STE P3: SYN TH ES IS

The first step of the synthesis consists of translating the functional requirements into

model equations. Hence we ask ourselves:

Research question 1 How can we reduce the number of iterations in the model buildingprocess?

The lack of knowledge on how the level of detail and form of equations influences the

final accuracy of the predictions, makes iterations in the model building inevitable. This

is one of the problems that shows why modelling is still non-trivial and considered an

art. At present the modellers experience dictates the model choices that are believed to

result in a certain pre-specified requirement such as a desired model accuracy. This re-

quirement can only be checked afterwards and if it is not met, additional detail is added

until the requirement is met or allowed time and/or money have been spent. The model

accuracy is closely related to the level of detail, which plays a central role in this thesis.We investigate the effect of the level of detail on the model building process during

the development of the two case studies in chapter2. In particular we investigate the

effect of the level of detail on the response of a tubular reactor model in chapter 3.

As indicated in particular the synthesis phase is time consuming, costly and CPU

expensive. Therefore we ask ourselves:

Research question 2 How can we improve the synthesis of large-scale dynamic models

with respect to effective use of resources: time, money and computational resources?

Very little data is available in literature on how much time is spent on each modelling

step. As a consequence little is known about what step is most time consuming. We give

the model building times for each step explicitly in chapter 2. This will help us iden-

tify bottle-necks and items for future research. Furthermore we discuss the synthesis in

detail, from efficient terminology to the synthesis procedure.

We do not consider step 4, analysis, in this work, since for local analysis (sensitivity,

bifurcation, stability etc.) current concepts are deemed rich enough. Expanding these

techniques to global analysis for large-scale systems is a significant undertaking on its

own. Finally, although analysis can give valuable insight into the system, it is less of a

limiting nature for chemical engineering modellers in terms of understanding the pro-

cess than the synthesis and evaluation aspects.


27/408


1

15

STE P5 : EVAL UATIO N

Now that we have a model and we can extract information from it, the next logical ques-

tion is to ask where the model is valid. This question is particularly important for users

of the model that can be warned if the model is outside its validated region.

Research question 3 How can we identify where the model is applicable, i.e. has an ac-ceptable quality of prediction?

We introduce a method to identify a validated region in chapter4.

STE P6 : APPLICATION

If the model is validated it can be used for many a purpose. In chapter5we optimize the

design and operation of a heat-integrated distillation column to demonstrate how mod-

elling can help solve complex questions. For these complex questions we usually need

to balance complexity of the problem with effort required to solve it. The complexity

of the problem is determined by the decision variables considered (number and type),

whether to consider uncertainty or probabilities, the model complexity in the sense ofthe level of detail and the implementation choices for example. A question therefore is:

Research question 4 How do we make decisions on where to simplify the problem set-up?

Finally, one of the most dynamic situations encountered duringnormaloperation of

a plant is start-up. Since start-up is a relatively dangerous part of operation, it makes

sense to optimize the safety and economics of start-up. Since during optimisation it is

common to see simplified models being used, a logical question is:

Research question 5 What is the effect of the level of detail on the predictions made by

the model?

In chapter6we optimize the start-up of the open-literature plant case study and inves-

tigate the effect of the level of detail on the results.

1.5.2.O UTLINEIn chapter2we will investigate the model synthesis process and suggest improvements

to reduce the model development time and discuss a method to determine the level of

detail. We investigate the effect of the level of detail on the model performance in chapter

3.We develop 14 different models of the liquid-filled tubular reactor and investigate the

effect of the different model formulations. In chapter4 we will investigate the model

validation process, with emphasis on data analysis and validity domain determination

for dynamic models. In chapter5we look at a case study, the internally heat integrated

distillation column, where we optimize the economics and operation. It functions as

an example of how modelling can be applied to deal with complex questions involving

many decisions. In chapter6we investigate the effect of the level of detail on the results

of the optimisation of start-up. This chapter will also highlight ways to deal with model

complexity.

1.5.3.S KETCH OF CASE STUDIES CONSIDEREDIn this work we consider two main case studies that are briefly introduced here.


28/408


29/408


1

17

Figure 1.8: Simplified flowsheet of real plant used in this thesis ( C atcatalyst, V vessel,Rreactor and C idistil-

lation columni).

data are given in appendixA.In this paragraph the numbers between brackets indicate

stream numbers in figure1.11. The fresh PO enters the plant (1) and is mixed in mixer

1 (M1, 2) with the MeOH from the recycle (10). It enters the first reactor (R1, via stream3) on the shell side and is heated to the desired temperature. Catalyst is added to the

heated stream (4) in mixer 2 (M2, 11) and the stream enters the tube side of R1 (5). Since

there is excess of MeOH the PO is virtually converted completely (non-equilibrium re-

action). R1 has an additional compartment which functions as an additional cooling

capacity (more heat is generated in the reaction than needed to heat the feed). The re-

actor effluent (6) flows to distillation column C1 where MeOH is recovered and recycled

via stream 9. Fresh MeOH is added via stream 12 in mixer 3 (M3). The bottom of C1 (7)

is fed to the second column (C2) in which the main product MP2 (8) is separated from

MP1, MDP and longer chains (13). In mixer M4 PO (14) and recycled MP1 (20) are added

to form stream 15 which enters reactor R2 to convert the MP1 to MDP (16). Column C3

separates MP1 from MDP and longer chains (17). Finally column C4 separates MDP (18)

from higher chains that are considered waste (19). For this plant the plant can be con-

sidered to consist of two similar blocks, being R1-T1-T2 and R2-T2-T3, we will focus on

the first block alone (indicated by the red dashed box) to restrict CPU time. The inter-

esting feature of the open literature plant is start-up of the plant which is investigated in

chapter6.Particularly so, since part is an adiabatic reactor with an exothermic reaction

prone to run-away (see chapter6).

Besides investigation of start-up behaviour, dynamics can be caused by for example

significant feed flow rate changes to cope with market demand, catalyst deactivation and

disturbances such as equipment failures to name a few.


30/408

1

18 1.I NTRODUCTION

Figure 1.9: Overview of key reactions of propylene-oxide,PO ,and methanol, MeOH, to 1-methoxy-2-propanol,

MP2,and 2-methoxy-1-propanol, MP1 (lines without connected letter represent hydrogen bond).

1.6.L IST OF SYMBOLSd disturbance

SP set-point

t time

u input

x state variable

y measurement

subscripts:

ss steady-state

superscripts:

optimal solution

Abbreviations:

Ci columnior chapteri

DAE differential algebraic equations

DCS distributed control system

DRTO dynamic real time optimisation

INCOOP Integrated plant-wide control and optimisation

Mi mixeri

MDP methoxy-propoxy-propanol

MeOH methanol

MP1 2-methoxy-1-propanol

MP2 1-methoxy-2-propanol

MPC model predictive control

MTP tri-propylene glycol methyl ether

NL-MPC non-linear MPC


31/408

1.6.L IST OF SYMBOLS

1

19

Figure 1.10: Structure of methoxy-propoxy-propanol, MDP,and tri-propylene glycol methyl ether, MTP (lines

without connected letter represent hydrogen bond).

Figure 1.11: Simplified flowsheet of the open plant (POpropylene-oxide,MeOHmethanol,C atcatalyst,M i

mixeri,Rireactori, C idistillation columni,M P2 1-methoxy-2-propanol,M DP methoxy-propoxy-propanol

and numbers indicate stream numbers).

PDAE partial differential algebraic equations

PO propylene-oxide

Ri reactori


32/408


33/408

2MODEL SYNTHESIS1

Modelling is a time consuming effort and especially for large-scale models a systematic

approach is needed to reduce errors and time. To determine where most time is lost we

report where we spend the time for the real plant case study. We focus on the synthesis

phase of the model building process.

We describe the model building process from a level perspective rather than procedural

one. Concepts introduced by Mesarovic et al.[1970]are used to explain different parts

of the process. In particular we use his distinction between strata, echelons and levels.

Seven synthesis structures are discussed and compared and a more general and practical

structure is developed based on a mathematical basis.

The synthesis echelon is split up in four levels: abstraction, decomposition, aggregation

and level of detail selection. These levels cover the translation of real world objects into

a numerical model and how one can deal with large-scale problems. Furthermore we

discuss the problem of determining the right assumptions and decisions that will lead to

pre-specified model performance targets such as speed of simulation and predictive ac-

curacy. The approach described in this chapter both increases understanding as well as

increases model building efficiency due to systematics.

We are dealing with two research questions in this chapter: 1) How can the model accuracy

requirements be met in the initial model synthesis phase? and 2) How can we improve thesynthesis of large-scale dynamic models with respect to effective use of resources: time,

money, human and computational resources?

2.1.INTRODUCTION

PROCESSmodels are used in a wide variety of cases in the chemical industry. Ranging

from mostly steady-state models for design purposes to dynamic models for control

and real-time optimization, or scenario testing and parameter estimation. In particular

1Edited and extended version ofSchmal et al.[2002].

21


34/408

2

22 2.M ODEL SYNTHESIS

the interest for high-fidelity first principle models is increasing in the optimization and

control world [Backx et al.,2000,Maciejowski,1999].

The model building process is still poorly understood. An extensive survey among

modellers with different backgrounds showed that the model building is considered to

be error prone and expensive [Foss et al.,1998,Cameron and Ingram,2008]. Further-

more, few data was found in literature on model building times making resource man-agement a difficult task.

The challenges of building a mathematical model consist of approximating some-

thing in the physical/information domain as closely as acceptable for certain goals in

mathematical equations (or code of a specific program) with a limited number of re-

sources. This implies we need to define what we are modelling for what purpose, how

accurate, in what software program and within what budget and/or time. In this chapter

we focus on model accuracy and on efficient use of resources.

The model building process consists of different phases: development, implementa-

tion, validation and application. In turn each phase has its own steps. These steps are

similar to the design procedure of technical artefacts in general [Roozenburg and Eekels,

2003,Swinkels et al., 2006]: specification, assessment, synthesis, analysis and evalua-

tion. So each phase has the same generic steps. Using the term synthesis on its own can

easily lead to confusion, since it can be the synthesis of the model (development stage),

the synthesis of the code (implementation), the synthesis of the validation, etc.

On top of that each phase and step has its own attributes: goals, criteria, assump-

tions, implementation and restrictions. Although these attributes are rarely explicitly

mentioned, they play an important role in the model building process. For example in

the application phase and evaluation step we can have restrictions due to the available

data present.

Many people have contributed to a deeper understanding of the model building

process [Himmelblau and Bischoff, 1968,Murthy et al., 1990,Aris, 1994,Hangos and

Cameron,2001a]. For non-linear empirical model techniques an overview can be found

inPearson[2006]. Formalization of the modelling process or parts of it is done to lesser

extent [Marquardt, 1992, 1995, Gawthrop and Smith, 1996, Polderman and Willems, 1998,

Zeigler et al.,2000,Yang and Marquardt,2009]. In this chapter we will focus on model

synthesis in the development phase (the scope will be clarified in section2.1.1). We

define model synthesis in the development phase as the process of generating the math-

ematical model, i.e. given a model goal generate equations that lead to a model capable

of running scenarios.

The synthesis step in the development phase has received little attention in litera-

ture. This became apparent when the authors developed a model for a process (in the

time period 2000-2003) that was part of a comprehensive cooperation project between

industry and academia, INtegrated plant-wide COntrol and OPtimisation (INCOOP).

In most literature cases primarily mathematical synthesis was explained by examples

rather than theory.Yang and Marquardt[2009]being a notable exception. Furthermore,

the synthesis step contributes most to the development time and model quality in the

model building process as we shall show later.

Furthermore we will discuss elements of all phases, i.e. from development to ap-

plication (including dissemination). A significant part of each practical model building


35/408

2.1.I NTRODUCTION

2

23

process is spent on debugging. We define debugging as the process of removing errors

during the complete model building process. These errors can be physically and/or nu-

merically based including code verification and physically incorrect equations or valida-

tions.

Strangely enough few modelling tools are supplied with an extensive debugging tool

other than degree of freedom analysis, index check and units check. ASCEND is one ofthe examples were debugging was part of the concept from the earliest days on [ Piela

et al.,1993]. It contains tools to find variables close to their bounds or far from nominal

values as well as a (substantial but small) error data-base. Closely related to debugging

problems is the problem of verification, which checks whether the implementation was

done correctly(see e.g. Lennox et al. [2001], Yuan et al.[2003] andLennox and Yuan

[2003]).

2.1.1.TERMINOLOGYMathematical modelling is concerned with the translation of physical items/ phenom-

ena into mathematical formulas. First the relevant part of the physical domain is re-duced to a simplified domain by means of physical assumptions, next the physical do-

main is translated to the mathematical domain, where other assumptions or reductions

may be applied, finally the mathematical domain is translated to the numerical domain,

where again reductions can be applied. These three mentioned reductions and the con-

nections between physical, mathematical and numerical worlds are shown in figure 2.1.

We will discuss the abstraction in more detail in section2.3.1. In addition to the do-

mains indicated a software domain could be considered, here we assume it is part of the

numerical domain since for practical large-scale model building it usually is. Although

clear definitions exist for mathematical concepts, this is less so for physical problems in

the physical domain. In general a mathematical problem is defined by the space (andits properties), objects and operations on these objects. In the physical domain we are

more concerned with phenomena with sometimes unclear boundaries, e.g. laminar or

turbulent regime.

In this chapter we will use the terminology first introduced byMesarovic et al.[1970]

to help communication during the modelling process. The terminology allows for a

clearer decomposition and description of the modelling process.

We first define the following terms: anobjectis an abstract thing, anentitya person

or thing existing in physical reality and aneventan activity. With these terms we can

define:

Stratum: an independent entity, object or event that can do or contains multiple

tasks.

Echelon: causal/hierarchical set of events, entities or objects.

Level: independent set of objects, entities or events.

Note that an echelon is procedural in the sense that it describes the flow of informa-

tion, whereas a level can be an element of this procedural flow. Consider for example

simplified model synthesis levels: 1) assumptions, 2) equations, 3) implementation and

4) simulation. An echelon would be: 1) write down the assumptions, 2) write down the


36/408

2


Figure 2.1: Simplified overview of abstraction process.

equations, 3) implement the equations, 4) run a simulation, 5) check results and if not

correct implement additional assumptions (level 1) etc. In most cases the steps of an

echelon are associated with a level.

The terminology allows for repetitive refinements in the stratum-echelon-level space

leading to (self-) similar structures. Thisfractalnature allows for a more precise defini-

tion of the process. Thisfractalfeature also allows people to be "guided" to the desired

point by explaining the route to the particular point of interest. For example if we talk

about analysis, we are not certain whether we mean the analysis of the design procedure,

the design, the model that was used in the design or for example the economic analysis

of the plant.

As a consequence the aforementioned model building phases: development, imple-

mentation, validation and application arelevelsin a model buildingechelon. Eachlevel

can have its ownlevels, the aforementioned "steps": specification, assessment, synthe-

sis, analysis and evaluation.

The complete model building process contains for instance the following strata: mod-

eller, plant, model code, PC, operator, manager; echelons: decision tree, synthesis pro-

cedure, numerical algorithm and levels: model synthesis, senior researcher (as a level in

the management hierarchy/echelon), test phase. The echelons, levels and strata all can

have their own echelons, levels and strata. In figure2.2we see the model building levels

(in the development phase) and echelon. As indicated the echelon contains a direction

of information flow, e.g. starting from the specification of functional requirements we

move to the assessment of domain knowledge. If at this stage we find out we lack some

knowledge we can go back to the functional requirements or if we do have sufficient

knowledge we can move on to the synthesis level etc.

In figure2.2we also see that the synthesis level that is part of the model building

levels and echelon has its own levels and echelon, hence the "fractal" nature. In other

words everything is at least associated with one level, one echelon or one stratum. A


37/408

2.1.I NTRODUCTION

2

25

Figure 2.2: Example of model building levels and echelon. Note that the echelon includes a form of direction

of information flow indicated by the arrows.

tutorial on the terminology is given in appendixB.1.

The strata, echelons and levels help to understand the different perspectives of the

model building process. For instanceHangos and Cameron[2001a]describe echelons,

Marquardt[1995] presents levels andMaier[1996] looks at the model building process

from the perspective of strata.

The generic design cycle, itself an echelon, consist of levels (specification, assess-

ment, synthesis, analysis and evaluation), but every level may encompass the generic

design cycle, i.e. a level may consist of multiple levels itself. For example in table2.1

we show two different sets of levels: the generic design cycle and part of the business

strategy levels. The generic design levels occur on each level of the business strategy lev-

els. A business strategy of a company may specify that they want to increase their profit

and decide to build a plant. At this point we can address the echelon of building a plant,

which is part of the business strategy echelon (the path we follow here is indicated by

italic text in the table). They asses that they have enough skills and knowledge to syn-

thesize different strategies. Again at this point we can go a level deeper and look at the

echelon of synthesizing the plant. In the synthesis of strategies, they may come up with

specific plants. Hence they need to design a plant etc. (following the italic text through


38/408

2


Figure 2.3: Simplified graphical overview of terminology and how different elements connect.

the table). To clarify what evaluation we are talking about we could thus call the mathe-

matical model validation also "business strategy analysis - plant design analysis - model

building synthesis - mathematical model evaluation". Of course the latter is too long for

common use. It does however prevent misunderstandings.

In most cases an echelon consists of multiple strata. The business strategy echelon

above contains chief executives, managers, designers, modellers, PCs and software for

example. Not every stratum takes part in every level or every sub-echelon (like model

building levels or echelon). In figure2.3an example of two echelons, generic design

levels and a number of strata is given. The figure shows two echelons: the model building

and the mathematical model building echelons. The model building echelon starts for

example with a manager asking a modeller to investigate problems in the plant. The

manager is part of the specification of the problem, among others, the modeller does

the assessment, synthesis and evaluation and requires a pc to implement the model.

The mathematical model building echelon, i.e. the procedure of synthesizing the model,

starts with the specification of the model, the model equations and variables, degrees

of freedom etc. Once the model is implemented the computer is used to assess and

evaluate the model, i.e. the user interface. The synthesis and analysis of the numerical

model is normally done by the software. The figure is meant as an illustration of the

interplay between echelons, strata and levels, not as a definition. (The shaded cubes are

only meant as a visual aid to help locate the filled blocks in the figure.)

Finally, we will define the word structureas a set of objects and connections between

these objects in which each object is defined by the operations that are allowed in the

object and the connections for transfer between these objects. For example we can de-

fine a structure which contains an object that can change things and an object that keeps


39/408

2.1.I NTRODUCTION

2

27

Table 2.1: Example of level decomposition into deeper levels (italic text is where we zoom in).

Generic design business strategy plant design model building

specification increase profit basis of design requirements

assessment suff. knowledge suff. knowledge suff. knowledge

synthesis different strategies different designs math. model

analysis plant design model building sensitivity

evaluation evaluate strategy evaluate design evaluate model

Generic design math. model

specification math. space

assessment suff. knowledge

synthesis model equations

analysis DOF etc.

par. estimation

evaluation validation

things the same (pure transportation).

2.1.2.G OAL AND OUTLINEModel building is the process of using limited resources to develop a solvable mathemat-

ical and numerical representation of a real world functionality with sufficient predictive

accuracy. An important step in the model building process is the model synthesis. The

problem with model synthesis at present can be formulated as having limited knowledge

on resource requirements and limited understanding of technical development and im-

plementation path. The goal of this chapter is to give insight in the complete model

building process and increase the efficiency of the model synthesis in the model devel-

opment level. We will describe the different steps in the model building process and

focus on one time consuming and complex step in the model development level with a

high impact on model quality: the synthesis. We will focus on a level description rather

than an echelon description. The main difference between the level and echelon de-

scription for synthesis is that in general an echelon contains iterations or a direction,

while a level does not.

Ideally during the synthesis we incorporate the right level of detail to meet the de-

sired accuracy. In practice this is rarely the case and experience is at present the only

way to reduce iterations (from validation back to synthesis).

Furthermore we will identify bottle-necks in the model building process. Particular

interest will be placed on generality and practicality.

The proposed model building strategy, i.e. the new structure level and synthesis ech-

elon levels in the model development level, is tested on two case studies. The results

from the case studies are evaluated with respect to the proposed method and conclu-

sions are presented.

In section 2.2we describe existing model structures and in section 2.2.2 a new model

structure. We discuss the synthesis in section2.3. The industrial case study (see sec-


40/408

2


tion1.5.3) will be used to exemplify the theory. Finally we discuss the results including

detailed insight in model building times in section2.4, before we end with conclusions.

2.2.SYNTHESIS STRUCTURE LEV ELS

The synthesis structure forms the basis of our models. It is the framework that is used todevelop the model in. The structure is defined by objects and connections with allowed

operations in these objects. These objects are levels in the synthesis structure.

For example we define a structure level in which change can occur and a level in

which change may not occur. With these two "building blocks" we can built a model. The

main importance is that by knowing what structure level is used, the allowed operations

are known and thus an insight in the modelling approach becomes clear. Since we only

discuss synthesis structure levels here, we will call them structure levels for short.

The structure levels should have a strong resemblance with reality. Furthermore it

should have the six characteristics indicated byGeoffrion[1989], i.e. it should be:

Generally applicable.

Rigorously formal.

Understandable and natural for the main actors.

Paradigm-neutral yet compatible with most paradigms.

Consistent with good modelling practice (modular, parsimonious etc.).

Suitable foundation for design of/in an executable modelling language.

Furthermore the structure level should help to simplify the model process and should

thus not be too complex. We translate the criterionconsistent with good modellingcri-

terion to complementarity of the structure, which also strongly reflects on whether it is

suitable forgeneral software. If a model is complementary we mean its parts have no

overlap, i.e. there are no redundant equations. An example where a model is not com-

plementary is when different levels of detail (for the same phenomenon) can be present

in the same model.

2.2.1.EXI ST IN G ST RU CT UR E LEV ELSIn this section we will identify different structure levels and give some examples. It is ac-

knowledged that other people than mentioned here may have contributed significantly

or even more. We choose these six approaches since they are most common in a chemi-

cal engineering or control related area. Furthermore, we stick to the terminology used in

the field without explaining the exact differences and/or similarities. References to the

fields are given, but the explanation should give sufficient insight in the differences.

Bond graph levels: Bond graphs have a strong resemblance with electrical systems

(see e.g.Gawthrop and Smith [1996]). The main items consist of nodes and ports. A node

can best be represented as an object that is connected by electrical wires that represent

the ports. The nodes can be subdivided in sources, stores and dissipators. Sources and


41/408

2.2.SYN TH ES IS ST RU CT UR E LE VE LS

2

29

dissipators cannot be subdivided further. Sources, stores and dissipators relate to the

conventional meaning of these words.

The ports consist of the transfer elements, usually called multi-ports, indicating they

have two or more elements for transferring energy. The port can be subdivided in junc-

tions, transformers and gyrators. Junctions can either be combining or splitting of ports

and can be either effort or flow based. The transformers allow a multiplication and gyra-tors a flow dependency of

dynamic chemical process modelling and validation - j.p. schmal

Documents