ORIGINAL PAPER

An engineering design knowledge reuse methodologyusing process modelling

David Baxter Æ James Gao Æ Keith Case ÆJenny Harding Æ Bob Young Æ Sean Cochrane ÆShilpa Dani

Received: 28 September 2005 / Revised: 22 August 2006 / Accepted: 22 August 2006 / Published online: 11 April 2007

� Springer-Verlag London Limited 2007

Abstract This paper describes an approach for reusing

engineering design knowledge. Many previous design

knowledge reuse systems focus exclusively on geometrical

data, which is often not applicable in early design stages.

The proposed methodology provides an integrated design

knowledge reuse framework, bringing together elements of

best practice reuse, design rationale capture and knowl-

edge-based support in a single coherent framework. Best

practices are reused through the process model. Rationale

is supported by product information, which is retrieved

through links to design process tasks. Knowledge-based

methods are supported by a common design data model,

which serves as a single source of design data to support

the design process. By using the design process as the basis

for knowledge structuring and retrieval, it serves the dual

purpose of design process capture and knowledge reuse:

capturing and formalising the rationale that underpins the

design process, and providing a framework through which

design knowledge can be stored, retrieved and applied. The

methodology has been tested with an industrial sponsor

producing high vacuum pumps for the semiconductor

industry.

Keywords Design knowledge reuse � New product

introduction � Knowledge management � Product lifecycle

management

1 Introduction

Engineering design in mature domains is increasingly

competitive in today’s globalised manufacturing environ-

ment. One approach to assist in this competitive cycle is to

reuse previous knowledge, and the main aim of this project

is to provide an engineering knowledge management

methodology to enable the creation of robust designs in

less time, with lower production costs.

Although the design process output, or solutions can be

directly reused, they cannot be expected to function in the

same way if they are directly scaled or if elements of them

are reused in different systems. Knowledge relating to

geometry can otherwise be reused through the formalisation

of associations between product parameters. This enables

optimisation of functionality where products are scaled up

or down within certain limits. Parametric associations that

are embedded in CAD models help to speed up product

development, reducing the time required to reproduce well-

known components. Many Knowledge-Based Engineering

(KBE) tools provide the above functionality, which provide

solutions that interact with product data, particularly

geometry. However, there is a wealth of non-geometric

knowledge elements that could be reused but is missing

from KBE systems. These include: project constraint rea-

soning, problem resolution methods, solution generation

strategies, design intent and supply chain knowledge.

D. Baxter (&)

Decision Engineering Centre, Cranfield University,

Cranfield, Bedfordshire MK43 0AL, UK

e-mail: d.baxter@cranfield.ac.uk

J. Gao

School of Engineering, The University of Greenwich,

Kent ME4 4TB, UK

e-mail: j.gao@gre.ac.uk

K. Case � J. Harding � B. Young � S. Cochrane �S. Dani

Wolfson School of Mechanical and Manufacturing Engineering,

Loughborough University, Loughborough,

Leicestershire LE11 3TU, UK

123

Res Eng Design (2007) 18:37–48

DOI 10.1007/s00163-007-0028-8

A significant body of research work has addressed the

subject of what knowledge is, how tacit and explicit

knowledge differ and evolve (Nonaka 1994) (Saviotti

1998), that tacit knowledge is best dealt with by social

methods and not IT systems (Lubit 2001) or that tacit

knowledge can not be represented in an IT system (Jo-

hannessen et al. 2001) (Walsham 2001). The classic data,

information and knowledge hierarchy has been questioned

(Tuomi 1999). Many papers with ‘knowledge’ in the title

(particularly within engineering) do not attempt to address

the issue of what knowledge is, they simply provide

methods and tools for the business of managing it. In the

context of this paper, knowledge will be considered as

‘actionable information’. It is further assumed that

knowledge can be stored in computer-based systems, and

in a variety of forms: documents (text), images, diagrams,

embedded algorithms, formulae and rules. The important

factor is that the ‘knowledge object’ infers knowledge to

the user and that the object is in a format that enables

appropriate application. Since it has previously been ap-

plied and stored, this application is reuse, and thus,

knowledge reuse.

2 Review of design reuse

A selection of existing reuse methods will be described,

relating to methodology, CAD/Computer Aided Engi-

neering (CAE), function, meaning (ontology) and matching

(case-based reasoning, CBR). Reuse relating more specif-

ically to the design process will be described in the fol-

lowing section.

Some approaches to design reuse base the system on a

design methodology (Shahin et al. 1999) (Blessing 1995),

structuring the elements of the system around the concep-

tual framework given by the design methodology (typically

systematic design). General design methodology can form

a core element of a design reuse method, or could itself be

regarded as a design reuse method, in which fundamental

principles are reused rather than specific design instances.

Axiomatic design (Suh 1990) is an approach to systematise

the design effort. Based on a formulation of the design

requirement (which is cited as the most important and

difficult task in engineering) alternative solutions can be

tested against the principles, or design axioms. The core

assumption supporting the axiomatic approach is that there

is a fundamental set of principles that determine good de-

sign practice.

CAD/CAE based design reuse methods include com-

ponent reuse, parametric design (both generative and var-

iant: see Andrews et al. 1999) and KBE systems. Most

Computer Aided Engineering (CAE) systems (such as

Unigraphics, Catia, Pro-Engineer and ICAD) provide

parameter-driven knowledge modelling capabilities which

are normally based on a geometric model. These systems

have design rules embedded in the parameters, and are

used for very specific engineering calculations. They are

very well suited to solving complex, highly structured

problems in which a level of optimisation is required.

Knowledge-Based Engineering is generally regarded as

an umbrella term describing the application of knowledge

to automate or assist in the engineering task. KBE can be

applied to a wide range of design tasks (Hew et al. 2001).

