information technology support in the chemical process design life cycle

Chemical Engineering Science 57 (2002) 1763–1792www.elsevier.com/locate/ces

Information technology support in the chemical processdesign life cycle�

Ralph Schneider, Wolfgang Marquardt ∗

Lehrstuhl fur Prozesstechnik, RWTH Aachen, Turmstra�e 46, D-52056 Aachen, Germany

Abstract

Information technology has been becoming increasingly important in all areas of engineering during the last few years. Much of theprogress achieved in chemical engineering would not have been possible without the enabling methods and tools provided by informationtechnology. This trend will continue in the future but most likely with a considerably wider scope. While individual software tools andservices have been in focus until recently, their integration into engineering work processes is an emerging and challenging area of researchand development. This contribution attempts to highlight state of the art and future trends in supporting the activities during the life cycleof a chemical process by means of information technology. Emphasis will be largely on the process and plant design process rather thanon procurement, manufacturing, and distribution of materials in the supply chain. ? 2002 Elsevier Science Ltd. All rights reserved.

Keywords: Process and plant design; Work2ow; Activity modeling; Information modeling; Product data; Tool integration; Integrated design environments

1. Introduction

Today, chemical engineering science is considered anestablished area of research which has been developing andmaturing during the last century. It has always been of atruly interdisciplinary nature. In particular, there has beena strong emphasis on the reconciliation of the constructiveengineering and the analytical natural sciences approach.While the former aims at the development of new productsand their manufacturing processes, the later strives for a pro-found understanding of nature and for the discovery of newphenomena, substances, and theories. In the last 50 years, thetraditional roots of chemical engineering—physics, chem-istry, and mechanical engineering—have been comple-mented by the systems sciences—notably mathematics,operations research, and computer science—and more re-cently by microbiology and biochemistry. Various recentpredictions of the future of our discipline, brie2y summa-rized in the next section, emphasize the interfaces to thefundamental sciences in various ways.

� Jubilee paper.∗ Corresponding author. Tel.: +49-241-80-977-62;

fax: +49-241-80-923-26.E-mail addresses: [email protected] (R. Schneider),

[email protected] (W. Marquardt).

1.1. Prediction of future trends in chemical engineering

Since the beginning of the 1990s, numerous articles havebeen published discussing future challenges and develop-ments in chemical engineering including the contributionsof Villermaux (1993), Guy (1994), Wei (1996), or Gross-mann and Westerberg (2000). The most comprehensive re-port is “Technology Vision 2020” (American Chemical So-ciety, American Institute of Chemical Engineers, ChemicalManufacturers Association, Council for Chemical Research,& Synthetic Organic Chemical Manufacturers Association,1996), a study sponsored by leading organizations orientedtowards chemistry as well as chemical engineering. In thisstudy, four technical disciplines are identiCed to be of majorimportance for future development, namely

• new chemical science and engineering technology,• supply chain management,• information systems, and• manufacturing and operations.

Indeed, all publications speculating about future trends inchemical engineering can be categorized according to thislist of topics with diEerent emphasis. Some of them are fo-cusing on improvements in the way design processes areundertaken (Morgan, 1992; Sowa, 1997; Basu, Mack, &Vinson, 1999). Others are concentrating on one important

0009-2509/02/$ - see front matter ? 2002 Elsevier Science Ltd. All rights reserved.PII: S 0009 -2509(02)00075 -1

1764 R. Schneider, W. Marquardt / Chemical Engineering Science 57 (2002) 1763–1792

task during process design like computer-aided modeling(Perkins, 1994; Ponton, 1995) or cost reduction and safetyaspects (Keller II & Bryan, 2000; Harold & Ogunnaike,2000). Only little attention has been given to a holistic viewof the design process and its product, the plant (Perris, 1994;Natori & O’Young, 1996). Surprisingly, the role of infor-mation technology has not been stressed by any of those pa-pers. Instead, information technology has been consideredto be a major enabler also in the process industries by man-agement consultants (e.g. Riemann, 2000) with a particularemphasis on procurement, manufacturing, and distributionof products and materials (Poesche, 2000).

There is a considerable degree of agreement between thevarious authors’ opinions about the future development ofchemical engineering, which may be an indication for theirreliability. However, a broader perspective regarding the dy-namics of economic development is taken in the next sec-tion. This exercise helps us to better explain the past and itmay be useful to substantiate our predictions into the future.

1.2. Dynamics of economic development

There are many competing theories in economics whichtry to explain the principles and mechanisms of economicdevelopment. Among others, the theory of long waves hasgained signiCcant attention in particular in the United Statesand in Germany (Modelski & Thompson, 1996; NeCodow,2000). This theory, originally introduced by the Russianeconomist N. D. KondratieE in the 1920s and endorsed bythe Austrian economist and social scientist J. A. Schumpeterin the 1930s, explains the socio-economic development by asequence of regular patterns of structural change which arecharacterized by strong growth of the world economy. Thesewaves are induced by a set of basic innovations which areof a level of signiCcance to launch a technologic revolutionon a large scale. This revolution may be distinguished bynew products or new markets, new sources of raw materials,new manufacturing methods, and new services or forms ofbusiness organization.

These so-called KondratieE waves show S-shape growthcurves covering a phase of slow start-up, followed by fastgrowth and ultimate leveling-oE over a period of some 50years. There is some agreement on the last four to Cve cy-cles. For example, NeCodow (2000) identiCes Cve Kondrati-eE waves on the basis of historical statistical data startingin the late 18th century. In the Crst wave, cotton textilesand the steam engine induce the industrial revolution. Thedevelopment of railroads and steamships, facilitated by in-dustrial steel production, enables mass transportation to linkdistant production sites and remote markets in the secondwave. In the third wave, electricity and the technology forthe large-scale synthesis of chemicals triggered a revolu-tion in production technologies. The fourth wave brought aquantum leap in mobility due to aEordable motor vehiclesand low cost petrochemical fuels.

With the Cfth wave starting in the early 1970s, an imma-terial product—information—has been the driving force fora structural change for the Crst time. The transition from thefourth to the Cfth wave is attributed to the start of a signiC-cant deviation between the growth rates of the gross nationalproduct of a particular national economy and its energy con-sumption in the 1970s. The drivers of the Cfth wave havebeen

• the hardware, such as electronics, the mainframe and per-sonal computers, networks and wireless communication,

• and the software to handle and process well-structureddata and expert knowledge or to support well-deCnedwork processes in service, manufacturing and distributionindustries.

The strong growth phase of this wave seems to be closeto completion today and the leveling-oE phase could havestarted already.

Despite the predicted duration of the current wave foranother ten years or so, the slow start-up phase of a sixthKondratieE wave is most likely already in place. Obviously,there are a number of candidates, basic innovations thatcould have the power to trigger another phase of fast eco-nomic growth on a world scale. NeCodow (2000) discussesenvironmental technology, biotechnology, optical technolo-gies and solar energy, as well as health and well being, asthe possible drivers of this sixth KondratieE wave. He em-phasizes though, that information technology will continueto play a major role in facilitating any future basic innova-tion to a signiCcant extent. In addition, cooperation, socialskills, and emotional intelligence will become a key quali-Ccation of individuals and institutions in the future due tothe ever increasing complexity of the (technical and social)systems that have to be dealt with and due to the almostunrestricted availability of information.

1.3. Focus and structure of the paper

It is interesting to note that chemical engineering willmost likely play a major role in the sixth KondratieE, if itcontinues to explore and exploit the interfaces with otherscientiCc areas, with the objective of introducing innovativeproducts, novel manufacturing processes as well as new en-gineering principles and concepts. However, due to the ap-parent and continuously increasing potential of informationtechnology to facilitate innovation and growth in any disci-pline today and even more in the future, we want to focuson information technology as an enabler of future chemicalengineering innovation. Obviously, this topic is too broad tobe covered comprehensively in such an article. Hence, ourattention is focussed on the life cycle of the chemical pro-duction process. Particular emphasis will be on (chemical)process and plant design rather than on (chemical) productdesign and development or manufacturing and distributionin the supply chain.

R. Schneider, W. Marquardt / Chemical Engineering Science 57 (2002) 1763–1792 1765

time

project

plant

project

product

enterprise

enterprise ABC

product XYZ

project ”new XYZ–plant”

XYZ–plant

project ”revamp XYZ plant”

Fig. 1. The design life cycle and its relation to other life cycles (dashed arrows indicate initiative).

The next section introduces the concept of the life cycleand discusses the potential of such a holistic approach. Thislife cycle characterization is reCned in Section 3 by meansof an integrated representation of life cycle activities usinginformation modeling. Section 4 discusses the synthesis ofthe individual activities in the life cycle to an integratedwhole from a conceptual and a technical point of view. Sec-tions 3 and 4 are structured similar according to the threelife cycle perspectives as introduced in Section 2, namelythe work2ow, the product data and the software perspective.The consequences of a life cycle approach for research, ed-ucation, and industrial practice will be discussed in the C-nal section. We tried to clearly separate the contents of allsections in order to ease the reading and understanding ofthis paper. Therefore the sections can be read quite indepen-dently from each other.

2. The concept of life cycle

The term life cycle has its roots in biology and is deCnedaccording to the Merriam-Webster’s Collegiate Dictionaryas:

A series of stages through which something (as an indi-vidual, culture, or manufactured product) passes duringits lifetime.

The concept of life cycle has been used for several yearsin software engineering (e.g. Rumbaugh, Blaha, Premerlani,Eddy, & Lorensen, 1991). It has been adopted more recentlyby many service-oriented process engineering companiesand software vendors to consider the various phases of achemical plant. Their objective is to provide services andtools to support the major phases of the life cycle of a plantin an integrated manner. This life cycle includes the design,creation, use, and decommissioning of the plant.

As in any technological context, a number of diEerent lifecycles can be distinguished, though a concise classiCcationand terminology is not yet broadly accepted. For example,the IFAC=IFIP Task Force on Architectures for EnterpriseIntegration has accounted for four major life cycles in theparts manufacturing industry (Molina, Sanchez, & Kusiak,1998). They comprise

• the enterprise life cycle, which refers to the enterpriseitself,

• the strategic enterprise management process life cycle,which refers to all the strategic management processes inan enterprise,

• the enterprise engineering process life cycle, which ac-counts for all the engineering processes in an enterprisein an integrated manner, and

• the product life cycle, which refers to a particular product.

The life cycle we are most interested in is related to theengineering processes during the product, process and plantdesign phases as well as during continuous revamping,improvement and debottlenecking accompanying the manu-facturing phase. This life cycle, being part of the enterpriseengineering process life cycle as introduced above, is re-ferred to as the chemical process design life cycle. Naturally,it interferes with many other life cycles. More precisely, itlinks all the design and development activities concatenatedin the design process implicitly or explicitly contained inother life cycles. For example, Fig. 1 shows the life cyclesof the enterprise, a certain chemical product, a project todesign and build or revamp a manufacturing plant in ad-dition to the life cycle of the plant itself. These life cyclesare partially covered by the (chemical process) design lifecycle. Hence, the design life cycle encompasses all thebusiness processes (see Kellner, Madachy, & RaEo, 1999,for an excellent deCnition) carried out by diEerent people


enterprise

particles,thin films

moleculecluster

molecules

process units

plants

site

single and multi-phase systems

1 pm 1 nm 1 µm 1 mm 1 m 1 km

ps

ns

ms

s

min

h

day

week

month

timescale

lengthscale

small

chemical scale intermediate

large

Fig. 2. Scales in the design life cycle.

from product design to operation support systems design(Schuler, 1998).

2.1. Elements of the design life cycle

During the design life cycle many diEerent activities areperformed by the members of an interdisciplinary team, theso-called actors, who are partly supported by tools. Thepeople or groups of people involved in the life cycle rep-resent diEerent roles. These roles may have an administra-tive or a technical motivation. Typical roles are the projectmanager leading a design team or the process simulationexpert, who—as a member of the design team with speciCcexpertise—is solving non-standard modeling and simulationproblems. Certain roles and their relationships are combinedin an organizational unit. The actors organized in a team,the available infrastructure (e.g. experimental facilities), andthe computer-based tools employed may be referred to asthe resources. The spectrum of activities ranges from thoseon an enterprise level to those on an operational level. En-terprise level activities include for example strategic deci-sions regarding the product portfolio. They are carried outby higher management. Activities on the operational levelinclude for example the execution of a process simulationduring a debottlenecking study. They are carried out by anindividual engineer during a design project.

Another major element of the design life cycle is informa-tion which comprises all kinds of data and their context andinterpretation. Examples include market forecasts, patents,design rationales, physical properties and all kinds of mathe-matical models (see Section 2.1.1). Information is retrievedfrom an external source or produced within a particular ac-tivity and interpreted, modiCed and expanded in some otheractivity carried out at a later time. Information can be rep-resented in the form of documents which are available assome kind of written paper or electronic Cle. Examples ofsuch documents are equipment data sheets, various kinds

of 2owsheets (PFD, P&ID, etc.), or project reports, whichhave always been used in the life cycle for communicationbetween people and to archive information.

Information is typically processed (or generated) in a cer-tain sequence during the life cycle. This is referred to as theinformation ;ow. Complementary to the information 2owthe control ;ow represents the chronological order of activ-ities. The entirety of all the activities and the control 2ow iscalled work;ow (Jablonski, BPohm, & Schulze, 1999). Typ-ically, the work2ow in an engineering project is structuredin a document-oriented manner according to the documentsused and generated during the project (Misander, 2000). Of-ten, documents re2ect the milestones of a project.

2.1.1. Mathematical modelsThe traditional view of the design life cycle, as estab-

lished in the parts manufacturing and service industries, doesnot account for rigorous mathematical models to describethe properties of a product or the behavior of the associ-ated manufacturing process. Instead rather simple, discreteevent models are used to analyze and optimize manufac-turing and distribution processes (e.g. Kosturiak & Gregor,1999; O’Kane, Spenceley, & Taylor, 2000).

In contrast, the numerous types of mathematical modelsemployed in chemical and process engineering across thevarious phases of the life cycle diEer in the level of detailand in the particular characteristics of the real process theycapture. As shown in Fig. 2, these models may be organizedon diEerent scales. On the Cnest length scale there are quan-tum physics or molecular mechanics models to representsingle atoms or molecules. On the following length scales(i) molecular dynamics models are used to capture inter-acting molecules in a cluster or in a thin Clm, (ii) diEeren-tial continuum models to describe particles or Clms as wellas single- and multi-phase compartments of a process unit,(iii) integral models to represent the behavior of a processunit, a manufacturing process or even an enterprise as part


Table 1Generic tools supporting collaborative work processes and administrative business processes

Type of Tool References Examples

Enterprise resource planning (ERP) Kirschner (1997), Shanks and Seddon (2000) SAP R=3, iBaanProject management tools Kerzner (1998) Artemis, MS ProjectWork2ow management systems Jablonski et al. (1999) StaEware, i-FlowDecision support tools Proudlove, VaderQa, and Kobbacy (1998) DRAMADocument management systems Zantout and Marir (1999) Documentum, HyperwaveGroupware systems Ellis, Gibbs, and Rein (1991) BSCW, Lotus NotesOSce tools MS OSce, Star OSce

of the supply chain, and Cnally (iv) models to represent thegeometry of the equipment and the layout of plants. Mod-els on a certain length scale are usually associated with atypical time scale. In addition to the two scales usually con-sidered, a chemical scale may be distinguished which refersto the number and type of (chemical) components resolvedin a model (Marquardt, von Wedel, & Bayer, 2000). Moredetailed examples of models in the design life cycle are dis-cussed by Marquardt (1999) and Sundquist, Ilme, MPaPattPa,& Turunen (2000).Mathematical models represent to a large extent a

