An Ontology-based Approach to Knowledge

A

nttda©

K

1

otdgiamgaiaiGar

0d

Available online at www.sciencedirect.com

Computers and Chemical Engineering 32 (2008) 320–342

An ontology-based approach to knowledgemanagement in design processes

Sebastian C. Brandt a,∗, Jan Morbach b, Michalis Miatidis a,Manfred Theißen b, Matthias Jarke a,c, Wolfgang Marquardt b

a Informatik 5 (Information Systems), RWTH Aachen University, Ahornstr. 55, 52056 Aachen, Germanyb Process Systems Engineering, RWTH Aachen University, Turmstr. 46, 52056 Aachen, Germany

c Fraunhofer FIT, Schloss Birlinghoven, 53754 St. Augustin, Germany

Received 24 January 2007; received in revised form 5 April 2007; accepted 10 April 2007Available online 24 April 2007

bstract

Engineering design processes comprise highly creative and knowledge-intensive tasks that involve extensive information exchange and commu-ication among distributed teams. In such dynamic settings, traditional information management systems fail to provide adequate support due toheir inflexible data structures and hard-wired usage procedures, as well as their restricted ability to integrate process and product information. In
his paper, we advocate the idea of Process Data Warehousing as a means to provide a knowledge management and integration platform for suchesign processes. The key idea behind our approach is a flexible ontology-based schema with formally defined semantics that enables the capturend reuse of design experience, supported by advanced computer science methods.
2007 Elsevier Ltd. All rights reserved.

ation

t(aoccd

ba(taA(

eywords: Process Data Warehousing; Engineering design; Ontologies; Inform

. Introduction

Knowledge about engineering design processes constitutesne of the most valuable assets of a modern enterprise. Normally,his knowledge is only known implicitly to the participatingesigners, relying heavily on the personal experience back-round of each designer. To fully exploit this intellectual capital,t must be made explicit and shared among designers andcross the enterprise. Consistent and comprehensive knowledgeanagement methods need to be applied to capture and inte-rate the individual knowledge items emerging in the course ofn engineering design project. Knowledge management (KM)s a scientific discipline that stems from management theorynd concentrates on the systematic creation, leverage, shar-ng and reuse of knowledge resources in a company (Awad &
haziri, 2003). Knowledge management approaches are gener-
lly divided into personalization approaches that focus on humanesources and communication, and codification approaches

∗ Corresponding author. Tel.: +49 241 80 21514.E-mail address: [email protected] (S.C. Brandt).

Kib(csm

098-1354/$ – see front matter © 2007 Elsevier Ltd. All rights reserved.oi:10.1016/j.compchemeng.2007.04.013

management; Knowledge management; Design repository

hat emphasize the collection and organization of knowledgeMcMahon, Lowe, & Culley, 2004). We only consider the latterpproach, stressing the automated recording of the applicationf implicit design knowledge. Thus, experience knowledge isaptured that can be shared and reused later on. This poses thehallenges on knowledge management systems (KMS) that areescribed below.

Typically, a vast amount of design knowledge is manipulatedy legacy tools and stored in highly heterogeneous sources, suchs electronic documents and databases. Thus, a KMS shoulda) provide a comprehensive representation of the contents ofhese sources, thereby correlating the scattered knowledge itemsnd providing a single point of access to design knowledge.s such a comprehensive representation cannot be complete

for reasons of scaling, maintainability, practicability, etc.), aMS should (b) employ mechanisms to easily locate the orig-

nal knowledge sources, where more detailed information cane retrieved. To this aim, (meta) information about the sources
e.g., type, structure, version history, storage location) should beombined with information about their contents, and the KMShould be integrated with existing tools and data stores to pro-ote easy access to the original sources. In addition, the KMS
mailto:[email protected]

dx.doi.org/10.1016/j.compchemeng.2007.04.013

hemi

sotrttpwrpd

ndKcuwtrbsoieft

gbatikdoo

2

ed&fdNntoftd

i

pstitpa

naubattupwtp

(watsastie

pidobW(gsac

ipmalt

S.C. Brandt et al. / Computers and C

hould (c) enable the capture and archival of work processes inrder to provide information about the circumstances in whichhe individual knowledge items have been created. In particular,ecording of the decision-making procedures allows to recallhe design rationale applied at that time. This allows to sys-ematically retrieve experience knowledge that is suitable for aarticular situation, and evaluate its applicability to the currentorking context. Moreover, best practices abstracted from the

ecorded work processes can be exploited for direct process sup-ort (i.e., the partially automated enactment of routine tasks inesign tools).

This paper presents a novel approach for supporting creative,on-deterministic1 design processes that addresses the aboveemands: based on the concepts introduced by Jarke, List, andoller (2000), our Process Data Warehouse (PDW) allows the

apture and reuse of design knowledge – product data, doc-ments, work processes, and decision-making procedures, asell as their interdependencies – through ontologies. In this con-

ext, the term “ontology” denotes a conceptual data schema thatepresents the relevant domain entities and their relationshipsy means of classes and relations. Ontologies are flexible datatructures that can be changed and adapted at run time; more-ver, they allow representing the semantics of design knowledgen a formal way the computer can interpret. These characteristicsnable the provisioning of advanced computer science methodsor managing, enriching, and searching the knowledge withinhe PDW.

The paper is organized as follows: the next section investi-ates the possibilities of supporting technical design processesy experience management. In Section 3, we introduce ourpproach of the Process Data Warehouse for knowledge cap-ure and experience reuse. Section 4 illustrates how the PDWs applied in process engineering design. Methods and tools fornowledge capture are described in Section 5. In Section 6, weiscuss how our work correlates with the research activities ofther groups. Finally, conclusions are drawn, including furthern-going and future research.

. Supporting creative design processes

Experience that can be gathered and recorded using knowl-dge management methods, is intended to be used for supportingesigners when executing creative design processes (Jarke

Marquardt, 1996). Those conceptual design processes, asound in chemical engineering, are highly dynamic and non-eterministic, and therefore hardly predictable (Marquardt &agl, 2004; Westerberg, Subrahmanian, Reich, Konda, & the-dim group, 1997). Any software solution has to cope withhe continually changing requirements and the many degrees
f freedom within these processes. Appropriate process supportor the chemical engineering domain is even harder to achievehan for domains like automotive engineering where stan-ardized, well-understood products are developed: the design
1 That is, work processes that cannot be completely planned and/or scheduledn advance due to initially incomplete knowledge, and uncertainties.

2mGa2

c

cal Engineering 32 (2008) 320–342 321

rocesses in these domains are relatively well-documented,trict, and deterministic, allowing a prescriptive definition ofhe activities to be executed. In contrast, chemical engineerings concerned with the development of individual and highly cus-omizable products (i.e., chemical plants); therefore, the designrocesses are more dynamic and do not allow for deterministicpproaches.

In this context, two different types of information resourceseed to be distinguished. On the one hand, the products createds part of the design processes (e.g., process flow diagrams, sim-lation models, design calculations, cost estimates, etc.) shoulde considered. These may be organized into documents, whichct as logical units to enable work distribution or version con-rol. On the other hand, there are the work processes or activitieshemselves, in which the products are created, used or manip-lated. Any kind of integrated support needs to take both theroduct and the process aspect into account. In the following,e discuss to which degree the different types of software solu-

ions available today support the management of product androcess knowledge.

Document Management Systems such as WindreamWindream GmbH, 2006) or Documentum (EMC2, 2006) areidely used in industrial practice for the storage, maintenance,

nd distribution of documents. Their process support is restrictedo micro-level processes like versioning and to the execution ofimple workflow definitions, offering a subset of the function-lity of standard workflow management systems. Some of theseystems provide collaborative extensions, such as the Documen-um eRoom. These offer additional functionalities for intra- andnter-enterprise collaboration, and for the flexible definition andxecution of cooperative and coordinative workflows.

A step further, Product Data Management (PDM) systemsrovide extended facilities for the handling of detailed productnformation, ranging from design to production stage. Nowa-ays, such systems are routinely applied for the manufacturingf mechanical and electronic devices. They are being succeededy Product Lifecycle Management (PLM) systems, such asindchill (PTC, 2006a), TeamCenter (UGS, 2006) or CATIA

Dassault Systemes, 2006). The aim of these systems is to inte-rate information on the manufacturing processes (usually CAMystems) with design data (CAD systems) on the one hand,nd information about Enterprise Resource Planning (ERP) pro-esses on the other hand.

The PDM/PLM systems available today adequately supportnformation exchange between developers, especially in the laterhases of the engineering lifecycle which are characterized byore deterministic and well-known processes. Nowadays, they

lso provide improved possibilities to integrate a company’segacy systems, provided that the company is willing to tacklehe required integration effort (Mesihovic, Malmqvist, & Pikosz,004). However, they lack essential capabilities for the manage-ent and reuse of design knowledge (Bilgic & Rock, 1997;ao, Aziz, Maropoulos, & Cheung, 2003; Maropoulos, 2003)

nd are less suited for the conceptual design stage (Gao et al.,003; Mesihovic et al., 2004).

A significant shortcoming of existing PDM and PLM systemsriticized by many authors, is their lack of adequate informa-

3 hemi

t&cptpB2

lamtbRic

ii(tp2(Pflbswd

tacP

lTsibn(dststaXvs(a

a

itaopiacpAacd

icepih

3

tIidOsu

3m

dVsgwset2

I“(feclasses and relations. By instantiating these ontological con-cepts, concrete facts and information items can be stored in the

22 S.C. Brandt et al. / Computers and C

ion models for product representation (e.g., Szykman, Sriram,Regli, 2001). These models would be needed to effectively

apture, exchange, retrieve, and reuse design knowledge. Inarticular, formal and well-structured information models forhe conceptual design stage are missing that reflect differenterspectives such as function, behavior, and structure (e.g.,ilgic & Rock, 1997; Mesihovic et al., 2004; Szykman et al.,001).

Regarding process support, current PDM systems haveargely focused on the support of micro-level processes on thedministrative level, such as versioning or engineering changeanagement (Mesihovic et al., 2004). Some attention is paid

o project management, however without reaching the capa-ilities of full-fledged project management systems (Bilgic &ock, 1997; Mesihovic et al., 2004). They lack the functional-

ty to capture complex work processes and decisions, as well asapabilities for direct process support.

While PLM systems are widely used in the manufacturingndustries, they are less common in the chemical engineer-ng domain. Instead, specialized Computer Aided EngineeringCAE) systems are used, which resemble classical PDM solu-ions but are specifically adapted to the needs of the chemicalrocess industries. Examples are Aspen Zyqad (AspenTech,006), Comos PT (Innotec, 2006), SmartPlant P&IDIntergraph, 2006a), and VANTAGE (AVEVA, 2006a). LikeDM systems, these CAE systems focus on geometrical data andowsheets; other plant-related information are also consideredut to a much lesser degree. Information models of CAE systemsuffer the same deficiencies as PDM systems, that is the lack ofell-structured product representation, especially for the earlyesign phases (e.g., Bayer, 2003; Bayer & Marquardt, 2003).

Like PDM systems, CAE systems offer process support onhe micro-level but fail to support more complex developmentctivities. They lack capabilities for the capture of work pro-esses and decisions, nor do they offer direct process support.roject management is supported to some degree.

The CAE systems available today do not cover the entireifecycle of a chemical plant (Schneider & Marquardt, 2002).herefore, vendors offer information integration environmentsuch as Optegra (PTC, 2006b) to integrate and consolidatenformation from heterogeneous sources. Some solutions haveeen developed specifically for the domain of chemical engi-eering, such as the Process Engineering Data WarehousePEDW, Bayer Technology Services, 2006), SmartPlant Foun-ation (Intergraph, 2006b), and VNET (AVEVA, 2006b). Theseolutions aim to correlate design data and technical specifica-ions obtained from multiple sources (CAE systems, processimulators, and other engineering tools) with other informa-ion, such as process studies, material balances, property data,nd project-related data. Data import is mainly realized throughML and is often restricted to the proprietary formats of theendors and their cooperation partners. The tools offer servicesuch as version management, change management, notification
if some changes have been committed), and simple navigationnd retrieval functionality.
In summary, none of the commercial solutions currentlyvailable is able to provide knowledge management support as

o

cal Engineering 32 (2008) 320–342

t has been envisioned in the previous section. Since each ofhese tools is based on its own proprietary information modelnd contains only some generic import and/or export functions,nly part of the product knowledge created during the designrocess can be captured for reuse. Reuse of product knowledges further hindered by the lack of adequate information modelsnd the tools’ insufficient retrieval capabilities. As for the pro-ess aspect, none of the tools offers process support beyondrescriptive workflow management and micro-level services.s mentioned before, these deterministic approaches are not

dequate for conceptual design processes which are not suffi-iently well understood and involve activities of multi-objectiveecision-making based on incomplete information.

Thus, to move beyond the approaches described so far, theres a need for integrated technical support in the early phases ofonceptual design. Therefore, the authors’ work groups havexamined the possibilities offered by recording and reusingroduct and process knowledge. To stress the integration andnterleaving of product and process data, the underlying conceptas been named the Process Data Warehouse.

. The Process Data Warehouse

In this section, the concept of the Process Data Warehouse as araces-based knowledge management system will be described.t records the traces of design processes in its experience repos-tory and thus allows them to be reused for supporting creativeesign processes. Section 3.1 introduces the so-called Corentology, and Section 3.2 describes some ontological exten-

ion modules. Section 3.3 shows how the ontological model issed for the implementation of the PDW.

.1. A Core Ontology for engineering knowledgeanagement

The concept of the Process Data Warehouse has beenerived from the concept of Data Warehousing (Jarke, Lenzerini,assiliou, & Vassiliadis, 2003) where large amounts of fixedlytructured data (e.g., from sales or accounting) are stored, aggre-ated, and then presented. For those conventional tools andarehouses, fixed schemas are used for data storage. Yet to

upport design and other creative work processes, dynamicxtension of the existing data structures and integration of addi-ional, suitable domain models2 must be supported (Jarke et al.,000).

The PDW uses ontologies to represent the domain models.n computer science, an ontology is usually understood as aformal, explicit specification of a shared conceptualization”Studer, Benjamins, & Fensel, 1998); that means, an ontology isormal model which explicitly represents the consensual knowl-dge of a domain. The domain entities are modeled through