Design knowledge, once embedded in KBE systems, is not

accessible (for reuse) to non-programmers. This limits the

potential to reuse the knowledge in other applications. In

order to make this knowledge more generally reusable, the

Methodology and tools Oriented to KBE Applications

(MOKA) project provides a standard methodology for

developing KBE applications, enabling reuse of the cap-

tured knowledge through a modified-UML knowledge

representation method (Sainter et al. 2000).

Design reuse approaches that apply function (Rodgers

et al. 1999, 2001) base the knowledge structure on a

functional decomposition, which is a similar approach to

QFD. In the CADET system, a flexible rule base is applied

to describe the domain knowledge—i.e. relating product

attributes such as wheel size to requirement attributes such

as ‘easy to push’. Another example is the Product Range

Model (Costa and Young 2001), which is intended to

support variant design activities through the representation

of product functions, relevant design solutions and

‘knowledge links’ between these attributes.

In terms of shared understanding and knowledge rep-

resentation, the development of ontology and its applica-

tion to engineering design is providing a means to represent

domain knowledge: understanding product (and manufac-

turing, service, etc.) concepts, data elements and relation-

ships between concepts (Kerr et al. 2004).

Case-Based Reasoning has been applied in a variety of

ways to enable design knowledge reuse. Essentially, it in-

volves creating an index of the problem area, then applying

artificial intelligence techniques to find similar cases. One

relevant example is the conceptual design information

server, in which the cases are selected by the user from a

wide variety of information sources to support conceptual

design (Wood III and Agogino 1996).

2.1 Design reuse issues

Around 20% of the designer’s time is spent searching for

and absorbing information. This figure is even higher for

technical specialists (Lowe et al. 2004a). Furthermore,

around 40% of all design information requirements are met

by personal stores, despite the fact that more appropriate

information may be available from other sources. The type

38 Res Eng Design (2007) 18:37–48

123

of information used changes during the design process

(Lowe et al. 2004b).

Some important factors to enable reuse include a

method to first make design reusable, then to store the

reusable elements so that they can be found. Even if

knowledge stored in computer-based systems is accessed,

if it is to be reused, several additional factors must be

met: reusability, availability and relevance. Efficient

exploitation of past designs has been prohibited by the

lack of a methodology to structure past designs and

information (Shahin et al. 1999). With a well-structured

library of reusable past designs, and a method to make

new design reusable, the issue of design reuse is greatly

simplified.

Busby provided a detailed study into problems with

design reuse (Busby 1999). Most reuse problems were

cases of reuse not taking place: belief that reuse was

desirable but not practised. The next most common prob-

lem was an unexpected amount of additional effort to re-

use. Others were knowledge loss through inappropriate

replication, and error where existing designs were reap-

plied to new purposes.

A review of design reuse was carried out (Sivalogana-

than and Shahin 1999). Several areas of future work are

proposed, including: compatibility of knowledge models

and design reuse models; integrating reuse tools with other

systems; recording bad designs.

Design reuse remains a developing area, and many ap-

proaches have been developed. Further effort is required to

understand the needs of knowledge users and producers in

order that appropriate methods can be applied (Markus

2001) (Busby 1999) (Finger 1998).

2.2 Process-based design reuse methods

It has been suggested that the design process is a driver of

design reuse for decision making at all stages of product

development (Inns and Neville 1998). Design reuse tools

should support the project (or design process) as a means to

reuse knowledge, either through guidance to reapply

knowledge at the most effective time or through the capture

and application of the knowledge embedded in the process

itself. If these factors can be combined, the process can be

used as a basis for design knowledge reuse (Baxter and

Gao 2004, 2005). The following table represents an attempt

to categorise existing work in which the design process has

a relationship to design knowledge management or design

reuse.

• Design process as KM core: the design process forms a

central element of the knowledge management method,

either through process templates, product model inte-

gration or knowledge-based process support (Blessing

1995; Backer et al. 1995; Park and Cutosky 1999;

Clarkson and Hamilton 2000).

• Integrating design rationale process: achieved either

through annotation of a process model or by describing

dependencies as part of the process (Burge and Brown

2002; Ramesh and Tiwana 1999).

• Socio-technical system: describing the design process

as a socio-technical system has implications for repre-

sentation, management and computation (Lu et al.

2000; Ramesh and Tiwana 1999; Tucker and Hackney

2000).

• Business process model: describing design in terms of

task dependencies, inputs, outputs, constraints and so

on. This type of research provides a means to represent

and manage design through the application of a logical

structure (Shooter et al. 2000; Hayashi and Herman

2002; Tate and Nordlund 1996; Yassine and Falken-

burg 1999; Gorti et al. 1998; Kalpic and Bernus 2002;

Pakovich and Marjanovich 2001; Huang and Gu 2006;

Park and Cutosky 1999; Concheri and Milanese 2000;

Clarkson and Hamilton 2000; Sim and Duffy 2003;

Pavkovic and Marjanovic 2000).

• Business process framework: as with the business

process model category, the process is described as a

logical mechanism. The research categorised as ‘frame-

work’ rather than ‘process’ describe the business model

in a broader sense, as a collaborative exercise between

business or product entities (Salminen et al. 2000;

Blessing 1995; Backer et al. 1995; Huang and Gu 2006;

Classen and Lopez 1998; Paashuis and Boer 1997).

• Decision support through designer monitoring: the

designer interactions with a workstation (direct inter-

action) or PLM system (database changes) are moni-

tored and responded to: active and dynamic design

process support (Leake and Wilson 2001; Li et al.

2004; Harding et al. 2003).

• Design methodology as process description or man-

agement method: a general design methodology forms

a key element of the process representation approach,

or is applied as a process management method—i.e. the

design process describes how to follow the steps