company’s knowledge. They capture aspects of a certainchemical process in a formal way. Consequently, they areaccounted for as a specialization of information in ourconsiderations. This is largely in contrast to the classicalsystems view, which focuses on a description of the com-ponents of a system, their properties and in particular theirgeometry, and their relations.

Such an integrated view of mathematical models and allother information handled in the life cycle is necessary be-cause of the importance of model-based techniques in all lifecycle phases including all aspects of process development,design, control, and operation (Foss, Lohmann, & Mar-quardt, 1998; Jones & MacLean, 1999; Marquardt, 1999;Marquardt et al., 2000; Sundquist et al., 2000). This impor-tance will grow due to the progress made in capturing thephysical, chemical, and even (but to a lesser extent) the bi-ological phenomena, which determine the function and thebehavior of a plant.

2.1.2. Software toolsThe life cycle is supported by diEerent kinds of resources.

Given the purpose of this article with its focus on informa-tion technology, software tools are of special relevance andwill therefore be brie2y reviewed in this section. We willnot elaborate on the functionality of an individual tool, buttry to classify various kinds of tools and to relate them to theelements of the life cycle described above. Largely, thereare two diEerent groups of software tools used during thelife cycle.

The Crst group comprises generic tools which are notspeciCc to chemical engineering but which are used in allindustries to support collaborative work processes and ad-ministrative business processes (see Table 1). The function-

ality of these tools is not driven by the needs of the (chemi-cal process) design life cycle. Rather, these tools attempt toaddress the domain-independent needs of a (much) largercustomer base. Hence, such tools do not re2ect the pecu-liarities and the particular needs of the ill-deCned, complexand dynamically changing, creative work processes, whichtypically occur in any (engineering) design life cycle. Fur-thermore, these tools do not account for appropriate inter-faces to relate activities, project schedules, or documentsproduced by individuals in the life cycle in a transparentmanner (Nagl, Westfechtel, & Schneider, 2002).

In contrast to these generic tools, the second group of toolsspeciCcally addresses certain design tasks during the lifecycle in the chemical engineering domain. They can roughlybe classiCed as data retrieval, synthesis, and analysis tools(see Table 2).

Though these tools are still largely used in a stand-alonemanner, the major software vendors are continuously inte-grating their products into some design environments withinterfaces to selected tools from cooperating vendors to ad-dress particular aspects in the life cycle (e.g. AspenTech’sEngineering Suite or Intergraph’s Smart Plant). In particu-lar, these tools are at least partly linked to engineering orproduct data management systems (Philpotts, 1996) such asComos PT or SmartPlant Explorer which persistently storethe information used and generated during (parts of) the lifecycle.

There is no (or very little) integration, neither conceptu-ally nor technically, between the two groups of tools sup-porting the administrative and the technical business pro-cesses in the life cycle. In particular, work2ow managementor groupware systems do not provide any interfaces to thededicated chemical engineering tools. In more general terms,there are no tools available, which integrate the work pro-cess perspective and the product data perspective of the lifecycle in a sound manner. Work2ow and product data arekept (strictly) separate in diEerent tools.

2.1.3. Three life cycle perspectivesSo far, the elements of the life cycle together with their

interactions have been identiCed. The major elements are theactivities, all kinds of information including mathematicalmodels, the resources, most notably software tools, and theorganizational units.


Table 2Chemical engineering tools

Type of Tool Examples

Data retrieval toolsPhysical property systems DETHERM (Westhaus, DrPoge, & Sass, 1999)

DIPPR (Wilding, Rowley, & Oscarson, 1998)

Synthesis toolsFlowsheet development PROSYN (Schembecker & Simmrock, 1996)