ntology.

2 A domain model is an information model for a particular application domain.

S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342 323

logy

diprtpomsos

oOJtldrDoaSoa

•

•

•

Fig. 1. Simplified view of the Core Onto

Ontologies have two major advantages over conventionalata schemas: firstly, they are highly flexible, enabling mod-fications and extensions of the data structures even duringroject execution. Secondly, they are represented in a machine-eadable, logic-based language, which allows to formally definehe semantics of the ontological concepts. This enables the com-uter to interpret and reason with the information stored in thentology. In consequence, advanced support for informationanagement and retrieval can be provided: for example, it is pos-

ible to perform a semantic search on the ontology. In contrast tother, simpler forms of search (e.g., keyword based), a semanticearch allows for a more systematic retrieval of information.

The PDW has been constructed on top of loosely connectedntology modules which are held together by a central Corentology (Brandt, Morbach, et al., 2006; Brandt, Schluter, &

arke, 2006a). The Core Ontology introduces top-level conceptshat describe products and processes, as well as their interre-ations and dependencies, independently from any particularomain or application. These fundamental concepts are thenefined and concretized within peripheral ontology modules.ifferent ontology modules can be added to the Core Ontol-gy to flexibly adapt the PDW to the requirements of a specificpplication domain; some exemplary extensions are presented inection 3.2. Fig. 1 displays a simplified view of the Core Ontol-gy. Four prominent areas of conceptualization are arrangedround the Object as the central concept.

Product Area. The Product Area (top) contains concepts forthe description of the type and version history of electronicdocuments and other information resources, as well as their

•

and some peripheral ontology modules.

mutual dependencies and their structural decomposition. TheProduct class denotes all kinds of information elements, suchas data items or decision representation objects, which arecreated or modified during a work process. Products can beaggregated into DocumentVersions. The different versions ofa Product can be bundled by a VersionSet. A specialization ofVersionSet is the (logical) Document, which bundles differentDocumentVersions.Storage Area. The Storage Area (right) describes at whichlocation (StoragePlace) inside a Store a particular Version-Set is stored. Examples of stores are databases, DocumentManagement Systems, and external tools. Instances of theTransformation class control the integration of external data,e.g., by defining XML document transformation based onXSLT (W3C, 1999).Descriptive Area. The Descriptive Area (left) containsbasic concepts for describing the content or the role ofProductObjects on a high semantic level. This includes Con-tentDescriptions and Categorizations, which are grouped intoCategorizationSchemes. Unlike Categorizations which sim-ply classify ProductObjects according to certain categories,a ContentDescription is a placeholder for a term (or even acomposite expression) from a controlled vocabulary that char-acterizes the contents of the associated ProductObject. Thus,the descriptive area provides content-specific meta informa-tion for the annotation of documents and data stores.
Process Area. The Process Area (bottom) contains the con-cepts needed to represent the ProcessObjects that manipulate(i.e., create, use, or modify) ProductObjects. Process-Elements comprise general process definitions (Activities)

3 hemi

i2tc

•

•

•

•

tt(ip

OtficcsKsse(

3

rtwod(i

3

(

acCrnsCoeeeutptddsat

rsP

3

rCtcfiiati

3

ibPsAt

SmsfieS


such as coarse-grained guidelines for designers or fine-grained process steps for direct process support. They alsocomprise ProcessTraces that describe the concrete actionsperformed in a project by Users or (software) Tools. IfProcessTraces have been executed according to a processdefinition given by an Activity, they are related by charac-terizedBy.

Knowledge is not only contained in information, but alson the relationships among information items (Rus & Lindvall,002). Thus, many relationships have been explicitly modeledhat associate classes inside one area, or between several of theonceptualization areas. The following may serve as examples:

describedBy connects the ProductObjects with descriptiveelements that describe their content or category;storedAt represents the storage of products and documents inphysical locations such as file systems or repositories;manipulatedBy describes how the ProductObjects are created,used, and modified by the users during process activities;a generic dependsOn relation allows to introduce and derivespecialized relations between Objects of any type.

Some of the concepts described here, especially those inhe Product and Process Areas, have been derived from theraceability reference model introduced by Ramesh and Jarke2001). Abstracted from a large number of industrial case stud-es, the model describes the conceptual relations of product- androcess-related traces in more detail.

For reasons of interoperability, the Web Ontology LanguageWL (Bechhofer et al., 2004), a W3C standard for the Seman-

ic Web (Berners-Lee, Hendler, & Lassila, 2001), would be therst choice for the representation of ontologies. However, sinceurrent OWL-based ontology repositories do not offer an effi-iently searchable storage in relational databases, the KAONystem (Oberle, Volz, Motik, & Staab, 2004) is used instead.AON is based on the same set of base standards (RDF, RDFS,

ee Manola & Miller, 2004) as OWL. KAON enables efficientearch and retrieval mechanism directly on the database back-nd, at the cost of loosing some of the expressiveness of OWLcf. discussion in Section 7).

.2. Selected extension modules

The Core Ontology only contains high-level conceptsequired to establish, organize, and integrate the four fundamen-al Areas. In addition, each Area offers some extension pointshere ontology modules for specific application domains orther specializations can be added. These modules refine theomain-independent concepts introduced in the Core Ontologyrefinement is indicated by dashed arrows in Fig. 1). Exemplar-ly, some extensions are presented in the following.

.2.1. OntoCAPEThe most elaborate of these extensions is OntoCAPE

Morbach, Yang, & Marquardt, 2007; Yang & Marquardt, 2004),

tm(e


large-scale ontology for the domain of computer-aided pro-ess engineering. OntoCAPE was originally developed in theOGents project (Braunschweig et al., 2004) and has been

efined in the context of this work. It consists of a set of intercon-ected partial models which are hierarchically organized acrosseveral levels of abstraction. Important areas covered by Onto-APE are substances and their thermophysical properties, unitperations and plant equipment, as well as mathematical mod-ling. The design of OntoCAPE emphasizes extensibility andase of customization. Accordingly, only the higher level domainntities are specified in the ontology at deployment time. Thesers can then easily refine and extend the ontology accordingo the needs of their respective organizations. The customizationrocess is guided by several mechanisms, such as the specifica-ion of a default structure for the partial models, the provision ofesign patterns to suggest best-practice solutions for commonesign problems, and the definition of a meta model that repre-ents the underlying design principles of the ontology and is thusble to enforce design consistency when changing or extendinghe ontology.

In the PDW, OntoCAPE extends the Descriptive Area byefining the ContentDescription class, thus providing a domain-pecific vocabulary for the description of ProductObjects androcessObjects.

.2.2. Chemical engineering documentsThe ontology module Chemical Engineering Documents

efines the generic Document class in the Product Area of theore Ontology. It provides a taxonomy of the document types

hat are typically used in chemical process design, such as Pro-ess & Instrumentation Diagrams, equipment lists, or modelles. A detailed description of this ontology module can be found

n Morbach, Hai, Bayer, and Marquardt (2007, chap. 2.3). In annalogous manner, alternative taxonomies can be developed byhe users of the PDW to represent the document types that existn the users’ organization.

.2.3. Document ManagementThe Storage Area offers the basic models for file storage

nside a Document Management System (DMS), correlating file-ased documents with their conceptual representation inside theDW. This allows to locate the documents in their physicaltorage places. Thus, the original documents can be accessed.dditionally, change notifications from such DMS can be cap-

ured.The Document Management extension module contains the

tore refinements for various kinds of DMS, including Docu-entum (EMC2, 2006), Jakarta Slide (Slide, 2006), and simpler

ystems that do not support version control, such as networkle systems. For each Store, specialized classes of StoragePlacexist that define the physical location of a document inside thetore, e.g., by giving a path and file name.

Other kinds of repositories – relational databases, interfaces
o external tools, etc. – also refine the Store class, and use refine-
ents of StoragePlace to define uniquely identifying attributese.g., primary keys or id tags) to represent the physical storagelements.

hemi

cel5

3

cptagbc2s

aioarmCuMcfctbc

3

atecoTcMtur

3

spdMaao

oodcmc

3

twnpbr

diri

3

chofiisfto

ecfoA(oqlptt

aoti


To achieve an integration of the external systems, it is ofourse necessary to develop specific program code for eachxternal system, and to connect this program code with the onto-ogical class that represents the Store refinement (cf. Section.2).

.2.4. Work Process & Project ManagementThe Work Process & Project Management module covers pro-

ess models which prescribe (part of) the work processes to beerformed by a designer or a design team confronted with a cer-ain task. Typically, these process models contain patterns, suchs sequences of Activities or alternative sub-processes. Coarse-rained process models are represented using a process ontologyased on the C3 modeling language (Eggersmann et al., 2007,hap. 2.4), a modified version of UML activity diagrams (OMG,004) which provides the required expressivity for the weaklytructured design processes in chemical engineering.

At a more fine-grained level, the designer performs his/herssigned tasks following various methodologies while usingnteractive software tools. Because of design creativity, only fewf the methodologies followed are well understood and can bedequately described using a fine-grained process model. Weefer to such well-understood methodologies as method frag-ents. In our case, we have extended the Process Area of theore Ontology with concepts for formalizing method fragmentssing the NATURE process meta model (Rolland, Souveyet, &oreno, 1995). Briefly, the NATURE meta model promotes the

ontextualization of process knowledge and represents methodragments as tuples of arbitrary contexts. A context relates theurrent process situation to the goal of the designer. Thus, a con-ext might either represent a specific method fragment that has toe followed, or the need for a choice among several alternativeontexts, or even a simple step operationalized by a tool action.

.2.5. Design tracesWhereas prescriptive process models capture an ideal

bstraction of the reality, design traces give a faithful descrip-ion of the real process that provides evidence how the processvolves over time (Ramesh & Jarke, 2001). This informationan be used, for example, to backtrace poor design decisions,r to crystallize knowledge out of successful ones. The Designraces module, based on the ProcessTrace class, comprises con-epts for structuring traces recorded during process execution.ore specifically, concepts are provided for the description of

he sequence of performed process steps, the states of the prod-ct being worked upon by the process steps, as well as theelationships between process and product traces.

.2.6. Decision documentationThe decision documentation module, based on the Deci-

ion Representation Language (DRL) by Lee and Lai (1996),rovides concepts for representing the rationale on which aesign decision is based during a particular project (Theißen &
arquardt, 2007, chap. 2.5). For example, a Goal can representconstraint to be met for a particular DecisionProblem, while
n Alternative denotes a design which is to be evaluated basedn Goals. The decision documentation module is a refinement

i

ap

cal Engineering 32 (2008) 320–342 325

f the Product class of the Core Ontology. Instances of classesf this module can be further specified using the concepts of theescriptive area. For instance, the goal of designing a chemi-al reactor with a product stream of 40,000 t/year can easily beodeled by connecting (i.e., refining) an instance of Goal with

oncepts from OntoCAPE.

.2.7. Application toolsThe extension application tools contains a representation of

he software tools that can support a designer when executing aork process. Activities can be associated with the Tools that areeeded to enact them. Thus, tool environments may be prepared,reconditions like tool usability may be checked, and users maye guided in using the appropriate tool. ProcessTraces can beelated to the Tool the changes have been executed in.

Additionally, most software tools only work with certainocument types (or other resource types). By relating thisnformation to a Tool instance itself, the information resourcesesulting from tool use or needed for using the tool can bedentified.

.3. Architecture of the PDW

In the preceding sections, the general problems of supportingreative processes have been described, and the Core Ontologyas been introduced. In this section, the architectural structuref the PDW experience repository as a trace recording and reuseramework is shown. Furthermore, it is described how the PDWnteracts with the software environment it is realized in. Follow-ng the authors’ concept of a posteriori integration, the existingoftware tools are augmented by integrating them with the PDWramework. While the engineers can go on working with theools they are accustomed to, additional support functionality isffered by the integrated environment.

Fig. 2 shows how the experience repository of the PDW ismbedded into its usage environment. The PDW server itselfan be seen on the right of the figure. The KAON ontologyramework (Oberle et al., 2004) is responsible for managing thentology classes of the PDW and the corresponding instances.ll this data is stored in an SQL2-compatible relational database

PostgreSQL, 2006), mapping the flexible ontology structurento a fixed relational schema. Additionally, KAON offers auery mechanism that is able to transform requests in a high-evel semantic query language into SQL queries which can beerformed directly on the relational storage back-end. Thus, onlyhose instances that either result from the query or are navigatedo need to be loaded from storage.