prescribed by the methodology (Tate and Nordlund

1996; Shahin et al. 1999; Hicks et al. 2002; Blessing

1995; Salminen et al. 2000; Backer et al. 1995; Gardam

and Burge 1997; Pakovich and Marjanovich 2001; Li

et al. 2004; Xu et al. 2002; Paashuis and Boer 1997;

Clarkson and Hamilton 2000; Hansen and Andreasen

2002; Schofield and Gregory 2002; Knott et al. 2003; Li

et al. 2004).

• Design article representation: a relationship between

the product and the design process: as a product of the

process, a means to monitor the process, or as

integration of knowledge types through mapping rela-

Res Eng Design (2007) 18:37–48 39

123

tionships between process and product (Shahin et al.

1999; Hansen and Andreasen 2002; Li et al. 2004;

Concheri and Milanese 2000; Xu et al. 2002).

• Design information capture and representation: a

method embedded in the design process to promote

and enable reuse across projects, products, processes or

decisions (Hicks et al. 2002; Matsumoto et al. 2005;

Concheri and Milanese 2000; Zdrahal et al. 2000;

Ramesh and Tiwana 1999; Knott et al. 2003; Bala-

subramanian et al. 1999).

This analysis highlights some issues for further research:

the relationship between the design process and the design

object is not well understood. Integrating rationale with the

design process has relatively little work. Design process

models as an integrated part of knowledge management

also requires further analysis to identify the limits and

nature of applicability determined by the type of design

process. Another area for further research is an integrated

knowledge reuse method for engineering design, in which a

process model and product model are provided in a single

framework.

One project which addresses some of these issues is the

Federated Intelligent Product EnviRonment (FIPER) pro-

ject. This approach describes an environment within which

a variety of distributed services can be applied to an

intelligent CAD master model. Software tools act as dis-

tributed service providers and service requestors (Rohl

et al. 2000). Extensions to the project include a workflow

model, developed to manage process definition, execution

and resources (Wujek et al. 2000). The intelligent master

model is most suitable for variant design in well known

areas, where extensive product knowledge has been built

up over many years and next generation will share much of

the same geometrical relationships. It is also apparently a

project with a focus on detail design, since the central

element of the approach, the master model, is a CAD-based

representation.

Other notable process-based methods include Signpo-

sting and the Design Roadmap (DR). Signposting (Clark-

son and Hamilton 2000) is a parameter driven task-based

model of the design process. The task model does not have

strong precedence links; instead the method uses the level

of confidence in key design and performance parameters as

the basis for identifying, or signposting, the next design

task. The Signposting method is well suited to the devel-

opment of new technologies in well-understood application

areas. The DR method provides a novel formal method to

represent the design process (Park and Cutosky 1999). The

method enables the representation of feedback and feed-

forward processes, which are common in design yet

uncommon in other representations. The process data

model enables a variety of graphical representations, or

views. Graph, matrix, tree and list views are supported.

Additional functions, including resource management,

document attachment and notification functions were ad-

ded to the DR framework. The method mainly addresses

project management issues, which implicitly applies

product knowledge.

2.3 Next step of design reuse research

Existing methods to reuse design knowledge are generally

not compatible with the whole product design process:

some are suitable in conceptual design; most are focused

on detail design. Further research is needed to explore the

potential of an integrated process and product modelling

approach. This should include non-geometric knowledge

such as problem solving methods, solution generation

strategies, design intent and project knowledge. These

knowledge types are associated with the variety of tasks in

today’s dynamic design process. The method proposed in

this project complements the existing approaches by en-

abling product data to be linked to the non-geometrical

information through the process model. The CAD-based

methods will remain highly valuable in supporting detailed

design, while these other elements can support early stages

of product development.

3 Overview of the proposed approach

The underlying principle of the proposed approach is based

on the interaction between a design process model and a

product data model through a set of parameters to meet the

particular needs of the application area: mature engineering

design. In the early stage of new or developing designs, a

great deal of details underlie (and can be extracted from) a

description of a product that includes only a small number

of parameters. These parameters may relate to size, per-

formance, or other technical characteristics. Technical

product types often include or refer to these parameters in

the product name (e.g. iH 600, an ‘intelligent harsh

600 m3 h–1 pump). The parameterised model of the prod-

uct is then extended to include parameters that are calcu-

lated, or inferred, from the original specification. These

parameters form a key element in the creation of a product

development process describing the best approach to the

design of that product within the organisation concerned.

Assuming that the organisation has developed similar

products in the past, a large amount of product knowledge

can be applied to the creation of the design process. During

enactment of the design process, the parameter-based

product model is applied. As the process model is carried

out, the product model is populated. Computational meth-

40 Res Eng Design (2007) 18:37–48

123

ods are applied through the creation of relationships be-

tween the process task model and the parameterised

product model. This architecture enables a variety of

analysis methods to use the same data set. The resulted

product and process model together can be regarded as a

project model or project template, and can be extended for

specific product instantiations. The project model is created

in such a way that the data sets are populated at the most

appropriate time—and so any product analysis is scheduled

to take place when the data is available.

The proposed design knowledge reuse system therefore

has two key elements (see Fig. 1): a Process Model and a

Product Model. The Process Model itself provides a de-

tailed structure that can be applied to the index and re-

trieval of additional information. The Product Model is a

combination of product data and ontology. The product

ontology in this case is a formal vocabulary defining the

product objects. The product data can be directly manip-

ulated within the system or externally. The product ontol-

ogy enables reasoning relating to product concepts, and

retrieval of similar concepts. The Process Logic Engine is

the interface with the Process Model, which manages the

assignment and updating of tasks. The Process Logic En-

gine also interacts with the Product Model, through the

assignment of product data in the form of features. The

Process Logic Engine serves as a trigger for the Library of

Analysis Methods. These methods use the product data as

