Res Eng Design (2007) 18:3748

DOI 10.1007/s00163-007-0028-8

ORIGINAL PAPER

An engineering design knowledge reuse methodology

using 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 knowledge-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

D. Baxter (&)
Decision Engineering Centre, Cranfield University,
Cranfield, Bedfordshire MK43 0AL, UK
e-mail: [email protected]
J. Gao
School of Engineering, The University of Greenwich,
Kent ME4 4TB, UK
e-mail: [email protected]
K. Case
J. Harding
B. Young
S. Cochrane

S. Dani
Wolfson School of Mechanical and Manufacturing Engineering,
Loughborough University, Loughborough,
Leicestershire LE11 3TU, UK

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 todays globalised manufacturing environment. 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 wellknown 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 reasoning, problem resolution methods, solution generation
strategies, design intent and supply chain knowledge.

123

38

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 (Johannessen 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 applied 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 Engineering (CAE), function, meaning (ontology) and matching
(case-based reasoning, CBR). Reuse relating more specifically to the design process will be described in the following 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 conceptual 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 design practice.
CAD/CAE based design reuse methods include component reuse, parametric design (both generative and variant: see Andrews et al. 1999) and KBE systems. Most
Computer Aided Engineering (CAE) systems (such as
Unigraphics, Catia, Pro-Engineer and ICAD) provide

123

Res Eng Design (2007) 18:3748

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 captured 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 knowledgei.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 representation, the development of ontology and its application to engineering design is providing a means to represent
domain knowledge: understanding product (and manufacturing, service, etc.) concepts, data elements and relationships between concepts (Kerr et al. 2004).
Case-Based Reasoning has been applied in a variety of
ways to enable design knowledge reuse. Essentially, it involves 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 designers 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

Res Eng Design (2007) 18:3748

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 problem was an unexpected amount of additional effort to reuse. Others were knowledge loss through inappropriate
replication, and error where existing designs were reapplied to new purposes.
A review of design reuse was carried out (Sivaloganathan 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 approaches 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).

39

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 integration 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 representation, 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 Falkenburg 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 framework 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 interaction) or PLM system (database changes) are monitored 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 management method: a general design methodology forms
a key element of the process representation approach,
or is applied as a process management methodi.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-

123

40

Res Eng Design (2007) 18:3748

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; Balasubramanian 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) project. 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 distributed 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 Signposting and the Design Roadmap (DR). Signposting (Clarkson 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 development 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 feedforward processes, which are common in design yet
uncommon in other representations. The process data
model enables a variety of graphical representations, or

123

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

Additional functions, including resource management,
document attachment and notification functions were added 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
todays dynamic design process. The method proposed in
this project complements the existing approaches by enabling 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, performance, 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 h1 pump). The parameterised model of the product is then extended to include parameters that are calculated, 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-

Res Eng Design (2007) 18:3748

41

ods are applied through the creation of relationships between 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 timeand 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 detailed structure that can be applied to the index and retrieval 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 manipulated within the system or externally. The product ontology 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 Engine 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 allow 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.

Process
Model Data
+
Knowledge

Task Data
+
Knowledge

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 engineering domains. A detailed design process model has been
developed, and the supporting knowledge has been captured and added to the model. The following section describes the approach in more detail, with a description of
the example.
4.1 The selected component
The component selected for the knowledge capture exercise 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 tolerances, shaft seal and atmosphere seal. View (b) shows the
bearing bores, critical elements include bearing bore
geometrical and positional tolerances. The dynamic seal

Product
Model Data
+
knowledge

Pump
Stator

Bearing
bore

Process Logic Engine

View (a)

Fig. 1 System architecture

View (b)

View (c)

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

features

123

42

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 includes activity boxes, with arrows representing inputs,
outputs, controls and mechanisms. A single activity represents 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 prevented the representation of both context and detail in a
single representation. The IDEF series enabled an observer 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 requirement 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 sequence 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

123

Res Eng Design (2007) 18:3748

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 subsequent 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 carried 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 enables 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 created, and where they are used. The explicit methods applied 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 Objects. 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

Res Eng Design (2007) 18:3748

43

Feature: Bearing Bore

Task
Bearing bore layout

Size (diameter, depth)

Bore Tolerance

Geometry Tolerance

Task
Lubrication system
(thrower, channels)
layout

Feature: Thrower
Size:
diameter

depth

Tolerances

Feature: h/p Stator

Feature: Gas flow
Task
Headplate Stator
Layout

Size (diameter, depth)

Bore Tolerance

Geometry Tolerance

Task
Dynamic seal
design

Feature: Drive
Task
Drive Layout
(motor, gears,
shaft)

Channel location

N2 Flow rate

Feature: Lip Seal

Gear position

Motor fixing

Shaft size

Task
Lip seal layout

Internal diameter

External diameter

Tolerances

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

and product model data. The task model has a user interface 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 readonly 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 (bottomcentre 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 implementations 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 requirements 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

Task model
Data +
Knowledge

Update

Access

Product
Model Data

Process model

Fig. 4 Prototype system architecture

123

44

Res Eng Design (2007) 18:3748

Fig. 5 Process object links

Task
Reqmnts
Specification

Feature C
Shaft dynamics

Feature A
Engineering
Reqmnts

Task 4
Cartridge Layout

Task
Math. modelling

Feature D
Cartridge model

Feature B
Product Model

Task
Dynamic model

Task
Bearing selection

Feature G
Bearing Spec

Task
Gear selection

Feature H
Gear spec

Task
Motor selection

Feature I
Motor spec

Task
Headplate design

Fig. 6 Design task overview showing precedence relationships

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
featuresin 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 calculationsin this
case the mass of components.

123

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

Res Eng Design (2007) 18:3748

45

Fig. 7 Mathematical model

task page

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-engineering) 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 knowledge elements embedded within the proposed method.