Around this ontology framework, the PDW-Model formsn implementation wrapper that represents the Core Ontol-gy and offers other specialized functionality. It gives accesso the ontological concepts both in a generic way (as classes,nstances, association types, and relations) and by specialized
nterfaces.
The realization of the server as described here is placed in anpplication server based on the J2EE programming language andlatform (Sun, 2006). This enables the PDW to offer services

326 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342

f the

b

•

•

•

smTPitAaii

bnldtoppf

wffsphu

erD2icvncputdit5

dmoariq

Fig. 2. Overview o

ased on various standardized communication protocols:

Web services are nowadays often used for service-basedintegration of enterprise applications, thus offering company-spanning workflows that can be dynamically composed.Especially in a cooperative setting, this allows to extend thePDW with well-defined and standards-based service inter-faces.Access for thin clients (i.e., web browsers) is provided byweb applications that are using the technologies of Servletsand Java Server Pages (Sun, 2006).Access to the server from rich clients (i.e., stand-alone clientapplications) is realized via Enterprise Java Beans, EJB (Sun,2006).

In the center of Fig. 2, such a rich client application can beeen. This application, the PDW front-end, forms the primaryeans of accessing the PDW experience server and repository.he front-end contains a client-side representation of a part of theDW’s classes and instances, thus reflecting the current state of

nformation inside the server. Changes to the client-side data areransferred to the server and persisted in a database transaction.ll those changes are then communicated to the running clients,

llowing the clients to synchronize with the current state ofnformation, and, possibly, display the newly created or changednformation.

Three different kinds of graphical user interfaces are offeredy the PDW front-end. The generic display is based on UMLotation (OMG, 2004) of the classes and instances of the onto-ogical models. It displays classes and instances as blocks ofifferent colors with their attribute types and values, and rela-ions as links between them. This view is mainly aimed at the
ntology engineer responsible for modeling and integrating aarticular domain into the system, and for rapid prototyping ofossible use cases. Specific user interfaces need to be createdor the various application cases, so that the domain users can
datr

PDW architecture.

ork with customized interfaces that offer appropriate solutionsor their problems. Semi-specific interfaces can be used to uni-ormly visualize different concepts of the ontology that haveimilar characteristics. This allows to define general rules forresentation as model annotations, e.g., to display compositionierarchies or networks of blocks and streams of various kinds,sing the same user interface.

The PDW system is in several ways integrated with itsxternal environment. As already mentioned, this external envi-onment is mainly kept unchanged, it is only extended. Aocument Management System, such as Documentum (EMC2,006) or Jakarta Slide (Slide, 2006), is responsible for support-ng document-based storages, offering version management andhange notification support. When an expert checks in a newersion of a document into the DMS, the PDW front-end run-ing on his or her workplace is notified. The ontology instancesorresponding to the document, its new version, and its storagelace are created or updated and shown to the expert. The doc-ment instance can then be enriched semi-automatically withhe current organizational context. Possibly, the content of theocument can be transformed from the external tool’s formatnto a representation inside the PDW’s repository, providedhat the format can be automatically interpreted (cf. Section.2).

Other external tools, mainly those that use repositories oratabases for storage purposes instead of simple files or docu-ents, can be integrated as external data sources as well. This

ften applies to ERP or CAE systems. Their data can usually beccessed by the programming interfaces offered by these tools,ead and converted into PDW storage, enriched with semanticnformation, and transferred to and from other tools for subse-uent design steps. A generic mechanism for integrating external
ata sources has been implemented using XML (W3C, 2006)s an exchange format, and XSLT (W3C, 1999) to transformhe intermediate files into a form that matches the conceptualepresentation of the PDW (for details, see Section 5.2).


amide

4

Putnd

4

oatdbIteG&

apacocs

i

1

2

3

o

4

tdmtpeeqtvk

acwdtrolcbetween the two query variables. Finally, the ChemicalReactionis specified by indicating the desired reactants (water and capro-

Fig. 3. Query for poly

. Using the PDW

In Section 4.1, we describe an exemplary session with theDW to illustrate its usage in an engineering design project;sage is demonstrated by means of an application scenario fromhe area of conceptual process design. As a single scenario can-ot cover all the application possibilities of the PDW, we williscuss other use cases in Section 4.2 in a systematic manner.

.1. A scenario in process design

As application scenario, we consider the conceptual designf a chemical reactor for polyamide-6, to be performed bysingle engineer who is part of an interdisciplinary design

eam. The chosen scenario is part of a large case study on theesign of a polyamide-6 production facility. This case study haseen elaborated in the Collaborative Research Center (CRC)MPROVE (Marquardt & Nagl, 2004) in cooperation with indus-rial partners (e.g., Bayer AG). A detailed description of thentire case study can be found elsewhere (Bayer, Eggersmann,ani, & Schneider, 2002; Eggersmann, Hackenberg, Marquardt,Cameron, 2002; Nagl, Westfechtel, & Schneider, 2003).At the outset of the application scenario, the engineer is

ssigned the task of developing a conceptual design for thisolyamide-6 reactor. The only specifications given at this pointre the feedstock – polyamide-6 is to be produced from water andaprolactam – and the desired amount and material propertiesf the polyamide-6 product. To come up with a suitable pro-ess design, the engineer can draw on the experience knowledgetored in the PDW.

Typically, a sample session with the PDW consists of threentertwined steps, each reflecting a different mode of operation:

. Retrieval of experience knowledge: The user searches thePDW for experience knowledge matching his/her currenttask. To this aim, the PDW supports two modes of operation:a. The user may either actively search the PDW by compos-

ing queries manually, orb. he may rely on the PDW’s ability to automatically derive

queries from the current work context of the applicationtools (context-sensitive knowledge retrieval).

l

3

-6 reactor equipment.

. Review and reuse of retrieved experience knowledge: Theretrieved information needs to be reviewed by the user, whocan then decide on reusing some or all of the experienceknowledge in the tools that form the current work context.

. Knowledge capture: The design knowledge created by theuser when processing the current task is recorded and storedin the PDW in order to increase the knowledge base.

In the following, we discuss how the three steps are carriedut in this particular application scenario.

.1.1. Step 1a: Manual search for experience knowledgeTo gain a first insight into the new task, the engineer wants

o search the PDW for experience knowledge created by formeresign projects. In particular, he is interested in the reactor equip-ent that is typically used for the production of polyamide-6. To

his end, he formulates a query to the PDW by selecting appro-riate concepts from the PDW ontologies. A graphical queryditor supports the composition of such queries in a “query-by-xample”-based fashion. Ontological classes can be employed asuery variables; that way, all knowledge items that are (seman-ic) instances of the respective class will be retrieved. The queryariables can be further specified by using relations and alreadynown instances from the ontology.

As it is shown in Fig. 3, the class ChemicalReactor is chosens a first query variable.3 However, since the semantics of thislass is fairly general – it is defined as “any apparatus withinhich a chemical reaction takes place” – the query would pro-uce a large number of unwanted results. Thus, the query needso be refined—for instance, by constraining the type of chemicaleaction that takes place in the reactor. This is done by meansf a second query variable, namely ChemicalReaction, which isinked to ChemicalReactor via the ontological relation takesPla-eIn (cf. Fig. 3); takesPlaceIn defines the semantic relationship

actam) as well as the product (polyamide-6) of the reaction; the

3 ChemicalReactor is a class defined in the OntoCAPE ontology (cf. Section.2); the prefixed question mark indicates that the class is used as a query variable.


about

cia

wandpttc“

eaaCf2r

epOtafiiDtlo

cppFVw

4k

auicoettbpaWd

iribmfcrsfotAt

•

•

Fig. 4. Query for P&IDs containing information

hemical substances are made available by the PDW in form ofnstances, their roles in this context (i.e., as reactants or product)re defined via ontological relations.

The query now reads: “Find all chemical reactors withinhich a reaction takes place that has caprolactam and waters reactants and polyamide-6 as reaction product”. It should beoted that, since the semantics of all query terms are formallyefined within the PDW ontologies, the computer can inter-ret the meaning of the query and is therefore able to retrievehe appropriate knowledge items, even if they are representedhrough different (but semantically equivalent) ontological con-epts within the PDW. This retrieval mechanism, which is calledsemantic searching”, will be further explained in Section 4.2.

The query is passed to the PDW to search for matching experi-nce knowledge. Several knowledge items (ontology instances)re found that match the query; all of them can be recognizeds instances of a particular class, VK Tube, a specialization ofhemicalReactor representing a special type of column reactor

or polyamide-6 production (e.g., Agrawal, Devika, & Manabe,001). The engineer concludes from these facts that a VK tubeeactor is an appropriate choice for this chemical process.

To find out more about the construction of a VK tube, thengineer decides to search for associated documents. For thaturpose, the above query is extended by concepts from the Corentology’s Product Area. First, ChemicalReactor is linked with

he query variable DocumentVersion via a describedBy relation,s shown in Fig. 4. Next, the query is further refined by speci-ying the desired document type: to this end, DocumentVersions linked with the class P&ID, a subclass of Document whichs introduced in the ontology extension Chemical Engineeringocuments (cf. Section 3.2) to represent Process & Instrumen-

ation Diagrams. By choosing the relation currentVersion for theinkage of DocumentVersion and P&ID, only the latest versionf the P&ID document will be retrieved.

Now the query reads: “Find the latest version of any Pro-ess & Instrumentation Diagram that describes a reactor forolyamide-6 production from caprolactam and water”. After
rocessing the query, several P&ID documents are retrieved.rom these, the engineer learns about the specific details ofK tube design. He now possesses enough information to startorking on his design task.
reactor equipment for polyamide-6 production.

.1.2. Step 1b: Context-sensitive retrieval of experiencenowledge

The manual construction of queries is highly flexible, buts it is a rather complex task it might discourage non-expertsers. Therefore, a more convenient way of knowledge retrievals offered by the PDW: Queries are derived from the current workontext of the application tools, thus providing reusable productr process knowledge that matches the current situation. To thisnd, the PDW needs to be integrated with the (legacy) applica-ion tools used by designers. To demonstrate the feasibility ofhis approach, a prototypical experience reuse framework haseen realized, consisting of the Process Data Warehouse, therocess-integrated development environment PRIME (Pohl etl., 1999) and a proprietary Flowsheet Editor (Bayer, Marquardt,eidenhaupt, & Jarke, 2001), which is an advanced prototypical

esign environment for process flowsheets.Assume that the engineer needs to perform simulation exper-

ments to determine certain design parameters of the VK tubeeactor. To this aim, he wants to query the PDW for mathemat-cal models that can be reused to simulate the physicochemicalehavior of the VK tube. Instead of composing such a queryanually, as it was done in Step 1a, the query can be derived

rom the work context of the Flowsheet Editor: An initial Pro-ess Flow Diagram has been created in the Flowsheet Editor,eflecting the main process steps and interconnecting materialtreams of the polyamide-6 process (Fig. 5, item 1). The searchor an appropriate mathematical model is triggered by clickingn a menu item “find simulation model” and selecting the sec-ion of the flow diagram that is to be simulated (Fig. 5, item 2).gain, the query is composed of concepts from several areas of

he Core Ontology:

The product part of the query defines the type of document(i.e., a model file) to be retrieved as well as optional furtherconstraints such as the desired format (e.g., an Aspen Plusfile).The descriptive part of the query specifies the content of the
model by using concepts from OntoCAPE. In this particularcase, the specification comprises the type of model (steady-state, rigorous), the type of the modeled reactor (VK tube),and the material streams flowing into and out of the reactor.


hemi

•

D(

4k

ermCntfhact

mbDpacfipas

det

audd(admappciamstnsor

4

tfi

Fig. 5. The application scenario of c

The most important process element is the user’s intentionin this situation, i.e., “find simulation model”, given by themenu item. This also determines the desired document type,a model file (see above).

This situation definition can then be passed on to the Processata Warehouse to search for matching experience information

Fig. 5, item 3).

.1.3. Step 2: Review and reuse of retrieved experiencenowledge

In the example scenario, several different mathematical mod-ls for the simulation of a polyamide-6 reactor are found andeturned. The models are combinations of different standardodel blocks, such as flash units, Plug Flow Reactors (PFR), orontinuous Stirred Tank Reactors (CSTR), which are intercon-ected via process streams. This information is then presented tohe user via the front-end of the PDW (Fig. 5, item 4). Two dif-erent visualizations, as described in Section 3.3, can be appliedere: The generic representation shows the class instances, theirttributes and relations in UML instance notation, while the spe-ific representation in this case shows a graphical snapshot ofhe reactor models (see Fig. 6).

Now the expert needs to decide which of the simulationodels to reuse. The PDW supports this decision-making

y providing additional information about the models in theescription Area, such as the reaction kinetics and materialroperties data used in the model. Moreover, by browsingssociated concepts from the Process Area (refinements of Pro-essTrace) and related decision documentation, the user may
nd out more about the former usage of the models. For exam-le, he may learn that a particular model was developed forn initial feasibility study (and is therefore likely to be ratherimple and inaccurate), while another model was employed for
attt

cal plant design with PDW support.

etailed design calculations and was therefore validated againstxperimental data. Thus, in accordance with the present task,he engineer decides to reuse the latter model.

The model is then retrieved from the PDW and adaptedccording to the specifications of the given design task. Sim-lation experiments are performed, from which the engineererives design parameters such as temperature, flow rates, orimensions. Based on these parameters, the reactor equipmentapparatus, heat transfer equipment, etc.) is specified. Option-lly, the rationale underlying this specification process can beocumented using the concepts of the decision documentationodule. For instance, assume that the engineer is notified aboutstill functional VK tube available from a decommissioned