input, carry out their function, and store the result in the

product model database. There is also a link between the

Process Model and the Library of Analysis Method to al-

low dynamic management of the process itself.

A major contribution of the method is derived from

creating it. The method requires an investigation to capture

the design process, followed by in-depth analysis to create

the project model (template). This exercise will allow the

organisation to formalise and improve their methods in

advance of applying the tool, which itself will provide

benefits.

As the limited scope of this project, the product model

will be created to satisfy a minimum requirement, i.e. to

allow the applicability and usefulness of the method to be

evaluated during design process execution. The emphasis is

its flexibility and extensibility (not its completeness), i.e.

when the product model is created, the product parameter

exists as an open data field that can be set to a variety of

standards (real, integer and string). With the process model

established, links can be created that point to additional

data, enabling a focused retrieval method for information

associated with a given task or task set.

4 Case study

The industrial partners supporting the research project that

this paper is reporting on are involved in mature engi-

neering domains. A detailed design process model has been

developed, and the supporting knowledge has been cap-

tured and added to the model. The following section de-

scribes the approach in more detail, with a description of

the example.

4.1 The selected component

The component selected for the knowledge capture exer-

cise is the Head-plate, shown in Fig. 2 The Head-plate

serves several critical functions for the operation of the

vacuum pump: seal, support and lubrication. Internal or

shaft, seals prevent oil from crossing from the bearing

cavity to the process chamber. External seals prevent

transfer of atmospheric gas. Bearings support the shaft

under load. They are lubricated with a single charge of oil

for the service life of the pump.

The Head-plate is designed as a common item for a

range of pump types. View (a) is the Head-plate stator side.

The stator face is a key element of its functionality. Part of

the functionality. Critical elements include stator toler-

ances, shaft seal and atmosphere seal. View (b) shows the

bearing bores, critical elements include bearing bore

geometrical and positional tolerances. The dynamic seal

ProcessModel Data

+Knowledge

Task Data+

Knowledge

ProductModel Data

+knowledge

Process Logic Engine

Fig. 1 System architecture

iew (a) View (b) View

pr

(c)

Bbearing

orePumStato

V

Fig. 2 Images of the Head-Plate showing different functional

features

Res Eng Design (2007) 18:37–48 41

123

system, including gas flow channels for purge and pressure

balancing, plays a major role in pump reliability. One gas

flow channel can be seen in view (c).

4.2 Process capture and representation

The design process for the Head-plate component was

captured, and first represented using Integration Definition

for Function Modeling IDEFø (NIST 1993). IDEFø in-

cludes activity boxes, with arrows representing inputs,

outputs, controls and mechanisms. A single activity rep-

resents the high-level purpose. Each activity can be broken

down and shown in more detail in a child diagram.

The process capture was extended to show the source of

the inputs to the design of the Head-plate. The IDEFø

representation requires several interrelated diagrams. The

resulting process, at the top level of abstraction, included

eight tasks. The IDEFø formalism specifies six activities

per page, which means that the diagram is not able to show

the whole process. It was also considered that this pre-

vented the representation of both context and detail in a

single representation. The IDEFø series enabled an ob-

server to gain an understanding of what is happening

during the process. This would be adequate if the system

analysis task was required for that purpose (as it is in a

system design project). The requirement of the process

representation method in this scenario is that it will enable

the process to be reapplied, and knowledge about it to be

reused. For this purpose the context is important, and so

combination of the six-node limit along with the complex

array of link types shown in an IDEFø diagram prompted

the search for an alternative. It should be emphasised that is

not a lacking in the process logic that prompted the

selection of an alternative process modelling method. The

change was driven by the need to understand, at a glance,

an overview of the process and its context. This require-

ment is in support of system usability.

The Head-Plate design process was later modelled using

the DR Framework (Park and Cutosky 1999). The DR

representation consists of two node types, task (the task

itself to be enacted) and feature (which is a task data set).

Link types include precedence, abstraction and constraints.

Precedence shows order of task execution, and likely

iteration. Abstraction relates to the capability for a se-

quence of elements to be represented by a single element.

Constraint links connect feature nodes, and show that a

constraint exists. Note that the term ‘feature’ is the name

given to the data objects included in the process model. It

bears no relation to other uses of the term ‘feature’ in the

engineering domain.

Figure 3 shows a view of Head-plate Design Tasks,

modelled using DR Framework, with some of the Features

and their attribute slots visible. Iterations, feedback and

side-effects have been removed for simplicity. Within the

Head-plate design task, both sequential and concurrent

activities take place. Data that is required by later tasks is

recorded in the features. For example, the Bearing Bore

Feature contains data (size and tolerance) that will be used

in the lubrication system design Task (see top of Fig. 3).

This same data set could also be used as an input to a

manufacturability analysis Task, i.e. data sets can be called

by any Task object. The main objective of the Features

shown in this diagram is to provide data required by sub-

sequent tasks. It is the Feature that triggers the Task. If a

data set is required but not complete, the task will not be

initiated.

4.3 Parameterised product model

The process representation method allows data to be car-

ried through the process using the Feature nodes. Within

this application, the data that is represented in the Feature

nodes is both created and used by the Tasks. For example,

the Requirements Specification Task produces a fully

populated engineering requirements data set. Other Tasks

use this Feature data as an input. It is possible to have a

Task creating multiple Features, and for a subsequent Task

to use multiple input Features.

The data handling provided by the process model en-

ables the Parameters of the product to be created through

the enactment of the design process. An implicit method

for the handling of the data set is embedded in the design

process, i.e. what the parameters are, where they are cre-

ated, and where they are used. The explicit methods ap-

plied to the storage and manipulation of the data set are not

made clear, so must be defined.

A full implementation of this method may involve

several thousand Parameters. Grouping the parameters into