the task. It includes general notes, formal design documentation, 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 generation product template to support design decisions.
Automation, in this context, is the application of knowledge-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.2 Task 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

The second knowledge element is task knowledge. This

includes information and automation. Supporting information is available to support the designer in completing

4.5.3 Product knowledge

Product Complexity

Table 1 Engineering requirements feature data

High complexity, different
product types:
* Process management
through general process
templates
* Limited knowledge reuse
Moderate to low complexity,
different product types:
*Least applicable and fewest
benefits. Method may be use
to develop a general process
template.

Highly complex, very similar

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

Feature name

Data

Data type

Units

Product type

Integer

Product-type

Vacuum requirement

0.001

Real

mb

Pump-down time

Real

Seconds

Length

950

Real

mm

Moderate to low complexity,

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

Width

350

Real

mm

Height

300

Real

mm

Power target
Cost target

999
1,500

Real
Currency

Watts
$

Pump-type

Integer

Pump-type

Shaft pitch

95

Real

mm

Number of stages

Integer

Integer

Bore diameter

200

Real

mm

Rotor thickness

22

Real

mm

Product similarity (direct reusability)

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

proposed methodology with respect to different product types

123

46

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 defined lexicon of terms, agreed parameter ranges and relationships 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 process (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

123

Res Eng Design (2007) 18:3748

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, computational 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 separately.

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 development effort. If the product in question is highly complex,
and also highly similar to the last generation, the organisation 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 coordination of distributed teams. The process management
methods and the methods to store and retrieve unstructured
information will also serve a useful purpose. The significance 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

Res Eng Design (2007) 18:3748

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 scenario 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 knowledge 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 retrieval, 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
environmentfour case studies. Comput Ind Eng 37:105109
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 951003
Balasubramanian P, Nochur K, Henderson J, Kwan M (1999)
Managing process knowledge for decision support. Decis
Support Syst 27(1):145162
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

47
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,
WAID02, MIT, Cambridge
Busby JS (1999) The problem with design reuse: an investigation into
outcomes and antecedents. J Eng Des 10(3):277297
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:527543
Costa CA, Young RIM (2001) Product range models supporting
design knowledge reuse. Proceedings of the institution of
mechanical engineersPart BEng Manuf 215(3):323338
Finger S (1998) Design reuse and design researchkeynote 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 objectoriented representation for product and design processes. Comput Aided Design 30(7):489501
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):19731986
Hayashi N, Herman G (2002) A coordination-theory approach to
exploring process alternatives for designing differentiated products. 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):459476
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):263280
Huang HZ, Gu YK (2006) Development mode based on integration of
product models and process models. Concurrent Eng Res Appl
14(1):2734
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:320
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 information in engineering conference (ASME DETC/CIE 2004)30th
design automation conference (DAC), Salt Lake City, UT, USA

123

48
Knott RP, Merunka V, Polak J (2003) The role of object oriented
process modeling in requirements engineering phase of information 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:7794
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):205229
Lowe A, McMahon C, Culley S (2004a) Information access, storage
and use by engineering designersPart 1. Eng Designer March/
April:3032
Lowe A, McMahon C, Culley S (2004b) Information access, storage
and use by engineering designersPart 2. Eng Designer May/
June:2325
Lu S, Cai J, Burkett W, Udwadia F (2000) A methodology for
collaborative design process and conflict analysis. Ann CIRP
49(1):6974
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):5793
Matsumoto IT, Stapleton J, Glass J Thorpe T (2005) A knowledgecapture report for multidisciplinary design environments. J
Knowl Manage 9(3):8392
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):1428
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:2542
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:213235
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):108115
Rodgers PA, Huxor AP, Caldwell NHM (1999) Design support using
distributed web-based AI tools. Res Eng Des 11(1):3144
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

123

Res Eng Design (2007) 18:3748

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 Conference, ASME, MD, USA
Saviotti PP (1998) On the dynamics of appropriability, of tacit and of
codified knowledge. Res Policy 26:843856
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):621627
Shooter S, Keirouz W, Szykman S, Fenves S (2000) A model for the
flow of design information in product development. Eng Comput
16(34):178194
Sim SK, Duffy AH (2003) Towards an ontology of generic
engineering design activities. Res Eng Des 14:200223
Sivaloganathan S, Shahin TMM (1999) Design reuse: an overview.
Proceedings of the institution of mechanical engineersPart
BEng Manuf 213(7):641655
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):179190
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):103117
Salminen V, Yassine A, Riitahuhta A (2000) A strategic management
framework for collaborative product development. In: Proceedings 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):599608
Wood III WH, Agogino AM (1996) Case-based conceptual design
information server for concurrent engineering. Comput Aided
Design 28(5):361369
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 Multidisciplinary Analysis and Optimization, AIAA-20004868, Long
Beach, CA, USA
Xu Z, Frazer J, Tang M (2002) Novel design methodology supporting
product life-cycle design. Comput Ind 49:253265
Yassine AA, Falkenburg DR (1999) A framework for design process
specifications management. J Eng Des 10(3):223234
Zdrahal Z, Mulholland P, Domingue J, Hatala M (2000) Sharing
engineering design knowledge in a distributed environment.
Behav Inf Technol 19(3):189200