lant. The capacity of this tube is not sufficient for the newlant, but it can be used to realize an alternative plant designomprising two VK tubes in parallel. In contrast to the orig-nal design, the alternative would require the acquisition of

considerably smaller and cheaper VK tube, which finallyakes the engineer opt for the alternative design. This deci-

ion is likely to become inscrutable when the knowledge abouthe already existing VK tube becomes lost. Thus, the engi-eer explicitly documents the underlying constraints to makeure that his decision in this particular case will not affectther design projects when knowledge from this project may beeused.

.1.4. Step 3: Knowledge captureUp to now, the scenario process comprises specifying a reac-

or design, simulating its behavior, analyzing the results, andnally the decision for a specific design. This process is traced,
nd some design knowledge is extracted, recorded, and stored inhe PDW in order to augment the knowledge base. Apart fromhe product information (the adapted simulation model as well ashe design specification in the Flowsheet Editor), the task-related


c (rig

wTi

ccus

cuiaaedFPDitN

DbtuBt

dMVSfwa

eSu

Fig. 6. The generic (left) and the specifi

orking steps and situations are traced (semi-)automatically.he technical realization of this knowledge capture is discussed

n Section 5.Fig. 7 illustrates how (part of) the application scenario is

aptured within the PDW. Grey boxes represent instances oflasses, which are defined in the peripheral ontology mod-les. For the sake of illustration, the representation has beenimplified.

The Product Area represents the ProductObjects that arereated in the scenario. ReactorBlock is an instance of Prod-ct representing the VK reactor within the Flowsheet Editor;t is contained in the ProcessFlowDiagram v0.7, which isn instance of the DocumentVersion class. ModelFile v1.0 isnother instance of DocumentVersion representing the math-matical model used in the final calculations for the originalesign featuring a single tube. ModelFile v1.0 and Process-lowDiagram v0.7 are the current versions of ModelFile androcessFlowDiagram, respectively, which are instances of the
ocument class. The upper part of the Product Area shows
nstances of the decision documentation module representinghe rationale to use a design with two VK tubes. For theumberOfVK TubesProblem, which is an instance of the class

if(r

ht) visualizations of the search results.

ecisionProblem, two instances of the class Alternative haveeen evaluated with respect to the sub-goal EconomyGoal (onlyhe Evaluation of the TwoTubesAlternative is shown in the fig-re), taking into account the existence of an old VK tube.ased on these Evaluations, the final Decision is in favor of

he TwoTubesAlternative.In the Descriptive Area, the ProductObjects are described by

omain-specific concepts: ModelFile v1.0 is characterized as aathematicalModel that models the behaviour of a VK Tube;K Tube, in turn, describes both the ReactorBlock and theingleTubeAlternative. MathematicalModel and VK Tube areurther specified by the indication of the ChemicalReaction,hich has Caprolactam and Water as reactants and Polyamide-6

s reaction product.In the Storage Area, all file versions of the Aspen Mod-

lFile are storedAt the location “<project>/AspenFile#1” (atoragePlace) inside the DocumentManagementSystem “Doc-mentum”. The Flowsheet Editor uses a database storage of
ts own that can be accessed via certain programming inter-aces. Therefore, this store has been integrated via this interfaceToolInterface), using parameterized StorageQueries to get cur-ent and historical flowsheet data.


plica

tadfioadPm

4

ts

eaTct

4

esnm

Fig. 7. Representation of the ap

The Process Area describes the usage and/or manipulation ofhe Products. The tasks that the engineer performs in the scenariore represented by instances of ProcessTrace (e.g., Modeling toenote the creation of the reactor model, and Deciding for thenal decision to use the two-tube design). Appropriate instancesf the classes User and Tool describe the human and computergents involved in the work process. The ProductObjects pro-uced during the engineering activities are associated with therocessTraces via the relation createdBy, a specialization of theanipulatedBy relation introduced in Fig. 1.

.2. Additional use cases

This section summarizes the different usage possibilities ofhe PDW, some of which have already been mentioned in theection above. In Section 4.2.1, the reuse of product knowl-

oeta

tion scenario within the PDW.

dge (i.e., documents and data) is discussed, while Section 4.2.2ddresses the reuse of process knowledge, including decisions.he support of intra-organizational and cross-organizationalooperation is addressed in Sections 4.2.3 and 4.2.4, respec-ively.

.2.1. Reuse of product knowledgeRetrieval of product knowledge (as well as process knowl-

dge) is supported by three major retrieval mechanisms: (1)emantic search, (2) browsing ontological categories, and (3)avigating through a semantic network of interconnected, the-atically related resources. All these retrieval mechanisms rely

n the description of the resources through meta information. Asxplained before, this meta information is represented by instan-iating the classes and relations specified in the Core Ontologynd their various extensions. The PDW does not only support

3 hemi

caToO

n

4ripfokocatwlotgptd

stSdqT

•

•

r

4pimp

•

•

4stdCb(


onventional, but also content-specific meta information to char-cterize the contents of the different documents and data stores.he terminology for the content descriptions is provided by thentology modules that extend the Descriptive Area of the Corentology, particularly by the domain ontology OntoCAPE.In the following, the usage of the different retrieval mecha-

isms offered by the PDW will be discussed in detail.

.2.1.1. Semantic search. As explained before, semantic searchetrieves information based on the types of the informationtems and the relations between them, instead of using sim-le string comparisons. Queries to the PDW can be composedrom arbitrary concepts (classes, instances, relations, attributes)f the PDW ontologies. A major advantage over conventionaleyword search is the possibility to connect query terms viantological relations instead of using Boolean operators. Inonventional information retrieval, Boolean operators producembiguous queries. Consider, for example, a query for a reac-or that produces Caprolactam. If the logical operator ANDas used to combine the query terms “Reactor” and “Capro-

actam”, the query could refer to a reactor for the productionf Caprolactam as well as to a reactor that takes Caprolac-am as a feed. The ambiguity can be resolved by replacing theeneric AND by the more specific relation “hasOutput” (whichroduces the composite query “Reactor hasOutput Caprolac-am”). That way, the intended meaning of the query is clearlyefined.

The queries are processed by the PDW’s built-in semanticearch engine which tries to match the query expression againsthe meta information describing the various knowledge items.ince the semantics of the ontological concepts are formallyefined, the search engine can interpret the meaning of bothuery and meta information in order to find a semantic match.his approach has the following advantages:

The search engine has the ability to skip homonyms4 during asearch in order to avoid some of the unwanted results producedby conventional search engines. For instance, consider search-ing for information about the reaction of a certain substance.A conventional search using the keyword “reaction” wouldyield not only the desired information but also informationabout allergic reactions to this substance. The semantic searchengine, on the other hand, can distinguish between a chemicalreaction and an allergic reaction since their respective mean-ings are formally defined in the PDW ontologies. Thus, asonly information with the desired meaning is retrieved, theprecision5 of the search is largely improved.Based on the inference functionality offered by the ontology
language, the semantic search engine takes the specializationrelations between ontological classes into account. This helpsto resolve the following dilemma of knowledge retrieval:domain experts prefer to use domain terminology as meta
4 Homonyms are terms with the same spelling but different meaning.5 Precision is defined as the proportion of relevant information out of all the

etrieved information.

b

DCira(


information since this enables the precise description ofknowledge items and therefore increases the probability ofrelevant retrieval. However, such a specialized vocabularyrestricts the access to the knowledge for a novice (Hinds,1999) as well as for a specialist from another area (Dougherty,1992). The PDW supports users of both groups: while domainexperts will prefer a specialized terminology to annotate andquery the repository, non-specialists may use more genericterms for information retrieval. The special terms are derivedfrom the more general ones, and these specialization rela-tions are automatically inferred. Therefore, the knowledgeresources will be found either way. For example, if an expertchooses the term “Reactor” to annotate a resource, it can actu-ally be retrieved by the generic query term “Vessel” sinceReactor is defined as a subclass of Vessel in the ontology.

.2.1.2. Browsing by categories. A second way to retrieveroduct knowledge from the PDW can be achieved by brows-ng the available meta information. To this aim, the ontology

odules that extend the Descriptive Area of the Core Ontologyrovide categories to structure the meta information.

Some Products are explicitly categorized by means of the Cat-egory concept. A well-known example for this type of retrievalmechanism is the Yahoo! Directory, http://dir.yahoo.com/.Classification under more than one category is of course pos-sible.The ContentDescriptions of Products can be searched in asimilar way. As explained, ContentDescriptions are given bythe OntoCAPE ontology. OntoCAPE has a concise structurewhich can be browsed easily: the ontology is thematically par-titioned into sub-ontologies (called “partial models”) whichalready constitute a coarse categorization of the domain. Thepartial models are consistently structured: on the entrancelevel, the top-level classes are organized according to theprinciples of general systems theory (e.g., van Gigch, 1991);the classes are then refined on the lower levels, thus creatingtaxonomies of specialized subcategories. To find informa-tion about a specific topic, one firstly selects the appropriatepartial model and then browses its class hierarchy for metainformation that describe the respective Products.

.2.1.3. Navigating through a semantic network. Another pos-ibility to explore the PDW is given by the ontological relationshat interlink the individual ContentDescriptions. They form airected graph, consisting of nodes which represent instances ofontentDescription and arcs which represent semantic relationsetween these ContentDescriptions. Such a semantic networke.g., Sowa, 1991) of related meta information can be navigatedy means of custom tools like the PDW front-end.

Semantic relations cannot only be used to connect Content-escriptions describing similar contents but also to interrelateontentDescriptions with complementary contents, thus point-

ng to additional product knowledge that would otherwiseemain undetected. For instance, the documents ModelFilend ProcessFlowDiagram created in the application scenariocf. Figs. 5 and 7), provide complementary information about

http://dir.yahoo.com/

hemi

tlfdft

dOt

•

•

eagausEsAfrsthnesi

4

tad

thdh

tp

(

(

4

cTlutmdpcmftwge

ap

4

tnctbcr


he chemical reactor. Therefore, their ContentDescriptions areinked via the modelsBehaviorOf relation. A user may navigaterom the simulation model of the reactor to the flowsheet objectescribing its realization, and vice versa. Such navigation is use-ul in daily work when questions arise like: “Where can I findhe simulation model that was used to design this apparatus!”.

Furthermore, ontological relations may be used to link Pro-uctObjects to concepts from the other areas of the Corentology in order to provide some additional information about

he respective products:

Via relations, it is possible to point from a document to itsauthor or other potential knowledge holders that might berelevant in this context.By connecting ProductObjects to ProcessObjects, it becomespossible to provide information about the organizational con-text (i.e., the work processes and decision-making procedures)in which a product was created, used, or modified. This allowsto answer questions such as “What has this model file been uti-lized for?” or “Which decisions have been taken on the basisof this data?”. That is, by analyzing the organizational contextassociated with some design knowledge, one can evaluate theapplicability of the retrieved knowledge to the current worksituation. As pointed out by Carlile and Rebentisch (2003),the circumstances in which the knowledge has been producedare highly relevant for its successful reuse: if the context ofthe information item changes between storing and reusingthis knowledge, new requirements or novel conditions arise.In this case, the stored knowledge is no longer relevant andcan even become harmful when it is retrieved for reuse andapplied under wrong conditions.

Concluding the discussion about the reuse of product knowl-dge, we would like to emphasize the PDW’s ability to centralizeccess to product information. Such a central point of accessreatly facilitates the retrieval of product knowledge. The PDWllows to simultaneously search the contents of all kinds of doc-ments and data stores, regardless of their respective formats ortorage locations, which reduces the search effort significantly.ase of use is further improved by the fact that the individualources can be explored via a single, familiar user interface.lso, the PDW contains relationships between elements of dif-

erent sources, which allows to find information based on theseelations that are not contained in any of the data sources them-elves. Moreover, the PDW allows to search information sourceshat could not be accessed otherwise, as the user might notave the required software or access rights to open the origi-al sources. And lastly, the search considers even sources of thexistence of which the designer was not even aware. Thus, thecope of knowledge retrieval is widened while the search efforts reduced.

.2.2. Reuse of process knowledge
The PDW contains coarse-grained and fine-grained process
races and decision-making procedures. The rationale leading todecision commonly spans multiple working steps, each withifferent products being manipulated. Hence, the full scope of

tcii

cal Engineering 32 (2008) 320–342 333

he rationale is only recognizable when looking at the processistory. Together with other aspects of the Process Area, theyocument the organizational context in which a certain projectas been or is being conducted.

Beyond this documentation of organizational context, poten-ial applications for reusing this process knowledge are (1)rocess advice, and (2) the automatic execution of processes.

1) One can systematically search for a work context similarto the current situation to find some procedural advice thatis applicable. Moreover, by analyzing the ProcessTraces ofalready accomplished projects, the user can find out whoalready solved a certain type of problem, and he can con-tact this expert directly to draw on the person’s implicitknowledge.

2) This also offers the possibility of analyzing the data todetect recurring fragments. Fine-grained process supportcan then be offered to the user by guiding him or her throughthese fragments, or even enacting those traces in the processengine of the process integrated environment (see PRIMEin Section 5.5).