Sets (Objects) could ease the retrieval and reuse process.

Rather than call an individual Parameter, an Object could

be called. These Objects are called by the Features in the

Process Model. Using an inheritance model, it will be

possible to treat the Parameter Set as a hierarchy of Ob-

jects. The attributes of the objects are populated through

the product design process.

4.4 Spreadsheet-based test system

This section describes how Microsoft Excel is used to

implement the design knowledge reuse methodology. The

Excel implementation applies a process model as the

central element. The process model is shown in Fig. 6. The

prototype system architecture is described in Fig. 4. This

prototype system differs from the system architecture

described in Fig. 1. In the prototype system the process

model itself is the central element, with links to task data

42 Res Eng Design (2007) 18:37–48

123

and product model data. The task model has a user inter-

face providing access to product model data.

The process model contains links to the feature (data

set) and task interface. In the Excel system, each feature

and task object has its own worksheet. An example of the

links between the worksheets is shown in Fig. 5: the

‘engineering requirements’ data set and the ‘mathematical

model’ task are accessed is via the corresponding process

object.

The ‘feature’ link opens a worksheet containing a read-

only view of the relevant product parameters. Changes are

made to the product master model via the task pages. Each

task page, such as the mathematical model task in Fig. 8,

includes ‘output’ cells, which are the data input cells.

Changes to these cells are reflected in the product master

model, which is a separate worksheet.

Once a task is completed and the data is entered into the

output cells, the user will click the ‘back’ button (bottom-

centre of Fig. 7), which links back to the process model, as

shown in Fig. 6. From the process model the user has the

option to click on another task to complete or to click on a

feature to view the data set contents. Future implementa-

tions should provide a dynamic mechanism to guide the

user to the next task. This prototype system requires the

user to select the appropriate task.

In addition to the read-only data input and the editable

data output fields, each task page contains: task description,

related information and an expert directory. These fields

can be seen in Fig. 7. In order to reduce the information

content of the task page, much of this information is stored

elsewhere and accessed via hyperlinks. These links may

refer to internal sources in other worksheets, or external

sources on networked drives or the Internet.

It can be seen that the Description header shows the

synopsis of a more detailed Task Description document.

The Related Information section contains links to other

documents, images or files. The Expert Directory section is

arranged by specialism, in which each link goes to another

page containing information about individuals, their

experience, and their contact details.

Parameters contained in the Feature objects are shown

on the Task page. One such feature, ‘engineering require-

ments’ is shown in Table 1. The Parameters in each feature

refer to data stored in the Master Product Model. In the

Excel model this is contained in a separate worksheet. This

TaskDrive Layout

(motor, gears, shaft)

TaskLubrication system (thrower, channels)

layout

TaskLip seal layout

TaskDynamic seal

design

TaskBearing bore layout

TaskHeadplate Stator

Layout

Feature: Bearing Bore

Size (diameter, depth)

Bore Tolerance

Geometry Tolerance

Feature: h/p Stator

Size (diameter, depth)

Bore Tolerance

Geometry Tolerance

Feature: Drive

Gear position

Motor fixing

Shaft size

Feature: ThrowerSize:diameter

depth

Tolerances

Feature: Gas flow

Channel location

N2 Flow rate

Feature: Lip Seal

Internal diameter

External diameter

Tolerances

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Fig. 3 The Head-plate Design tasks modelled using design roadmap framework

UpdateTask model Data + Product

Model Data KnowledgeAccess

Process model

Fig. 4 Prototype system architecture

Res Eng Design (2007) 18:37–48 43

123

method enables a single parameter to be accessed by

multiple features. The Product Data includes Feature name,

Data, Data Type and Units parameters. Only the name and

data are displayed in the task pages. The data type and units

fields are for error checking and consistency: calculations

on product parameters should not be allowed where the

units are not compatible.

Within the Master Product Model there is scope for a

Standard Parameter Set, relating to standard components

such as standard dowels, along with the associated product

features—in this case tolerances for the associated press fit

and clearance fit holes, along with other product features.

The Product Model also contains any necessary universal

data, such as density of iron, to enable calculations—in this

case the mass of components.

4.5 System Knowledge

Three knowledge elements are included in the proposed

knowledge reuse system: best practices knowledge

(embedded in the process), task knowledge (supporting

information and algorithms or knowledge-based methods)

and product knowledge (a product parameter template).

4.5.1 Process knowledge

The product model and process model together enable

effective distributed collaboration on the product design.

The process model itself represents knowledge relating to

the process (best practices knowledge). A deep knowledge

of the product and experience of carrying out the design

Fig. 5 Process object links

TaskMath. modelling

Feature A Engineering

Reqmnts

TaskMotor selection

TaskGear selection

Task 4Cartridge Layout

TaskBearing selection

TaskHeadplate design

TaskDynamic model

TaskReqmnts

Specification

Feature B Product Model

Feature C Shaft dynamics

Feature D Cartridge model

Feature G Bearing Spec

Feature H Gear spec

Feature I Motor spec

Fig. 6 Design task overview showing precedence relationships

44 Res Eng Design (2007) 18:37–48

123

process in the context of the organisation are required to

specify the ‘best’ design process model. The sequence of

activities to produce the required product function in the

most effective way includes knowledge of relationships

between product components, parameters and materials.

Process decisions such as likely or necessary iterations and

task dependencies all contribute to the development of the

process model. Additional project related (i.e. non-engi-

neering) factors such as component lead time, product test

times and organisational factors such as the availability of

expertise and systems also contribute to the process model.

As such, the process model represents one of the knowl-

edge elements embedded within the proposed method.

4.5.2 Task knowledge

The second knowledge element is task knowledge. This

includes information and automation. Supporting infor-

mation is available to support the designer in completing

the task. It includes general notes, formal design docu-