DISTIL (Wasylkiewicz & Castillo, 2001)Plant layout and pipe routing PDMS Router (http://www.cadcentre.com/)

Schmidt-Traub, KPoster, HoltkPotter, & Nipper (1998)Equipment design HTFS (http://www.software.aeat.com/)

Aspen Hetran (http://www.aspentech.com/)Mathematical modeling MODKIT (Bogusch, Lohmann, & Marquardt, 2001)

Model.la (Bieszczad, Koulouris, & Stephanopoulos, 2000)Solvent selection Hostrup, Harper, & Gani (1999)

Analysis toolsProcess simulators HYSYS (http://www.hyprotech.com/)

Aspen Plus (http://www.aspentech.com/)CFD packages FLUENT (http://www.2uent.com/)

CFX (http://www.software.aeat.com/)Controllability analysis tools MATLAB (http://www.mathworks.com/)HAZOP tools Venkatasubramanian, Zhao, & Viswanathan (2000)2D=3D CAD tools AutoCAD (http://www.autodesk.com/)

Pro=ENGINEER (http://www.ptc.com/)

activities activities activities

documents(incl. mathematical models)

data

documents(incl. mathematical models)

data

= tools = roles,

Fig. 3. Elements of the life cycle.

These elements can be grouped into three diEerent lifecycle perspectives, which are relevant in the context of in-formation technology support (see Fig. 3). They comprise

• the work;ow perspective, which addresses the activitiestogether with their control and information 2ow in someorganizational structure,

• the product data perspective, which emphasizes the infor-mation generated and managed during the work process,and

• the software perspective, which focuses on the computer-based tools used in the work process.

The elements of major interest from the work2ow perspec-tive are the actors involved and the activities performed in-cluding the order of their execution (the control 2ow). Theproduct data perspective focuses on the documents and dataused and generated together with their relations and interde-pendencies, which is partially re2ected by the information

2ow. The persistent storage of product data in some databasesystem and the tools supporting diEerent life cycle activitiesconstitute the software perspective.

Despite their obvious and strong dependency, thework2ow and the product data perspectives have oftenbeen considered independently from each other. Sincecomputer-based tools are increasingly used during thework2ow for processing and generating product data, thesoftware can be seen as some kind of integrating factorbetween the work processes and its associated product data.

2.2. The bene=ts of the life cycle approach

In the last decade the chemical industries have under-gone major changes mainly due to the globalization ofcompetition and the increasing stringency of governmentalregulations (e.g. Harold & Ogunnaike, 2000). In order tosuccessfully cope with this new situation, the often

http://www.cadcentre.com/

http://www.software.aeat.com/

http://www.aspentech.com/

http://www.hyprotech.com/

http://www.aspentech.com/

http://www.fluent.com/

http://www.software.aeat.com/

http://www.mathworks.com/

http://www.autodesk.com/

http://www.ptc.com/


evolutionary and largely unsystematic improvement of themajor business processes have to be replaced if possibleby standardized procedures. At least frameworks should beemployed to guide the business processes without restrict-ing creativity and initiative as a prerequisite for innovation.

This is especially true for design processes during thedesign life cycle which tend to be neglected in favor ofstriving for excellence in manufacturing and supply chainmanagement where economic beneCts can be materializedon a shorter time horizon. It is still common practice thatplants are engineered and constructed on the basis of a lab-oratory scale process, oE the chemists’ work bench, withoutseriously considering conceptual process design, front-end,and basic engineering. This is in particular true in the areaof speciality chemicals and pharmaceuticals not only in thesmall to medium size enterprises (Basu et al., 1999). Hence,one key to succeed is a continuous improvement of the de-sign process with an emphasis on

• shortening of the time to market by a reduction of thedevelopment time,

• cutting development cost,• documenting and reusing proven designs and design pro-

cedures, and• achieving a better quality of process design, in order to

◦ reduce the speciCc production costs,◦ ensure a higher 2exibility and availability of the plant,

and◦ to reduce the total cost of ownership over the whole

life span of the plant.

The Crst three objectives are directly linked to the designprocess, whereas the last is linked to the product of the de-sign process, the plant. There are numerous factors whichin2uence the possibilities to improve the design process ac-cording to the objectives given above. The potentials forimprovement are located in diEerent life cycle phases withpossible orders of magnitude diEerences in impact. Tradi-tionally most of them are not considered during the designprocess, often because the interfaces between diEerent de-sign tasks are not clearly deCned and the interdependen-cies between the decisions in the various life cycle activitiesare unknown. Typical and almost classical examples are theinteraction between design and control, the assessment ofspeciCc production costs or total cost of ownership duringconceptual design, or the interactions between conceptualdesign and plant layout and pipeline routing.

The consideration of all relevant factors during the de-sign phase is called concurrent engineering (e.g. Cleetus,1992; Abdalla, 1999). The use of concurrent engineeringallows the analysis and evaluation of more design alterna-tives. Through the integration of diEerent activities withinthe early phases of the design process, unfavorable alterna-tives can be eliminated on a solid basis, leading to a betterproduct of the design process. Furthermore, diEerent designtasks can be solved in parallel leading to shorter develop-

ment times. Despite these advantages, the implementation ofconcurrent engineering is not common in process industries(Badham, Couchman, & Zanko, 2000). This is due to the factthat this is not only a technology issue such as the provisionof computer-based tools to eEectively support collaborativework in the chemical and process industries. Rather it is toa large extent a question of changing the culture in an enter-prise and of reengineering the business processes (Hammer& Champy, 1993) as well as providing appropriate organi-zational structures (Finger, Konda, & Subrahmanian, 1995).

Besides an integration of activities across the various lifecycle phases, the distribution of subtasks among diEerentand even geographically distant organizations is becomingmore and more relevant. This trend is largely due to theconcentration of a business on its core competencies andthe exploitation of both, the skills of specialized serviceproviders, and the low cost solutions to standard problemsprovided by engineering contractors.

Obviously, a formal and suSciently detailed represen-tation of the complete design life cycle including all itselements and their dependencies forms a prerequisite forimplementing concurrent engineering, with a division of thework between geographically, organizationally, or even in-stitutionally distributed business units. In particular, it is al-most impossible to concurrently work on diEerent aspectsof a design or to include third party contractors without hav-ing properly deCned interfaces between diEerent tasks andactivities in a project.

The development and maintenance of such a formal rep-resentation is a major challenge even if appropriate methodsand tools were available. In the next section an overview isgiven on the modeling and formal representation of the threemajor perspectives of the design life cycle as introduced inSection 2.1.3.

3. An integrated representation of the life cycle

In the previous section, the life cycle and its major con-stituents have been introduced phenomenologically. In thissection, it is attempted to capture the objects and conceptscharacterizing the life cycle together with their relationshipsand interdependencies more formally in the sense of sys-tems analysis. A formal representation of the life cycle busi-ness processes is aimed at by an information model whichcontributes to a clariCcation of the complex relationshipsbetween the various business processes and their products.Furthermore, this model can form the basis for the develop-ment of computer-based support systems to achieve an inte-grated design of chemical products and their manufacturingprocesses (Marquardt et al., 2000).

3.1. Information modeling

Information modeling constitutes a key to more and bet-ter information services and management (see Mylopoulos,


1998, for an excellent recent survey). Three diEerent per-spectives can be distinguished with increasing level of detailand degree of formalization to properly re2ect the objectivesof the modeling activity (Fowler, 1997):

(a) Conceptual models target at a proper understanding ofthe domain for which an information system is built withlittle or no regards on the actual software.

(b) Speci=cation models refer to the software’s functional-ity by precisely deCning the interfaces of the individualmodules and the way they are enacted.

(c) Implementation models Cnally cover all the details ofsoftware implementation by means of some software en-gineering environment and programming language(s).

In this article, we are largely interested in conceptual mod-eling to contribute to a better understanding of the life cy-cle. A conceptual information model incorporates a commonvocabulary and a common understanding of the life cyclebetween all the experts involved. It materializes the sharedmemory and the shared meaning (Konda, Monarch, Sargent,& Subrahmanian, 1992) of the members of the interdisci-plinary life cycle team. The identiCcation of activities andentities together with their relationships in the life cycle, e.g.the conceptualization of the domain of interest (Genesereth& Nilsson, 1987), is obviously a precondition to representthe business processes and their results in the life cycle withsuScient degree of detail and coverage. The conceptual lifecycle model qualiCes as the medium for information trans-fer and knowledge sharing across the life cycle, regardlessof the desired or implemented level of information tech-nology support. In addition, it serves as the starting pointfor the speciCcation and implementation models for build-ing information systems, which support the activities in thedesign life cycle (Fowler, 1997). Further, it can guide theintegration of existing applications and information systems(e.g. legacy or third party software from various sources)to an integrated design support environment (Wiederhold &Genesereth, 1997).

A prerequisite for information modeling is the elicitationof the knowledge on the actual business process from allparticipating stakeholders, which is usually very diScult toaccomplish. Elicitation of the private and often tacit ratherthan explicit knowledge of the diEerent actors requires notonly suitable techniques (Cooke, 1994), but also an attrac-tive system of incentives and full support of higher man-agement. Only then, conCdence can be built that the stake-holders will not loose in2uence if their private knowledgeis converted into the organizational knowledge of the enter-prise (Nonaka & Takeuchi, 1995).

The development of an encompassing conceptual infor-mation model for the complete life cycle forms an enormoustask. It is fair to say that—at least today—there is no chanceto formulate a complete information model which capturesthe life cycle with a signi=cant level of detail in its entirebreadth and depth because of the shear complexity and the

continuous evolution of the business processes. The mod-eling exercise is further complicated by the variety of ap-plications the model may eventually be used for. Examplesinclude the formulation of best practice work processes, thedocumentation of some design activities, the developmentof a design process data storage, and the integration of asuite of tools to a design environment. Though complete-ness of the information model may be strived for in all theseapplications, there are natural limitations not only due to thecomplexity and the dynamics, but also due to the fact thatany model only re2ects those aspects of reality which areboth fully understood and considered relevant by the mod-eler (Minsky, 1965).

Nevertheless, signiCcant progress can already beachieved, if the life cycle business process is formally cap-tured in its entirety on a coarse level of granularity. Such aninformation model, completely covering the life cycle, maythen be gradually reCned and detailed in those parts beingof particular interest. Hence, emphasis must be on a skele-ton of the conceptual information model rather than on itsdetails which often are speciCc to a particular enterprise andwhich may quickly evolve over time. Such a coarse modelshould only include the key concepts and their relationsto re2ect the basic structure of the life cycle. It can thenserve as an information modeling framework to guide themodeling activity as well as the more detailed speciCcationand ultimately the implementation of information systemsover a long period of time.

There is no agreed procedure on how to accomplish theinformation modeling task successfully and eSciently. Thisis not at all surprising, since compared to the generation of amathematical model of a plant, which is still considered anart rather than a science (Aris, 1991), information modelingis even more ill-deCned and more complex than mathemat-ical modeling. A recommendation for a procedure that hasbeen used successfully in our work is described elsewhere(Marquardt et al., 2000).

The conceptual life cycle model has to cover the work2owwith all its activities in the life cycle and their order in aso-called (work) process model and the results producedduring these activities in a so-called product (data) modelin an integrated manner. Here, we will start with a (work)process centered view, since it will naturally lead us to thevarious activities, the organizational units, and also to theproduct data, i.e. the information and resources in the lifecycle.

3.2. Work processes

An information modeling language for the represen-tation of work processes has to encompass all elementsdescribed in Section 2.1. The C3 formalism (Killich etal., 1999), which has been developed for the investigationand representation of cooperative, weakly structured workprocesses in general, fulClls these and other more speciCc


Fig. 4. Elements of the C3 formalism.

requirements mandatory for work process modeling. It isbased on UML, the UniCed Modeling Language (Booch,Rumbaugh, & Jacobson, 1999). The abbreviation C3 refersto the three major aspects this formalism focuses on: coop-eration, coordination, and communication. After minor ex-tensions and modiCcations, C3 has been proven well suitedfor the representation of life cycle activities during con-ceptual process design (Foltz, Wolf, Luczak, Eggersmann,Schneider, & Marquardt, 2000b).

The major language elements of C3 are given in Fig. 4(see Foltz, Killich, & Wolf, 2000a, for a more detailed de-scription):

• roles,• activities,• input and output information,• control 2ows,• tools,• synchronous communication.

All activities are assigned to a role which is responsible fora number of activities organized in so-called swim lanes.Depending on the work process to be modeled, roles canbe attributed to an organizational unit, such as an individ-ual person, or to groups of people ranging from a projectteam to a division of a company or even to a whole en-terprise. Within each swim lane, the temporal order (fromtop to bottom) is indicated by the sequence of activities andtheir connecting control ;ows represented by solid lines.There is no temporal relation between activities in diEer-ent swim lanes. Coordination points refer to required syn-

chronous communication between roles. They roughly Cx atemporal frame of the work process. The 2ow of informa-tion, produced within some activity and used in another, isrepresented by a dashed line. The particular data transferredbetween activities according to the information 2ow is spec-iCed within a complementing box. It represents the func-tional aspects of an activity in terms of shared informationresources or a transformation of the input information intooutput information. Information 2ow between two or moreactivities indicates which activities can be performed afterthe completion of another one. Tools used within an activ-ity are indicated by arrows attached to the activity. Whenthe temporal order cannot be predetermined, activities canbe aggregated within a blob.

The C3 modeling language can be used in quite diverseways. There are at least four diEerent types of applications:

• Documentation: A design process with its decisions, in-termediate results, failures, etc. can be documented dur-ing its execution.

• Analysis: The documented design process can be ana-lyzed to identify weak points and possible improvementsor to deCne interfaces between diEerent activities androles.

• Reengineering: The analysis of a completed project canlead to conclusions how the work2ow can be changed infuture projects of the same type in the sense of businessprocess reengineering.

• Planning: Before and=or during a design process thesteps to be undertaken in the near future can be scheduledand discussed during a project meeting.


Meta Class

Output-Information

Social System

tool

prerequisite

Technical System

Input-Information

Goal

Skill

subactivity

Activity

information quality:- exact- must exist- complete

hierarchicalrefinement

enforced activity ordering

required qualification

association withthe product model

individual actor orteam executing the activity

objective of the executor, contributed to by the activity

infrastructure (e.g. experimental facilities),software

aggregation attribute comment

Fig. 5. Activity meta model.

In the sense of object-oriented information modeling (Rum-baugh et al., 1991), C3 is intended for the informal modelingof work processes on an instance level. In order to be able toprovide computer-based support such as guidance throughpredeCned work2ows or suggestion of possible activities ina given situation (see Bogusch et al., 2001, for work pro-cess support in computer-aided mathematical modeling), thework processes have to be represented in a formal manneron a class level.

An example of such a formal model for design pro-cesses in chemical engineering is given in Fig. 5 (Eggers-mann, Krobb, & Marquardt, 2000). It is part of CLiP, theConceptual Life Cycle Process model (Bayer, Krobb, &Marquardt, 2001a). Fig. 5 shows the deCnition of the majorconcepts of the activity model (the so-called meta level).This model is based on ideas originating from requirementsengineering (Pohl, 1996; Grosz, Rolland, Schwer, Souveyet,Plihon, Si-Said, Ben Achour & Gnaho, 1997), that part ofsoftware engineering, which deals with the speciCcation ofan information system. A more detailed description of theunderlying concepts, especially on the actors and the dif-ferent types of activities (synthesis, analysis, and decision)can be found elsewhere (Eggersmann, Henning, Krobb,Leone, & Marquardt, 2001a, Eggersmann, Henning, Krobb,& Leone, 2001b).

Despite the very diEerent origins (ergonomics and soft-ware engineering) and the complementary applications (theinvestigation and analysis of human work processes and thestrongly formalized representation of activities as a basisfor computer-based support of work processes in the lifecycle), there is a close relationship between the concepts inboth modeling approaches. In particular, the activities in aC3 model can be mapped to the activities in CLiP. As in C3,activities require input information to produce output infor-mation. However, the association classes Input and OutputInformation in CLiP characterize the information moreprecisely. They can specify if the referenced information isexact or inexact, must or may not exist, and is complete

or incomplete. Furthermore, these classes directly refer toclasses of the product data model within CLiP, which isdescribed in Section 3.3. This way, a formally sound inte-gration of the work process perspective with the productdata perspective can be accomplished.

Compared to the Cxed sequences of activities modeledin C3, the order of activities can be deCned more 2exiblyby means of prerequisites in CLiP. Prerequisites are ac-tivities, that always have to be executed before the activ-ity to which they belong to, independently of the availableinput information. The execution of an activity requires aspecial qualiCcation, modeled via the class skill. Based onthis information, a computer-based support system is able tochoose a suitable resource (a tool or an actor) to execute thisactivity.

3.3. Product data

As illustrated in the previous section, activities are thekey elements in the life cycle. They are highly related tothe product data on which they work. For this reason themodeling of product data (and ultimately its integration withthe work2ow modeling) is a vital prerequisite for an eScientsupport of work processes.

CLiP is a conceptual information model, whichdescribes—besides design activities—the data and the re-lations between data independently from a speciCc imple-mentation (Bayer et al., 2001a). The primary intent of thismodel is not to serve as a basis for an engineering supportsystem, but to learn more about the domain of chemicalprocess design and its information needs. This understand-ing will help to improve the design process in a systematicmanner. CLiP has been developed to serve as an ontology(Gruber, 1993; Chandrasekaran, Josephson, & Benjamins,1999) for chemical processes and at the same time theassociated design processes. Therefore, the dependenciesbetween the data and the work processes are consideredexplicitly in the model structure.


System

Simple Class

Meta Class

Meta Meta Class

refers to contains

in connection with

uses

references

Connection Device

described by

subclass attribute instance

Social System

Processing Material

Chemical Process System

Operating Subsystem

Management System

ProcessingSubsystem

described by

models

Costs

interacts with

Materialmodels

Technical System

MathematicalModel

Cost Model Material Model

Processing Subsystem Model

described by

Chemical Process System Cost

Activity

performsworks on

has

Fig. 6. The three meta layers of CLiP.

As illustrated in Fig. 6, the model covers three meta lev-els ranging from general systems to speciCc systems de-scribing the chemical process and all related informationneeded and produced during the design life cycle. The mod-els are given in O-Telos implemented using Concept Base(Jeusfeld, Jarke, Nissen, & Staudt, 1998), a tool to supportconceptual information modeling.

The root concept of CLiP, from which all other model-ing concepts can be derived, is the system on the meta metalayer (Marquardt et al., 2000). A system can be decom-posed into one or several parts, which are systems them-selves. A special reference method between systems is themodel-association. A system can be the model of anothersystem. This means, it can be used to describe and predictthe properties and behavior of the original system under agiven aspect with several (known and unknown) simpliC-cations and assumptions (see for example Minsky, 1965).This very abstract introduction to the model as some typeof system includes all kinds of models, like mathematicalmodels, real systems which are copies of the original systemon a diEerent length scale, and even information models.

DiEerent types of systems can be distinguished on themeta level. Technical systems represent all kinds of techni-cal artifacts that are built to fulCll some functionality. Theycan be decomposed and do interact with other technical sys-

tems. Material abstracts substances, that can be used in var-ious manners by technical systems. A social system can bea group of people or a single person. Technical systems aresomehow connected with social systems. Furthermore, ac-tivities are represented on the meta level. Within an activ-ity some properties of the technical system of interest arechanged or created. In this way, a Crst step is achieved to-wards the integration of work process and product data mod-els (cf. Section 3.2).

On the simple class level, CLiP is divided into diEer-ent parts—the so-called partial models—in order to providesome additional structure. Within these partial models re-lated modeling concepts are grouped into logical clustersthat represent one distinct part of the domain of interest. Theconcept of technical systems is further reCned to the chem-ical process system. The chemical process system consistsof the processing and operating subsystem and is associ-ated with the management system. An instantiation of ma-terial is the processing material, which is processed in or-der to get a speciCed product. The behavior of material canbe described by material models. These are referenced bychemical process system models which describe the behav-ior of processing subsystems. Cost models, material mod-els, and processing subsystem models are both mathemati-cal models, which are an instance of a technical system. The


importance of mathematical models in the chemical engi-neering design process is re2ected by this class.

3.4. Related work

There has been signiCcant eEort in product data as wellas work process modeling which is reviewed brie2y, ratherselectively than concisely, in this section.

3.4.1. Work process modelingWork process or work2ow modeling has been extensively

undertaken in various domains driven by software engi-neering, operations research, and management sciences. Themost important eEorts and approaches include enterprise orbusiness process (re-)engineering (e.g. Hammer & Champy,1993; Scheer, 1998; Fox & Gruninger, 1998; Uschold, King,Moralee, & Zorgios, 1998), requirements engineering (e.g.Dardenne, van Lamsweerde, & Fickas, 1993; Pohl, 1996)and software engineering (e.g. Finkelstein, Kramer, & Neu-seibeh, 1994; Estublier, Dami, & Amiour, 1997; Boochet al., 1999).

The formalisms employed range from (largely informal)purely graphical representations to logical formulae witha strict formal semantics. The constructs incorporated intothe languages emphasize the characteristics speciCc to workprocesses in the application domain under consideration.An evaluation of some representative examples of the workprocess modeling languages in the domains mentioned canbe found elsewhere (Killich et al., 1999; Eggersmann et al.,2000).

For a number of reasons, it is diScult to directly trans-fer work process modeling languages to the chemicalengineering domain. For example, enterprise modelingapproaches aim at building computer-based support systemson the enterprise or at least division level which follow abest-practice approach. For this application, it is usuallysuScient to assume a Cxed work2ow as it is often appropri-ate for administrative business processes (for example theinsurance business (Reimer, Margelisch, & Staudt, 2000)).In contrast, (chemical) engineering design processes areill-deCned, complex, highly creative, and change over time.Hence, a work process model with a prescribed and Cxedstructure as it is assumed in many work2ow modeling ap-proaches is not appropriate. The most important drawbackof the software engineering approaches is the missing do-main speciCc knowledge which is required to eEectivelyrepresent design processes in chemical engineering. Themost promising approaches originate from requirementsengineering (Pohl, 1996). The NATURE software processmodel (Grosz et al., 1997), for example, has been used asthe basis of the modeling formalism sketched in Section 3.2.

3.4.2. Product data modelingThere has been signiCcant activity in recent years in

deCning standard data models to represent engineering

product data and enterprise models. The most prominentexample is the STEP initiative, promoting a Standard forthe Exchange of Product model data (ISO 10303, 1994;Burkett & Yang, 1995). Some kind of work2ow modeling,so-called activity modeling, has also been undertaken aspart of STEP. Life cycle models are formulated on a verycoarse level, in particular to guide the product data model-ing eEort and to provide a work2ow context for the productdata model (AIChE, 1998). Besides STEP, the WorkingGroup 2 of PIEBASE (Process Industry Executive forachieving Business Advantage using Standards for dataExchange) has developed an activity model, which is nowbeing used in all STEP projects related to chemical engi-neering (PIEBASE Working Group 2, 1998). In the areaof enterprise engineering, an ISO standardization group isdeveloping a whole family of standards related to businessprocess modeling (Kosanke & Nell, 1999). The Crst twoare ISO 14258 (Concepts and Rules for Enterprise Models)and ISO 15704 (Requirements for Enterprise ReferenceArchitectures and Methodologies).

The AIChE Process Data Exchange Institute, pdXi, hasbeen addressing the deCnition of a generalized data model(Book, Sitton, Motard, Blaha, Maia-Goldstein, Hedrick,& Fielding, 1994; Fielding, Book, Sitton, Blaha, Maia-Goldstein, Hedrick, & Motard, 1995) for conceptual designfront end engineering within STEP. A formal standardiza-tion is currently attempted via ISO, the International Orga-nization for Standardization, in the ISO=STEP ApplicationProtocol AP231. Also related to chemical engineering areAP221 and AP227 which cover product data in detail en-gineering including the detailed description of apparatusand instrumentation as well as the exact layout of a plant.There is a signiCcant overlap with redundancy as well asinconsistency to be removed or at least properly managedin future consolidation. These protocols primarily aim atdeCning standards for data exchange between diEerentsoftware tools.

In contrast to CLiP, these modeling activities have nei-ther the goal of covering the whole life cycle of a chemicalprocess in the sense of an ontology nor to build a basisfor an integrated support system. The Multi-DimensionalObject-Oriented Model (MDOOM) developed by McG-reavy, Wang, Lu, and Naka (1995), Lu, Batres, Li, andNaka (1997), and Batres and Naka (2000) is comparablein scope and philosophy to that of CLiP. Within MDOOMthree life cycle dimensions are identiCed (behavioral, phys-ical, management); embedded in each of them are themodels representing information, activities, and performers.

4. Integration across the life cycle

The potential of integration across the life cycle has beenwidely acknowledged in the process industry (e.g. Ram-age, 1998; Schuler, 1998) as well as by the software ven-dors (e.g. Braunschweig, Pantelides, Britt, & Sama, 2000),


recently. Major operating companies have launched strate-gic projects to improve life cycle integration by an upgradeof their technology base but also by reengineering their busi-ness processes in some parts of the life cycle. The softwarevendors have reacted to the potential identiCed by their cus-tomers. The integration of their portfolio of software prod-ucts into integrated engineering design environments hasbeen pushed continuously for a number of years. This strat-egy re2ects the global business objective of the operatingcompanies to establish design excellence by simultaneouslyimproving the quality of the design process and reducingthe total eEort spent. Such an integration is considered atremendous business opportunity.

Yet, there seems to be a lack of scientiCc principles toguide the signiCcant eEort in the operating and software ven-dor companies to establish an integration across the life cy-cle. These principles need to be established in future researchfocusing on the three life cycle perspectives (cf. Section2.1.3), the work2ow (Section 4.1), the product data (Sec-tion 4.2), and the software perspective (Section 4.4), whichwill be covered in the subsequent sections. These sectionscan be interpreted as an agglomerate of current research di-rections (largely outside the Celd of chemical engineering)and future challenges and requirements.

4.1. Work process integration

The most signiCcant beneCt of integration across the lifecycle should occur via the integration of the actual work pro-cesses (Haddad, 1996; Subrahmanian, Konda, Reich, West-erberg, & the n-dim group, 1997; Herder & Weijnen, 2000),namely the integration of (chemical) product design, con-ceptual process design, front end engineering, as well as ba-sic and detail engineering. In this section, we want to deCneand discuss diEerent possibilities of work process integra-tion, which will lead to new research objectives.

The deCnition of concurrent engineering given by Cleetus(1992) serves as a starting point for this discussion:

Concurrent Engineering is a systematic approach to inte-grated product development that emphasizes response tocustomer expectations and embodies team values of co-operation, trust and sharing in such a manner that decisionmaking proceeds with large intervals of parallel workingby all life cycle perspectives early in the process, syn-chronized by comparatively brief exchanges to produceconsensus.

To our knowledge, the literature on concurrent engineer-ing stresses the aspects of supporting team values bycomputer-based tools and social factors, but concrete rec-ommendations on how concurrency can be achieved andimplemented in the work process in an area like chemicalengineering are largely missing. The problems identiCedare not the enabling information technologies, like data andtool integration, but the reengineering of the work process.

A number of case studies (e.g. Haddad, 1996) showsthat concurrent engineering can lead to substantial savingsin development time and cost and hence contributes to theobjectives formulated in Section 2.2. Surprisingly, concur-rent engineering is not widely used in the process industries(Gunasekaran, 1998). The industrial segments that have ben-eCted most from concurrent engineering are those whichhave adopted industrial engineering and computer scienceprinciples at an early stage. This is particularly true forthe parts manufacturing, the automotive and the aerospaceindustries. Furthermore, it seems (at least from a chemi-cal engineering perspective) that the design processes inthese areas are much better understood. They may either beless complex or considerably more eEort has been put intostreamlining the work processes because of a competitivemarket with strong interdependencies between manufacturesand suppliers.

In the following sections we will Crst identify commonpatterns of work process integration which may serve as astarting point for work process analysis, design and reengi-neering. For clarity reasons, these patterns are strongly sim-pliCed.

4.1.1. Sequential work process patternIn order to classify the diEerent possibilities of work pro-

cess integration, we start with a typical sequential work pro-cess (see Fig. 7), where a new activity (denoted by a box)starts after the previous one is completed. In software en-gineering this model is known as the waterfall model byRoyce (1970). The results of the activity are summarizedin documents which are passed downstream. On a coarsegranularity level there are no iterations or even a backwardinformation 2ow between those activities as these would betoo expensive in terms of time and money. One examplefor such a pronounced gap between major life cycle phasesis the transition from basic to detail engineering: it is notunusual that the designers involved in basic engineering donot know if and how the plant they have designed is goingto be built.

The eSciency of the work process can be improvedby incorporating information retrieval and propagationfrom past activities to current or future activities intothe still sequential work2ow. Such a pattern is shownin Fig. 8.

Again, documents are passed from an upstream to a down-stream activity. In addition, the designers currently dealingwith some activity, are able to retrieve, rate, and discussany facet of the product and work process data generatedpreviously in the same or an upstream activity at any timeduring the project (cf. the dashed arrows in Fig. 8 linkingactivities A, B, and C). Obviously, work processes and re-lated product data have to be traced and stored persistentlyin a shared life cycle database (cf. Section 4.2) at least as abasis for the (probable) communication between the peopleinvolved.


activity A

activity B

activity C

time

Fig. 7. Sequential work process pattern.

activity A

activity B

activity C

activity A’

time

Fig. 8. Information retrieval and propagation in the work2ow.

A very similar pattern occurs if information is propagatedfrom some activity in the current project to another activityin a future project. This is illustrated by the dotted arrowlinking activity B and A′ in Fig. 8. This way, designexperience can be captured, preserved and reused to im-prove design quality. For example, if B refers to (an activityin) detail engineering, experience could be gathered andpropagated to (an activity in) basic engineering A′, or if Brefers to manufacturing and A to process and plant design(both on a coarse granularity level), operational experienceaccumulated by plant personnel can be systematically com-bined with “Crst-principles” design knowledge held by thedesigners to either drive retroCt design and debottleneckingof the process, or to improve design practice in general. Thispattern not only requires means to share product and workprocess data but also to interpret and abstract these datain the sense of knowledge elicitation and knowledge rep-resentation (Russell & Norvig, 1995) in order to use priorexperience eSciently at a later time in a related context.

4.1.2. Concurrent engineering work process patternFig. 9 illustrates the concurrent engineering work process

pattern. The sequential work process is reorganized in sucha way that the activities overlap in time. In this case, there isno complete set of documents available before the followingdownstream activity starts. In order to work on a task in adownstream activity B concurrently to the upstream activityA, results still to be produced in future tasks in activity A andonly available in the documentation at time tf;A need to bepredicted at time t0;B to set the constraints and objectives foractivity B. Hence, at any time before tf;A available resultsare passed as a set of incomplete documents together withpredicted results from the upstream to a downstream activity(cf. dashed arrows in Fig. 9 linking A and B and B and C,respectively). On the basis of this information, activity Bis processed independently of activity A. The informationpassed from A to B over time is used to reCne the objectivesand constraints for the future tasks within B and to assesswhether the tasks already solved comply with the reCned


activity A

activity C

time

activity B

t0,B tf,A

Fig. 9. Concurrent engineering work2ow pattern.

objectives and constraints. If not, part of the tasks need to bereiterated in B. Results of B or problems with the objectivesand constraints stemming from directions set by A are fedback from B to the still progressing activity A (cf. dottedarrows in Fig. 9).

The information exchange between the upstream anddownstream activities has to be carried out (largely asyn-chronously) according to either the directions of projectmanagement or to some unpredicted event occurring dur-ing the solution of some design problem. Although thisapproach looks—at least at a Crst glance—quite simpleand logical, many questions arise concerning its imple-mentation. For example, it is largely open on how to dothe predictions, how to identify as quickly as possibledeviations from the predictions, and how to evaluate theconsequences of these deviations. There have to be meansto handle unavoidable uncertainty systematically. Further,guidelines and information technology support are essentialto manage the complexity of a concurrent design process.

There are many promising areas where the concurrentengineering work process pattern could be applied at least toparts of design life cycle. On a coarse scale of granularity,examples include the integration of

• chemical product design and conceptual process design,• conceptual process design, operability analysis, and con-

trol system design,• conceptual design with front end engineering, or• equipment design, plant layout, and pipeline routing.

In addition to the integration across these largely adjacentphases of the design life cycle, the integration of more gen-eral design considerations like

• health, environment, and safety,• cost estimation and engineering economics, or• maintenance and asset management

have to be considered as activities which have to be contin-uously processed during the whole life cycle together withthe other life cycle activities mentioned above.

Obviously, these issues of concurrent engineering re-quire in the Crst place chemical engineering concepts andmethods to be accomplished. Many related results are avail-able in the literature. However, these techniques have tobe systematically integrated into the work processes, whichoften requires their reengineering. Information technology,targeting at the support of complex work processes, couldact as an additional enabler (cf. Section 4.4.3).

4.1.3. Integrated design problem formulation patternConcurrency can and should be addressed on the Cner

granularity level of the activities than the ones referred toin the last section. The simultaneous treatment of reaction,separation, and heat integration (Daichendt & Grossmann,1997) or the integration of conceptual design, control, andoperations (Perkins & Walsh, 1996; Biegler, Alkaya, &Anselmo, 2000; van Schijndel & Pistikopoulos, 2000) couldserve as examples. This observation leads to a last pattern ofwork2ow integration as shown in Fig. 10. Design tasks, tra-ditionally treated separately, are lumped into an integrateddesign problem formulation. Instead of executing the ac-tivities B and C sequentially, a new activity D is deCned,which attempts to achieve the objectives of activities B andC simultaneously.

This integration of problem formulations seems to be atbest supported by a rigorous optimization framework. Usu-ally, this approach results in a complex optimization problemwhich has to be solved approximately to obtain a solutionat reasonable computational cost. Often, the problem is for-mulated in a hierarchical fashion on various levels of detail(e.g. Daichendt & Grossmann, 1997). Then, the same prob-lem is solved repeatedly with an increasing level of detailincluded in the model constraining the optimization. This


activity C1

time

activity B1

activity D1

activity C2

activity B2

activity D2

Fig. 10. Integrated design problem formulation pattern.

procedure is illustrated in Fig. 10 with the activities B1, C1

forming an activity D1, which are reCned to activities B2,C2, and D2 processed subsequently.

The resulting optimization problems are large-scale andof mixed type and are therefore challenging to solve. Biegleret al. (2000) refer to two related and major issues, globaloptimization and model Cdelity. The need for global op-timization must receive more attention with integratedformulations due to the increasing likelihood of local(non-optimal) extrema. Realistic and hence fairly detailedmodels are required for reliable results, which also in-evitably increase numerical eEort. In addition, integrateddesign problems across the life cycle require consistencybetween the partial models on potentially diEerent scales(cf. Section 3.3).

4.1.4. Designing the life cycle work processThe considerations in the previous sections have identi-

Ced diEerent patterns in the life cycle work process. Im-plicitly, we have supported the claim of Subrahmanian etal. (1997) that the life cycle work process has to be de-signed in the sense of life cycle process reengineering, aspecial case of business process reengineering (Hammer &Champy, 1993). This strategy seems to be increasingly im-portant. Business processes and hence the design life cycleprocesses are not just a matter of enterprise culture but mayform a viable competitive advantage. They are largely deter-mining excellence in design (as well as in manufacturing),in particular if most operating companies are using the samesuite of software tools from the same vendors.

The design of the life cycle work process requires fur-ther empirical investigations (e.g. Finger et al., 1995; Sub-rahmanian et al., 1997; Foss et al., 1998) to acquire a deepunderstanding of industrial design practice. Until now the

correlation and dependencies between the diEerent activi-ties performed during process design are not suSciently un-derstood. This is even true for reasonably well investigatedinteractions such as those between process synthesis andanalysis. For example, there are no accepted guidelines toreCne mathematical models across the diEerent scales (cf.Section 2.1.1) on the basis of the results of analysis on onescale. Further, the identiCcation of a suitable temporal or-der of activities according to the preconditions of an activ-ity from a chemical engineering perspective is essential tomodel scheduling constraints, that are a prerequisite for de-signing the life cycle work processes.

Reengineering of current design processes will entail theneed for both,

• new methods to allow the integration of design activitiesin the early design phases, and

• integrated software tools with new functionality to bettersupport the work2ow.

In the subsequent sections, the focus will be on more tech-nical issues which have to be addressed to provide eEectiveinformation technology support for design processes.

4.2. Product data integration

Product data integration refers to the persistent storageof all major data that are collected and generated for docu-mentation and reuse during the design and development lifecycle, associated with the same or diEerent chemical prod-ucts and their manufacturing plants. Examples of data andtheir context include market surveys, properties of the chem-ical end product, performance speciCcations of the manu-facturing process, physical properties, all sorts of mathemat-ical models, logs of laboratory or pilot scale experiments,


simulation speciCcations, simulation results, equipment de-sign parameters, plant layout data, and cost estimates at var-ious levels of detail.

Data integration is a major research area in computer sci-ence (see e.g. Chap. 3 of Jarke, Lenzerini, Vassiliou, & Vas-siliadis, 2000, for an introduction). The discussion in relationto product data integration across the life cycle will heavilyrely on the concepts and techniques developed in that area.

4.2.1. The sources of product dataTraditionally, product data in chemical engineering

largely refer to the information managed in the late phasesof the life cycle, namely detail engineering and construction(Waligura & Motard, 1977), with emphasis on equipmentdata and plant layout. As indicated in Section 3.3, a broaderperspective is taken here. Hence, a larger variety of productdata types needs to be considered.

Typically, the product data are distributed in variousheterogeneous sources. The heterogeneity comes in threediEerent types. The data can be carried by diEerent physicalstorage media including paper or a variety of electronicmeans such as text Cles, dedicated databases (or databasemanagement systems, DBMS), document management sys-tems, the World Wide Web, or data Cles associated withspeciCc tools.

Regardless of the media, the data are represented in a spe-ciCc often proprietary and thus heterogeneous format withspeciCc syntax and semantics. The syntax largely refers tothe language used for representation whereas the seman-tics roughly refers to the concepts used to abstract real-ity. Let us look at a number of examples to clarify theseissues. A project report may be represented electronicallyin plain ASCII or PDF format without any speciCc con-cepts beyond a character. Alternatively, it may be repre-sented in XML (W3C, 1997), which provides a data deC-nition language to deCne common concepts in a documentsuch as abstract, section, table, or more speciCcally the el-ements of an equipment data sheet. Similarly, a 2owsheetor an engineering design drawing can be represented eitheras a pixel map or as a set of graphical icons character-ized by certain semantics. Other examples include physicalproperty data represented in databases by means of a rela-tional data model, mathematical models represented in a textCle employing the proprietary modeling language (deCn-ing syntax and semantics) of the process modeling environ-ment with which they have been generated, or equipmentdesign data stored in the proprietary database of a CADsystem.

4.2.2. Homogenization of product dataIntegration of product data requires some kind of homoge-

nization with respect to medium, syntax, and semantics. Wewill not discuss homogenization with respect to the mediumhere, as it is a largely technical issue. Subsequently, the fo-

cus is rather on homogenization with respect to syntax andsemantics of heterogeneous product data.

A classical approach to handle diEerent data sourcesis the deCnition of a unifying and complete informationmodel with particular syntax and semantics. CLiP (seeSection 3.3) forms an example of such an informationmodel. It can be deCned in a proprietary manner for prod-uct data integration as a basis for the implementation ofa life cycle product database after transformation into thedatabase schema. Given such a life cycle database, thedata stemming from diEerent data sources can be accessedand Cltered to select the information to be stored cen-trally. Then, the data is reconciled and transformed intothe database schema, before storing it in the life cycledatabase.

Obviously, the integration of product data will be facil-itated, if a (de jure or de facto) standard for a neutral—non-exclusive, non-proprietary, and vendor independent—information model is agreed upon and made publiclyavailable (Book et al., 1994). The owners of the life cycledatabase and the data sources only have to provide con-verters from the proprietary to the neutral data formats,which are then used for the actual exchange. Data sourcesand targets, which are to be integrated eventually, have notto be known a priori. Obviously, the translation steps willbecome super2uous, if the data source and the database usethe neutral format (Fielding et al., 1995).

Despite the tremendous eEorts spent in the various initia-tives (in particular STEP as discussed in Section 3.4), thestandard data models have not yet gained adequate accep-tance, neither in the chemical, engineering, or constructioncompanies, nor in the (process engineering) software indus-tries.

Obvious reasons could be the incomplete coverage, whichis always limited to parts of the life cycle, as well as thelack of coherence and consistency between the suggestedstandards stemming from (at least initially) independent ini-tiatives. Experience shows, that it seems hardly possible toagree on a life cycle product data model, not for technicalbut rather for organizational reasons. Even agreement on askeleton of a life cycle product data model on a coarse gran-ularity scale can be diScult to achieve because of the com-promise required to reconcile the objectives of the variousstakeholders.

Though standardized process and plant data models arenot yet widely used, most software vendors and also someof the operating companies have been adopting the mod-eling philosophy and part of the concept taxonomies, buthave made substantial changes and extensions to make thedata model Ct their particular needs. Our investigations haveshown that the most general concepts (e.g. meta classes andmajor classes in CLiP) are acceptable in most cases. How-ever, there is a lot of detail the users of such a model wantto be added according to their speciCc and well establishedconventions in order to facilitate a broad acceptance of sucha model in their companies.


4.2.3. Customization and extension of product datamodels

It is claimed that novel approaches to product data mod-eling need to be developed if the variety of activities duringthe life cycle shall ultimately be covered while at the sametime the diversity of proprietary business processes shall beretained. There is a need for domain speciCc informationmodeling environments. They should provide a set of con-cepts speciCc to the domain of chemical and process engi-neering, a library of partial information models to be useddirectly or in the sense of a template, and a platform for cus-tomizing and extending information models at reasonablecost on top of the generic concepts.

The situation seems to be analogous to equation-orientedmodeling of non-standard equipment by means of pro-cess modeling environments (Marquardt, 1996). Due tospeciCc and highly competitive manufacturing processes,simulation software users cannot only rely on commer-cially available mathematical models. Hence, they employmodeling environments which provide on top of a genericequation-oriented modeling language, a set of domain spe-ciCc concepts such as stream, unit, mass balance, etc., whichcan be reCned and extended to develop customized processmodels. This declarative representation is then compiledinto executable code or interpreted to enable the numericalcomputations.

An information modeling system in this spirit could bedeveloped on the basis of available computer-aided soft-ware engineering (CASE) tools which provide informationmodeling services as well as compilers to generate databaseschemata to be implemented in some database managementsystem.

Typically, a data model evolves over time and thereforerequires continuous maintenance. For example, new con-cepts may be emerging after the deCnition of the data model,diEerent abstractions of the real objects may become neces-sary, and alternative ways of organizing the database schemamay better match the nature of the most frequent databasetransactions. Such schema evolution (Date, 2000) refers tothe problem of adding or deleting a class, of reorganizing aclass tree, and of migrating instances between classes. Ob-viously, in case of complex data models as those consideredhere, only the developers may be in the position to man-ually carry out the database evolution tasks at best. Thereis a need for computer-based techniques which are able todeal with a complex schema such as that of the life cy-cle database. Baumeister (2001) evaluates diEerent meth-ods for modifying and reorganizing object-oriented datamodels.

4.2.4. Integration of product data modelsAs already mentioned, it seems to be impossible to agree

on a homogeneous data model for a complex domain suchas the life cycle. It is rather more realistic to independentlydevelop a number of dedicated data models of limited

complexity for parts of the life cycle. Most likely, diEerentteams comprising the experts for a certain set of tasks in thelife cycle will be involved: The resulting (partial) data mod-els (see also the discussion on CLiP in Section 3.3) have tobe integrated in order to account for the interdependenciesand the relationships between some of the concepts (Bayeret al., 2000). This diScult task may be alleviated if aninformation modeling framework exists. For example, astirred tank reactor may be represented in three (partial)data models which refer to a speciCcation of its func-tion (residence time, reactions, heat removal, etc.), to itsrealization (including the equipment design and construc-tion data), and to its behavior, represented by a math-ematical model. Obviously, data referring, for example,to the reactor volume are included in all three modelsin diEerent ways. These dependencies have to be madeexplicit in a global schema integrating the (partial) datamodels.

The general situation is more complicated, since theremay not only be redundancy between the individual mod-els. There may rather be some or even signiCcant overlapincluding a mismatch in the semantics which stems froma diEerent way of abstraction. This issue can be illustratedwith a simple example. A heat exchanger concept is avail-able in two partial models. A partial data model C refers tothe heat exchanger area in lumped form, whereas in anotherpartial data model D it is only available as number of tubesin a bundle and tube dimensions. Obviously, there is a se-mantic mismatch between the two heat exchanger conceptswhich has to be handled somehow.

Such situations occur very easily in those cases, where thedata models to be integrated are developed independently indiEerent phases of the life cycle. Typically, due to the (very)diEerent cultures and knowledge bases of the disciplinesinvolved across the life cycle, no shared meaning (Kondaet al., 1992) is established which could guide the abstrac-tion of real world objects into a data model. In those situ-ations, a large semantic gap is very likely to occur. In theexample above, the diEerence of the heat exchanger con-cept can easily be explained by the context the data modelhas been deCned for. Models C and D have been deCnedfor applications in conceptual and detailed process design,respectively.

Another area with lots of semantic mismatches arisesin mathematical modeling across the life cycle. The samepiece of equipment, say a chemical reactor with the verysame physico-chemical phenomena is modeled diEerently inthe various phases of the life cycle. For example, a coarsesteady-state model is required in the early phase of concep-tual design, a CFD model is necessary to analyze mixingat a later stage, a dynamic model is required for operabilityanalysis, a qualitative model is suScient for HAZOP anal-ysis, and a simpliCed steady-state model is appropriate forcampaign planning. These models are diEerent in variousways, for example, in the resolution in length, time, andchemical scales, in the level of mechanistic detail, in the


mathematical formalisms used and in the modeling languagethey are coded in (cf. Section 2.1.1). It has already beennoted that these mathematical models are considered partof the life cycle product data (provided they are coded ina declarative way independent of a solver used for their in-terpretation). Hence, the integration of these models is (atleast partly) a matter of product data integration.

The integration of diEerent (partial) data models into ahomogeneous global data model has been called (database)schema integration in the computer science literature. Ba-tini, Lenzerini, and Navathe (1986) provide an early reviewon this subject which introduces four major steps. The in-dividual data models have to be analyzed Crst to decideon an integration policy (preintegration). Next, the mod-els are compared to understand the correlation and detectpossible con2icts between concepts (comparison). Then,they have to be made compatible for integration (conform-ing). Finally the global data models have to be generated(merging=restructuring). These steps can hardly be carriedout manually in the case of large and complex data models.Rather, automation is required. There are a number of ap-proaches to support and at least partly automate these steps(see Chap. 3 of Jarke et al., 2000).

Very promising approaches may be built in the futureon a representation of diEerent data models in descriptionlogics. This knowledge representation formalism, devel-oped in the artiCcial intelligence community, is able tocapture entity-relationship as well as many variants ofobject-oriented data models (Calvanese, Lenzerini, & Nardi,1998). Hence, it is possible to translate data representedin diEerent partial data models into this representationformalism Crst, and then use the inference and reasoningcapabilities of description logics to reliably check the inter-dependencies of the classes belonging to diEerent schemata(Catarci & Lenzerini, 1993). However, at this point, thereseem to be no tools available which can be successfullyapplied to complex data models such as those occurring inthe process design life cycle. Such techniques seem to beindispensable to reconcile complex data models such as thevarious STEP=ISO models and to come up with a main-tainable global data model for the life cycle at reasonableeEort. Nevertheless, this technique is just an aid in solvingthe integration problem.

4.2.5. Product data and documentsSo far we have conCned the discussion to product data

which are typically handled by the software tools employedduring the life cycle. In addition, there are the documentswhich are typically used to assist communication and co-operation between team members (cf. Section 2.1). Thus,these documents are the central working units of the teammembers in the life cycle. The documents contain productdata in a speciCc format. They re2ect a certain context dur-ing the life cycle and can be interpreted as a situated viewon the product data or more precisely on a product data

conCguration. Hence, there is an intimate relation betweendocuments and product data.

Any data integration eEort has to account for these inter-dependencies by clarifying the relations between data anddocuments on a Cne granularity level. Only then, a seam-less integration of life cycle product databases and documentmanagement systems can be achieved, which is a necessity,for example, for a consistent update of the documents anda refreshment of the databases during change propagation.To our knowledge, the reconciliation of documents and datahas not yet been seriously addressed, neither in the engi-neering nor the computer science literature. The current sit-uation seems to largely re2ect the document-oriented andthe database-oriented approaches in computer science. Fu-ture work should aim at bridging the gap between these ap-proaches.

4.2.6. Product data and work processesWork process integration cannot only be achieved by shar-

ing the product data across the life cycle. Rather, we have togather knowledge on the work processes (together with therationale of the decision making processes) which have ledto the product data. Hence, the interactions between workprocesses and product data have to be well understood andformally represented, as a prerequisite for the design of in-tegrated tools to support cooperative work (Lee, Sause, &Hong, 1998; Marquardt & Nagl, 1998).

Admittedly, it is quite diScult to describe the linkage be-tween the work processes and the product data reasonably,because there is a principle redundancy between a data andprocess centered representation of the work process. Typi-cally, an activity corresponds to a set of product data. Forexample, consider the activity of simulating a chemical re-actor which requires a simulation model and produces sim-ulation results. The activity and the products have a closerelationship which needs to be treated properly in an inte-grated (work) product and process model. The great beneCtof having these diEerent perspectives is the chance of gain-ing new insights in the design process and the complemen-tary information.

It is not clear how the work process and product data inte-gration is most appropriately addressed in conceptual infor-mation modeling. At this point, we are preferring a balancedrepresentation of process and product in CLiP. Process andproduct model are quite separately developed and mutuallinks are inserted afterwards.

4.3. Knowledge management

It has been seen already in the two previous sections thatthe sharing of product data and the generation of work pro-cesses is not suScient to improve design excellence. Rather,an interpretation of the conglomerate of product data andwork processes is mandatory to capture the knowledge usedby the various stakeholders during the life cycle—the keyasset of an enterprise (Nonaka & Takeuchi, 1995).


Tool A data

Integrator A

Tool A

Integrator B

Tool B

Dedicated database

Integrator X. . . .

Tool A UI Tool B UI Data source UI

Life cycle database

Life cycle database UI

(partially integrated) user interfaces

Fig. 11. Data centered integration of tools.

Knowledge management has been given increasing atten-tion in recent years. It refers to managing and identifyingknowledge and knowledge needs (Quintas, Lefree, & Jones,1997). Wiig (1997) deCnes diEerent knowledge manage-ment strategies. Comparable to the deCnitions of diEerentlife cycles given in Section 2, they comprise strategies on theenterprise level, the individual level, and a tool-supportedlevel.

The term knowledge respectively knowledge manage-ment is diScult to deCne properly. From our point of view,it is more than just the pure combination of product data andwork processes in a formal manner. The persons (the know-ers) involved in the work2ow with their ability to interpretthe interactions between product data and work processeshave to be considered (Brown & Duguid, 2000). Thereforeknowledge management is diScult to achieve, if there is noculture of sharing knowledge because of missing incentives.Tacit knowledge needs to be converted into explicit orga-nizational knowledge (Liebowitz, 2001; Stenmark, 2001).Further, process design teams usually comprise highly qual-iCed and creative professionals who are not used to followsome speciCed=prescribed design processes, they feel them-selves to be artists.

The focus of knowledge management today is not on thedevelopment of sophisticated tool support but on the elici-tation of knowledge and creation of some awareness of theimportance of knowledge (Shin, Holden, & Schmidt, 2001).At this point, knowledge management is largely the domainof management and social sciences. The major challengefor the future is the link of these tremendous activities withan engineering tradition of broadening good practice in anultimately quantitative model-based manner.

4.4. Tool integration

Tool integration is a key topic in software and informationsystems engineering. Four well accepted dimensions of toolintegration may be distinguished (Wasserman, 1990):

• Data integration refers to the sharing of data and man-aging the relationships between them.

• The notiCcation of tools about certain events and the ac-tivation of tools to respond to some request for service iscalled control integration.

• Platform integration facilitates the execution of an in-tegrated set of tools on a heterogeneous and distributedcomputer network.

• Presentation integration aims at human-computer inter-faces of a set of integrated tools with a common look andfeel.

Despite their relevance, these classical integration dimen-sions are not suScient for the integration of tools in thedesign life cycle (Marquardt & Nagl, 1998). Many otheraspects of integration could be considered in addition (Bell& Sharon, 1995). The most important Cfth integration di-mension is (work) process integration which refers to allaspects related to the work2ow perspective of the life cycle(Nagl & Westfechtel, 1994).

These diEerent integration dimensions will be used tostructure our discussion of tool integration. A data centeredapproach to the integration of design environments fromexisting tools will be treated Crst. Then, recent developmentsof control and platform integration and their implications onthe design life cycle will be reviewed next. Work process


integration and related issues from presentation integrationwill be discussed in the last subsection.

4.4.1. Product data centered integration of toolsA classical product data centered approach to tool inte-

gration is shown in Fig. 11. The life cycle database is thecenterpiece of the integrated design environment. The var-ious tools are interfaced by means of dedicated convertersor integrators (e.g. SchefstrPom & van den Broek, 1994).Bi-directional data exchange between tools and the databaseand hence implicitly between tools can be implemented thisway. All the data are materialized in the life cycle database.They are duplicated in those cases where the tools providea persistent storage mechanism themselves. This material-ized data integration assumes the availability of a coherentglobal database schema which fully covers the domain ofinterest (cf. Sections 4.2.2 and 4.2.4).

The life cycle database will typically not only be popu-lated by importing data instances from the data sources asso-ciated with the integrated tools. Rather, those data collectedor generated during life cycle activities that are not accessi-ble electronically have to be entered manually by means ofsuitable user interfaces. This functionality is provided by adedicated interface of the life cycle database.

A data centered approach to tool integration has beenadopted in chemical and process engineering in the early1980s. Prominent examples are the PEDB system of ICI(Cherry, Grogan, Knapp, & Perris, 1982), the VTPLANsystem of Bayer (Nagel, 1981), or thePRODABAS andDe-signMASTER process databases (Angus & Winter, 1985;Craft, 1985). These information systems have been built tocollect and store persistently the data in a part of the lifecycle, namely the phases of conceptual process design andfront end engineering, and to exchange data between diEer-ent tools. Elementary services for version and conCgurationmanagement as well as for long transactions were provided(Kemper & Moerkotte, 1994).

Though these domain speciCc systems are not in use anymore today, the concept of data centered tool integrationstill forms the backbone of today’s process and chemicalengineering design environments. Life cycle databases in-clude for example Flour Daniel’s MasterPlant, Intergraph’sSmartPlant P&ID, Bayer’s PDW, Akzo’s FET, AspenTech’sZyqad, or Innotec’s Comos PT. These systems do not coverthe whole life cycle but focus on either conceptual designand front end engineering (e.g. Zycad or PDW) or basic anddetail engineering (e.g. MasterPlant or Comos PT).

The integration of an already existing tool into the de-sign environment is possible in principle, if the data canbe accessed from the data source associated with a tool bysome reasonably documented interface, if the syntax and se-mantics of the proprietary data format of the tool is knownand if there is no (signiCcant) mismatch between the se-mantics of the life cycle concepts deCned in the applicationand the life cycle database. As already indicated by meansof the heat exchanger example in Section 4.2.4, there may

be non-unique (m : n)-relationships (n �=m; n¿ 1; m¿ 1)between the data objects which cannot be resolved easily.

Straightforward conversion from some tool data formatto the life cycle database schema is hence restricted. A moresophisticated concept is required instead in order to copewith general (m : n) relationships between the concepts andtheir attributes in the source and in the target data model.In the heat exchanger example given above, the informationon the tube bundle must be converted to the lumped heatexchanger area by associating this relation with a methodto compute the heat exchanger area. If we want to ex-port a heat exchanger area into a tool which only knowsabout tube bundles, we are not even able to provide such amethod, since there is non-uniqueness which cannot be re-solved without additional context knowledge and human in-teraction. Hence, sophisticated concepts are required whichcover the whole range from fully automatic to fully manualbut computer-assisted conversion (Gruner, Nagl, & SchPurr,1997). Advanced integrators have been reported for exam-ple by Nagl (1996) and Zhou, Hull, and King (1996).

A fundamental disadvantage of the architecture presentedand currently implemented in all chemical engineering de-sign environments is the required homogenization of the databy means of one global schema and their materialization ina single central database. These requirements can be relaxedby introducing a meta data repository as the centerpiece ofan integrated design environment as depicted in Fig. 12.

The repository in this architecture is a database whichincludes a description of the data objects (meta data) usedin the design life cycle and in particular those stored ina variety of storage systems typically associated with theintegrated design tools (Bernstein & Dayal, 1994). Therepository manager provides the services to deCne andmaintain the conceptual model and to retrieve and managethe data objects provided and employed by the tools of theenvironment. The functionality of the repository managershould not only include check-in and check-out of data ob-jects to implement data sharing between tools. Accordingto Bernstein and Dayal (1994) the manager should providein addition version and conCguration control to manage thehistory of data objects and their binding to some compos-ite objects, notiCcation services to trigger an activity aftercreation or modiCcation of a data object, and even work-2ow control. Obviously, this functionality goes beyonddata integration. NotiCcation services and work2ow controlare clearly functions related to (work) process centeredintegration architectures (see Section 4.4.3).

This repository based architecture requires a global ho-mogeneous data model only on the conceptual level (cf.CLiP in Section 3.3, or Cui, Tamma, & Bellifemine, 1999).It does not materialize the data in a central database andhence avoids the problem of integrity maintenance betweenthe data in the tools and in the life cycle database. Rather, avirtual integration of the data is attempted, which allows aglobal and unifying access to data without interfering withthe autonomy of the data sources in the tools.


Tool A

Flowsheet Editor

(Meta Data)Repository

Repository Manager

user interfaces

Tool B Tool X. . . .

Data integration: wrapping and mediation

FlowsheetDatabase

MathematicalModelsStorage

PhysicalPropertiesDatabase

Fig. 12. Data centered tool integration using a meta data repository.

Further, the conceptual model facilitates the implemen-tation of integrators which are concatenated in Fig. 12 inthe data integration layer. It consists of wrappers to accessthe data in the linked data sources and in the tools and ofmediation services (Wiederhold & Genesereth, 1997).

The idea of a repository based architecture for tool inte-gration has recently been adopted to persistently store andmanage mathematical models during the design life cycle.ROME (von Wedel & Marquardt, 2000b) manages modelsfrom various sources in various declarative and proceduralrepresentations including a (neutral) symbolic format, pro-prietary symbolic formats employed in speciCc simulators,and executable software components with standardized in-terfaces. High level check-in and check-out mechanisms toautomatically translate between the diEerent representationsare currently studied. Reuse and retrieval is supported bya high level documentation service. In addition, symbolicmodels are materialized in an equation-oriented schema inthe database.

So far, discussion has only been on the integration of thedata sources at the technical level. The integrated informa-tion has to be retrieved by a designer in some aggregatedmanner which is determined by the context of a life cycleactivity and may not be restricted by the set of contexts pro-vided by the integrated tools. For example, the user interfaceof a process simulator allows access to the lumped area ofa heat exchanger but not to the detailed geometric dimen-sions, accessible via the user interface of a heat exchangerdesign tool. A user may want to access both pieces of infor-mation at the same time without the restrictions imposed bythe integrated tools. In order to solve this problem, a single2owsheet-oriented user interface should be provided as partof the design environment (Bayer, Weidenhaupt, Jarke, &Marquardt, 2001b) instead of using the native tool interfaces(see the 2owsheet editor in Fig. 12). Aggregated views onthe information in the life cycle database have to be deCnedto access a certain set of data. Such views are conCgurations

of data needed to execute a speciCed life cycle activity andare therefore closely connected to the work processes.

4.4.2. Control centered integration of toolsAll the integration approaches discussed in the last section

assume the availability of a global data model at least on theconceptual level. Though these solutions are elegant, there issome doubt with respect to scalability given the tremendouscomplexity of the design life cycle.

Alternatively, one may strive for cooperating tools em-phasizing control rather than data integration in the sensediscussed in the last section. The basic idea here is to makethe tools communicate by exchanging messages to either in-form each other about their status or current actions or torespond to a request for service issued by some other tool(Brown, 1993). In this case, there is no common view (nei-ther material nor virtual) on the data handled in the life cy-cle. Rather, all the data are kept locally in the tools. Datasharing is accomplished either by means of a neutral andeventually standardized exchange format or by integratorsbetween tools (cf. Fig. 13) rather than between tools and alife cycle database (cf. Figs. 11, 12). This again comprisesa wrapper and a mediator which is responsible for the ho-mogenization and integration of the data.

In principle, such an architecture does not prevent anytool to interoperate with any other tool. However, as in thecase of the data centered architectures presented above, somekind of reference architecture or a framework (Buschmann,Meunier, Rohnert, Sommerlad, & Stal, 1996) needs to bedeCned which—at least on a coarse level—Cxes the type ofcomponents (with a speciCed functionality) and their rela-tions in order to realize the desired functionality of an inte-grated environment.

Interoperability between the individual tools requiressome agreement on the protocol for data transfer and onthe syntax and semantics of the messages. There are var-ious message passing protocols which are widely used in


Tool A

user interfaces

Tool X

Tool B

Informationin

neutralformat

ABIntegrator

Informationin

format A

Informationin

format B

Fig. 13. Control centered integration of tools.

parallel and distributed computing (e.g. PVM or MPI,Dowd, 1993). More versatile implementations are howeverprovided by recent component software and middlewaretechnologies such as CORBA, COM=DCOM, or Jav-aBeans (Krieger & Adler, 1998). A software componentis a piece of executable code which is encapsulated by oneor more public interfaces. Every component can expose itsdata or it can provide some service through the enforcementof its methods via the interface by means of a Cxed protocol.Hence, components allow for control as well as data integra-tion. The functionality of a component is deCned implicitlythrough its interface and in particular through the methodsassociated with it. The middleware platforms provide stan-dard mechanisms of interaction between software compo-nents regardless of the computer language in which they areimplemented, the type of machine in a computer network,or the operating system used. Hence, component and mid-dleware technology provide the technical means of buildingintegrated environments from already existing tools.

A prerequisite for interoperability is an agreement onthe interface deCnitions of all the software components in-volved comprising the commands and the data to be passedbetween all the components of the design environment.This is again a problem on the scale of the whole life cyclewith the problems already discussed. Instead, it is desirableto restrict the integration task to the context given by thetwo tools to be integrated. Syntactic and semantic mis-matches between the data and the commands used in bothtools have to be handled by sophisticated integrators whichconsist of a wrapper to access data and commands in thetools and a mediator which resolves possible con2icts asalready discussed in Section 4.4.1.

There seems to be very little experience with such aconcept in the area of (chemical) engineering design en-vironments. Related objectives have been pursued in theCAPE-OPEN and Global CAPE-OPEN (GCO) projects(Braunschweig et al., 2000). The major objective of theprojects is to open up chemical process simulators by acomponent software approach. Standard interfaces usingCORBA as well as COM=DCOM have been deCned forthe major functional modules of a simulator such as theunits, a set of equations, the numerical solvers, or the phys-ical property models and data. Any implementation of sucha module, compliant with the standard, can be plugged intoa simulator executive oEering an appropriate socket. Thereference architecture is deCned implicitly in this case bythe established architecture of process simulators. The GCOtechnology will hopefully lead to a market for componentsoE the shelf provided by niche suppliers.

Obviously, this idea can be carried on in principle tothe next level of granularity, namely to the interaction be-tween diEerent highly specialized simulators at runtime. Forexample, the various units of a polymerization process(interconnected by a recycle) may be modeled by means ofdedicated simulators including commercial sequential-modular, equation-oriented as well as in-house simula-tors. CHEOPS, a component-based simulation frameworkcurrently under development in our group (von Wedel& Marquardt, 2000a), provides the functionality for theintegration of the diEerent simulators at runtime.

The CHEOPS technology contributes to integratedprocess modeling in the life cycle (Hackenberg, Krobb,Schopfer, von Wedel, Wyes, & Marquardt, 2000; Marquardtet al., 2000), but does not address design tool integration


in general. However, the fundamental principles are alsoapplicable to a design environment consisting of a set ofintegrated tools, including process simulators or even aheterogeneous simulation framework such as CHEOPS.Ongoing research addresses this issue in the GCO project(Braunschweig et al., 2000).

The control 2ow in a control integrated design environ-ment is implicitly given by the way the components aredeCned and the way the users can interact with the tools.The components themselves do not have an autonomousbehavior, which may be preferable to support uncertainand ill-deCned domains such as design. Various researchgroups have adopted agent technology (Hayes, 1999) toexplore the design and implementation of collaborativechemical engineering design environments (e.g. Han, Dou-glas, & Stephanopoulos, 1995; Struthers & Curwen, 1998;Batres, Asprey, Fuchino, & Naka, 1999; Tyner & West-erberg, 2001). In contrast to the software componentsdiscussed so far, software agents are able to act (at least inpart) autonomously and to make decisions on their own.Though this is a promising line of research, much work stillneeds to be done.

4.4.3. Work process centered integration of toolsWork process centered tool integration covers the aspects

of supporting the activities of a single designer, the collab-oration in a team, and the coordination of activities, actors,and resources on a project level.

Current and, even more, novel types of work processes(cf. Section 4.1) require novel tool support. Nowadays tools,which are supporting work processes, are mainly work2owmanagement systems or document management systems in-cluding a work2ow component. This is due to the fact thatthe work2ow is organized in a document-oriented manner(cf. Section 2.1). The tools used by engineers during pro-cess design are not integrated in these systems.

Work process centered tool integration has to comprisemore than a data centered integration of single tools (Mar-quardt & Nagl, 1998; Nagl & Marquardt, 2001). Tools haveto be guided and controlled in a design environment and theirfunctionality has to be extended. Furthermore, new methodsand tools have to be developed to support the work processeSciently. The governing paradigm should be the following:

Tools have to be adjusted to the work processes and notvice versa.

In order to achieve this objective, industrial work processeshave to be analyzed (e.g. using a formalism such as C3)to identify the requirements of tool support (e.g. Fingeret al., 1995). As a result of such an analysis, e.g. Bayer et al.(2001b) identiCed the central role of 2owsheets in the de-sign process. In contrast to this result, nowadays 2owsheetinformation is not stored and handled in a single tool, but indiEerent ones (e.g. spreadsheet programs, steady state anddynamic simulators, or modeling tools). As a consequence,

Bayer et al. (2001b) recommend that a single and versatile2owsheet tool should be part of a coherent design environ-ment to deCne and retrieve 2owsheets of all kinds and onall levels of details. No other 2owsheet functionality shouldbe provided by any other tool. This way, the 2owsheet canbe used as a central portal to the product data for the designteam throughout the life cycle.

Another example demonstrating the need of tools withnew functionality is the development of mathematical mod-els. The eEort of developing sophisticated mathematicalmodels is enormous. The developer needs support in thedocumentation of the model assumptions, guidance throughthe model development, and support of model reCnementand reuse (see Bogusch et al., 2001, for a detailed de-scription). These are all requirements, which are drivenby a work process perspective. The modeling environmentMODKIT (Bogusch et al., 2001) supports tasks like thegraphical deCnition of the structure, the behavioral descrip-tion, and the documentation of a process model in a workprocess oriented manner. Within MODKIT, code for dif-ferent simulators can be generated, leading to a modelingprocess which is independent from a speciCc simulator.

Besides the development of new tools, existing toolscan be process integrated (Pohl, Weidenhaupt, DPomges,Haumer, Jarke, & Klamma, 1999). Thereby new function-ality is added to guide and advise the designer during theuse of a tool. Depending on the actual context, a work2owcomponent can restrict the possible actions of a tool orsuggest possible next steps in the sense of a best-practiceapproach. A prerequisite for this kind of support is the elic-itation and formalization of the knowledge needed, whichcan only be gained from empirical studies (see Section 4.1).Some observations can be made automatically by tracingthe activities during design. Current research (DPomges &Pohl, 1998) aims at discovering successful work processesfor certain activities of limited complexity and to oEerthose subsequently to the user as work process supportby the work2ow component, an ambitious but obviouslyrewarding attempt.

An important part of knowledge which needs to be rep-resented are the decisions made during a design process.IBIS, the Issue- Based Information System (Kunz & Rittel,1970; Conklin & Begeman, 1988) provides a simple andformal way of doing so. By means of diEerent concepts(issue, argument, position), the design rationale can be cap-tured and presented. This approach has been adopted andextended in the KBDS system (Banares-AlcQantara, 1995;Banares-AlcQantara & Lababidi, 1995) to provide sometracing and guidance during the design process (see alsoDRAMA, (Brice & Johns, 1998), a commercial version ofKBDS).

Groupware tools support the collaboration in a geograph-ically distributed team. Many products featuring diEerentaspects of collaboration are available (e.g. video confer-ence, application sharing, communityware). However, theyare hardly used in chemical engineering. This may be due


to the fact that these tools are still too complex to han-dle and that the communication bandwidth provided on theintra=internet is still too low. But this is simply a technicalissue, which will change within the next few years. Pro-cess design in chemical engineering is characterized by a lotof diEerent working documents (2owsheets, tables, simula-tion results, etc.), which form the basis of the discussionsbetween diEerent developers. All these documents have tobe accessible and modiCable during multimedia commu-nication. Annotations and documentation of the discussionhave to be enabled, which is not possible with existingsoftware.

The coordination of a set of related projects requires thecoordinated management of the highly interrelated work pro-cesses, product data, and resources (Westfechtel, 1999; Naglet al., 2002). A management system has to cope with thedynamic characteristics of a design process, like the struc-tural change of the work2ow due to results of already ex-ecuted activities, leading to unforeseen activities and extraresources needed. Furthermore, the designers have to be co-ordinated and the work of the individual designer has to beintegrated with the management of the whole design process.

The illustrating examples show that research in the area ofwork process centered tool support in chemical engineeringis a challenging task which is still at the beginning. Unfor-tunately, it does not attract many academic groups. The col-laborative research center IMPROVE (Sonderforschungs-bereich 476) at RWTH Aachen seems to be a unique inter-disciplinary collaboration eEort in the area of informationtechnology to support the chemical process and plant de-sign process. IMPROVE is a research center, funded by theGerman Research Foundation DFG (Deutsche Forschungs-gemeinschaft) with a focus on research and development inthe area of information technology support for collaborativeand geographically as well as organizationally distributedteams designing chemical processes. The research partner-ship consists of three computer science and three chemicalprocess and mechanical engineering groups involving morethan 20 researchers. The major objectives are the capturingand reengineering of the design process across the life cyclelargely with a focus on the conceptual and front end engi-neering activities, on the development of a life cycle processmodel, and on work process centered integration of existingengineering tools by means of advanced computer sciencemethods and tools. For more information we refer to Nagland Westfechtel (1999) or Nagl and Marquardt (2001).

5. Summary and recommendations

This article takes a rather unusual perspective on thechemical engineering design process. It emphasizes the in-creasing relevance of the design and manufacturing workprocesses to complement the traditional, purely engineeringperspective dominated by the product of the work process.If this new vista is accepted, hopefully only after serious de-

bate and discussion, chemical engineering has to acknowl-edge the existence of an additional interface—informationtechnology—which has to be accounted for in industrialpractice, in education, and in research.

5.1. Consequences for industrial practice

It has been argued in this article that a work process cen-tered view of the (chemical process design) life cycle issteadily gaining momentum in the chemical and process in-dustries. Numerous discussions with industrial colleaguesabout the evolution of the practiced business processes sup-ports the need for a more systematic consideration and docu-mentation of good practice in particular in process and plantdesign. Integration across the life cycle has to become astrategic goal of an enterprise. Actual work processes haveto be elicited and assessed systematically. They have to bereorganized and changed at least in part to enable knowl-edge sharing and to foster proper documentation of previ-ous experience. Work process analysis and reengineeringbecome also increasingly relevant because of the continu-ous restructuring of corporations through mergers and ac-quisitions. These structural changes result in the need forintegrating diEerent methods and tools. Further, process in-dustries have to cope with geographically and institutionallydistributed design teams.

Information technology standards will gain increasing at-tention. The standardization process is tedious for technical,organizational and also economical reasons. The operatingcompanies have to drive that process because it is primarilyin their interest and to a lesser extent in the interest of soft-ware vendors. Non-proCt institutions need to be formed,which manage and facilitate the standardization process,maintain existing standards, support software developers inimplementing and testing the standards and Cnally certifycompliance of software with the standard. An example ofsuch an organization is the CO-LaN which has been formedrecently to continue the eEorts of GCO (Braunschweiget al., 2000; CO-LaN, 2001).

All the major vendors promote life cycle approaches.However, in many cases, driven by the business needs, theypursue a rather pragmatic approach to solve the life cycleintegration problem. Close collaboration with the end usersfor eliciting requirements and with the academics to broadenthe technology base seems to be indispensable (Marquardtet al., 2000).

5.2. Consequences for education

Obviously, the interface between chemical engineeringand information technology has to be properly re2ected ineducation. At the moment, there are very few well-trainedpeople who can actively participate in the development ofmethods and software tools for supporting design processes.These people are not only required by software vendors but


also by operating companies to introduce and to adapt thetools to the speciCc needs.

Current curriculae are not suSciently targeted, neitherin chemical engineering nor in computer science. Chemicalengineers are not suSciently trained in software engineer-ing and computational techniques, and computer sciencegraduates do not know enough about engineering appli-cation domains (Parnas, 1999). Academic education hasto quickly adjust to the new situation. New study pro-grams have to be established which Cll the gap betweentraditional disciplines. For example, a program should pro-duce a graduate with chemical engineering thinking butwith signiCcant emphasis on operations research, softwareengineering, computational methods, and mathematicalmodeling of process systems. Alternatively, mathematicsor computer science programs should be opening up intoapplications and oEer amongst others chemical engineeringmajors.

Such interdisciplinary curriculae are becoming more andmore popular. There is already a large number of related de-gree programs in the area of computational engineering andscientiCc computing (Gallopoulos & Sameh, 1997; SIAMWorking Group on CSE Education, 2001). Most of them puta strong emphasis on numerical and computational methodswith some applications in the natural sciences but are notsuSciently targeting at engineering (e.g. Yasar, Rajasethu-pathy, Tuzun, McCoy, & Harkin, 2000). The same is truefor the emerging software engineering curriculae (Parnas,1999). True engineering proCles are needed in the future tosatisfy the needs of information technology support in thechemical and process industries. One way to achieve this ob-jective is probably a combined degree program like the oneat the University of Melbourne (Shallcross & Wood, 2001),which combines chemical engineering with either science,arts, law, or commerce.

5.3. Consequences for research

A number of research challenges have been formulatedin the course of this article which will not be repeated here.We want to emphasize however the increasing importanceof the business processes, in addition to the engineeringmethods and tools traditionally in the focus of chemicalengineering research. These methods and tools have to beapplied in a synergistic manner in order to fully exploit theirpotential.

For some time, it has been apparent that industry isquickly moving towards a widespread strategic use ofinformation technology to better perform their businessprocesses in research and development, in process designas well as in procurement, manufacturing, and distribution.The vendor companies are moving quickly to explore thisbusiness opportunity and to serve the needs of their cus-tomers. Many of the solutions are pragmatic and, at leastto some extent, lack a solid scientiCc basis. This is largely

due to the fact that there is very little research activity atthe interface between chemical engineering and computerscience. There are great opportunities in interdisciplinaryresearch teams, combining solid knowledge and experiencein both, the computer science and the chemical engineeringdisciplines.

Acknowledgements

This work has been supported in part by DFG (DeutscheForschungsgemeinschaft) in the collaborative research cen-ter IMPROVE (CRC 476) and by the European Union inthe project Global CAPE-OPEN. The authors thank theircolleagues of CRC 476, and in particular B. Bayer, M. Eg-gersmann, C. Foltz, M. Jarke, C. Krobb, M. Nagl, L. vonWedel, and A. Yang for many fruitful discussions.

References

Abdalla, H. (1999). Concurrent engineering for global manufacturing.International Journal of Production Economics, 60–61, 251–260.

American Chemical Society 1996, American Institute of ChemicalEngineers, Chemical Manufacturers Association, Council for ChemicalResearch, & Synthetic Organic Chemical Manufacturers Association.Technology vision 2020: The US chemical industry. Available onlineat http://www.ccrhq.org/vision/ (Accessed 10 April 2001).

American Institute of Chemical Engineers (1998). Project managementfor the process industries. AIChE Publication No. U-45.

Angus, C., & Winter, P. (1985). An engineering database for processdesign. IChemE Symposium Series, 92, 593–605.

Aris, R. (1991). Manners makyth modellers. Transactions of theInstitution of Chemical Engineers, Part A, 69, 165–174.

Badham, R., Couchman, P., & Zanko, M. (2000). Implementingconcurrent engineering. Human Factors and Ergonomics inManufacturing, 10, 237–249.

Banares-AlcQantara, R. (1995). Design support systems for processengineering. I. Requirements and proposed solutions for a designprocess representation. Computers & Chemical Engineering, 19, 267–277.

Banares-AlcQantara, R., & Lababidi, H. (1995). Design support systems forprocess engineering. II. KBDS: An experimental prototype. Computers& Chemical Engineering, 19, 279–301.

Basu, P., Mack, R., & Vinson, J. (1999). Consider a new approach topharmaceutical process development. Chemical Engineering Progress,95, 82–90.

Batini, C., Lenzerini, M., & Navathe, S. (1986). A comparative analysisof methodologies for database schema integration. ACM ComputingSurveys, 18, 323–364.

Batres, R., Asprey, S., Fuchino, T., & Naka, Y. (1999). AKQML multi-agent environment for concurrent process engineering.Computers & Chemical Engineering, 23(Suppl.), S653–S656.

Batres, R., & Naka, Y. (2000). Process plant ontologies based on amulti-dimensional framework. In M. Malone, J. Trainham, & B.Carnahan (Eds.), Fifth international conference on foundations ofcomputer-aided process design. AIChE Symposium Series No. 323,96, 433–437.

Baumeister, M. (2001). Ein Objektmodell zur Reprasentationund Wiederverwendung verfahrenstechnischer Proze�modelle. Ph.D.Thesis, RWTH Aachen.

Bayer, B., Krobb, C., & Marquardt, W. (2001a). A data model fordesign data in chemical engineering. Technical Report LPT-2001-15,Lehrstuhl fPur Prozesstechnik, RWTH Aachen. Available online at

http://www.ccrhq.org/vision/


http://www.lfpt.rwth-aachen.de/Publication/Techreport/2001/LPT-2001-15.html (Accessed 10 December 2001).

Bayer, B., Schneider, R., & Marquardt, W. (2000). Integration of datamodels for process design—Crst steps and experiences. Computers &Chemical Engineering, 24, 599–605.

Bayer, B., Weidenhaupt, K., Jarke, M., & Marquardt, W. (2001b). A2owsheet-centered architecture for conceptual design. In R. Gani, &S. JHrgensen (Eds.), European symposium on computer aided processengineering—11 (pp. 345–350) Amsterdam: Elsevier.

Bell, R., & Sharon, D. (1995). Tools to engineer new technologies intoapplications. IEEE Software, 12, 11–16.

Bernstein, P., & Dayal, U. (1994). An overview of repository technology.In J. B. Bocca, M. Jarke, & C. Zaniolo (Eds.), VLDB 94, Proceedingsof 20th International conference on very large data bases, September12–15, 1994, Santiago de Chile, Chile (pp. 705–713).

Biegler, L., Alkaya, D., & Anselmo, K. (2000). Multi-solver modelingfor process simulation and optimization. In M. Malone, J. Trainham,& B. Carnahan (Eds.), Fifth international conference on foundationsof computer-aided process design. AIChE Symposium Series No. 323,96, 125–137.

Bieszczad, J., Koulouris, A., & Stephanopoulos, G. (2000). Model.la: Aphenomena-based modeling environment for computer-aided processdesign. In M. Malone, J. Trainham, & B. Carnahan (Eds.),Fifthinternational conference on foundations of computer-aidedprocess design. AIChE Symposium Series No. 323, 96, 438–441.

Bogusch, R., Lohmann, B., & Marquardt, W. (2001). Computer-aidedprocess modeling with MODKIT. Computers & ChemicalEngineering, 25, 963–995.

Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The uni=ed modelinglanguage user guide. Reading: Addison Wesley.

Book, N., Sitton, O., Motard, R., Blaha, M., Maia-Goldstein, B., Hedrick,J., & Fielding, J. (1994). The road to a common byte. ChemicalEngineering, 101, 98–111.

Braunschweig, B., Pantelides, C., Britt, H., & Sama, S. (2000). Processmodeling: The promise of open software architectures. ChemicalEngineering Progress, 96, 65–76.

Brice, A., & Johns, B. (1998). Improving process design by improvingthe design process: A DRAMA white paper. QSL-9002A-WP-001,QuantiCcation Science.

Brown, A. (1993). Control integration through message-passing in asoftware development environment. Software Engineering Journal, 8,121–131.

Brown, J., & Duguid, P. (2000). The social life of information. Boston:Harvard Business School Press.

Burkett, W., & Yang, Y. (1995). The step integration informationarchitecture. Engineering with Computers, 11, 136–144.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., & Stal, M.(1996). A system of patterns. Chichester: Wiley.

Calvanese, D., Lenzerini, M., & Nardi, D. (1998). Description logicsfor conceptual data modeling. In J. Chomicki, & G. Saake (Eds.),Logics for databases and information systems (pp. 229–264). Boston:Kluwer Academic Press.

Catarci, T., & Lenzerini, M. (1993). Representing and using interschemaknowledge in cooperative information systems. Journal of Intelligentand Cooperative Information Systems, 2, 375–398.

Chandrasekaran, B., Josephson, J., & Benjamins, V. (1999). What areontologies, and why do we need them? IEEE Intelligent Systems,14, 20–26.

Cherry, D., Grogan, J., Knapp, G., & Perris, F. (1982). Use of data basesin engineering design. Chemical Engineering Progress, 78, 59–67.

Cleetus, K. (1992). De=nition of concurrent engineering. Techni-cal Report, CERC-TR-RN-92-003, Concurrent EngineeringResearch Center, West Virginia University. Available online athttp://www.cerc.wvu.edu/CERC-TR-INDEX.htm (Accessed 7 January2002).

CO-LaN, (2001). The CAPE-OPEN laboratories network. Availableonline at http://www.colan.org/ (Accessed 17 December 2001).

Conklin, J., & Begeman, M. (1988). gIBIS : A hypertext toolfor exploratory policy discussion. ACM Transactions on OJceInformation Systems, 6, 303–331.

Cooke, N. (1994). Varieties of knowledge elicitation techniques.International Journal of Human-Computer Studies, 41, 801–849.

Craft, J. (1985). The impact of CAD and database techniques in processengineering. IChemE Symposium Series, 92, 565–579.

Cui, Z., Tamma, V., & Bellifemine, F. (1999). Ontology management inenterprises. BT Technology Journal, 17, 98–107.

Daichendt, M., & Grossmann, I. (1997). Integration of hierarchicaldecomposition and mathematical programming for the synthesis ofprocess 2owsheets. Computers & Chemical Engineering, 22, 147–175.

Dardenne, A., van Lamsweerde, A., & Fickas, S. (1993). Goal-directedrequirements acquisition. Science of Computer Programming, 20,3–50.

Date, C. (2000). An introduction to database systems. Reading: AddisonWesley.

DPomges, R., & Pohl, K. (1998). Adapting traceability environments toproject-speciCc needs. Communications of the ACM, 41, 54–62.

Dowd, K. (1993). High performance computing. Sebastopol: O’Reilly &Associates.

Eggersmann, M., Krobb, C., & Marquardt, W. (2000). A modelinglanguage for design processes in chemical engineering. In A. Laender,S.Liddle, & V. Storey (Eds.), Conceptual modeling—ER 2000. LecturesNotes in Computer Science, Vol. 1920 (pp. 369–382). Berlin: Springer.

Eggersmann, M., Henning, G., Krobb, C., Leone, H., & Marquardt,W. (2001a). Modeling and understanding process design activities.In Proceedings of ENPROMER, 3rd Mercosur Congress onProcess Systems Engineering, 1st Mercosur Congress on ChemicalEngineering Vol. I (pp. 151–156). Santa Fe, Argentina.

Eggersmann, M., Henning, G., Krobb, C., & Leone, H. (2001b). Modelingof actors within a chemical engineering work process model. InProceedings of the international CIRP design seminar, Stockholm,Sweden (pp. 203–208).

Ellis, C., Gibbs, S., & Rein, G. (1991). Groupware—some issues andexperiences. Communications of the ACM, 34, 39–58.

Estublier, J., Dami, S., & Amiour, M. (1997). High level process modelingfor SCM systems. In R. Conradi (Ed.), Software Con=gurationManagement. Lectures Notes in Computer Science, Vol. 1235 (pp.81–97). Berlin: Springer.

Fielding, J., Book, N., Sitton, O., Blaha, M., Maia-Goldstein, B., Hedrick,J., & Motard, R. (1995). Methodology for data modeling for the processindustries. In L. Biegler, & M. Doherty (Eds.), Fourth internationalconference on foundations of computer-aided process design, AIChESymposium Series 304, 91, 352–355.

Finger, S., Konda, S., & Subrahmanian, E. (1995). Concurrent designhappens at the interfaces. Arti=cial Intelligence for EngineeringDesign, Analysis and Manufacturing, 9, 89–99.

Finkelstein, A., Kramer, J., & Neuseibeh, B. (Eds.) (1994). Softwareprocess modelling and technology. New York: Wiley.

Foltz, C., Killich, S., & Wolf, M. (2000a). K3 user guide. Available on-line at http://www.iaw.rwth-aachen.de/produkte/k3/downloads.html(Accessed 6 December 2000).

Foltz, C., Wolf, M., Luczak, H., Eggersmann, M., Schneider, R., &Marquardt, W. (2000b). Entwurf eines Referenzszenarios zur Analyseund Gestaltung von Entwicklungsprozessen in der verfahrenstech-nischen Industrie. In e. V. Gesellschaft fPur Arbeitswissenschaft(Ed.), Komplexe Arbeitssysteme—Herausforderung fur Analyse undGestaltung (pp. 545–548). Dortmund: GfA Press.

Foss, B., Lohmann, B., & Marquardt, W. (1998). A Celd study of theindustrial modeling process. Modeling, Identi=cation and Control, 19,153–174.

Fowler, M. (1997). UML distilled. Reading: Addison Wesley.Fox, M., & Gruninger, M. (1998). Enterprise modeling. AI Magazine,

19, 109–121.Gallopoulos, E., & Sameh, A. (1997). CSE: Content and product. IEEE

Computational Science & Engineering, 4, 39–43.

http://www.lfpt.rwth-aachen.de/Publication/Techreport/2001/LPT-2001-

mailto:15.html

http://www.cerc.wvu.edu/CERC-TR-INDEX.htm

http://www.colan.org/

http://www.iaw.rwth-aachen.de/produkte/k3/downloads.html


Genesereth, M., & Nilsson, N. (1987). Logical foundations of arti=cialintelligence. Palo Alto: Morgan Kaufmann.

Grossmann, I., & Westerberg, A. (2000). Research challenges in processsystems engineering. A.I.Ch.E. Journal, 46, 1700–1703.

Grosz, G., Rolland, C., Schwer, S., Souveyet, C., Plihon, V., Si-Said,S., Ben Achour, C., & Gnaho, C. (1997). Modelling and engineeringthe requirements engineering process: An overview of the NATUREapproach. Requirements Engineering, 2, 115–131.

Gruber, T. (1993). A translation approach to portable ontologyspeciCcations. Knowledge Acquisition, 5, 199–220.

Gruner, S., Nagl, M., & SchPurr, A. (1997). Integration tools supportingdevelopment processes. In M. Broy & B. Rumpe (Eds.), Internationalworkshop requirements targeting software and systems engineering(RTSE) (pp. 235–256). Berlin: Springer.

Gunasekaran, A. (1998). Concurrent engineering: A competitive strategyfor process industries Journal of the Operational Research Society,49, 758–765.

Guy, K. (1994). The industrial challenge: The process industries in the21st century. In European symposium on computer aided processengineering—4. IChemE Symposium Series No. 133, Rugby, 479–480.

Hackenberg, J., Krobb, C., Schopfer, G., von Wedel, L., Wyes, J., &Marquardt, W. (2000). A repository-based environment for lifecyclemodeling and simulation. In JSPS International Workshop onSafety-Assured Operation and Concurrent Engineering, Yokohama,3–5.12.2000.

Haddad, C. (1996). Operationalizing the concept of concurrentengineering: A case study from the U.S. auto industry IEEETransactions on Engineering Management, 43, 124–132.

Hammer, M., & Champy, J. (1993). Reengineering the corporation: Amanifesto for business revolution. New York: Harper.

Han, C., Douglas, J., & Stephanopoulos, G. (1995). Agent-based approachto a design support system for the synthesis of continuous chemicalprocesses. Computers & Chemical Engineering, 19(Suppl.), S63–S69.

Harold, M., & Ogunnaike, B. (2000). Process engineering in the evolvingchemical industry. A.I.Ch.E. Journal, 46, 2123–2127.

Hayes, C. (1999). Agents in a nutshell—A very brief introduction. IEEETransactions on Knowledge and Data Engineering, 11, 127–132.

Herder, P., & Weijnen, M. (2000). A concurrent engineering approachto chemical process design. International Journal of ProductionEconomics, 64, 311–318.

Hostrup, M., Harper, P., & Gani, R. (1999). Design of environmentallybenign processes: Integration of solvent design and separation processsynthesis Computers & Chemical Engineering, 23, 1395–1414.

ISO 10303 (1994). Part 1. Overview and fundamental principles. ISOTC184 SC4.

Jablonski, S., BPohm, M., & Schulze, W. (Eds.) (1999).Work;ow-Management: Entwicklung von Anwendungen undSystemen. Heidelberg: dpunkt.

Jarke, M., Lenzerini, M., Vassiliou, Y., & Vassiliadis, P. (Eds.) (2000).Fundamentals of data warehouses. Berlin: Springer.

Jeusfeld, M., Jarke, M., Nissen, H., & Staudt, M. (1998). ConceptBase—managing conceptual models about information systems. In P. Bernus,K. Mertins, & G. Schmidt (Eds.), Handbook on Architectures ofInformation Systems (pp. 265–285). Berlin: Springer.

Jones, G., & MacLean, B. (1999). Project life cycle beneCts realizedthrough dynamic process simulation. Pulp & Paper Canada, 100,46–49.

Keller II, G., & Bryan, P. (2000). Process engineering: Moving in newdirections. Chemical Engineering Progress, 96, 41–50.

Kellner, M., Madachy, R., & RaEo, D. (1999). Software processsimulation modeling: Why? What? How? The Journal of Systems andSoftware, 46, 91–105.

Kemper, A., & Moerkotte, G. (1994). Object-oriented databasemanagement: Applications in engineering and computer science.Englewood CliEs: Prentice-Hall.

Kerzner, H. (1998). Project management: A systems approach toplanning, scheduling, and controlling. New York: Wiley.

Killich, S., Luczak, H., Schlick, C., Weissenbach, M., Wiedenmaier, S.,& Ziegler, J. (1999). Task modelling for cooperative work. Behaviour& Information Technology, 18, 325–338.

Kirschner, E. (1997). Running on information. Chemical & EngineeringNews, 75, 15–19.

Konda, S., Monarch, I., Sargent, P., & Subrahmanian, E. (1992). Sharedmemory in design: A unifying theme for research and practice.Research in Engineering Design, 4, 23–42.

Kosanke, K., & Nell, J. (1999). Standardisation in ISO for enterpriseengineering and integration. Computers in Industry, 40, 311–319.

Kosturiak, J., & Gregor, M. (1999). Simulation in production system lifecycle. Computers in Industry, 38, 159–172.

Krieger, D., & Adler, R. (1998). The emergence of distributed componentplatforms. IEEE Computer, 31, 43–53.

Kunz, W., & Rittel, H. (1970). Issues as elements of information systems.Working Paper No. 131, Institute of Urban & Regional Development,University of California, Berkley.

Lee, C.-H., Sause, R., & Hong, N. (1998). Overview of entity-basedintegrated design product and process models. Advances in EngineeringSoftware, 29, 809–823.

Liebowitz, J. (2001). Knowledge management and its link to artiCcialintelligence. Expert Systems with Applications, 20, 1–6.

Lu, M., Batres, R., Li, H., & Naka, Y. (1997). A G2 based MDOOMtestbed for concurrent process engineering. Computers & ChemicalEngineering, 21(Suppl.), S11–S16.

Marquardt, W. (1996). Trends in computer-aided process modeling.Computers & Chemical Engineering, 20, 591–609.

Marquardt, W. (1999). Von der ProzeYsimulation zur Lebenszyk-lusmodellierung. Chemie Ingenieur Technik, 71, 1119–1137.

Marquardt, W., & Nagl, M. (1998). Tool integration via interfacestandardization? DECHEMA Monographie, 135, 95–126.

Marquardt, W., von Wedel, L., & Bayer, B. (2000). Perspectiveson lifecycle modeling. In M. Malone, J. Trainham, & B.Carnahan (Eds.), Fifth international conference on foundations ofcomputer-aided process design. AIChE Symposium Series No. 323, 96,192–214.

McGreavy, C., Wang, X., Lu, M., & Naka, Y. (1995). A concurrentengineering environment for chemical manufacturing. ConcurrentEngineering—Research and Applications, 3, 281–293.

Minsky, M. (1965). Matter, mind and models. In A. Kalenich, (Ed.),Proceedings of International Federation of Information ProcessingCongress (pp. 45–49). Washington: Spartan Books.

Misander, P. (2000). A document-oriented model of the work;ow inan engineering project. EU-Project CAPE.NET, TWG 4: ConcurrentProcess Engineering. Available online at http://capenet.chemeng.ucl.ac.uk (Accessed 7 January 2002).

Modelski, G., & Thompson, W. (1996). Leading sectors and worldpowers: The coevolution of global politics and economics. Columbia:University of South Carolina Press.

Molina, A., Sanchez, J., & Kusiak, A. (Eds.) (1998). Handbook of lifecycle engineering. Dordrecht: Kluwer Academic Press.

Morgan, S. (1992). Use process integration to improve process designand the design process. Chemical Engineering Progress, 88, 62–68.

Mylopoulos, J. (1998). Information modeling in the time of the revolution.Information Systems, 23, 127–155.

Nagel, S. (1981). Integrierte RechnerunterstPutzung fPur Aufgaben derThermischen Verfahrenstechnik am Beispiel des VTPLAN-Systems.Chemie Ingenieur Technik, 53, 615–619.

Nagl, M. (Ed.) (1996). Building tightly integrated software developmentenvironments: The IPSEN approach. Berlin: Springer.

Nagl, M., & Marquardt, W. (2001). Tool integration via cooperationfunctionality. In Proceedings of the 3rd European Congress ofChemical Engineering, Topic 6: Process Integration. Availableonline at http://www.dechema.de/veranstaltung/ecce/cd/table06.htm(Accessed 17 December 2001).

Nagl, M., & Westfechtel, B. (1994). A universal component forthe administration in distributed and integrated development

http://capenet.chemeng.

mailto:ucl.ac.uk

http://www.dechema.de/veranstaltung/ecce/cd/table06.htm


environments. Technical Report, Aachener Informatik-Berichte 94-8,Fachgruppe Informatik, RWTH Aachen.

Nagl, M., & Westfechtel, B. (Eds.) (1999). Integration vonEntwicklungssystemen in Ingenieuranwendungen. Berlin: Springer.

Nagl, M., Westfechtel, B., & Schneider, R. (2002). Tool support for themanagement of design processes in chemical engineering. Computers& Chemical Engineering, submitted.

Natori, Y., & O’Young, L. (1996). Vision of 21st century’s plant andhow to get there. Computers & Chemical Engineering, 20, 1469–1479.

NeCodow, L. (2000). Der sechste KondratieK. Wege zur Produktivitatund Vollbeschaftigung im Zeitalter der Information. Sankt Augustin:Rhein-Sieg-Verlag.

Nonaka, I., & Takeuchi, H. (1995). The knowledge-creating company.Oxford: Oxford University Press.

O’Kane, J., Spenceley, J., & Taylor, R. (2000). Simulation as an essentialtool for advanced manufacturing technology problems. Journal ofMaterials Processing Technology, 107, 412–424.

Parnas, D. (1999). Software engineering programs are not computerscience programs. IEEE Software, 16, 19–30.

Perkins, J. (1994). Trends in process systems engineering. Modeling,Identi=cation and Control, 15, 171–177.

Perkins, J., & Walsh, S. (1996). Optimization as a tool for design=controlintegration. Computers & Chemical Engineering, 20, 315–323.

Perris, T. (1994). SpeciCc challenges to the CAPE community. InEuropean Symposium on Computer Aided Process Engineering—4.IChemE Symposium Series No. 133, Rugby, 507– 516.

Philpotts, M. (1996). An introduction to the concepts, beneCts andterminology of product data management. Industrial Management &Data Systems, 4, 11–17.

PIEBASE Working Group 2, (1998). PIEBASE Activity Model.Available online at http://cic.nist.gov/piebase/ (Accessed 8 October2001).

Poesche, J. (2000). Ein2uss der Informationstechnologie und desInternets auf die Produktionsplanung der WertschPopfungskettenin der chemischen Industrie. Chemie Ingenieur Technik, 72,1294–1303.

Pohl, K. (1996). Process-centered requirements engineering. New York:Wiley.

Pohl, K., Weidenhaupt, K., DPomges, R., Haumer, P., Jarke, M., &Klamma, R. (1999). PRIME: Towards process-integrated environmentsACM Transactions on Software Engineering and Methodology, 8,343–410.

Ponton, J. (1995). Process systems engineering: Halfway through the Crstcentury Chemical Engineering Science, 50, 4045–4059.

Proudlove, N., VaderQa, S., & Kobbacy, K. (1998). Intelligent managementsystems in operations: A review Journal of the Operational ResearchSociety, 49, 682–699.

Quintas, P., Lefree, P., & Jones, G. (1997). Knowledge management: Astrategic agenda Long Range Planning, 30, 385–391.

Ramage, M. (1998). Computation and competiveness: Managingtechnology in the information age. In J. Pekny, G. Blau (Eds.), Thirdinternational conference on foundations of computer-aided processoperations. AIChE Symposium Series No. 320, 94, 126.

Reimer, U., Margelisch, A., & Staudt, M. (2000). EULE:A knowledge-based system to support business processesKnowledge-Based Systems, 13, 261–269.

Riemann, A. (2000). Am Beginn eines neuen Zeitalters. CIT plus, 6,8–11.

Royce, W. (1970). Managing the development of large software systems:Concepts and techniques. In Proceedings of IEEE WESCON,1–9.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen,W. (1991). Object-oriented modeling and design. Englewood CliEs:Prentice-Hall.

Russell, S., & Norvig, P. (1995). Arti=cial intelligence—a modernapproach. Upper Saddle River: Prentice-Hall.

Scheer, A.-W. (1998). Business process engineering: Reference modelsfor industrial enterprises. Berlin: Springer.

SchefstrPom, D., & van den Broek, G. (1994). Tool integration:Environments and frameworks. Chichester: Wiley.

Schembecker, G., & Simmrock, K. (1996). Heuristic-numeric processsynthesis with PROSYN. In Conference on Intelligent Systemsin Process Engineering. AIChE Symposium Series No. 312, 92,275–278.

Schmidt-Traub, H., KPoster, M., HoltkPotter, T., & Nipper, N. (1998).Conceptual plant layout. Computers & Chemical Engineering,22(Suppl.), S499–S504.

Schuler, H. (1998). ProzeYfPuhrung. Chemie Ingenieur Technik, 70, 1249–1264.

Shallcross, D., & Wood, D. (2001). Chemical engineering education andcombined degrees—A vision for education. In 6th World Congressof Chemical Engineering, Melbourne, 23.–27.9.2001, CongressProceedings CD.

Shanks, G., & Seddon, P. (2000). Enterprise resource planning (ERP)systems. Journal of Information Technology, 15, 243–244.

Shin, M., Holden, T., & Schmidt, R. (2001). From knowledge theoryto management practice: Towards an integrated approach InformationProcessing and Management, 37, 335–355.

SIAM Working Group on CSE Education (2001). Graduate education incomputational science and engineering. SIAM REVIEW, 43, 163–177.

Sowa, C. (1997). Process development: A better way. ChemicalEngineering Progress, 93, 109–112.

Stenmark, D. (2001). Leveraging tacit organizational knowledge. Journalof Management Information Systems, 17, 9–24.

Struthers, A., & Curwen, R. (1998). A new approach to integrated processsystem engineering—The VIBE agent environment. Computers &Chemical Engineering, 22(Suppl.), S745–S748.

Subrahmanian, E., Konda, S., Reich, Y., Westerberg, A., & the n-dimgroup (1997). Designing the process design process. Computers &Chemical Engineering, 21(Suppl.), S1–S9.

Sundquist, S., Ilme, J., MPaPattPa, L., & Turunen, I. (2000). Using modelsin diEerent stages of process life-cycle. Computers & ChemicalEngineering, 24, 1253–1259.

Tyner, K., & Westerberg, A. (2001). Multiperiod design of azeotropicseparation systems. I. An agent based solution. Computers & ChemicalEngineering, 25, 1267–1284.

Uschold, M., King, M., Moralee, S., & Zorgios, Y. (1998). The enterpriseontology. The Knowledge Engineering Review, 13, 31–89.

van Schijndel, J., & Pistikopoulos, E. (2000). Towards the integration ofprocess design, process control, and process operability: Current statusand future trends. In M. Malone, J. Trainham, & B. Carnahan (Eds.),Fifth International Conference on Foundations of Computer-AidedProcess Design. AIChE Symposium Series No. 323, 96, 99–112.

Venkatasubramanian, V., Zhao, J., & Viswanathan, S. (2000). Intelligentsystems for HAZOP analysis of complex process plants. Computers& Chemical Engineering, 24, 2291–2302.

Villermaux, J. (1993). Future challenges for basic research in chemicalengineering. Chemical Engineering Science, 48, 2525–2535.

von Wedel, L., & Marquardt, W. (2000a). CHEOPS: A case study incomponent-based process simulation. In M. Malone, J. Trainham, &B. Carnahan (Eds.), Fifth international conference on foundations ofcomputer-aided process design. AIChE Symposium Series No. 323,96, 494–497.

von Wedel, L., & Marquardt, W. (2000b). ROME: A repository to supportthe integration of models over the lifecycle of model-based engineeringprocesses. In S. Pierucci (Ed.), European symposium on computeraided process engineering—10 (pp. 535–540). Amsterdam: Elsevier.

W3C (1997). Extensible markup language (XML). Available online athttp://www.w3.org/XML/ (Accessed 17 December 2001).

Waligura, C., & Motard, R. (1977). Data management on engineeringand construction projects. Chemical Engineering Progress, 73, 62–70.

http://cic.nist.gov/piebase/

http://www.w3.org/XML/


Wasserman, A. (1990). Tool integration in software engineeringenvironments. In F. Long (Ed.), Software Engineering Environments(pp. 137–149). Berlin: Springer.

Wasylkiewicz, S., & Castillo, F. (2001). Automatic synthesis of complexseparation sequences with recycles. In R. Gani & S. JHrgensen (Eds.),European Symposium on Computer Aided Process Engineering—11(pp. 591–596). Amsterdam: Elsevier.

Wei, J. (1996). A century of changing paradigms in chemical engineering.Chemical Technology, 26, 16–18.

Westfechtel, B. (1999). Models and tools for managing developmentprocesses. Berlin: Springer.

Westhaus, U., DrPoge, T., & Sass, R. (1999). DETHERM—athermophysical property database. Fluid Phase Equilibria, 158–160,429–435.

Wiederhold, G., & Genesereth, M. (1997). The conceptual basis formediation services. IEEE Expert, 12, 38–47.

Wiig, K. (1997). Knowledge management: Where dit it come from andwhere will it go? Expert Systems with Applications, 13, 1–14.

Wilding, W., Rowley, R., & Oscarson, J. (1998). DIPPR project 801evaluated process design data. Fluid Phase Equilibria, 150–151,413–420.

Yasar, O., Rajasethupathy, K., Tuzun, R., McCoy, R., & Harkin, J. (2000).A new perspective on computational science education. Computing inScience & Engineering, 2, 74–79.

Zantout, H., & Marir, F. (1999). Document management systemsfrom current capabilities towards intelligent information retrieval: Anoverview. International Journal of Information Management, 19,471–484.

Zhou, G., Hull, R., & King, R. (1996). Generating data integrationmediators that use materialization. Journal of Intelligent InformationSystems, 6, 199–221.

information technology support in the chemical process design life cycle

Documents