.2.3. Support of intra-organizational cooperationThe members of design teams need to communicate effi-

iently to achieve the common goal of completing a project.ypically, the team members are distributed across disparate

ocations and use different software tools to create and manip-late product information. The PDW guides and drives theransfer of development product information between team

embers and across software systems. The participating expertsirectly access the repository of the PDW, which contains theroduct and process traces of the project, thus reflecting itsurrent status. Access can be achieved by extending the com-on design tools of the domain with additional, integrated

unctionality that accesses the PDW’s repository. The PDW par-icularly improves the communication in interdisciplinary teamshere the team members have heterogeneous professional back-rounds, as the ontologies provide access at different levels ofxpert knowledge (cf. discussion in Section 4.2.1).

In later stages of the plant lifecycle, the PDW can be used asn information base to support tasks like change management,lant expansion, or claims management.

.2.4. Support of cross-organizational cooperationInformation often needs to be passed on to a coopera-

ion partner, based on strict rules of intellectual property andeed-to-know. Besides the problems of business agreements,ommunications, and the technologies used for informationransfer, it must be ensured that only specific information maye passed across organizational boundaries. Consequently, theooperation partner may only be allowed to have access to aestricted and well-controlled view of the repository.

To define such a view on the side of the contractee (i.e.,
he delegating company), cooperative discussions among theontractee’s experts are necessary. They need to agree whichnformation items (ontology instances), relations between thesetems (ontology relationships), and which of their attributes may

3 hemi

bctefsvw

itaci

miaet

rariaca

5

fdSip

5

abdz1&tia

kwbtnl

tti

pppFhsrimwllpt

skw

5

iTfdtmcTamtw

bstSc“tt

5

sml


e transferred to the external contractor (“released”). The dis-ussion results are recorded in the PDW, including the decisionsaken with their arguments, and the data to be transferred. Thisnables the reuse of these traces in later cooperations. In theront-end of the PDW (see Section 3.3), the instances that corre-pond to the released information can be marked. Furthermore,iew definitions may be abstracted from a concrete view to definehich information items are to be usually released jointly.The marked information can then be exported into an ontolog-

cal format (e.g., OWL, Bechhofer et al., 2004) and transferredo the contractor. This ontological information is defined by

precise semantic structure; thus, the contractor can draw onomputer support (e.g., transformations or matching rules) tontegrate the information into his own information systems.

While the task is being solved at the contractor’s site, infor-ation may be recognized to be missing. In this case, it has to be

nquired from the contractee. The PDW allows finding this datand, possibly, additionally retrieving the decision that led to itsxclusion. This decision may now either be revised (allowinghe data to be released) or confirmed.

As a last part of the cooperation process, the informationeturned from the contractor needs to be reviewed, discussed,nd then integrated into the project flow through the PDW’sepository. Similarly, the PDW can support the contractor,nstead of the contractee as described above. More informationbout the cross-organizational support functionality of the PDWan be found in Brandt, Fritzen, Jarke, and List (2007, chap. 4.1)nd Brandt, Schluter, and Jarke (2006b).

. Knowledge acquisition

This section describes how information, and thus knowledge,rom existing sources can be acquired by the PDW. Section 5.1iscusses the problems of knowledge acquisition in general.ection 5.2 gives an overview on how the PDW handles the

ntegration of external data sources. The subsequent sectionsrovide examples of these integrations.

.1. General problems of knowledge acquisition

Knowledge acquisition – that is, the process of capturingnd storing knowledge in an appropriate format in a knowledgease – is recognized as a major bottleneck when it comes to theeployment of a knowledge management system in an organi-ation (e.g., Abecker, Bernardi, Hinkelmann, Kiihn, & Sintek,998; Carlile & Rebentisch, 2003; Thomson, Adams, Cowley,

Walker, 2003; Zeng, Pan, Zheng, & Peng, 2006). In indus-rial practice, documentation and archival of design knowledges often neglected or not performed at all. The reasons for thisre two-fold.

Employees are reluctant to invest much time in sharing theirnowledge since this requires extra effort on top of their dailyorkload, from which they do not profit personally. Even worse,
y making their knowledge explicit, employees could weakenheir position as indispensable knowledge holders in the orga-ization, and thus facilitate their replacement. Likewise, projecteaders have little interest in enforcing a thorough documenta-
u(Di


ion of processes and key decisions, as these do not count amonghe core activities of a project and are therefore not consideredn the project budget and schedule.

While this lack of motivation can be counteracted by appro-riate reward systems (e.g., Rus & Lindvall, 2002), a secondroblem is that knowledge capture is both haphazard and error-rone: empirical studies (e.g., Furner, Ellis, & Willett, 1999;urnas, Landauer, Gomez, & Dumais, 1987; Leonard, 1977)ave shown that little agreement exists among different per-ons on the sets of annotation terms to be assigned to individualesources. Thus, meta information about products is chosennconsistently and, similarly, work processes and decision-

aking procedures are captured by different users in differentays (e.g., using dissimilar structuring mechanisms on different

evels of detail). Consequently, knowledge retrieval is severelyimited, as only part of the available knowledge items would beroperly integrated into the ontology structure of the PDW andhus could be found by some query.

A solution to these problems is to automate knowledge acqui-ition as much as possible. Depending on the nature of thenowledge, different techniques can be applied, some of whichill be described in the following sections.

.2. Connecting external data sources

The recording of product information is normally realizednside the different software tools of a development environment.hus, an important task of the PDW is to transfer information

rom the external data sources into its repository. This concernsocument-based tools, application tools that use a database storehemselves (such as CAE systems), external databases (such as

aterial databases), and complete software systems that provideertain data or programming interfaces (such as ERP systems).he architectural concepts of integrating these data sources havelready been introduced in Section 3.3. Here, the underlyingechanisms for connecting external data sources and converting

heir contents to and from the information storage of the PDWill be described in more detail.For this goal, a flexible and extensible mechanism had to

e developed for integrating all these different kinds of dataources. External stores and their elements can be representedhrough ontological concepts from the Storage Area, particularlytore and StoragePlace. For accessing the external stores andonverting their data into the PDW format, “connectors” andtransformers” have been designed which will be described inhe following. The two cases of file-based storage and externalool interfaces will be distinguished.

.2.1. Importing documentsWhen working with documents or files, those are usually

tored inside a Document Management System, which auto-atically offers cooperative features like shared folders, file

ocking, access control, and workflow management. The Doc-
mentum (EMC2, 2006) system and the Jakarta Slide systemSlide, 2006), which is based on the WebDAV standard (Webistributed Authoring and Versioning, RFC, 1999), have been
ntegrated with the PDW for this purpose.

hemi

DctcseibtettfiaP

fctSttfhmiiaffifit

dmpmccePtc(drnuicSab

aP

bPw

uasi

5

ecifttatfaadqa

btaf(cPooco

5

aaiipcm2

otr


When a new version of such a document is checked into theMS, the PDW is notified of this change and can then locate the

orresponding ontology instances for the Store, the place wherehe document is stored (StoragePlace), and the logical documentoncept (the Document) with its various versions (DocumentVer-ion). A connector which needs to be specifically developed forach kind of source document, is then responsible for reading thenformation from the external file into an intermediate, XML-ased format. This format is usually specific for each applicationhe document stems from. Sometimes, the information from sev-ral tools may be treated the same way, or needs to be integratedo construct a comprehensive intermediate document (see Sec-ion 5.3 for an example). In most cases, only part of the externalle needs to be read, as some specific details or fine-grainedspects are often not necessary for the “overview” aspect of theDW.

This intermediate XML is then transformed into an inputormat that directly represents instances of the PDW’s con-epts. The appropriate Transformation instance is looked up inhe PDW, and the corresponding transformer is activated. RDFchema (W3C, 2004) is used here as output format from the

ransformers and thus, as input format to the PDW. This hashe advantage that, on the one hand, the KAON system whichorms the base of the PDW, can directly work with it; on the otherand, many cases allow to use powerful XML Schema Transfor-ations (XSLT; W3C, 1999) to convert the intermediate XML

nto the XML-based RDF Schema representation. The Productnstances corresponding to the entities defined in the input files,nd their related descriptive meta information, can be createdrom this data; furthermore, relations to or from existing identi-able instances can be created or modified. It is also possible tond the differences between the existing and the new version of

he document, thus importing only the changes into the PDW.Sometimes, such a transformation is not possible, as the

ocument is too weakly structured or the necessary imple-entation has not yet been realized. In such a case, it is also

ossible to annotate and/or enrich the Document and Docu-entVersion instances of the PDW manually, for example, by

lassifying them into categories or by providing other kinds ofontent description. Several tools are available for this purpose:xisting markup tools like the OntoMat-Annotizer (Annotationortal, 2006) or SemanticWord (Teknowledge, 2006) support

he annotation of informal text documents with ontological con-epts via simple drag and drop operations. The tool TRAMPJarke, Miatidis, Schluter, & Brandt, 2006) has been especiallyeveloped for structuring and annotating multimedia contentsesulting from three-dimensional simulations in plastics engi-eering. Also, the organizational aspect (especially the currentser and workflow activities) can be recorded in relation to themported information: traces of coarse-grained work processesan be captured by the Workflow Modeling System WOMS (cf.ection 5.4). For supplementary information like decisions takennd their arguments, specialized tools (e.g., a decision editor) are
eing developed.
Additionally, environments for fine-grained process supportt the engineering workplaces can store traced experiences in theDW and reuse them when demanded, by providing experience-

(tmd

cal Engineering 32 (2008) 320–342 335

ased methodical guidance for developers. To this end, theRIME process-integrated modeling environment closely inter-eaves with the PDW (cf. Section 5.5).This kind of external source integration described so far is

sually change- or source-driven: that is, when a user changesdocument with the corresponding tool, the new information is

tored in the PDW. This stands in contrast to the query-drivenntegration as described in the following.

.2.2. Integrating databases and toolsOften, information needed for the PDW is stored by an

xternal application in some repository or database format thatannot be accessed directly, but only through the programmingnterfaces offered by the external tool. Sometimes, informationrom such a tool is required in the PDW, e.g., when browsinghrough the experience base and navigating from an instancehat is related to an external storage representation. In this case,

connector as described above, is responsible for retrievinghe required data and writing it into the intermediate XMLormat. Again, this XML data is transformed by the appropri-te transformer and then imported into the PDW as instances,ttributes and relationships. Similar queries can be executed onatabase back-ends, often by using SQL. The execution of theseueries can also be triggered by external events (source-driven,s above), or done regularly.

As an example, the ERP system SAP R/3 (SAP, 2006) haseen integrated into certain PDW-based workflows. This allowso retrieve the transport history of certain goods by calling theppropriate SAP interface method, and use this informationor information visualization and semantic queries in the PDWKopecky, 2006). Usually, the relatively unstructured design pro-esses are not supported by deterministic systems like ERP. TheDW, in contrast, allows to relate these creative design processesn the one hand, with the administrative or business perspectiven the other hand. This can be achieved by integrating the pro-ess traces of the PDW with the project management sub-systemf the ERP system.

.3. Conversion of simulation models

Conversion of document formats with well-defined syntaxnd semantics (databases, XML files, model files, etc.) canutomatically be performed by connectors that extract metanformation from the documents and transformers that mapt onto the ontologies of the PDW. For demonstration pur-oses, a prototypical converter has been developed, whichan automatically create content-specific meta information forodel files of the process simulator Aspen Plus (AspenTech,

006).The converter follows a step-wise approach: in the first step

f this conversion process, a mathematical model represented inhe Aspen Plus input format (.inp), is converted to a so-calledaw XML file, which gives a more structured representation of
selected portions of) the Aspen Plus model. In the next step,he raw XML is transformed into CapeML, an XML-based
odel exchange language specifically developed for the CAPEomain (von Wedel, 2002). This second conversion step com-


f Asp

pomifibTl5

itIi2

vXrecrwted

5

mTTCpiibd(

ttrttto

baibuoetawfawa

5

soataTiva

Fig. 8. Step-wise conversion o

rises a further structural as well as a semantic enrichmentf the raw XML data. Additionally, material property infor-ation derived from an Aspen Plus report file (.rep) may be

ncluded in the CapeML file. In the final step, the CapeMLle is converted to an OWL file; this transformation comprisesoth a format conversion and a further semantic enrichment.he resulting file can then be imported by the PDW (simi-

ar to the import based on RDF Schema described in Section.2).

A graphical illustration of the conversion chain is shownn Fig. 8: the Aspen2CapeML Converter integrates the firstwo conversion steps, which are indicated by the blocks Aspennp(ut) Handler and Report File Handler. The final conversions performed by the XML2OWL Converter (Amin & Morbach,007).

The converters implementing the different steps of the con-ersion chain may also be used independently. In particular, theML2OWL converter is not limited to handling CapeML files;

ather, it is capable of mapping arbitrary XML data onto anyxisting OWL ontology. The conversion from XML to OWL isontrolled by so-called mapping rules specified in an externalules definition file. These rules can be formulated easily andithout deep knowledge of the converter’s program logic. Thus,

he converter can be easily configured to a number of differ-nt mapping problems, such as the WOMS to OWL conversionescribed in the next section.

.4. Process and decision documentation

The Workflow Modeling System WOMS was created forodeling design processes on a coarse-grained level (cf. Hai,heißen, Schneider, Morbach, & Marquardt, 2007, chap. 5.1).he tool, based on Microsoft Visio, supports a variant of the3 modeling language. Its graphical user interface (see Fig. 9)rovides the C3 modeling elements which can easily be draggednto the drawing area. Several macros support the easy and intu-
tive creation of work process models. WOMS is suitable foroth prescriptive models (e.g., guidelines or best practices foresigners) and descriptive models of executed design processesi.e., design traces). As the tool provides an export functionality
otcp