mentation, images, tables and catalogues. Informal notes

and annotation or rationale, may be added during the

process. The combination of these elements is intended to

be brought together and edited for reuse in the next gen-

eration product template to support design decisions.

Automation, in this context, is the application of knowl-

edge-based methods or algorithms to manipulate the

product data. These algorithms take parameters from the

product model as inputs, make calculations on them, and

store them as new or updated parameters.

4.5.3 Product knowledge

The third knowledge element is referred to as product

knowledge. In this implementation of the system, the

product knowledge is represented by the parameter set.

This enables the application of a product template to the

Fig. 7 Mathematical model

task page

Table 1 Engineering requirements feature data

Feature name Data Data type Units

Product type 1 Integer Product-type

Vacuum requirement 0.001 Real mb

Pump-down time 2 Real Seconds

Length 950 Real mm

Width 350 Real mm

Height 300 Real mm

Power target 999 Real Watts

Cost target 1,500 Currency $

Pump-type 1 Integer Pump-type

Shaft pitch 95 Real mm

Number of stages 4 Integer Integer

Bore diameter 200 Real mm

Rotor thickness 22 Real mm

High complexity, different product types: * Process management through general process templates* Limited knowledge reuse

Highly complex, very similar products (e.g. aero engine):* Benefits from indexing unstructured knowledge* Process management through product specific template

Moderate to low complexity, different product types:*Least applicable and fewestbenefits. Method may be useto develop a general process template.

Moderate to low complexity, very similar products:* Most applicable: benefits from domain-specific process templates, also managing structured & unstructured knowledge

Product similarity (direct reusability)

Pro

duct

Com

plex

ity

Fig. 8 Assessment of the potential application and benefits of the

proposed methodology with respect to different product types

Res Eng Design (2007) 18:37–48 45

123

development of a new product variant. The template can be

applied at a variety of levels. The first is ‘data labels only’,

to develop a whole new product of the same type (such as

the next generation product in the range). The second level

can be applied on a broad spectrum depending on the

constraints: using a partial data model to develop a new

product family member (such as a different pumping speed

or application variant). Clearly the application of the partial

data model exists within certain limits, which must be

defined for each product type.

One aim is to extend the product knowledge element to

include a product ontology to represent a collectively de-

fined lexicon of terms, agreed parameter ranges and rela-

tionships between terms. This should improve the

understanding of the design process, and also extend the

capability for managing the design process in a distributed

manner.

4.5.4 Relationship with KBE

This system is not itself a KBE system; however it does

have the capability to include KBE methods. The main

contribution in terms of KBE is a system to provide the

capability to define multiple input and output data sets for

analysis by multiple KBE systems. The definition of the

product model will be shaped by the organisational

requirements at the early design stages. Product model

parameters and structure (content of individual data sets)

will be defined according to the needs of the process,

including KBE systems. The process model supports KBE

by including the required tasks. Task knowledge includes

KBE methods or in the case of external systems, support

for carrying out the task. Automation of the task, including

data input/output, represents system task knowledge.

4.6 Application and extension of the DR method

The process representation method is based on the DR

method. It should be noted that the implementation applies

only a part of the DR framework. The basic process logic

was applied: a data object precedes (and is consumed by) a

task object. Precedence and abstraction links were the only

types applied to the example. The other DR link types

(feedback, feedforward and constraint relationships) would

add value to an extended process model. The DR process

logic was also not rigorously defined in this test system; the

main objective being the process representation. It is

therefore not possible to show alternate views of the pro-

cess (design structure matrix representation is an option in

the DR system).

One limitation of the DR method is that there is no

method to link task knowledge, including supporting

information and computational methods, to the process

model. The approach described in this paper provides a

method to link task knowledge to the process model.

Supporting information is stored and indexed with relation

to tasks. Through interaction with a product model, com-

putational methods can also be applied to task support. The

product model concept further extends the DR method, by

suggesting that product and process data are stored sepa-

rately.

5 Evaluation of the proposed methodology

and its potential applications

Within variant design domains, where similar products are

designed for several generations, this approach can provide

significant benefit. The application of process templates

along with the capability to store and apply additional

information and data will significantly enhance the reuse of

product knowledge, and so improve the product develop-

ment effort. If the product in question is highly complex,

and also highly similar to the last generation, the organi-

sation will gain most benefit from the application of KBE

technologies that aid the synthesis and analysis of the next

generation product. The method proposed here, in that

case, could be applied to the management of design and

project knowledge, especially unstructured knowledge that

supports product development. The calculations (KBE

driven analysis) will be carried out using the proprietary

KBE systems. So this method will be of use to the product

development team, but more benefits will be gained from

the application of KBE systems. The management of

structured knowledge provided by this approach will allow

the product development team to keep a central data store

that tracks the product development, enabling better coor-

dination of distributed teams. The process management

methods and the methods to store and retrieve unstructured

information will also serve a useful purpose. The signifi-

cance of KBE and geometry-based methods is due to the

high relative importance of geometry in later stages of the

design process, and the scale of the detailed design effort

when compared to conceptual design, particularly with

highly complex products.

The (project) model context relates directly to the

product. A process map template is created for a specific

product type, just as the product model template. If the type

of product differs widely from one generation to the next,

then the amount of detail relevant to the next product will

be greatly reduced. There comes a point at which the

benefits to be gained from applying such a context specific

knowledge reuse tool are overtaken by the costs, when

compared with following a general design process. In such

cases, the method can be used to implement a general

design (or innovation) methodology. It can also be used to

46 Res Eng Design (2007) 18:37–48

123

store and manage design data through the process. This

relationship is described in the matrix in Fig. 8.

These relationships must be tested in an industrial sce-

nario in order to gauge the degree to which a particular

approach is suitable, and to show what circumstances lead

to a successful application of the method. Where vacuum

pump is shown on the matrix to have moderate complexity,

this is in comparison to an aero engine.

6 Conclusion

The method described in this paper addresses the need to

reuse engineering design knowledge. Three knowledge

types are supported: process knowledge, product knowl-

edge and task knowledge. The underlying principle of the

methodology is the interaction between a product model

and a process model through a set of parameters to meet the

particular needs of an application domain. The proposed

system provides project guidance and monitoring, a

framework to organise information and knowledge re-

trieval, and a central repository of product data. These

elements can be brought together through the use of a

combined method to represent the design process, provide

data support, and to form relationships between the process

model and product concepts. The system has been tested

with an industrial sponsor on a major component. The next

challenge is to build additional product components into

the model, with the longer term aim being to capture and

represent knowledge for an entire product family.

Acknowledgements The authors would like to acknowledge the

funding provided for this collaborative project through the Cranfield

University and Loughborough University Innovative Manufacturing

Research Centres, which are supported by the Engineering and

Physical Sciences Research Council. The participation and continued

support of BOC Edwards is greatly appreciated.

References

Andrews P, Shahin T, Sivaloganathan S (1999) Design reuse in a CAD

environment—four case studies. Comput Ind Eng 37:105–109

Backer T, Siegel T, Rabin P, McGrath T (1995) Avoiding the

redesign trap: standard design processes improve design quality

and reuse. In: Proceedings of the 10th computing in aerospace

conference, AIAA, San Antonio, TX, USA, pp 95–1003

Balasubramanian P, Nochur K, Henderson J, Kwan M (1999)

Managing process knowledge for decision support. Decis

Support Syst 27(1):145–162

Baxter DI, Gao JX (2004) Process based representation for design

knowledge. In: Proceedings of the 2nd international conference

on manufacturing research 2004 (ICMR 2004), Sheffield Hallam

University, Sheffield, UK

Baxter DI, Gao JX (2005) Process based design knowledge reuse

through process and product representation. In: Proceedings of

the 12th CIRP life cycle engineering seminar (CIRP LCE) 2005,

Grenoble, France

Blessing LTM (1995) A process-based approach to design. Colloq

Dig IEE 49:4

Burge JE, Brown DC (2002) Integrating design rationale with a

process model. In: International workshop on agents in design,

WAID’02, MIT, Cambridge

Busby JS (1999) The problem with design reuse: an investigation into

outcomes and antecedents. J Eng Des 10(3):277–297

Clarkson PJ, Hamilton JR (2000) Signposting, a parameter-driven

task-based model of the design process. Res Eng Des 12(1):18–

38

Classen A, Lopez L (1998) New product introduction between two

geographically dispersed entities. In: International conference on

engineering and technology management, 1998. (IEMC ‘98),

IEEE, San Juan, PR, USA

Concheri G, Milanese V (2000) MIRAGGIO: a system for the

dynamic management of product data and design models. Adv

Eng Softw 32:527–543

Costa CA, Young RIM (2001) Product range models supporting

design knowledge reuse. Proceedings of the institution of

mechanical engineers—Part B—Eng Manuf 215(3):323–338

Finger S (1998) Design reuse and design research—keynote paper. In:

Engineering design conference ‘98, Professional Engineering

Publishing, Brunel University, UK

Gardam A, Burge SE (1997) Changes in the engineering design

process. In: Proceedings of the 11th national conference on

manufacturing research (NCMR) Advances in Manufacturing

Technology XI. Glasgow Caledonian University, UK

Gorti SR, Gupta A, Kim GJ, Sriram RD, Wong A (1998) An object-

oriented representation for product and design processes. Com-

put Aided Design 30(7):489–501

Hansen C, Andreasen M (2002) The content and nature of a design

concept. In: Norddesign 2002: visions and values in engineering

design. Norwegian University of Science and Technology,

Trondheim, Norway

Harding JA, Popplewell K, Cook D (2003) Manufacturing system

engineering moderator: an aid for multidiscipline project teams.

Int J Prod Res 41(9):1973–1986

Hayashi N, Herman G (2002) A coordination-theory approach to

exploring process alternatives for designing differentiated prod-

ucts. In: Engineering management conference, 2002 (IEMC ‘02),

IEEE International, Cambridge, UK

Hew KP, Fisher N, Awbi HB (2001) Towards an integrated set of

design tools based on a common data format for building and

services design. Automat Constr 10(4):459–476

Hicks BJ, Culley SJ, Allen RD, Mullineux G (2002) A framework for

the requirements of capturing, storing and reusing information

and knowledge in engineering design. Int J Inform Manage

22(4):263–280

Huang HZ, Gu YK (2006) Development mode based on integration of

product models and process models. Concurrent Eng Res Appl

14(1):27–34

Inns T, Neville P (1998) Establishing a company-level design process

to facilitate design reuse. In: Engineering design conference ‘98,

Professional Engineering Publishing, Brunel University, UK

Johannessen J-A, Olaisen J, Olsen B (2001) Mismanagement of tacit

knowledge: the importance of tacit knowledge, the danger of

information technology, and what to do about it. Int Inform

Manag 21:3–20

Kalpic B, Bernus P (2002) Business process modelling in industry-the

powerful tool in enterprise management. Comput Ind 47(3):299–

318

Kerr C, Roy R, Sackett P (2004) A product ontology for automotive

seat specification. In: The 2004 ASME international design

engineering technical conferences & the computer and informa-

tion in engineering conference (ASME DETC/CIE 2004)—30th

design automation conference (DAC), Salt Lake City, UT, USA

Res Eng Design (2007) 18:37–48 47

123

Knott RP, Merunka V, Polak J (2003) The role of object oriented

process modeling in requirements engineering phase of infor-

mation systems development. In: EFITA 2003, Debrecen,