en Plus files into an OWL file.

o XML, the further conversion into OWL is realized by usinghe XML2OWL converter described in Section 5.3; the OWLepresentation can then be imported by the PDW. Depending onhe type of the work process model (prescriptive or descriptive),he OWL representation is based either on concepts defined inhe extension module Work Process & Project Management orn concepts defined in Design Traces (cf. Section 3).

The difficulties in knowledge acquisition described in theeginning of Section 5 are in particular significant for capturingnd documenting the rationale of design decisions. Document-ng design rationale is often seen as an unacceptable overheady designers (e.g., Lee, 1997), while the beneficiaries of the doc-mentation are typically to be found later in the design processr even later in the life cycle of the artifact (Grudin, 1996), forxample, on the occasion of a retrofit of an existing plant. A fur-her obstacle is the reluctance to explicitly document discardedlternatives as they might be conceived as an indication of notorking in an optimal way. In order to support designers as

ar as possible during the creation of decision documentation,n extended version of WOMS is under development, whichill support the integrated documentation of work processes

nd decisions.

.5. Process-integrated tracing and guidance

The considerable heterogeneity of the software toolsupporting various design tasks greatly complicates their inter-perability as well as the exchange of data (cf. Section 2). Asremedy to this problem, integrated tool environments consti-

ute an ambitious endeavor for integrating individual tools intocoherent whole, whose interplay is much easier to coordinate.ypically, such environments employ application and process

ntegration techniques in order to orchestrate the services pro-ided by disparate legacy systems using some sort of middlewarend agreed-upon protocol.

In the context of the IMPROVE project, we aimed at devel-
ping such an approach in order to integrate the heterogeneousools employed during the reference polyamide-6 design pro-ess, and provide method guidance to the designer based onreviously traced experiences. To this end, we adapted the


odelin

Ptc1tetcshapmmJepedcc

mctaepp

ct

•

•

•

•

6

apk

Fig. 9. Workflow M

rocess-Integrated Modeling Environment (PRIME) approacho build an integrated design support environment for chemi-al engineering (Jarke, List, & Weidenhaupt, 1999; Pohl et al.,999; Weidenhaupt, 2001). PRIME is especially well suited forhe realization of tool environments for creative processes, likengineering design processes. It builds on the key idea of a pos-eriori process integration that offers the potential to flexiblyouple different tools. At the same time, it provides flexible,ituated method guidance to the designer directly from insideis tools. More specifically, PRIME is able to record all thections executed inside a process-integrated tool, as well as theroducts worked upon by these actions. The recorded infor-ation is structured according to a concrete traceability metaodel abstracted from a number of case studies (Ramesh &

arke, 2001). On the other hand, recorded process or productxperiences from the past can be reused, on request, insiderocess-integrated tools. Then, the tool is able to automaticallyxecute the steps comprising a requested method fragment, orirectly load products for reuse support, corresponding to theurrent design situation (Miatidis, Jarke, & Weidenhaupt, 2007,hap. 3.1).

The overall PRIME-IMPROVE environment has been imple-ented as a flowsheet-centered architecture that operationally

ouples the fully process-integrated Flowsheet Editor (cf. Sec-ion 4.1) with other domains-specific simulation tools (Bayer et
l., 2001). It has a flexible repository layer that can be fairlyasily adapted in order to exploit the PDW infrastructure for theersistent storage of information manipulated or generated byrocess-integrated tools. More specifically, the PRIME approach
t&td

g System WOMS.

an potentially exploit the following four extension modules ofhe Core Ontology:

process models which are described by using fine-grainedconcepts of the Work Process & Project Management module,can be enacted by process-integrated tools in order to providemethod guidance to the designer;the Design Traces module can be used to build a concretetraceability structure, according to which the design historyinside process-integrated tools is recorded;inside PRIME, process-integrated tools are modeled withrespect to their services and user interface capabilities. Thus,the application tools module can be employed for theirdescription;lastly, descriptions of the products manipulated by process-integrated tools, can be represented using elements from theChemical Engineering Documents module.

. Related work

As already discussed in Section 2, most of the existing PDMnd PLM systems still lack essential aspects needed for sup-orting phases of conceptual design, such as capabilities fornowledge management (Gao et al., 2003), or flexible data struc-
ures that allow runtime extensions and adaptations (Marquardt
Nagl, 2004). Some recent research projects try to extendhe capabilities of PDM/PLM systems. Two examples from theomain of automotive engineering are given in the following.

3 hemi

osamsaosrta

wtccrederop

iea

rtVcLp

ddbAcSfw

otaod

rppcaI

mpiottCtrtoinr

dmor

KeouKioton(r&tbcmafl

hToiAsCddm

rp


Kim, Kang, Lee, and Yoo (2001) have integrated conceptsf artificial intelligence into commercial PDM systems. Theoftware is based on a dynamic and flexible workflow model,s opposed to the deterministic workflows seen in most com-ercial PDM applications. A built-in workflow management

ystem enables the integrated management of task processesnd information flows. The system can be searched by meansf a semantic query and manipulation language. However, theystem relies on prescriptive process definitions which requireelatively well-understood and well-documented processes. Ashis does not apply to conceptual process engineering, thispproach cannot be used here.

Gao et al. (2003) describe an integration of a PDM systemith ontological methods and tools. The Protege ontology edi-

or (Stanford Medical Informatics, 2006) is combined with aommercial PDM system to provide knowledge managementapabilities for the conceptual design stage. In an associatedesearch project, a graphical interfaces for user-friendly knowl-dge acquisition has been developed. In contrast to the PDWescribed here, knowledge needs to be entered manually andxplicitly, based on ontology instances and static rules; expe-ience knowledge is not recorded. Again, this approach reliesn a domain where the processes are better understood than inrocess engineering.

Some research teams are currently developing design repos-tories based on semantic technologies. Two representativexamples from the domain of electromechanical engineeringre described below.

Kopena and Regli (2003) designed an ontology for the rep-esentation of product knowledge. A Core Ontology defineshe basic structure to describe products from a functional view.ocabulary extensions describe the domain of electromechani-al devices. The model representation is based on a Descriptionogic (DL) system with low expressivity to achieve good com-utability and scalability (cf. discussion in Section 7).

Szykman, Sriram, Bochenek, Racz, and Senfaute (2000)escribe a design repository to enable storage and retrieval ofesign artifact knowledge. It is based on a proprietary knowledgease implementation that can be accessed via a web interface.ll queries need to be developed manually and coded as spe-

ific algorithms. The system uses technologies that predate theemantic Web approach. Consequently, it tries to mimic theunctionality of ontological models and semantic technologiesithout reaching their potential.Both described design repositories are limited to the storage

f product data and documents. They do not offer support forhe recording and management of the associated work processesnd decision-making procedures. A review of other recent devel-pments in the area of representation, capture and retrieval ofesign knowledge is given also by Szykman et al. (2001).

An ontological architecture for knowledge management thatesembles the Core Ontology described here has been pro-osed by Abecker et al. (1998). Similar to our approach, the
roposed ontology-based system it is intended to enable bothontent-specific and task-specific retrieval of resources. Theuthors distinguish three types of interconnected ontologies:nformation Ontologies that model the different kinds of infor-
&ntw


ation sources, their structure, access permissions, and formatroperties; Domain Ontologies that describe the content of thenformation sources; and Enterprise Ontologies that model therganizational context, such as the work processes or the struc-ure of an enterprise. Thus, the Information Ontologies coverhe scope of both the Product Area and Storage Area of theore Ontology, the scope of the Domain Ontologies correspond

o that of the Descriptive Area, and the Enterprise Ontologiesesemble the Process Area. The paper gives a good overview onhe process of knowledge management itself and the conceptsf ontological support, from the perspective of computer andnformation science. The application of these concepts to engi-eering domains does not fall into the scope of this particularesearch group.

In the area of chemical engineering, several prototypicalesign environments have been developed based on ontologicalodels and tools. Unlike the PDW, these environments focus

n other aspects than knowledge management and experienceeuse. Some recent examples are given here.

Banares-Alcantara and Lababidi (1995) have developedBDS, a prototypical design support system for process

ngineering. The implementation is based on CLOS, an object-riented extension of Common Lisp, and additionally makesse of an assumption-based truth maintenance system (ATMS).DBS is not a full-fledged KM system, but incorporates some of

ts features: it supports (1) the representation and managementf different design alternatives (i.e., alternative flowsheets) andheir relations to mathematical models, (2) the documentationf the design objectives, (3) the evaluation of a design alter-ative against a previously stated set of design objectives, and4) the evolution of these aspects during a design project. Theepresentation of design rationale in KBDS (Banares-Alcantara

King, 1996) is based on IBIS (Issue-Based Information Sys-ems, Kunz & Rittel, 1970), a graphical notation similar to DRL,ut less expressive. KBDS supports decision-making in the con-eptual design stage and facilitates the cooperation between theembers of a project team. Compared to the PDW, KBDS hasnarrower focus in so far as it covers only information aboutowsheet alternatives and design objectives.

Batres and Naka (2000) and Batres, Naka, and Lu (1999)ave developed the prototypical design environment P-DOSS.he major objective of the P-DOSS system is to enhance inter-perability between different application tools. Within P-DOSS,nformation are described through the ontology MDF (Batres,oyama, & Naka, 2001; Batres & Naka, 2000), which is repre-

ented in the Knowledge Interchange Format, KIF (KSL, 2006).omparable to OntoCAPE (cf. Section 3.2), the MDF ontologyescribes products and processes in the chemical engineeringomain, however with the focus on the later design stages (pri-arily detail engineering and operations planning).Kitamura and Mizoguchi (2003) describe a design envi-

onment called Functional Way Server which is based on therototypical ontology editor Hozo (Kozaki, Kitamura, Ikeda,

Mizoguchi, 2000). In the conceptual design stage, the usereeds to specify the desired function of the engineering artifacto be designed; the system then suggests alternative “functionalays” (e.g., different physical principles) how to achieve the

hemi

asTipkpi2epi

HJVotdpgkspb

sidSaa

7

oIm(t(afeaCobaidp

tlt

tiatsb

a&assagmwpawtRTRtos

ldo

tetcctsipemrsBd

sWdldd


rtifact’s desired function. It also determines the manufacturingteps that are necessary for the realization of each functional way.he Functional Way Server relies on a knowledge base consist-

ng of two major ontologies: the Functional Ontology, whichrovides a comprehensive representation of generic designnowledge, forms the core of the knowledge base. For the sup-ort of conceptual process engineering, the Functional Ontologys extended by a domain-specific Plant Ontology (Mizoguchi,001; Mizoguchi, Kozaki, Sano, & Kitamura, 2000). The knowl-dge base of the Functional Way Server must be developed ariori; unlike the PDW, there are no mechanisms to record andncorporate experience knowledge during project execution.

The Process Information Repository developed by Zhao,ailemariam, et al. (2006), Zhao, Jain, et al. (2006), Zhao,

oglekar, Jain, Venkatasubramanian, and Reklaitis (2005), andenkatasubramanian et al. (2006) aims at the systematic reusef knowledge in the pharmaceutical industries. Like the PDW,he repository stores product knowledge (meta informationescribing the contents of documents and databases) as well asrocess knowledge (deterministic guidelines) in form of ontolo-ies. However, the scope of representable (and thus retrievable)nowledge is limited, as the ontologies of the repository arepecialized on describing particular aspects of pharmaceuticalroducts and processes, and are consequently not as generic androadly applicable as those of the PDW.

Moreover, the system does allow to perform inference andearch operations directly on the repository, but requires load-ng all data into memory first. This is not a practicable optionue to scalability and performance problems (cf. discussion inection 7). A further shortcoming is that the crucial point ofutomated knowledge capture (cf. discussion in Section 5) is notddressed.

. Discussion and outlook

The Process Data Warehouse has been developed as anntology-based repository for the support of design processes.ts key features are: (1) flexible data structures and work processodels for the support of creative and dynamic work processes,

2) improved navigation and retrieval mechanisms based onhe use of Semantic Web technologies (e.g., semantic search),3) integrated representation of resources, content descriptions,nd organizational context to enable experience reuse, and (4)unctionality for (semi-)automatic capture of experience knowl-dge during the execution of design projects. These featuresre achieved by means of a specific architecture: a centralore Ontology which is flexibly refined by extension ontol-gy modules. The application of the PDW has been illustratedy several use cases, including a major application scenariobout the conceptual design of a polyamide-6 production facil-ty. In the following, some of the shortfalls of our approach areescribed, together with possible counter-measures and somelanned extensions.

A major problem of current ontology-based frameworks ishe trade-off between implementation efficiency and descriptiveogical power. Most existing ontology frameworks need to loadhe entire information into memory to work with it. As a result,

rtsc

cal Engineering 32 (2008) 320–342 339

hese frameworks can handle only a relatively small amount ofnstance data. Thus, to develop a system usable for real-worldpplication, it is necessary to use a back-end for database storagehat is directly able to interpret at least some inference rules andemantic queries. The KAON system which the PDW uses haseen realized this way.

On the other hand, the full expressive power of ontologynd description-logic (DL) based languages (Baader, Horrocks,

Sattler, 2004, chap. 1) would offer capabilities not avail-ble in the current PDW. While the PDW is only able to inferupertype and subtype relations, a full-fledged description logicystem would be able to infer certain characteristics of classesnd instances, based on semantic constraints and rules. Thisoes beyond the capabilities of semantic search currently imple-ented in the PDW, as can be seen from the following examplehich extends the use case described in Section 4.2.1: if an inex-erienced user enters information about a reactor, annotating its an instance of the generic class Vessel only, the current PDWill not return this instance when queried for a Reactor. In con-

rast to that, a DL system might contain an inference rule “Aeactor is a Vessel in which a ChemicalReaction takes place”.he system could then conclude that the above Vessel is in fact aeactor, and return it when queried for such. Thus, the recall of

he search (i.e., the proportion of relevant information retrievedut of all the relevant information in the collection) may beignificantly enhanced.

As we did not find a way to combine scalability and fullogic expressiveness, we decided to focus on the former for theevelopment of the PDW. This decision will have to be reviewednce efficient and scalable DL systems have become available.

In addition to this technical aspect, we are planning to extendhe models and application cases of the PDW. Experience knowl-dge from the full plant life cycle is going to be examined, fromhe design phase through plant operation (production), modifi-ations and redesign or reengineering. As a first step, we haveonsidered to extend the knowledge acquisition to the produc-ion stage. One potential benefit of this could be to incorporateelected data from production processes into the PDW and relat-ng it to the simulation models used to design the respectiveroduction facility. This allows to compare the simulation mod-ls with the actual plant performance; thus, when reusing theodels, the model quality can be easily determined. Expe-

iences in this direction have been gained by recording andupporting rubber extrusion processes (Raddatz, Schluter, &randt, 2006), and by feeding these traces back into processesign.

To remedy the difficulties in documenting design and deci-ion rationale mentioned in Section 5.4, an extended version of

OMS is under development, which supports the integratedocumentation of work processes and decisions. In particu-ar, the tool will enable the reuse of fragments of generalizedecision models (decision templates) as part of the decisionocumentation in concrete projects. This approach will not only
educe the effort to create decision documentation but also helphe designer to consider the relevant aspects in a particular case,uch as potential alternatives and their pros and cons underertain constraints.

3 hemi

A

fC4GtCw

R

A

A

A

A

A

A

A

AB

B

B

B

B

B

B

B

B

B

B

B

B

B

B

B

B

B

B

C

D

D

E

E

E

F

F

G

G

H


cknowledgements

Most of the research described in this article has been per-ormed in the context of the Collaborative Research Center onooperative Computer-Aided Process Engineering (CRC/SFB76 IMPROVE, Marquardt & Nagl, 2004), funded by theerman Research Foundation (DFG). The authors would like

o thank their student workers, especially M.A. Amin, M.omanns, M.T. Ikram, J. Kopecky, A. Passen, and J. Renner,ho implemented major parts of the software systems described.

eferences

becker, A., Bernardi, A., Hinkelmann, K., Kuhn, O., & Sintek, M. (1998).Toward a technology for organizational memories. IEEE Intelligent Systems,13(3), 40–48.

grawal, A. K., Devika, K., & Manabe, T. (2001). Simulation of hydrolyticpolymerization of nylon-6 in industrial reactors: Part I Mono-acid-stabilizedsystems in VK tube reactors. Industrial & Engineering Chemistry Research,40(12), 2563–2572.

min, M. A., & Morbach, J. (2007). XML to OWL converter. Technical report(LPT-2007-02), Lehrstuhl fur Prozesstechnik. RWTH Aachen University.

nnotation Portal. (2006). OntoMat Homepage. Available at http://annotation.semanticweb.org/ontomat/index.html. Accessed October 2006.

spenTech. (2006). Homepage. Available at http://www.aspentech.com/.Accessed October 2006.

VEVA. (2006a). VANTAGE Plant Engineering. Available at http://www.aveva.com/products/plant/vpe.html. Accessed October 2006.

VEVA. (2006b). VANTAGE Enterprise Net. Available at http://www.aveva.com/products/plant/vnet.html. Accessed October 2006.

wad, E. M., & Ghaziri, H. M. (2003). Knowledge management. Prentice Hall.aader, F., Horrocks, I., & Sattler, U. (2004). Description logics. In S. Staab & R.

Studer (Eds.), Handbook on ontologies. Berlin, Heidelberg: Springer-Verlag.anares-Alcantara, R., & King, J. M. P. (1996). Design support systems for

process engineering—III. Design rationale as a requirement for effectivesupport. Computers and Chemical Engineering, 21, 263–276.

anares-Alcantara, R., & Lababidi, H. M. S. (1995). Design support systemsfor process engineering—II. KBDS: An experimental prototype. Computersand Chemical Engineering, 19, 279–301.

atres, R., Aoyama, A., & Naka, Y. (2001). A life-cycle approach for model reuseand exchange. In R. Gani & S. B. Jørgensen (Eds.), European symposiumon computer aided process engineering, Vol. 11 (pp. 87–92). Elsevier.

atres, R., & Naka, Y. (2000). Process plant ontologies based on a multi-dimensional framework. In M. F. Malone, J. A. Trainham, & B. Carnahan(Eds.), Proceedings of the fifth international conference on foundations ofcomputer-aided process design, AIChE symposium series no. 323, Vol. 96(pp. 433–437).

atres, R., Naka, Y., & Lu, M. L. (1999). A multidimensional design frameworkand its implementation in an engineering design environment. ConcurrentEngineering: Research and Applications, 7(1), 43–54.

ayer, B. (2003). Conceptual information modeling for computer aided sup-port of chemical process design. Ph.D. thesis. Lehrstuhl fur Prozesstechnik,RWTH Aachen University. Published in: Fortschritt-Berichte VDI: Reihe 3,No. 787. Dusseldorf: VDI-Verlag.

ayer, B., Eggersmann, M., Gani, R., & Schneider, R. (2002). Case studies indesign and analysis. In B. Braunschweig & R. Gani (Eds.), Software archi-tectures and tools for computer aided process engineering (pp. 591–634).Elsevier Science.

ayer, B., & Marquardt, W. (2003). A comparison of data models in chemi-cal engineering. Concurrent Engineering Research and Applications, 11(2),
129–138.
ayer, B., Marquardt, W., Weidenhaupt, K., & Jarke, M. (2001). A flowsheetcentered architecture for conceptual design. In R. Gani & S. B. Jørgensen(Eds.), European symposium on computer aided process engineering, Vol.11 (pp. 345–350). Elsevier.

H


ayer Technology Services. (2006). Engineering software—PEDW. Availableat http://www.bayertechnology.com/eng/products/43 1488.php. AccessedOctober 2006.

echhofer, S., Harmelen, F., van Hendler, J., Horrocks, I., McGuiness, D.,Patel-Schneider, P., et al. (2004). OWL Web Ontology Language Reference.Available at http://www.w3.org/TR/owl-ref/. Accessed September 2006.

erners-Lee, T., Hendler, J., & Lassila, O. (2001). The Semantic Web—A newform of Web content that is meaningful to computers will unleash a revolutionof new possibilities. Scientific American, 17.

ilgic, T., & Rock, D. (1997, September). Product data management systems:State-of-the-art and the future. In Proceedings of the 1997 ASME designengineering technical conferences

randt, S. C., Fritzen, O., Jarke, M., & List, T. (2007). Goal-oriented informationflow management in design processes. In M. Nagl & W. Marquardt (Eds.),Collaborative and distributed chemical engineering design processes: Fromunderstanding to substantial support. Berlin, Heidelberg: Springer-Verlag.

randt, S. C., Morbach, J., Miatidis, M., Theißen, M., Jarke, M., & Marquardt,W. (2006). Ontology-based information management in design processes.In W. Marquardt & C. Pantelides (Eds.), 16th European symposium on com-puter aided process engineering and 9th international symposium on processsystems engineering (pp. 2021–2026). Elsevier.

randt, S. C., Schluter, M., & Jarke, M. (2006b). A process data warehouse fortracing and reuse of engineering design processes. International Journal ofIntelligent Information Technologies, 2(4), 18–26.

randt, S. C., Schluter, M., & Jarke, M. (2006c). Process data warehouse modelsfor cooperative engineering processes. In Proceedings 9th IFAC symposiumon automated systems based on human skill and knowledge.

raunschweig, B., Fraga, E., Guessoum, Z., Marquardt, W., Nadjemi, O., Paen,D., et al. (2004). CAPE web services: The COGents way. In A. Barbrosa-Povoa & H. Matos (Eds.), European symposium on computer aided processengineering, Vol. 14 (pp. 1021–1026). Elsevier.

arlile, P. R., & Rebentisch, E. S. (2003). Into the black box: The knowledgetransformation cycle. Management Science, 49(9), 1180–1195.

assault Systemes. (2006). PLM Solutions. Available at http://www.3ds.com/products-solutions/plm-solutions/. Accessed October 2006.

ougherty, D. (1992). Interpretive barriers to successful product innovation inlarge firms. Organization Science, 3, 179–202.

ggersmann, M., Hackenberg, J., Marquardt, W., & Cameron, I. (2002). Applica-tions of modelling: A case study from process design. In B. Braunschweig &R. Gani (Eds.), Software architectures and tools for computer aided processengineering (pp. 335–372). Elsevier Science.

ggersmann, M., Hai, R., Kausch, B., Luczak, H., Marquardt, W., Schlick, C.,et al. (2007). Work process models. In M. Nagl & W. Marquardt (Eds.),Collaborative and distributed chemical engineering design processes: Fromunderstanding to substantial support. Berlin, Heidelberg: Springer-Verlag.

MC2. (2006). Documentum. Available at http://software.emc.com/products/product family/documentum family.htm. Accessed September 2006.

urnas, G. W., Landauer, T. K., Gomez, L. M., & Dumais, S. T. (1987). Thevocabulary problem in human-system communication. Communications ofthe ACM (CACM), 30, 964–971.

urner, J., Ellis, D., & Willett, P. (1999). Inter-linker consistency in the man-ual construction of hypertext documents. ACM Computing Survey (CSUR),31(4). Article No. 18

ao, J. X., Aziz, F. L., Maropoulos, P. G., & Cheung, W. M. (2003). Appli-cation of product data management technologies for enterprise integration.International Journal of Computer Integrated Manufacturing, 16(7–8), 491–500.

rudin, J. (1996). Evaluating opportunities for design capture. In T. P. Moran &J. M. Carroll (Eds.), Design rationale: Concepts, techniques, and use (pp.453–470). Mehwah, New Jersey: Lawrence Erlbaum Associates, Inc.

ai, R., Theißen, M., Schneider, R., Morbach, W., & Marquardt, W. (2007).Scenario-based analysis of industrial work processes. In M. Nagl & W. Mar-quardt (Eds.), Collaborative and distributed chemical engineering design
processes: From understanding to substantial support. Berlin, Heidelberg:Springer-Verlag.
inds, P. J. (1999). The curse of expertise: The effects of expertise and debias-ing methods on prediction of novice performance. Journal of ExperimentalPsychology: Applied, 5, 205–221.

http://annotation.semanticweb.org/ontomat/index.html

http://annotation.semanticweb.org/ontomat/index.html

http://www.aspentech.com/

http://www.aveva.com/products/plant/vpe.html

http://www.aveva.com/products/plant/vpe.html

http://www.aveva.com/products/plant/vnet.html

http://www.aveva.com/products/plant/vnet.html

http://www.bayertechnology.com/eng/products/43_1488.php

http://www.w3.org/TR/owl-ref/

http://www.3ds.com/products-solutions/plm-solutions/

http://www.3ds.com/products-solutions/plm-solutions/

http://software.emc.com/products/product_family/documentum_family.htm

http://software.emc.com/products/product_family/documentum_family.htm

hemi

I

I

I

J

J

J

J

J

K

K

K

K

K

K

K

L

L

L

M

M

M

M

M

M

M

M

M

M

N

O

O

P

P

P

P

R

R

R

R

R

S

S

S

S

S

S


nnotec. (2006). Homepage. Available at http://www.innotec.de/index.php?id=14&L=l. Accessed September 2006.

ntergraph. (2006a). SmartPlant P&ID. Available at http://www.intergraph.com/smartplant/pid/. Accessed October 2006.

ntergraph. (2006b). SmartPlant Foundation. Available at http://www.intergraph.com/smartplant/foundation/. Accessed October 2006.

arke, M., Lenzerini, M., Vassiliou, Y., & Vassiliadis, P. (2003). Fundamentalsof data warehouses (2nd ed.). Springer-Verlag.

arke, M., List, T., & Koller, J. (2000). The challenge of process data ware-housing. In Proceedings of the 26th international conference on very largedatabases—VLDB

arke, M., List, T., & Weidenhaupt, K. (1999). A process-integrated conceptualenvironment for chemical engineering. In Proceedings of the 18th interna-tional conference on conceptual modeling—ER.

arke, M., & Marquardt, W. (1996). Design and evaluation of computer-aidedprocess modeling tools. In J. F. Davis, G. Stephanopoulos, & V. Venkata-subramanian (Eds.), Intelligent systems in process engineering, AIChEsymposium series no. 312, Vol. 92 (pp. 97–109).