Hungary

Leake DB, Wilson DC (2001) A case-based framework for interactive

capture and reuse of design knowledge. Appl Intell 14:77–94

Li Y, Shao X, Li P, Liu Q (2004) Design and implementation of a

process-oriented intelligent collaborative product design system.

Comput Ind 53(2):205–229

Lowe A, McMahon C, Culley S (2004a) Information access, storage

and use by engineering designers—Part 1. Eng Designer March/

April:30–32

Lowe A, McMahon C, Culley S (2004b) Information access, storage

and use by engineering designers—Part 2. Eng Designer May/

June:23–25

Lu S, Cai J, Burkett W, Udwadia F (2000) A methodology for

collaborative design process and conflict analysis. Ann CIRP

49(1):69–74

Lubit R (2001) The keys to sustainable competitive advantage: tacit

knowledge and knowledge management. Organ Dyn 29(4):164–

178

Markus ML (2001) Toward a theory of knowledge reuse: types of

knowledge reuse situations and factors in reuse success. J

Manage Inf Syst 18(1):57–93

Matsumoto IT, Stapleton J, Glass J Thorpe T (2005) A knowledge-

capture report for multidisciplinary design environments. J

Knowl Manage 9(3):83–92

National Institute of Standards and Technology, USA (1993)

Integration definition for function modeling (IDEFø)

Nonaka I (1994) A dynamic theory of organizational knowledge

creation. Organ Sci. 5(1):14–28

Paashuis V, Boer H (1997) Organizing for concurrent engineering: an

integration mechanism framework. Integr Manuf Syst 8(2):79–

89

Pakovich N, Marjanovich D (2001) Considering an object oriented

approach to the design process planning. Int J Technol Manag

21:25–42

Park H, Cutosky MR (1999) Framework for modeling dependencies

in collaborative engineering processes. Res Eng Des 11(2):84–

102

Pavkovic N, Marjanovic D (2000) Entities in the object oriented

design process model. In: International design conference

(Design 2000), Dubrovnik, Croatia

Ramesh B, Tiwana A (1999) Supporting collaborative process

knowledge management in new product development teams.

Decis Support Syst 27:213–235

Rodgers PA, Caldwell NHM, Clarkson PJ, Huxor AP (2001) The

management of concept design knowledge in modern product

development organizations. Int J Comput Integr Manuf

14(1):108–115

Rodgers PA, Huxor AP, Caldwell NHM (1999) Design support using

distributed web-based AI tools. Res Eng Des 11(1):31–44

Rohl P, Kolonay R, Irani R, Sobolewski M, Kao K (2000) A federated

intelligent product environment. In: Proceedings of the 8th

AIAA/USAF/NASA/ISSMO Symposium on Multidisciplinary

Analysis and Optimization, Long Beach, CA, USA

Sainter P, Oldham K, Larkin A, Murton A, Brimble R (2000) Product

knowledge management within knowledge-based engineering

systems. In: ASME 2000 Design Engineering Technical Con-

ference, ASME, MD, USA

Saviotti PP (1998) On the dynamics of appropriability, of tacit and of

codified knowledge. Res Policy 26:843–856

Schofield M, Gregory M (2002) The impact of architectural

uncertainty on product introduction in dispersed environments.

In: Engineering management conference, 2002 (IEMC ‘02),

IEEE International, Cambridge, UK

Shahin TMM, Andrews PTJ, Sivaloganathan S (1999) A design reuse

system. proceedings of the institution of mechanical engineers,

Part B: J Eng Manuf 213(6):621–627

Shooter S, Keirouz W, Szykman S, Fenves S (2000) A model for the

flow of design information in product development. Eng Comput

16(3–4):178–194

Sim SK, Duffy AH (2003) Towards an ontology of generic

engineering design activities. Res Eng Des 14:200–223

Sivaloganathan S, Shahin TMM (1999) Design reuse: an overview.

Proceedings of the institution of mechanical engineers—Part

B—Eng Manuf 213(7):641–655

Suh NP (1990) The principles of design. Oxford University Press,

Oxford

Tate D, Nordlund M (1996) A design process roadmap as a general

tool for structuring and supporting design activities. In:

Proceedings of the second world conference on integrated

design and process technology, Austin, TX, USA

Tucker D, Hackney R (2000) Towards the integration of concurrent

engineering environments within organisational strategy. J

Manag Dev 19(3):179–190

Tuomi I (1999) Data is more than knowledge: implications of the

reversed knowledge hierarchy for knowledge management and

organizational memory. J Manag Inform Syst 16(3):103–117

Salminen V, Yassine A, Riitahuhta A (2000) A strategic management

framework for collaborative product development. In: Proceed-

ings of the 4th international conference on engineering design

and automation (ED&A), Orlando, FL

Walsham G (2001) Knowledge management: the benefits and

limitations of computer systems. Eur Manage J 19(6):599–608

Wood III WH, Agogino AM (1996) Case-based conceptual design

information server for concurrent engineering. Comput Aided

Design 28(5):361–369

Wujek B, Koch P, Chiang W (2000) A workflow paradigm for

flexible design process configuration in FIPER. In: Proceedings

of the 8th AIAA/USAF/NASA/ISSMO Symposium on Multi-

disciplinary Analysis and Optimization, AIAA-2000–4868, Long

Beach, CA, USA

Xu Z, Frazer J, Tang M (2002) Novel design methodology supporting

product life-cycle design. Comput Ind 49:253–265

Yassine AA, Falkenburg DR (1999) A framework for design process

specifications management. J Eng Des 10(3):223–234

Zdrahal Z, Mulholland P, Domingue J, Hatala M (2000) Sharing

engineering design knowledge in a distributed environment.

Behav Inf Technol 19(3):189–200

48 Res Eng Design (2007) 18:37–48

123