arke, M., Miatidis, M., Schluter, M., & Brandt, S. C. (2006). Process inte-gration and media-assisted traceability in cross-organisational engineering.International Journal of Business Process Integration and Management,1(2), 65–75.

im, Y., Kang, S., Lee, S., & Yoo, S. (2001). A distributed, open, intelligent prod-uct data management system. International Journal of Computer IntegratedManufacturing, 14, 224–235.

itamura, Y., & Mizoguchi, R. (2003). Ontology-based description of functionaldesign knowledge and its use in a functional way server. Expert Systems withApplications, 24(2), 153–166.

opecky, J. (2006). Model-based integration of operating and ERP systems data.Master’s thesis. RWTH Aachen University.

opena, J., & Regli, W. C. (2003). Functional modeling of engineering designsfor the semantic web. IEEE Data Engineering Bulletin, 26(4), 55–61.

ozaki, K., Kitamura, Y., Ikeda, M., & Mizoguchi, R. (2000). Developmentof an environment for building ontologies which is based on a fun-damental consideration of “relationship” and “role”. In Proceedings ofthe sixth pacific knowledge acquisition workshop (PKAW2000) (pp. 205–221).

SL, Stanford University. (2006). Knowledge Interchange Format (KIF).http://www.ksl.stanford.edu/knowledge-sharing/kif/.

unz, W., & Rittel, H. W. J. (1970). Issues as elements of information sys-tems. Working paper no. 131. Institute of Urban and Regional Development,Berkeley. Available at http://www-iurd.ced.berkeley.edu/pub/WP-131.pdf.Accessed October 2006.

ee, J. (1997). Design rationale systems: Understanding the issues. IEEE Expert,12(3), 78–85.

ee, J., & Lai, K.-Y. (1996). What’s in design rationale? In T. P. Moran & J. M.Carroll (Eds.), Design rationale: Concepts, techniques, and use (pp. 21–51).Mehwah, New Jersey: Lawrence Erlbaum Associates, Inc.

eonard, L. E. (1977). Inter-indexer consistency studies, 1954–1975: A reviewof the literature and summary of study results. Occasional papers series,no. 131. University of Illinois Graduate School of Library Science, Urbana-Champaign, IL.

anola, F., & Miller, E. (Eds.) (2004). RDF Primer. Online available athttp://www.w3.org/TR/rdf-syntax-grammar/. Accessed January 2007.

aropoulos, P. G. (2003). Digital enterprise technology—Defining perspec-tives and research priorities. International Journal of Computer IntegratedManufacturing, 16(7/8), 467–478.

arquardt, W., & Nagl, M. (2004). Workflow and information centered supportof design processes—The IMPROVE perspective. Computers and ChemicalEngineering, 29, 65–82.

cMahon, C., Lowe, A., & Culley, S. J. (2004). Knowledge management inengineering design, personalisation and codification. Journal of EngineeringDesign, 15(4), 307–325.

esihovic, S., Malmqvist, J., & Pikosz, P. (2004). Product data managementsystem-based support for engineering project management. Journal of Engi-neering Design, 15(4), 389–403.

iatidis, M., Jarke, M., & Weidenhaupt, K. (2007). Using developers’ experi-ence in cooperative design processes. In M. Nagl & W. Marquardt (Eds.),

S

S

cal Engineering 32 (2008) 320–342 341

Collaborative and distributed chemical engineering design processes: Fromunderstanding to substantial support. Berlin, Heidelberg: Springer-Verlag.

izoguchi, R. (2001). Ontological engineering: Foundation of the next gener-ation knowledge processing. In Proceedings of web intelligence: Researchand development, Lecture notes in computer science, Vol. 2198 (pp. 44–57).Springer.

izoguchi, R., Kozaki, K., Sano, T., & Kitamura, Y. (2000). Construction anddeployment of a plant ontology. In R. Dieng & O. Corby (Eds.), Proceedingsof the 12th European workshop on knowledge acquisition, modeling andmanagement, Lecture notes in computer science, Vol. 1937 (pp. 113–128).Springer.

orbach, J., Hai, R., Bayer, B., & Marquardt, M. (2007). Document models.In M. Nagl & W. Marquardt (Eds.), Collaborative and distributed chemicalengineering design processes: From understanding to substantial support.Berlin, Heidelberg: Springer-Verlag.

orbach, J., Yang, A., & Marquardt, W. (2007). OntoCAPE—A large-scaleontology for chemical process engineering. Engineering Applications ofArtificial Intelligence, 20(2), 147–161.

agl, M., Westfechtel, B., & Schneider, R. (2003). Tool support for the manage-ment of design processes in chemical engineering. Computers and ChemicalEngineering, 27(2), 175–197.

berle, D., Volz, R., Motik, B., & Staab, S. (2004). An extensible ontology soft-ware environment. In S. Staab & R. Studer (Eds.), Handbook on ontologies(pp. 311–333). Springer.

MG. (2004). Unified Modeling Language (UML), version 2.0. Available athttp://www.uml.org/. Accessed October 2006.

ohl, K., Weidenhaupt, K., Domges, R., Haumer, P., Jarke, M., & Klamma, R.(1999). PRIME: Towards process-integrated environments. ACM Transac-tions on Software Engineering and Methodology, 8(4), 343–410.

ostgreSQL. (2006). Homepage. Available at http://www.postgresql.org/.Accessed October 2006.

TC. (2006a). Windchill. Available at http://www.ptc.com/appserver/mkt/products/home.jsp?k=37. Accessed October 2006.

TC. (2006b). CADDS 5i Optegra. Available at http://www.ptc.com/products/cadds/optegra.htm. Accessed October 2006.

addatz, M., Schluter, M., & Brandt, S. C. (2006). Identification and reuseof experience knowledge in continuous production processes. In 9th IFACsymposium on automated systems based on human skill and knowledge

amesh, B., & Jarke, M. (2001). Toward reference models for requirementstraceability. IEEE Transactions on Software Engineering, 27(1), 58–93.

FC—Request for Comment. (1999). HTTP Extensions for Dis-tributed Authoring—WEBDAV. IETF RFC 2518. Available athttp://www.ietf.org/rfc/rfc2518.txt. Accessed October 2006.

olland, C., Souveyet, C., & Moreno, M. (1995). An approach for definingways-of-working. Information Systems, 20(4), 337–359.

us, I., & Lindvall, M. (2002). Knowledge management in software engineering.IEEE Software, 19(3), 26–38.

AP. (2006). SAP—Business software applications and services (homepage).Available at http://www.sap.com/. Accessed October 2006.

chneider, R., & Marquardt, W. (2002). Information technology support in thechemical process design life cycle. Chemical Engineering Science, 57(10),1763–1792.

lide. (2006). The Jakarta Slide project. Available at http://jakarta.apache.org/slide/. Accessed October 2006.

owa, J. (Ed.). (1991). Principles of semantic networks: Explorations inthe representation of knowledge. San Mateo, CA: Morgan KaufmannPublishers.

tanford Medical Informatics. (2006). The Protege ontology editor and knowl-edge acquisition system. Available at http://protege.stanford.edu/. AccessedOctober 2006.

tuder, R., Benjamins, V. R., & Fensel, D. (1998). Knowledge engineering:Principles and methods. IEEE Transactions on Data and Knowledge Engi-neering, 25(1–2), 161–197.

un. (2006). Java 2 Enterprise Edition Homepage. Available athttp://java.sun.com/javaee/. Accessed October 2006.

zykman, S., Sriram, R. D., Bochenek, C., Racz, J. W., & Senfaute, J. (2000).Design repositories: Engineering design’s new knowledge base. IEEE Intel-ligent Systems, 15(3), 48–55.

http://www.innotec.de/index.php%3Fid=14%26L=l

http://www.innotec.de/index.php%3Fid=14%26L=l

http://www.intergraph.com/smartplant/pid/

http://www.intergraph.com/smartplant/pid/

http://www.intergraph.com/smartplant/foundation/

http://www.intergraph.com/smartplant/foundation/

http://www.ksl.stanford.edu/knowledge-sharing/kif/

http://www-iurd.ced.berkeley.edu/pub/WP-131.pdf

http://www.w3.org/TR/rdf-syntax-grammar/

http://www.uml.org/

http://www.postgresql.org/

http://www.ptc.com/appserver/mkt/products/home.jsp%3Fk=37

http://www.ptc.com/appserver/mkt/products/home.jsp%3Fk=37

http://www.ptc.com/products/cadds/optegra.htm

http://www.ptc.com/products/cadds/optegra.htm

http://www.ietf.org/rfc/rfc2518.txt

http://www.sap.com/

http://jakarta.apache.org/slide/

http://jakarta.apache.org/slide/

http://protege.stanford.edu/

http://java.sun.com/javaee/

3 hemi

S

T

T

T

U

v

V

v

W

W

W

W

W

W

Y

Z

Z

Z


zykman, S., Sriram, R. D., & Regli, W. C. (2001). The role of knowledge in next-generation product development systems. ASME Journal of Computationand Information Science in Engineering, 1(1), 3–11.

eknowledge. (2006). Semantic word. Available at http://mr.teknowledge.com/daml/SemanticWord/SemanticWord.htm. Accessed October2006.

heißen, M., & Marquardt, W. (2007). Decision models. In M. Nagl & W. Mar-quardt (Eds.), Collaborative and distributed chemical engineering designprocesses: From understanding to substantial support. Berlin, Heidelberg:Springer-Verlag.

homson, J., Adams, D., Cowley, P. J., & Walker, K. (2003). Metadata’srole in a scientific archive. IEEE Computer Magazine, 36(12), 27–34.

GS. (2006). Teamcenter 2005. Available at http://www.ugs.com/products/teamcenter/. Accessed October 2006.

an Gigch, J. P. (1991). System design modeling and metamodeling. New York:Springer.

enkatasubramanian, V., Zhao, C., Joglekar, G., Jain, A., Hailemariam, L.,Suresh, P., et al. (2006). Ontological informatics infrastructure for pharma-ceutical product development and manufacturing. Computers & ChemicalEngineering, 30, 1482–1496.

on Wedel, L. (2002). CapeML—A model exchange language for chem-ical process modeling. Technical report (LPT-2002-16), Lehrstuhl furProzesstechnik. RWTH Aachen University.

eidenhaupt, K. (2001). Anpassbarkeit von Software-Werkzeugen in prozess-integrierten Entwicklungsumgebungen. Ph.D. thesis. Informatik V, RWTHAachen University.

esterberg, A. W., Subrahmanian, E., Reich, Y., Konda, S., & the n-dim group.(1997). Designing the process design process. Computers & Chemical Engi-neering, 21(S), S1–S9.

indream GmbH. (2006). Managing documents by Windream. Available athttp://www.windream.com/. Accessed October 2006.

Z


3C-World Wide Web Consortium. (1999). XSL Transformations (XSLT), ver-sion 1.0, W3C Recommendation. Available at http://www.w3.org/TR/xslt.Accessed September 2006.

3C-World Wide Web Consortium. (2004). RDF Vocabulary Descrip-tion Language 1.0: RDF Schema. W3C Recommendation. Available athttp://www.w3.org/TR/rdf-schema/. Accessed October 2006.

3C-World Wide Web Consortium. (2006). Extensible Markup Lan-guage (XML) 1.0 (Forth Edition), W3C Recommendation. Available athttp://www.w3.org/TR/xml/. Accessed October 2006.

ang, A., & Marquardt, W. (2004). An ontology-based approach to conceptualprocess modelling. In A. Barbarosa-Povoa & H. Matos (Eds.), Europeansymposium on computer aided process engineering, Vol. 14 (pp. 1159–1164).Elsevier.

eng, A., Pan, D., Zheng, Q. L., & Peng, H. (2006). Knowledge acquisitionbased on rough set theory and principal component analysis. IEEE IntelligentSystems, 21(2), 78–84.

hao, C., Hailemariam, L., Jain, A., Joglekar, G., Venkatasubramanian, V.,Morris, K., et al. (2006). Information modeling for pharmaceutical prod-uct development. In W. Marquardt & C. Pantelides (Eds.), 16th Europeansymposium on computer aided process engineering and 9th internationalsymposium on process systems engineering (pp. 2147–2152). Elsevier.

hao, C., Jain, A., Hailemariam, L., Joglekar, G., Venkatasubramanian, V.,Morris, K., et al. (2006). A unified approach for knowledge modeling in phar-maceutical product development. In W. Marquardt & C. Pantelides (Eds.),16th European symposium on computer aided process engineering and 9thinternational symposium on process systems engineering (pp. 1929–1935).Elsevier.

hao, C., Joglekar, G., Jain, A., Venkatasubramanian, V., & Reklaitis, G. V.(2005). Pharmaceutical informatics: A novel paradigm for pharmaceuticalproduct development and manufacture. In L. Puigjaner & A. Espuna (Eds.),European symposium on computer aided process engineering, Vol. 15 (pp.1561–1566). Elsevier.

http://mr.teknowledge.com/daml/SemanticWord/SemanticWord.htm

http://mr.teknowledge.com/daml/SemanticWord/SemanticWord.htm

http://www.ugs.com/products/teamcenter/

http://www.ugs.com/products/teamcenter/

http://www.windream.com/

http://www.w3.org/TR/xslt

http://www.w3.org/TR/rdf-schema/

http://www.w3.org/TR/xml/