Res Eng Design (2012) 23:17–52
DOI 10.1007/s00163-011-0112-y
ORIGINAL PAPER
Supporting product architecture design using computational
design synthesis with network structure constraints
David F. Wyatt • David C. Wynn • Jerome P. Jarrett
P. John Clarkson
Received: 21 July 2010 / Accepted: 26 March 2011 / Published online: 21 April 2011
 Springer-Verlag London Limited 2011
Abstract A product’s architecture can affect many
aspects of product and process quality, from technical
performance to the design effort required, production costs
and satisfaction of later lifecycle requirements. This paper
explores how computational tools can augment creative
methods in product architecture design. Based on an
empirical study aiming to understand the context of prod-
uct architecture design, a new computational method is
proposed to support this activity. In the method, product
architectures—networks of components linked by connec-
tions—can be synthesised using constraints on the structure
of the network to define the set of ‘realisable’ architectures
for a product. An example illustrates how the method
might be used on a real design problem, including the
construction of an appropriate set of network structure
constraints and the identification of promising architectures
from the synthesis results. Preliminary evaluation of the
method’s usability, assessed through a laboratory experi-
ment, and its utility, assessed through application to a real
historical design problem, supported by initial validation
by an engineer from the case study company, suggests that
the method has value for engineering design practice.
Keywords Product architecture  Conceptual design 
Design support method  Computational design synthesis 
Network structure constraints  Cambridge advanced
modeller (CAM)
D. F. Wyatt (&)  D. C. Wynn  J. P. Jarrett  P. J. Clarkson
Cambridge Engineering Design Centre,
Department of Engineering, University of Cambridge,
Trumpington Street, Cambridge CB2 1PZ, UK
e-mail: dw274@cam.ac.uk
URL: http://www-edc.eng.cam.ac.uk
•
1 Introduction
Product architectures are the abstract conceptual structures
underlying the functioning of engineering artefacts, and
their design is an important but difficult task (Ulrich 1995).
They have a wide-ranging influence on product and
enterprise success (Crawley et al. 2004; Ulrich 1995;
Yassine and Wissmann 2007). In particular, the early
stages of design commit a large fraction of the overall cost
of bringing a product to market (Berliner and Brimson
1988; Port and Schiller 1990). However, it can be hard to
identify ‘good’ product architectures since they are quali-
tative and abstracted from reality.
This paper proposes an approach based around compu-
tational design synthesis, which would allow designers to
consider possible architectures for a product systemati-
cally, potentially leading to better results. The approach is
combined with insights from a case study to develop a
specific method, in which the ‘space of possible architec-
tures’ is modelled in a declarative formal language. The
model comprises an ontology of the components and
relations from which architectures may be constructed, and
network structure constraints to identify the arrangements
of these elements that are ‘realisable’. Product architec-
tures that comply with the constraints can then be syn-
thesised computationally and reviewed by the designer.
Preliminary evaluation shows that the method has value for
engineering practice.
The next section provides background on definitions of
‘product architecture’ and informal and formal methods for
product architecture design. Section 3 then identifies
requirements for a support method from a case study into
the context of product architecture design. Section 4
describes the support method and tool developed to meet
these requirements, and Sect. 5 illustrates the method
123
18
through application to an example problem: the redesign of
a vacuum cleaner. Section 6 describes preliminary evalu-
ation of the method’s usability, through an experiment
where novice designers applied the method to a simple
design problem, and applicability and usefulness, through
applying the method to a real historical design problem; it
then describes an initial validation of the method through
its use by an engineer from the case study company. Sec-
tion 7 reflects on the advantages and limitations of the
method and approach, and Sect. 8 concludes.
2 Background
2.1 Defining ‘product architecture’
Ulrich (1995) states that ‘product architecture’ represents a
product’s functions (in the sense of Pahl et al. (2007)), their
mapping to physical components, and the interfaces
between the components (particularly the degree of cou-
pling at interfaces and issues of cross-compatibility
between uncoupled interfaces). Other authors have inclu-
ded additional elements: the partitioning of subfunctions
into ‘modules’ (Stone et al. 2000); the requirements on a
product (Yassine and Wissmann 2007); and ‘principle
solutions’ or ‘organs’, intermediate between functions and
components (Andreasen 1992). In the domain of software
and other (non-physical) systems, Maier and Rechtin
(2000) quote a range of definitions for ‘architecture’,
focusing on structure in terms of components and rela-
tionships, but also point out that ‘architecture is what
architects produce, and […] what architects do is help
clients make decisions about building systems’.
All these definitions share the concept of product or
system architecture as ‘an abstract description of the enti-
ties of a system and the relationships between those enti-
ties’ (Crawley et al. 2004). Therefore, that definition will
be used throughout the rest of this paper:
A product architecture is a model of an engineering
artefact in terms of components linked by relations.
In most engineering design domains, components and
relations are physical, but increasingly products involve
mechatronic elements and thus electronic and software
components must also be considered. The view of product
architecture as a design’s components and their interrela-
tions has been termed ‘topology’ (Shea et al. 1997),
‘product structure’ (Lindemann et al. 2008), or ‘configu-
ration’ (Murdoch and Wallace 1992; Campbell et al. 2000).
(‘Configuration’ may also be used to mean selection from
predesigned components, a less open-ended problem than
designing the initial ‘concept’ although similar in some
123
Res Eng Design (2012) 23:17–52
respects (Ziv-Av and Reich 2005); this is discussed further
in Sect. 2.2.2.)
2.2 Designing product architectures
2.2.1 Informal and formal approaches
Methods to support product architecture design may be
divided into informal methods, which rely on human cre-
ativity, and formal methods, involving codifiable rules and
procedures. Frequently used informal methods include
brainstorming (Osborn 1957), the 635 method (Rohrbach
1969) and synectics (Gordon 1961). However, the discon-
tinuous and qualitative nature of the ‘design space’ of
product architectures may make it difficult to construct new
product architectures, or even to be aware that there are
alternatives to a particular architecture. This is in contrast
to certain other classes of design problems, for instance
numerical optimisation problems where the ‘design space’
is clearly defined with one quantitative dimension for each
design variable. ‘Fixation’ effects (Purcell and Gero 1996)
may further hinder designers from thinking beyond known
architectures. These two factors may result in reliance by
the designer on a restricted set of architectures, often those
used in previous designs. Since different architectures may
have different levels of ‘overall quality’ (in whatever way
this is judged), a restricted set of architectures may not
include the one(s) which are the ‘best’ in the specific
design context.
An alternative approach is to use formal (often com-
putational) methods (Cagan et al. 2005) to synthesise
potential architectures. Formal methods can be made sys-
tematic (Pahl et al. 2007), giving them the potential to
identify high-quality architectures more reliably than
informal techniques and reducing the effect of fixation
(Kurtoglu and Campbell 2009). They also require a product
architecture design problem to be represented in a form
appropriate for such methods, giving advantages from
greater transparency (Schmidt and Cagan 1997):
• Modelling the problem requires the designer to make
explicit their assumptions about the space of possible
architectures, which allows them to be reasoned about
and reconsidered if necessary.
• If aspects of ‘overall quality’ can be expressed
formally, architectures resulting from formal methods
may be evaluated automatically against them, reducing
effort and ensuring consistency.
• The models of the design problem and the synthesised
solutions can contribute to documentation (particularly
the rationale for choosing a particular architecture).
This may be important for future design projects and/or
certification.
Res Eng Design (2012) 23:17–52 19

Fig. 1 A model of the process

by which product architecture is
designed, showing the
conventional approach based on
informal techniques (solid lines)
and the modifications to this
process in order to exploit
formal computational methods
to support design (dashed lines).
The shaded portion is the focus
of the method developed in this
paper

Figure 1 illustrates how these two alternative approa-
ches, informal and formal, may be realised in a design
process. The solid lines represent the informal process for
designing the (product) architectures of solutions to a
particular design problem, based on Cross’ four-phase
Exploration-Generation-Evaluation-Communication model
of design (Cross 1994):
• Through exploring the problem to be solved (1), the
designer develops an understanding of it (2). At the
same time they may abstract from past solutions (3)
(products that solved the same or a similar problem) to
give mental models of the architectures of those
solutions (4).
• The designer then generalises their understanding of
the problem and past solutions to an understanding of
possible architectures for solutions to the problem (5).
• The understanding of possible solution architectures
allows the designer to generate specific solution
architectures (6) (which may be the same as past
solutions).
• These solution architectures are evaluated for appro-
priateness to establish whether they would indeed solve
the problem, informed by the designer’s understanding
of the problem. If so, one or more may then be
communicated in the form of solution architecture
designs (7). If not, the designer may iteratively refine
the solutions.
• A solution architecture design is then evaluated for
quality against successively higher-fidelity models of
the problem, for instance, through simulation or
prototype testing. If the solution architecture design is
shown to be appropriate, it may be taken forward into
detailed design, manufacture and ultimately the pro-
duction of a solution (8). If the designer’s understand-
ing is at fault, they may need to refine their
understanding of the problem.

123
20
As discussed above, the ‘Generation’ step in the infor-
mal process may be problematic. Dashed lines indicate
how it may be circumvented using computational design
synthesis, inspired by Cagan et al.’s (2005) framework:
• The understanding of possible solutions (5) is forma-
lised into a representation of the design space of
solution architectures (5a).
• This is used to synthesise possible solution architec-
tures (5b).
• These solution architectures must be interpreted as
mental models (6) in order that they can be evaluated
for appropriateness against the designer’s understand-
ing of the problem.
• If the solution architectures are not ‘appropriate’ in
terms of the designer’s understanding of the problem,
the designer may iteratively refine the formalisation.
2.2.2 Formal architecture synthesis
Methods for formal and/or computational design synthesis
in engineering are many and varied (Antonsson and Cagan
2001; Chakrabarti 2002), with applications ranging from
load-bearing structures (Xie and Steven 1997) to robotic
mechanisms and their controllers (Lipson and Pollack
2000). Of the methods that specifically address product
architecture design, perhaps the most fundamental is
morphological analysis (Zwicky 1969): a design problem is
decomposed into partial problems, solutions are identified
to each partial problem, and combinations of those partial
solutions are systematically considered, potentially gov-
erned by compatibility constraints (Allwood 2007; Golkar
et al. 2009; Hellenbrand and Lindemann 2008). However,
morphological analysis requires the lists of partial solutions
as input and assumes the relationships between the partial
solutions do not vary, unless such variation is explicitly
represented by a ‘configuration’ partial problem (Hellen-
brand and Lindemann 2008). The Subjective–Objective
System (Ziv-Av and Reich 2005) is based on morpholog-
ical analysis combined with a definition of ‘overall quality’
as a weighted sum of different characteristics of the solu-
tion related to the fulfilment of the customer requirements
(‘objective’) or enterprise-specific context (‘subjective’).
Both the characteristics and the compatibility constraints
are defined numerically, allowing the ‘best’ solution to be
found through optimisation rather than exhaustive enu-
meration as long as such detailed information about
‘quality’ is available.
Other methods can handle situations which cannot be
expressed as combinations of partial solutions, or where the
possible ‘configurations’ are not known a priori. One
popular approach uses the concept of generative grammars
from linguistics (Chomsky 2002) applied to graphs
123
Res Eng Design (2012) 23:17–52
representing product architectures (Helms et al. 2009;
Kerzhner and Paredis 2009; Kurtoglu and Campbell 2009;
Schmidt and Cagan 1997; Stanković et al. 2009). (Gram-
mar-based approaches have also been used with geomet-
rical shapes (Stiny 2006).) In such ‘graph grammar’
approaches, the nodes in a graph represent components
and/or subfunctions of the product and the edges represent
connections between them. The grammar then defines
‘transformation rules’ that modify either the structure of
the graph or the properties of the elements (components
and/or connection) within it; multiple modifications may be
made in a single rule application (e.g. adding a component
and linking it to other parts of the architecture). Graph
grammars can, if appropriately constructed, act on existing
architectures as well as designing ‘from scratch’. This is
valuable because in practice engineering design is fre-
quently incremental, with many products evolving and/or
having parts of their design reused in later products (Eckert
et al. 2004). However, formulating the rules for a grammar
can be challenging (Kerzhner and Paredis 2009), since
typically each rule only determines a small fraction of the
resulting structure and thus multiple rules must be applied
in succession to produce valid results. Thus, the designer
must construct the grammar such that appropriate sequen-
ces of rules can be completed and unintended interaction
between rules is prohibited.
An alternative approach is exemplified by the A-Design
system (Campbell et al. 2000), in which autonomous
software ‘agents’ modify an emerging architecture
according to their preferences and the desired objectives.
The agents are of several types, with distinct populations
working to construct a function structure out of functional
component descriptions and to ‘instantiate’ a design using
components from a catalogue. The Schemebuilder project
(Bradley et al. 1992) and the FBS Modeller (Umeda et al.
1996) used a similar model of design as incremental con-
struction of linked functional and physical structures, but
were intended to be used interactively by a designer rather
than autonomously. In the former case, this was based on a
function-means tree; the latter was later linked with a
separate product family design system in the IMS/GNOSIS
project (Ranta et al. 1996).
Knowledge-Based Engineering (KBE) represents a more
pragmatic form of design support. Rather than supplying a
formalised problem definition to generic solution-finding
mechanisms, KBE involves capturing the steps an expert
designer would take to solve the problem in computer-
executable form. KBE tools such as ICAD (now incorpo-
rated into CATIA KnowledgeWare), Design ??,
Unigraphics NX with KnowledgeFusion and GenWorks
GDL typically provide an environment with geometry
and a notion of product structure and are thus applicable
to architecture design. More general tools include
Res Eng Design (2012) 23:17–52
optimisation environments (such as Isight or modeFRON-
TIER) and constraint solvers (e.g. ILOG Solver). KBE tools
have reduced the design time in domains such as aerospace
(Corallo et al. 2009); however, due to their complexity, the
effort required to configure a tool for a specific application
is significant (Bermell-Garcı́a and Fan 2002), and thus their
use is restricted to largely repeatable design problems. In
addition, the focus of the approach on capturing existing
knowledge may mean that novel architectures are beyond
the reach of such tools (since they effectively formalise the
fixation effects described in Sect. 2.2.1).
Similar in philosophy to KBE tools are product config-
uration systems, or ‘configurators’ (in the second sense of
‘configuration’ discussed in Sect. 2.1). These are used
specifically to guide the selection of combinations of pre-
designed components for a particular customer’s needs.
One of the earliest, R1/XCON, was used at Digital
Equipment Corporation to configure VAX computers from
1978 (McDermott 1980); more advanced systems such as
COCOS (Stumptner et al. 1998) can handle systems
involving thousands of components. However, such sys-
tems assume total knowledge of the product and are thus
not applicable during the early part of design considered in
this paper.
Many of these methods employ constraints, in the widest
sense of explicit tests which a design must satisfy. In some
cases, such as in grammar-based approaches, the con-
straints play a minor role in synthesising solutions; how-
ever, in other methods, the constraints are more significant
in determining the resulting solutions. Numerical con-
straints, restrictions on the possible values of a design
parameter, have been used in parametric design (Medjdoub
and Yannou 2000; Mullineux et al. 2005). Alternatively,
constraints may represent high-level qualitative informa-
tion. In this case, they may be part of the problem defini-
tion, as in the configurators described above; or they may
be implicit in the method, such as for flow compatibility in
the FuncSION system for synthesis of mechanisms from a
set of fundamental ‘building blocks’ (Chakrabarti and
Bligh 1996) and in the system described by Ulrich and
Seering (1989), for synthesis of input–output dynamic
systems from specified components. Although not directly
applicable to architecture design, numerical constraints
may represent qualitative constraints—for instance, a
numerical constraint specifying a distance of zero between
two walls in a building floorplan effectively defines a
qualitative constraint of connectivity between the corre-
sponding rooms. In terms of product architecture design,
qualitative constraints have similar expressive power to
graph-grammar-based approaches. However, while graph
grammars can express complex transformations of an
architecture succinctly, constraints represent the ‘bound-
aries’ of the ‘design space’ more directly, which may allow
21
easier and more accurate formalisation of a product
architecture design problem.
3 Understanding product architecture design
in practice
Despite the potential advantages of computational design
synthesis-based methods described in the previous section,
their take-up in industry has been limited (Wood and Greer
2001). Acting on the hypothesis that this is due to a mis-
match between the needs of engineering design practice
and the systems developed to date, requirements for a
method to support product architecture design were
established from a case study at an engineering firm.
3.1 Procedure
The basis for selecting the case study was that the design
context should be representative of other engineering
products and that the architecture of the product should
permit variation (whether or not such variation occurs).
The target chosen was a UK-based manufacturer of med-
ium-scale off-highway diesel engines, which in the last
decade became vertically integrated into a multinational
engineering group after decades of independent operation.
Diesel engines are comparable to many types of mechan-
ical products in terms of complexity, safety-criticality,
strong legislative pressure, requirements for high reliability
and potentially contradictory market demands (in this case,
increased performance within a fixed physical footprint).
While the core technology is mature and restricted by many
of these factors, and thus the scope for architecture change
in the ‘core engine’ was known to be limited, innovation
was thought to be possible in the design of the peripheral
systems (cooling, fuel, air, exhaust handling); this was
borne out during the study. Thus, diesel engine design is an
appropriate context from which to infer requirements for a
support method.
The questions investigated during the case study inclu-
ded not only requirements for product architecture design
support methods but also design processes, organisation
and effects of product architecture on later design; a full
discussion of the findings may be found in Wyatt et al.
(2009a).
Interaction with the company involved 13 semi-struc-
tured interviews with eight engineers at the company’s
headquarters over a period from May to December, 2008.
Interviews lasted between 45 min and 2 h, with each
engineer interviewed 1–3 times. Initial selection of inter-
viewees used contacts from previous research projects
carried out at the company by the authors’ research group,
after which further interviews were based on suggestions
123
22 Res Eng Design (2012) 23:17–52

from interviewees (‘snowball’ sampling). All interviews of the relevant subproblem and to consider the effects
were recorded, then transcribed and reviewed. Other of the excluded portions when appropriate.
sources of information included informal comments from
To gain further insights, a specific design problem was
other employees of the company and sample items of
investigated during the case study, involving the design of
design documentation.
the mounting arrangement for the engine components
(particularly, the core engine and ‘cooler group’, a com-
3.2 Findings and inferred requirements for the support
bination radiator and charge air cooler) in electrical gen-
method
eration and pumping applications. Numerical analysis had
suggested that the design used in the previous product
In the case study, design was observed to be primarily
generation could no longer be used due to changes in
incremental: development of a new product line was based
component dimensions, and therefore a redesign was nee-
on the previous generation, and in particular few changes
ded. Five potential new architecture concepts were gener-
were made at the architectural level. To a large extent, this
ated by ‘brainstorming’, although most were drawn from
architecture carry-over was deliberate and planned: the
previous products made by the company or its competitors
large ‘investment’ both in capital equipment and in
rather than from first principles (evidence of the difficulty
organisational processes associated with an architecture
of solution generation as described above). The concepts
meant that the cost of changes to it had to be spread over
involved different arrangements of a small set of possible
multiple product generations, and thus modifications to the
‘components’, many of which (e.g. the core engine) had
architecture only occurred where new requirements could
complicated internal structures which were abstracted
not be met using the existing architecture. Recently,
away while brainstorming (evidence of the need to support
requirement changes have come from emissions legislation
problem decomposition and integration). When asked
(Jarratt et al. 2003), and corresponding architectural
about the concepts, the engineers were readily able to
changes have included adding exhaust after-treatment
explain why particular patterns of elements were workable
systems to the engine. However, in addition to deliberate
while others were not; for instance, the cooler group would
architecture carry-over, there was evidence that architec-
be damaged by vibrations from the engine block and so
ture was carried over involuntarily because the engineers
could not be rigidly mounted to it. These explanations
involved in design were unable to identify alternatives,
often could not be simply formulated using the concept of
reinforcing the difficulty of ‘Generation’ as stated in Sect.
‘function’ as an input–output transformation, used in many
2.2.1. Therefore, a formal method for systematically gen-
of the methods described in Sect. 2.2.2, in some cases due
erating solutions to a design problem could be beneficial in
to the internal structures of the elements. Two further
this context. The need to incorporate planned architecture
requirements arise from these observations:
carry-over represents a formalisation-related requirement
on a support method: • F3–Problem-specific elements: The method should
allow the designer to define the architecture’s compo-
• F1–Incremental design: The method should allow the
nents as fits the problem, rather than at the level of
designer to specify an architecture as a starting point for
elementary machine elements or input–output
synthesis of new solutions.
‘functions’.
Through the course of the interviews, it became clear • F4–Declarative definition: The method should repre-
that there was no single point where the engine’s archi- sent the design space of architectures implicitly (with-
tecture, in the sense of the definition in Sect. 2.1, was out enumeration) and declaratively (through constraints
designed. Instead, those parts of the architecture that did that define allowable architectures).
change were redesigned in separate but interlinked design
The five new engine-mounting architecture concepts
subproblems of limited complexity, such as the core engine
were evaluated against the original using a Pugh analysis
layout or the incorporation of the fuel injector into the
(Pugh 1990) with 19 weighted criteria. In the evaluation, the
cylinder head. This is a characteristic commonly observed
‘technical confidence’ in the solution was only one of the
in engineering artefacts (Alexander 1964), which have
most important criteria—others were high-level business
been termed ‘almost decomposable systems’ (Simon
and customer drivers, e.g., market competitiveness and ease
1996), and represents a further requirement:
of assembly. Again, the engineers were usually able to
• F2–Problem decomposition: Where an overall design articulate the specific features of each architecture concept
problem may be decomposed into interlinked subprob- that caused them to assign it a particular score, based on
lems, the method should allow designers both to their previous experience since the detailed knowledge
abstract away portions of the design outside the scope needed to predict its technical performance was not yet

123
Res Eng Design (2012) 23:17–52
available. When the design problem was originally under-
taken, the two highest-scoring architectures were taken
forward to more detailed evaluation.
This suggests two requirements for the interpretation
step of the method:
• I1–Interpretation support: The method should present
synthesised architectures such that they can be inter-
preted and further evaluated by designers.
• I2–Feature-based evaluation: The method should allow
designers to specify structural features of architectures
which have beneficial or detrimental effects on any of
the lifecycle objectives of the product, and to evaluate
synthesised architectures by testing for the presence of
these features.
Finally, in terms of the overall solution-finding proce-
dure, the iterative nature of design and the difficulty of
constructing an appropriate description of a problem (in
informal terms much less a formal representation) means
that in addition to the three phases of Formalisation, Syn-
thesis and Interpretation, a method should also support the
‘Refinement of formalisation’ iteration in Fig. 1:
• P1–Refinement of formalisation: The method should
support the modification of the problem formalisation
by the designers in response to their interpretation of
the synthesised solutions.
It is notable that many of the computational synthesis
methods described in Sect. 2.2.2 do not fulfil these
requirements, in particular:
• Although certain classes of approach are in theory
applicable to incremental design problems (Require-
ment F1), such as graph grammars if appropriately
formulated, the issues associated with this are rarely
discussed.
Fig. 2 A simple gear train, reproduced from Starling and Shea (2005)
23
• Many methods that use the energy-transformer model
of components, such as Campbell et al. (2000) and
Chakrabarti and Bligh (1996), are not appropriate in
this context (Requirement F3).
• Grammar-based approaches are by definition proce-
dural, rather than declarative, descriptions of the design
problem (Requirement F4).
• Few methods explicitly support designers in refining
the definition of the space of architectures and/or the
start point (Requirement P1).
The next section presents a method to support product
architecture design based on these requirements.
4 Proposed support method
4.1 Formalisation: representing architectures
and spaces of architectures
In the method, product architecture design problems are
represented using a set of constructs which have been
developed iteratively through a series of examples,
including those described in Sects. 5 and 6. A simple
example will be used to illustrate the various constructs,
based on the problem of transmitting torque through a gear
train. Figure 2, from Starling and Shea (2005), shows an
example gear train containing seven gears indicated by
numerals; ‘[S]’ indicates the shaft of the motor (the input to
the gear train) and ‘[W]’ indicates the connection to the
winding mechanism (the output from the gear train).
4.1.1 Modelling product architectures
A product architecture is represented as a network in which
nodes represent components and links represent connec-
tions or other relations, in accordance with the definition in
Sect. 2.1. Both components and connections are assigned a
concrete type (e.g. ‘Input gear’) that indicates where dif-
ferent elements are members of some category and are thus
equivalent at the architectural level; the details of compo-
nents of the same type may be different, for instance, one
‘Idler gear’ may have a different number of teeth from
another. Higher-level similarities may be indicated by a
generalisation-specialisation hierarchy of types, in which
types above the ‘leaf’ level may be marked as abstract to
indicate that they may not be instantiated directly; a given
type can have multiple ‘parents’. Abstract component and
connection types may serve purely a cognitive or aesthetic
role, to indicate the organisation of the hierarchy, but they
can also be used to assign a single network structure
constraint (described in the next subsection) to multiple
concrete types.
123
24
The types of connections modelled are at the discretion
of the designer, but may include any or all of:
• Structural relations such as ‘attached to’, as used in
Shea et al. (1997), and ‘contains’;
• Behavioural relations such as flows of energy, materials
and signals and their subtypes, as used in function
structures (Pahl et al. 2007; Hirtz et al. 2002);
• Assignment relations such as ‘comprises’, similar to the
‘component realises organ’ relations of Andreasen
(1992);
• Geometrical relations such as relative position.
This flexibility in defining relations makes it possible to
focus on the essence of different solutions to an architec-
ture design problem–for example, geometry may be
unimportant. A connection type must be marked as either
symmetric (e.g. ‘attached to’) or asymmetric (e.g. ‘con-
tains’) to reflect its semantic meaning. In the examples
considered, the expressiveness of this representation of the
relations between components has been found to be
equivalent to other representations that equip components
with input and output ports that may be interconnected if
their flow types are compatible, such as Helms et al. (2009).
While detailed modelling and analysis of an architecture
may require consideration of the connections of individual
ports of elementary components (such as the three termi-
nals of a transistor) (Paredis et al. 2001), the omission of
ports in this method simplifies the modelling language
while maintaining flexibility.
Figure 3 shows how the architecture of the simple gear
train in Fig. 2 may be represented in this form, as a net-
work (in this case a chain) of components linked by con-
nections. The figure uses elements from a graphical
Fig. 3 The architecture of the gear train in Fig. 2, modelled using the graphical notation introduced in this paper
123
Res Eng Design (2012) 23:17–52
modelling notation that will be used throughout this paper:
components are represented as cubes and connections as
concentric circles, with component and connection types
indicated by the corresponding symbol within a border. In
this case, there are three concrete component types (‘Input
gear’, ‘Output gear’ and ‘Idler gear’), one concrete con-
nection type (‘Meshes with’, which is symmetric) and one
abstract component type (‘Gear’) from which all three
concrete component types inherit.
For brevity, in the remainder of this paper the term
‘architecture’ will be used to refer to a model of a product
architecture in this form.
4.1.2 Defining a space of architectures
In the method, a specific product architecture is viewed as a
point in a ‘space of possible architectures’. The extent of a
space of architectures is defined by the complete set of
possible arrangements of components and connections, but
not every arrangement of components and connections
‘makes sense’. Put more formally, an arrangement of
components and connections is realisable if it is an archi-
tecture of a product that could fulfil the desired function. Of
course, an architecture can give rise to a very large or
infinite number of detailed designs, only some of which will
be functional in the desired sense. In keeping with
requirement F4, the set of realisable product architectures is
defined implicitly and declaratively by using qualitative
constraints on the arrangement of the components and the
connections between them. This is analogous to defining the
feasible region in a parametric design problem through
numerical constraints. Four types of network structure
constraints (NSCs) are defined in the method:
Res Eng Design (2012) 23:17–52 25

• Component number constraints (CNCs) indicate how concept of ‘slot modularity’ (Ulrich 1995) and may also
many components of a given type must be present, for be used to represent alternative embodiments (child
instance ‘There must be one input gear’. concrete component types) for a function (the abstract
• Direct connection constraints (DCCs) indicate which component type). Connection types may also be
component types may be connected together by which similarly grouped, particularly when used in ICCs.
connection types. In addition, they specify the required
Although fairly simple, the set of NSC types has been
cardinality of the connection—how many components
found sufficient to define almost all aspects of realisability.
of the second type must be connected to a component of
However, in some cases this language may not suffice;
the first type, and vice versa. For instance, ‘A gear must
possibilities for extending it are discussed in Sect. 7.1.
mesh with at least one other gear’.
The set of component types, connection types and NSCs
• Fan out constraints (FOCs) indicate how many
for a particular problem, which describes a range of pos-
connections of a certain type that components of a
sible architectures, is termed a schema. This terminology
certain type must have in total, for instance ‘An idler
was chosen by analogy with Extensible Markup Language
gear must mesh with at least two other components’ (to
(XML) schemas (XML Working Group 2004); equivalent
avoid ‘dangling’ idler gears at the end of the gear train).
pairs of terms from other areas of research include
If the connection type is asymmetric, an FOC may
‘instantiated architecture’ and ‘generic architecture’ in
apply to incoming connections only, outgoing connec-
mass customisation (Jiao and Tseng 1999), ‘closed product
tions only or both.
structure’ and ‘open product structure’ in engineer-to-order
• Indirect connection constraints (ICCs) indicate how
systems (Mesihovic and Malmqvist 2000), ‘product model
many continuous paths there must be from every
instance’ and ‘product model’ in knowledge-based engi-
component of one type to every component of another
neering (Brimble and Sellini 2000), and ‘model’ and
type, made up of connections of specified type(s), for
‘metamodel’ in object modelling (Object Management
instance ‘There must be exactly one path of ‘meshes
Group 2006).
with’ connections from the input gear to the output
In many cases, there are multiple ways of abstracting an
gear’ (to transmit torque from the input to the output
architecture design problem into a schema, varying in level
without loops in the gear train). Where asymmetric
of detail and scope:
connections are present, an ICC may be configured to
either obey or ignore the direction of the connections • Level of detail: The component and connection types in
when checking for paths. Optionally, the number of the schema may represent architecture elements at any
components of particular types on the path may also be level of granularity, from high-level assemblies to
specified. individual geometrical features; the level of detail need
not be consistent across all elements.
Numerical aspects of NSCs are specified as ranges with
• Scope: The schema may allow any architecture that
a minimum and a maximum for the quantity concerned. All
could potentially solve the problem, in an unrestricted
NSCs are assumed to apply simultaneously (Boolean
design context, or may be more focused around a
‘AND’) to all components of the corresponding types
particular set of possibilities if, for example, manufac-
(universal quantification). As mentioned in the previous
turing limitations or intellectual property issues are
subsection, NSCs may refer to either concrete or abstract
significant.
component/connection types. This capability may be used
to express constructions which would otherwise require Other forms of variation between schemas are possible:
Boolean combinations of multiple NSCs (the example for instance, the NSCs may be set up such that the number
DCC quoted previously is an example of both of these of components of a particular type is limited by the cor-
constructions): responding CNC or by a cardinality constraint in a DCC.
However, the processes of formalisation and interpretation
• One NSC may apply to all component types within a
are complementary, and thus different schemas may still
higher-level grouping (‘AND’), for instance ‘Every car
lead to realisable architectures when interpreted appropri-
[an abstract component type with child component
ately. Indeed, architectures synthesised from different
types hatchback, saloon, estate and sports car] must
schemas can lead to the same embodiment. This issue is
comprise four wheels’.
discussed further in the context of the usability evaluation
• Alternatively, an abstract component type may express
in Sect. 6.1.
the possibility for alternatives (‘OR’), for instance
To continue the illustrative example, the space of gear
‘Every sports car must comprise one roof [an abstract
trains for the winding mechanism shown in Fig. 2 may be
component type with child component types solid roof
represented by the schema shown in Fig. 4, which indicates
and folding roof]’. This construction is similar to the

123
26
Fig. 4 A schema for the space of simple gear trains
how NSCs are represented in the graphical notation. Since
each component type will have its own component number
constraint, CNCs are shown by numbers within the com-
ponent type symbols; other types of NSCs (DCCs, FOCs
and ICCs) are indicated by separate elements whose icon
indicates the type of constraint, linked by arrows to the
relevant component and connection types. An unlimited
upper bound in a numerical range is indicated by ‘*’. In
this case, the schema uses appropriate CNCs, the example
DCC, FOC and ICC quoted previously, and an additional
ICC specifying that there must be a single path of con-
nections from the input gear to each idler gear (again to
prevent loops in the gear train). Some of these constraints
are not necessary for the case of a single output gear, but
become important if multiple output gears are allowed.
Finally, the hierarchies of concrete component and con-
nection types have been completed by top-level abstract
component and connection types.
In cases where continuous arrows between elements would
be inconvenient, the arrows may be split by ‘hyperlinks’.
These are represented by small white circles containing
numbers; pairs of circles containing the same number repre-
sent a logical connection.
The graphical notation is summarised in Fig. 5.
4.1.3 Ensuring consistency between schema
and architectures
In order to be used for computational synthesis, it is
important that a schema accurately represents the space of
solution architectures for a product, taking into account any
abstractions or modelling conventions made in setting up
123
Res Eng Design (2012) 23:17–52
the design problem. In particular, apart from syntactic
errors in the use of the method constructs, there are two
possible problems with a schema: overconstraint, where
realisable architectures are rejected; and underconstraint,
where unrealisable architectures are allowed. A single
schema may be both underconstraining and overcon-
straining in different respects. However, although a schema
is a declarative representation, because it is also implicit it
may be difficult to check its accuracy manually. This stems
from both the implicit nature of the ‘real’ set of possible
architectures and from cognitive limitations in ‘thinking
through’ schemas with more than a few elements.
On the other hand, it is straightforward to test for
consistency between a schema and an architecture by
checking whether the architecture is in the design space
described by the schema (i.e. satisfies the schema’s
NSCs). If the schema accurately represents the space of
possible designs, and if the architecture accurately rep-
resents a specific design, the schema and architecture will
be consistent. Conversely, if the architecture and schema
are inconsistent, one or other must be unrepresentative of
reality and must be refined by the designer. Typically,
such refinement will proceed iteratively, guided by
information about the specific constraints violated, until
the architecture and schema are mutually consistent—at
which point the schema will be representative of at least
that segment of the design space that contains the
example architecture. While this process does not assess
whether the schema is accurate outside the example
concerned, applying the process several times using dif-
ferent architectures can then extend the segment of the
design space known to be represented by the schema and
reduce the likelihood of overconstraint. Since it is more
direct to construct a representative model of a real
product’s architecture than to construct a representative
schema, this consistency checking can reduce the diffi-
culty of constructing a representative schema. Under-
constraint can be detected more straightforwardly by
inspecting the ‘realisability’ of synthesised architectures,
and again can be corrected by iteratively refining the
schema.
The discussion has focused on ensuring that a schema
accurately represents the real design problem, but the
approach of consistency checking can also be applied
in situations in which it is important to obtain an archi-
tecture that is an accurate model of a real product—for
instance, if an architecture is to be used as the starting point
for synthesis as discussed in the next section.
4.2 Synthesis algorithm
Based on a schema, sets of solution architectures may
be generated using computational design synthesis. The
Res Eng Design (2012) 23:17–52
Fig. 5 A summary of the graphical notation for product architectures
and schemas
technique used is state space search (Russell and Norvig
2003). The space of architectures forms a state space, since
any architecture, realisable or not, can be reached from any
other architecture by appropriate sequences of four types of
elementary operations:
1. Removing an existing component (in which case all
connections associated with it must also be removed);
27
2. Removing an existing connection.
3. Adding a component of one of the types defined in the
schema;
4. Adding a connection of one of the types defined in the
schema, between two existing components;
While these operations could be represented by rules in
a graph grammar such as those discussed in Sect. 2.2, in
graph grammar methods any architecture that contains only
terminal symbols and has been generated from the starting
point by a sequence of rules is assumed to be realisable. In
contrast, in this method, the evaluation of realisability is
separate from the synthesis process and achieved by testing
whether the current architecture satisfies the NSCs at each
point in the search.
The architecture from which the synthesis starts, the
start point, is supplied by the designer according to the
type of design problem:
• If the problem involves adapting an existing design,
i.e., is a case of planned architecture carry-over, the
start point may be the architecture of the existing
design. This start point may be modified before
synthesis by manually removing components or con-
nections; alternatively, the synthesis algorithm may be
configured to remove different combinations of ele-
ments automatically.
• If the problem involves the relation between a design
and an external context, the start point may be a model
of this context. The synthesis algorithm can then be
restricted to using only those component and connec-
tion types that represent the architecture to be designed,
rather than those which represent the context.
• If there are no preconceived ideas about the form of the
solution (i.e. there is no architecture carry-over except
that embodied in the schema), to reduce computational
expense the synthesis algorithm automatically gener-
ates a start point: an architecture containing the
minimum number of components of each type to
satisfy the corresponding CNC. For instance, in the
case of the schema in Fig. 4, the minimal architecture
will contain one input gear and one output gear but no
idler gears.
The type of the design problem may also determine
whether all types of elementary operations may be used or
whether a specific subset is appropriate. For instance, if the
designer wishes to conserve the set of components in an
existing architecture and investigate how those components
could be connected in different ways, synthesis may be
restricted to adding and removing connections (operation
types 2 and 4), while in design with no architecture carry-
over there are no existing components or connections to
remove and thus operation types 1 and 2 are unavailable.
123
28
State space search problems can be solved exhaustively
using conventional graph search algorithms (Knuth 1998).
In this case, depth first search is used to reduce runtime
memory requirements, with a limit on the maximum search
depth—i.e., the maximum ‘distance’ (number of elemen-
tary operations) between the start point and any generated
architecture. The algorithm is based on a first-in last-out
‘stack’ of architectures to be examined and proceeds as
follows:
1. Initialise the stack to contain the start point.
2. Remove one architecture from the top of the stack.
3. Test whether this architecture is valid (i.e. satisfies all
NSCs in the schema, and thus represents a realisable
product architecture).
a. If so, add it to the list of solutions found and return
to step 2.
b. If not, proceed to step 4.
4. Test whether the maximum search depth has been
reached.
a. If so, proceed to step 5.
b. If not, generate all ‘children’ of the current
architecture (those architectures that can be
reached by a single elementary operation), and
add them to the top of the stack.
5. Test whether the stack is empty.
a. If so, terminate and return the list of solutions
found.
b. If not, return to step 2.
In step 4b, elementary operation types are applied in
sequence: different combinations of components are
removed from the start point; for each of those, different
combinations of connections are removed; for each of
those, different combinations of components are added; for
each of those, different combinations of connections are
added. Testing for validity is only performed after adding
connections (which must always occur), and each ele-
mentary operation type has its own maximum search depth.
The search is most efficient if the maximum search depth is
not significantly greater than the minimum depth necessary
to synthesise architectures that satisfy the NSCs.
The computational expense of the search can be sig-
nificant for moderately complex problems. To make the
search more efficient, techniques are used to prune the
search space. Each architecture examined is recorded to
ensure each point in the state space is searched only once.
When adding connections, the set of connections added to
produce the ‘children’ is restricted to those which would
contribute to satisfying a DCC whose lower bound is not
met, until all DCCs are satisfied (inspired by Stumptner
123
Res Eng Design (2012) 23:17–52
et al. (1998)); when no unsatisfied DCCs remain, connec-
tions are only added if they do not violate any DCCs.
Likewise, when adding components architectures are not
considered for adding connections unless all CNCs are
satisfied. Lastly, in the case of large problems where
exhaustive search methods such as depth first search
require an excessive computation time, stochastic methods
can be used to sample from the space of architectures.
Samples are generated by performing a random number
(less than or equal to the maximum search depth) of ran-
dom elementary operations with search pruning as descri-
bed above, after which the resulting architecture is tested
for validity. These refinements have proved sufficient to
allow application to realistic cases, such as the example
described in Sect. 5; however, the computational cost
remains considerable. Future avenues for improving syn-
thesis efficiency are outlined in Sect. 7.3.
4.3 Interpretation of generated architectures
4.3.1 Graphical representation
A single synthesised architecture may be presented to the
designer as a two-dimensional image using a force-directed
layout (Eades 1984) to arrange the elements automatically
in an interactive manner; masses represent components and
springs represent connections. Four examples are shown in
Fig. 6, representing gear train architectures synthesised
from the schema in Fig. 4 modified to require two output
gears; the layout has been configured to display compo-
nents as gear shapes, with light grey representing the input
gear, dark grey the output gears and white the idler gears (if
present).
4.3.2 Quantitative evaluation
To support the designer in choosing between a set of
architectures, each architecture may be evaluated quantita-
tively using one or more metrics. In this context, a metric is
defined as a function f from a space of architectures A to the
set of real numbers R, as shown in Eq. 1. Without loss of
generality, such functions must return positive values with
smaller values corresponding to ‘better’ architectures, in
accordance with the conventions of objective functions in
optimisation. Each metric may assess a particular aspect of
the ‘quality’ of an architecture related to any of the pro-
cesses with which the product is involved during its lifecycle
(Huang 1996). Multiple metrics may be used in combination
to give a greater overview of the solution space.
f :A!R ð1Þ
However, an architecture as a network of components
and connections contains little information about any
Res Eng Design (2012) 23:17–52
aspects of its quality. This means that many conventional
assessment methods for product design cannot be used,
with the exception of pure ‘complexity’ metrics (Summers
and Shah 2010). To assess more concrete aspects of
quality, it is necessary to incorporate additional
information about a specific design context via one of
two routes:
• Into the architecture, by assigning properties to the
elements, e.g., the manufacturing operations used to
produce each component or the materials of which they
are composed, which allows the use of generic metrics;
or
• Into the metric, for instance by testing an architecture
for the presence of specific structural patterns which are
deemed to be significant for the corresponding aspect of
the quality of the design (Lindemann et al. 2008).
In this work, the architectures resulting from synthesis
do not include additional information themselves (although
the method could potentially be extended to include such
information). Thus, more specific metrics must be derived
by including information in the metric definition. Three
such metrics, which assess different aspects of the devel-
opment process for a product, are described in Table 1. The
metrics are based on graph-theoretical properties of an
architecture and assess the complexity of designing a
Fig. 6 A selection of synthesised gear trains with two output gears, arranged using a force-directed layout
29
product (D-complexity), the complexity of manufacture
(M-complexity) and the complexity of making a change to
the product (C-complexity).
Since these metrics are not calibrated against an abso-
lute scale (e.g. cost or time) and are intended to be generic
across product domains, they are used only as an indication
of the relative differences between architectures. If infor-
mation about a specific product domain is available,
structural complexity metrics may be tailored for that
context; an example of this is given in Sect. 6.2.
4.3.3 Constraint-based classification and visualisation
In design situations where the design objectives are well-
defined and their meaning in architectural terms is well
understood, quantitative evaluation using metrics may be
appropriate. However, in other situations, it may be more
appropriate for a designer to explore the different concepts
within the set of architectures resulting from synthesis, for
instance, by classifying them into categories based on
specific patterns in the way components are connected
together. Patterns may be ‘interesting’ either because they
are known from prior experience to be significant (e.g.
patterns that have been used in previous products), or
simply because they are observed to be shared between
architectures.
123
30 Res Eng Design (2012) 23:17–52

Table 1 Metrics used to evaluate product architectures

D-complexity M-complexity C-complexity

P
n P
n .P
n P
n
DðAÞ ¼ 1n zi MðAÞ ¼ n þ 1n zi CðAÞ ¼ nðn1Þ
n dij
i¼1 i¼1 i¼1 j¼iþ1

Components with more interfaces require The manufacturing cost of a product may be The likelihood of change propagating between
more redesign work (Sosa et al. 2007). divided into the manufacturing cost of its two components in a product is inversely
Thus, a metric for the design complexity, components and the cost of assembling them. related to the graph distance between the two
D(A), of an architecture A containing While the costs of a component and a single components in the architecture (Clarkson
n components is: the mean of the number of assembly operation may be different, the total et al. 2004; Giffin et al. 2009; Keller et al.
connections per component zi for all part and assembly costs per item can be 2006). Therefore, a metric for the change
components i in A comparable (Huang 1996). Therefore, without complexity, C(A), of an architecture
additional information about the relative costs A containing n components is: the reciprocal
of parts and assembly operations, a metric for of the mean of the graph distances dij between
the manufacture complexity, M(A), of an all pairs of components i,j in A
architecture A containing n components is: the
sum of the number of components n and the
number of connections per component zi for
all components i in A (halved to avoid double
counting)

Such patterns can be defined using the same NSCs as in
the construction of the schema. These additional NSCs do
not affect synthesis, but are used only in the exploration of
the synthesis results. By comparing (computationally) all
of the synthesised architectures against the auxiliary NSCs
that define a category, the set of synthesised architectures is
classified into two subsets: those which satisfy the NSCs,
exhibit the pattern and are thus members of the category;
and those which do not and are not. Likewise, two patterns
divide the set of synthesised architectures into four subsets,
and three patterns divide it into eight subsets etc., although
some subsets may be empty. The category-membership
information may be condensed to a numerical ‘similarity’
value and used for hierarchical clustering (Langdon and
Chakrabarti 2001). Alternatively, the raw information may
be presented a visual form that preserves the complex
similarity relationships between architectures, for instance
through automatically generated Venn/Euler diagrams.
Examples of this are given in Sect. 5.4; more information
about this technique is presented in Wyatt et al. (2009b).
Java programming language (Sun Microsystems 2006).
The force-directed layout described in Sect. 4.3.1 was
implemented using Touchgraph (Shapiro 2002), and the
Euler diagram visualisation described in Sect. 4.3.3 using
the Prefuse information visualisation library (Heer 2007).
Figure 7 shows a screenshot of the software tool in use on
the example problem described in the next section.
4.5 Summary
A flowchart of the use of the system is shown in Fig. 8. The
sequence of activities is derived from Fig. 1, involving the
three key steps of formalisation, synthesis and interpreta-
tion. As indicated, the designer’s understanding of the
problem can potentially be enhanced by the synthesised
architectures, leading to generation of a wider range of
solutions. Alternatively, if the synthesised architectures
directly represent the possible options, they may be eval-
uated through the methods described in Sect. 4.3.2.

4.4 Implementation 5 Illustrative example: vacuum cleaner redesign

The method was implemented as a support tool based on
the Cambridge Advanced Modeller (CAM) software
framework, formerly the P3 Platform (Wynn et al. 2009).
CAM provides a user interface for constructing network
models conforming to a specified modelling language, with
an extensible plug-in architecture to allow analysis func-
tionality to be added to the software. In this case, a mod-
elling language was constructed to specify the eight types
of element described in Sect. 4.1, including the graphical
notation defined in Fig. 4. The synthesis and evaluation
algorithms were then implemented as plug-ins using the
Household vacuum cleaners originally used physical fil-
tration to separate dust from the air stream, most com-
monly employing a cloth or disposable paper ‘bag’ that
also collects dust for disposal. However, recent vacuum
cleaners have been equipped with cyclonic dust separators
(Dyson 1986). These use centrifugal effects in a cylinder of
rapidly rotating air to move dust to the perimeter leaving
clean air in the centre—a technology originally developed
for industrial dust extraction systems (Ogawa 1984).
Cyclonic systems can be more complex to engineer than
systems with physical filters, but have potential

123
Res Eng Design (2012) 23:17–52
Fig. 7 A screenshot of the
software tool in use on the
example problem described in
Sect. 5, showing the modelling
window, the synthesis control
panel and a force-directed
layout of a synthesised
architecture
advantages: they are not dependent on pores that can
become blocked by the collected dust, meaning that the
resistance to air flow does not reduce significantly over
time; and there is reduced waste and expense since the dust
collector can be emptied and reused. Thus, cyclonic vac-
uum cleaners are attractive to consumers: in a survey of
features of vacuum cleaners considered by consumers
when purchasing, ‘bagless’ (i.e. cyclonic dust separation)
was ranked second after ‘suction power’ (Mintel 2008). It
is therefore attractive for vacuum cleaner manufacturers to
introduce products that use cyclonic separation. However,
as discussed in Sect. 3.2, rather than designing a cyclonic
vacuum cleaner ‘from scratch’, a manufacturer may con-
sider conserving architecture elements from previous non-
cyclonic designs to minimise risk and cost.
Therefore, this example considers a hypothetical case of
adapting a bagged cylinder vacuum cleaner to use a
cyclonic dust separator. It is assumed that only the base
unit requires redesign to accommodate the cyclone—the
hose, nozzle etc. are not affected by the change. This
problem is an appropriate example for the method because
its level of complexity permits many possible architectural
variants, witnessed by the diversity of vacuum cleaner
designs in production, and thus a systematic exploration of
possible architectures could be beneficial. While more
complex design problems exist, as argued in Sect. 3.2 they
are often decomposed into sub-problems, each of which
may be of a similar level of complexity to this example.
31
Moreover, this problem is an example of ‘technology
infusion’ (Suh et al. 2008), which is widespread in engi-
neering design—the addition of aftertreatment systems to
diesel engines in the case study described in Sect. 3 was
also an example of this trend. As seen there, technology
infusion can cause wide-ranging architectural change but at
the same time can allow further changes to be made with
minimal additional cost. Technology infusion is therefore a
suitable class of problems for architecture design support
methods, and the procedure used to apply the method to
this design problem could potentially be used for other
design problems in this class.
This problem was addressed using the method proposed
in Sect. 4; the description follows the sequence of steps in
Fig. 1. The time taken to carry out each step was recorded,
to give an indication of the effort required.
5.1 Understanding the problem and possible solutions
In order to understand the different possible architectures
of vacuum cleaners, four examples were obtained spanning
a range of types; they are shown in Table 2. The last of
these, the Sanyo SC-N200, was chosen to fulfil the role of
the existing product in the example. The four example
vacuum cleaners were disassembled, and stages in disas-
sembly were photographed. After disassembly a written
description of each vacuum cleaner was prepared, record-
ing the architecture of the vacuum cleaner in terms of the
123
32
Fig. 8 A flowchart showing the use of the method proposed in this paper to support product architecture design
components and the connections between them. The level
of detail of the description was chosen by the authors,
trained engineers with no direct experience in vacuum
cleaner design, to include those design elements which
were considered necessary to describe different solutions to
the problem. Accordingly:
• Fasteners and internal wiring were recorded as con-
nections rather than components.
• Components such as the motor and the switch, which
would be designed and assembled in a separate process
or bought preassembled from suppliers, were not
reduced to individual parts.
• Some features of the product that were not physically
separable components but whose role in the architec-
ture would nonetheless be explicitly considered, such as
the handle, were recorded separately.
123
Res Eng Design (2012) 23:17–52
The descriptions and photographs were used as refer-
ences during formalisation of the problem. Disassembly
and documentation of each of the four examples took
approximately 3 h.
5.2 Formalising the problem
5.2.1 Initial modelling
The understanding gained through the activities described
in Sect. 5.1 was used to construct a schema for cylinder
vacuum cleaner power units, both cyclonic and non-
cyclonic. The schema is shown in Fig. 9, using the
graphical notation presented in Fig. 5. In this case, the
level of detail was chosen to be appropriate to the
problem under consideration, as described in Sect. 5.1,
Res Eng Design (2012) 23:17–52
Table 2 A comparison of the four example vacuum cleaners studied
Manufacturer Lever Industrial Goblin
Product name Ensign 360e AquaVac Industrial 40
Form factor Upright Wet/dry
Dust separator Bag Filter
Picture
and the scope was intended to include the entire space of
possible devices of this type, including not only the four
vacuum cleaners dismantled but also other designs of
which the authors were aware. The schema uses 16
concrete component types (including ‘Bag’ and
‘Moulding’), nine abstract component types (including
‘Airflow component’ and ‘Environment’), 11 concrete
connection types (including ‘Attached to’ and ‘Air
[flow]’) and one abstract connection type (‘Structurally
connected to’). Each component type has an associated
CNC, in addition to which 19 DCCs and three ICCs
were used. Although needed in other problems, FOCs
were not used here.
The majority of the entities in the schema were defined
by considering the types of physical components, and the
connections between them, present in the dismantled vac-
uum cleaners. Most of the abstract component types were
created in order to enable the same DCCs to apply to
multiple concrete component types (e.g. ‘Airflow compo-
nents can be interconnected [by Air connections]’ and
‘Components that must be contained must be contained by
one compartment’, two out of 10 such cases). Other
abstract component types were created to give a ‘complete’
hierarchy and thereby assist the organisation and read-
ability of the diagram (e.g. ‘Vacuum cleaner component’ is
a supertype of all component types except ‘Atmosphere’).
ICCs were used to ensure the existence of appropriate air
33
Tesco Sanyo
VC106 SC-N200
Cylinder Cylinder
Cyclone Bag
flow paths: the primary flow from the hose socket to the
atmosphere via a bag, filter and fan; and a secondary
flow from the atmosphere to the motor and vice versa,
which is required in all designs to cool the motor
windings.
In addition, a model was built of the architecture of the
Sanyo SC-N200 vacuum cleaner. The architecture is shown
in Fig. 10, again using the graphical notation presented in
Fig. 5. This served two roles during the formalisation of
the problem:
• During modelling it was used as an example architec-
ture to check the schema for consistency (as described
in Sect. 4.1.3).
• After modification, it was used as the start point for
synthesis (as described in Sect. 5.2.2).
The architecture contains 29 components and 50 con-
nections. The components and connections in the archi-
tecture are connected to the corresponding component or
connection type in the schema using hyperlinks, which are
also used for clarity within the schema in Fig. 9, to link
NSCs to the connection types with which they are
associated.
This stage took approximately 10 h in total:
• 8 h to build the schema;
• 2 h to build the SC-N200 architecture.
123
34
Fig. 9 The schema for the vacuum cleaner illustrative example. For
clarity, the connection types are grouped separately with hyperlinks to
the relevant NSCs. Shading indicates component and connection
5.2.2 Model simplification and refinement
While constructing the complete schema and architecture
models, it became clear that the incorporation of the
cyclone could be decoupled from many other parts of the
architecture such as the wheels or the mains cable storage.
Again this reflects the decomposable nature of many
engineering problems described in Sect. 3.2. In order to
focus the computational synthesis on solving the problem
at hand, therefore, the architecture of the SC-N200 vacuum
cleaner was simplified by removing or collapsing all ele-
ments which, in the view of the authors, were peripheral to
the problem. In particular, the ‘Airflow components’ after
the first filter (the ‘Fan’, ‘Motor’, ‘Rear compartment’ and
‘Exhaust vent’) and the ‘Atmosphere’ were collapsed into a
single component labelled ‘Rest of vacuum cleaner’; this is
shown by dark grey shading in Fig. 10. Parts of the
123
Res Eng Design (2012) 23:17–52
types that were removed or collapsed when the schema was
simplified—see text for details
architecture that could be completely decoupled were
removed (the ‘Wheels’, ‘Handle’, ‘Pressure relief valve’,
‘Mains cable’ and associated components), shown by light
grey shading in Fig. 10, and other appropriate modifica-
tions were made. The schema was likewise simplified to
remove definitions for unused component and connection
types, shown in Fig. 9 by dark grey shading for those
component types that were collapsed into ‘Rest of vacuum
cleaner’ and light grey for those that were removed.
In order to set up the problem for solution through
computational synthesis, the ‘Bag’ (outlined in black in
Fig. 10) was removed from the architecture and replaced
by a single ‘Cyclone’ component. This component repre-
sented the cyclone of air but not the surrounding casing;
thus it was defined such that it had to be ‘comprised by’ at
least two ‘Mouldings’ (plastic structural parts; two were
specified to ensure that it can be disassembled to empty the
Res Eng Design (2012) 23:17–52
Fig. 10 The architecture of the Sanyo SC-N200 vacuum cleaner. Shading and outlining indicates regions that were removed or collapsed when
the schema was simplified—see text for details
collected dust) and required incoming and outgoing ‘Air’
connections. In the architecture, the ‘Cyclone’ was given
‘Air’ connections corresponding to those of the ‘Bag’, but
no other connections. The task for the synthesis algorithm
was therefore to find ways to incorporate the cyclone into
the existing architecture.
However, when the initial version of the schema and
architecture were used for synthesis, inspection of the
results revealed many architectures that were unrealisable
(i.e. failed the ‘Appropriateness evaluation’ in Fig. 1),
indicating that the formalisation of the problem was
incorrect and required refinement. The schema was there-
fore revised (following the ‘Refinement of formalisation’
iteration in Fig. 1) and the synthesis repeated. For example,
some architectures included a ‘Moulding’ that ‘comprised’
the ‘Cyclone’ without being structurally connected to the
other components of the architecture, which would be
unrealisable under the interpretation used when construct-
ing the schema. To rule out such architectures, a new
abstract component type ‘Structurally connected to’ was
introduced into the schema, with children ‘Hinged to’,
‘Clips to’, ‘Attached to’ and ‘Locates against’; a new ICC
was then defined, requiring every ‘Moulding’ to be (indi-
rectly) ‘Structurally connected to’ the ‘Rest of vacuum
cleaner’. In total, approximately 75 synthesis runs were
performed—interspersed with modifications to the schema
35
and synthesis start point—before the architectures syn-
thesised were almost all realisable. However, one synthesis
run did not necessarily correspond to a single problem with
the schema, as multiple runs were often performed to
resolve a single problem due to errors in the initial solution
or interactions with other parts of the schema. Almost all
runs were short in duration as flaws in the schema were
frequently obvious from the first few architectures
synthesised.
The final versions of the simplified architecture and
schema are shown in Figs. 11 and 12. The final schema
contains seven concrete and five abstract component types,
seven concrete and one abstract connection types, 13
DCCs, two FOCs and two ICCs. The final architecture
contains nine components and 13 connections. This stage
took approximately 9 h:
• 1 h to simplify the architecture and schema;
• 8 h (spread over seven sessions) to iteratively refine the
simplified architecture and schema.
5.3 Synthesis
Once the schema and architecture were finalised, synthesis
was carried out to explore the problem of incorporating the
cyclone. The configuration of the synthesis algorithm is
123
36
Fig. 11 The simplified schema for the illustrative example
shown in Table 3, along with some information about the
results obtained. To establish appropriate maximum search
depths, a plausible ‘complete’ architecture was constructed
that satisfied all NSCs in the schema. In this architecture,
the ‘Cyclone’ was ‘comprised by’ two ‘Mouldings’, which
were ‘clipped to’ each other to form a unit that was
physically separate from the other ‘Mouldings’ in the
vacuum cleaner and ‘contained by’ the ‘Front compart-
ment’. The architecture had 11 components and 18 con-
nections. In order to allow architectures that were more
complex than this, the maximum search depths were cho-
sen to be one larger for both components and connections,
i.e., 12 components and 19 connections. Since the start
point shown in Fig. 12 has nine components and 13
123
Res Eng Design (2012) 23:17–52
connections, the synthesis algorithm was allowed to add up
to three components and six connections.
5.4 Interpretation of results
The 1101 architectures resulting from synthesis were
evaluated using the D-, C- and M-complexity metrics
defined in Sect. 4.3.2. Table 4 shows the minimum value of
each metric, corresponding to the ‘best’ architecture in
each case, and the metric values obtained from the original
architecture. Figure 13 shows a three-dimensional scatter
plot of the individual results, again including the original
architecture; the ‘best’ architectures are those closest to the
origin of the plot. Comparing the synthesised architectures
Res Eng Design (2012) 23:17–52 37

Fig. 12 The simplified

architecture of the Sanyo
SC-N200, used as the synthesis
start point in the illustrative
example

Table 3 Synthesis configuration for the example problem
Schema As shown in Fig. 11
Synthesis start point Architecture of Sanyo SC-N200
vacuum cleaner, as shown in Fig. 12
Elementary operations Adding components and
connections of all types
Maximum search Adding components: 3
depths Adding connections: 6
Search algorithm Stochastic search (500,000 samples)
CPU timea 11 h 0 min 2 s
Number of 1101
architectures synthesised
a
Intel Core 2 Duo P8600 processor at 2.4 GHz, 4 Gb RAM, Java
Runtime Environment version 1.6.0_20 on Windows Vista 32-bit
with the initial architecture, it has been possible to obtain a
slight improvement in D-complexity and a significant
improvement in C-complexity while the M-complexity has
deteriorated due to the addition of the cyclone. However, it
can clearly be seen that there is a tradeoff between the three
criteria, and thus a single ‘best’ architecture does not exist.
In such a situation, one method for deciding between
alternatives is weighted summation of the individual values
to produce a single ‘overall quality’ value (Q(A) in Eq. 2).
For this example, equal importance is assumed for the three
metrics and thus wC = wD = wM = 1 after normalising
each metric to return values between 0 and 1; in practice,
these weights would be determined by the context of the
design problem.
QðAÞ ¼ wC CðAÞ þ wD DðAÞ þ wM MðAÞ ð2Þ
Figure 14 shows a histogram of the Q values of the
synthesised architectures. In this case, the ‘best’ (lowest) Q
value of 0.47 is exhibited by a single architecture, which
Table 4 The minimum metric values achieved by the synthesised
architectures and the values obtained from the original architecture
Metric Minimum value Original
obtained from architecture
synthesised architectures
D-complexity 1.55 1.56
C-complexity 0.33 0.37
M-complexity 26 23
would therefore be recommended for further investigation for
the new vacuum cleaner. The architecture is shown in
Fig. 15, which is a copy of Fig. 12 with the components and
connections added during synthesis shown in dark grey (the
diagram was created manually based on a force-directed
layout visualisation of the synthesis results). One possible
three-dimensional embodiment layout, out of the many
defined by the architecture, is shown in Fig. 16. Interestingly,
this bears certain similarities to the Dyson DC08 shown in
Fig. 17. Since Dyson have never manufactured bagged
vacuum cleaners, there will have been little incentive for
planned architecture carry-over from such products (although
involuntary carry-over may still occur), and thus their
architecture may be regarded as approaching the best
available for a vacuum cleaner with a cyclone.
In general, however, an architecture found using this
method may not be usable in practice. This may be because
it is unrealisable due to imperfections in the schema, or
because it violates constraints that have not been modelled,
for instance related to manufacturing processes. If this
occurs, one of several routes may be followed to obtain a
usable architecture:
• The schema may be modified to correct imperfections
(‘Refinement of formalisation’ in Fig. 1);

123
38 Res Eng Design (2012) 23:17–52

Fig. 13 The original

architecture of the vacuum
cleaner and the 1101
synthesised architectures,
evaluated with respect to the
three structural complexity
metrics. Data points
corresponding to synthesised
architectures are plotted as dark
grey circles/spheres. The
original architecture is indicated
by a black square/cube

Fig. 14 A histogram of the Q values of the 1101 synthesised architectures

123
Res Eng Design (2012) 23:17–52 39

Fig. 15 The synthesised

architecture with the lowest Q
value

• The recommended architecture may be modified man-

ually to repair problems;
• Other architectures with a higher (but still low overall)
Q value may be investigated and considered.
The routes require different amounts of effort, and thus
the route followed will depend on the design context.
To further understand the different possibilities pro-
duced by synthesis, the constraint-based classification
method described in Sect. 4.3.3 was applied to investigate
which ‘Mouldings’ ‘comprise’ the ‘Cyclone’ in the syn- Fig. 16 One possible embodiment of the architecture shown in Fig. 13.
The ‘Front moulding’ and ‘Moulding 4’ comprise the cyclone, while the
thesised architectures. As noted above, the schema speci-
‘Front compartment’ and ‘Compartment 3’ (hidden in this view) are
fies that the ‘Cyclone’ must be ‘comprised by’ two empty, and could potentially be used for tool storage
‘Mouldings’. Since the constraint-based classification
method does not distinguish between different instances of Figure 18b shows an Euler diagram of this classification.
a component type, the schema was modified by adding This now represents a complete description of the ‘Moul-
three new component types as children of ‘Moulding’, to dings’ that ‘comprise’ the ‘Cyclone’, since all architectures
represent the three mouldings present in the start point (the are either members of two of the original three categories
‘Front moulding’, the ‘Lower casing’ and the ‘Lid’). This or are members of one of the additional three and the ‘An
allowed the following categories to be defined using DCCs: extra moulding’ category. However, some architectures are
members of the ‘An extra moulding’ category as well as
• Front moulding comprises cyclone
two of the original three categories (e.g. architecture 1),
• Lower casing comprises cyclone
raising the question of what role(s) the extra moulding
• Lid comprises cyclone
plays. Inspecting a selection of these architectures could in
Figure 18a shows an Euler diagram for a set of 25 turn lead to the definition of patterns representing the dif-
architectures generated using the synthesis configuration in ferent roles, potentially leading to further investigation of
Table 3, classified with these three categories. The diagram the possibilities. Iteratively classifying architectures in this
shows that, as expected, in some architectures two of the way can help the designer to explore the solution space and
pre-existing ‘Mouldings’ ‘comprise’ the ‘Cyclone’; how- incrementally expand their understanding of possible
ever, in others only one of the existing ‘Mouldings’ is used, solutions to the original problem.
for instance only the ‘Lower casing’ in architecture 5.
By inspecting such cases individually, it was determined
that synthesis had added an additional ‘Moulding’ which 6 Evaluation
also ‘comprised’ the ‘Cyclone’. Thus, an additional cate-
gory was defined using an auxiliary CNC to identify those To establish the value of the method proposed in Sect. 4 for
architectures where an additional ‘Moulding’ was present. design practice, the Design Research Methodology

123
40
Fig. 17 The Dyson DC08 cyclonic vacuum cleaner: a assembled, and the mating surfaces of b the base unit and c the cyclone/dust collector
module
developed by Blessing and Chakrabarti (2009) recom-
mends evaluation with respect to:
• Usability: the ease with which the method can be used
for the intended task;
• Applicability: whether it has the intended direct effect
on a design process; and
• Usefulness: whether the direct effect leads to an
improvement in a high-level success factor, taking into
account possible side effects.
In this case, the chosen high-level success factor is the
quality of the architecture concept selected at the conclu-
sion of conceptual design. As discussed in Sect. 2.2.1, the
quality of this selected concept will be positively correlated
with the thoroughness of the evaluation of the solution
space of product architectures, operationalised as the
number of candidate architectures examined during con-
ceptual design. This operational definition has previously
been shown to be correlated with success in student design
projects (Yang 2008). Therefore, the intended direct effect
of the method is to increase this number.
Preliminary evaluation of the method was carried out in
two separate studies, the first considering its usability and
the second its applicability and usefulness. Since these took
place in somewhat artificial contexts, an initial validation
study was subsequently carried out to explore all three
aspects in a more realistic setting.
6.1 Usability
6.1.1 Experiment setup
To assess usability, a laboratory study was carried out in
which participants were asked to apply the method to a
123
Res Eng Design (2012) 23:17–52
simple design scenario, involving generating new concepts
for bicycle lighting systems. As source material, the par-
ticipants were supplied with an example set of bicycle
lights, shown in Fig. 19a, and a sheet of images spanning
the range of available bicycle light designs, examples from
which are shown in Fig. 19b–d. They were also given a
summary of the relevant standard (British Standards
Institute 1986), although they were not required to produce
designs that conformed with it. The problem was chosen
due to participants’ familiarity with the domain; the aim of
the study was to establish how easily the participants found
it to follow the steps of the method rather than to examine
the range of architectures produced, and thus the existence
of a clear dominant design (represented by Fig. 19a) is not
problematic.
The six participants comprised four Ph.D. students and
two postdoctoral researchers. All had backgrounds in
design research, but not computational design synthesis
and all worked or studied at the Cambridge Engineering
Design Centre. Five out of six participants reported prior
experience with bicycle lights, all reported experience of
mechanical design and modelling products as networks of
components, and three out of six had used applications
based on the CAM framework (though not the support tool
described in Sect. 4.4). Variations in prior experience did
not discernibly affect their performance on the example
task.
The experiment took place on a single occasion, after a
pilot study with a single participant to assess feasibility
(results not included here). All participants were physically
present with access to their own laptop computers. The
participants were given a 1 h 20 min presentation covering
the method, the software tool and the example design
problem. The presentation suggested a procedure for using
Res Eng Design (2012) 23:17–52
Fig. 18 Automatically generated Euler diagrams for classifications of
a set of 26 vacuum cleaner architectures, a according to which of the
pre-existing ‘Mouldings’ ‘comprise’ the ‘Cyclone’, b with an
additional category to identify those architectures where synthesis
added a new ‘Moulding’
the method based on Fig. 7: choose a specific bicycle light
architecture; model it; construct a schema able to represent
it; add flexibility to the schema to represent a wider range
Fig. 19 a The example bicycle lights given to participants. b–d Examples from the sheet of images of alternative bicycle light designs,
illustrating the diversity in commercially available bicycle lighting systems
41
of architectures. The participants then worked individually
on the problem for up to 4 h, with support from the authors
on the modelling language and software tool but no
assistance with decisions about the formalisation of the
problem. One participant subsequently continued working
on the problem unassisted for a further 4 h. Those who
successfully synthesised architectures were asked to pro-
vide sketches of possible embodiments of three of their
results, to establish whether the synthesis results could be
interpreted. Schemas, architectures and embodiment sket-
ches were recorded, and subjective impressions of the
method were elicited through a feedback questionnaire. In
addition, the authors recorded their own observations.
6.1.2 Results
After spending 3–8 h on the problem, five of the six par-
ticipants had constructed schemas that yielded multiple
realisable architectures when used for synthesis. All five
participants who reached this stage also demonstrated the
interpretation of 1–3 of their synthesised architectures.
Figure 20 shows examples from two participants of sche-
mas (a, d), synthesised architectures (b, e) and sketches of
possible embodiments (c, f). For clarity, the synthesised
architectures are presented using the graphical notation of
Fig. 5 and were manually laid out, although they were
originally presented to the participants using the force-
directed layout visualisation described in Sect. 4.3.1.
Although the participants were given considerable
freedom in choosing the type of bicycle light to model
(indeed as shown in Fig. 19b–d the sample images inclu-
ded many different types), all five successful formalisations
were based on the type of lights shown in Fig. 19a. How-
ever, one participant allowed for an external power supply
(such as a dynamo) and another assumed that the lights
would be mounted on an armband rather than fixed to the
bicycle’s handlebars. Most participants used the connection
types ‘contains’ and ‘attached to’ (these were used in an
example from a different design domain in the initial
presentation) and chose a similar level of detail for their
123
42
(a)
(b)
(d)
(e)
Fig. 20 a A schema created by one participant as a formalisation of
the problem. b An example architecture synthesised from the schema.
c The participant’s interpretation of this architecture in the form of a
concrete component types (a typical example is ‘Light
source’, ‘Power supply’, ‘Switch’, ‘Socket’, ‘Casing’,
‘Attachment’). Participants obtained 6–17 architectures from
synthesis, containing 4–8 components and 3–10 connections.
Four participants employed abstract component types, in two
cases to represent alternative options for components to
fulfil a certain role and in three cases to apply a constraint
to multiple concrete component types. Two participants
constructed an architecture manually and used the consis-
tency checking facility described in Sect. 4.1.3 to check it
against the schema, while one constructed an architecture
but did not use the software to check it. In addition, one
participant built a separate small schema in order to test
part of the problem. All five completed schemas allowed
variation in the number of some components if every
123
Res Eng Design (2012) 23:17–52
(c)
Bulbs 1
Light switch 1
Total casing 1
Power source 1
Fastening device 1
(f)
Light 1
Light plate 1
Switch 1
Battery 1
Compartment 1
Strip 1
sketched embodiment layout (labels added for clarity). d–f A schema,
architecture and sketch produced by a second participant
component of a given type was connected isomorphically
(e.g. varying numbers of ‘Batteries’ ‘contained by’ a
‘compartment’), but only two allowed for true topolog-
ical variation. The participant who was not able to reach
the stage of successfully synthesising architectures also
attempted to allow variations in the numbers of com-
ponents, as well as alternative options for specific
components.
Aside from user-interface issues, a small number of
conceptual problems with the method were uncovered
through the experiment: one participant initially believed
the abstract component types represented an assembly
hierarchy rather than generalisation-specialisation, and the
distinction between components/connections and compo-
nent/connection types was initially unclear. However, a
Res Eng Design (2012) 23:17–52
more serious issue was identified in the procedure sug-
gested to the participants. Many participants began by
constructing a schema to represent only their chosen ‘basis
architecture’. Only once they had successfully constructed
this did they experiment with relaxing the NSCs to gen-
erate other architectures. Thus, although the procedure
enabled them to produce results from the method in many
cases, it was not conducive to generating a wide range of
different architectures. Participants perceived this limita-
tion, and during later discussion expressed interest in
constructing schemas with wider scopes. This procedure
also led to difficulties on a user-interface level: once they
could successfully synthesise architectures, participants often
tried relaxing the numerical ranges in the CNCs, but numerical
ranges elsewhere (typically in the DCCs) also required con-
certed changes which were often not immediately perceived
by the participants. For instance, if the basis architecture
contained a single LED and the CNC for ‘LED’ was modified
to require two LEDs, the DCC between the battery and the
LEDs also required modification to allow each battery to
supply electricity to (at least) two LEDs.
Despite the similar level of detail and similar (narrow)
scope chosen by many participants, the schemas con-
structed demonstrate the potential for variation in formal-
ising a given design problem, as discussed in Sect. 4.1.2.
As an example, in Fig. 20 the embodiment sketches in
(c) and (f) are extremely similar, but the architectures
(b) and (e) represent these embodiments quite differently
and the schemas in (a) and (d) have little in common.
Nonetheless, since each participant was able to interpret
the architectures synthesised from their schemas, the
schemas are equally valid as representations of (segments
of) the space of possible designs.
In the feedback questionnaire, opinions differed as to
whether the method limited the variety of results:
‘it is quite tempting to think along conventional lines’
‘[the results are] constrained around the chosen
model and mainly tell you what would happen if you
change [the] number of component[s], but do not
yield radically new ideas’
or enabled more wide-ranging thinking:
‘it helps you overcome your own inhibitions in that it
makes you consider design concepts that may not be
realised in practice’
‘specifying the relationship types makes you think a
bit wider [sic]’
‘Once the model was created, it was an effective way
to think of alternative ideas… The schema also
forced the modeller to develop a clear logic of the
interaction between components.’
43
A common theme was that beneficial effects resulted
from the activity of formalising the problem, rather than
the results produced:
‘the more valuable bit is probably the thought process
while constructing the schema’
The tool, although a prototype, was usable for the task:
‘intuitive in application, easy to use, once you know
what you want to design and understand the meaning
of different connection types’
‘with a small amount of practice, I believe that it
should be an easy tool to use’
However, some participants felt that the example prob-
lem was too simple to properly test the method:
‘[I] didn’t come up with anything I wouldn’t have
been able to come up with just using a piece of paper,
[it] felt a bit like shooting cannons at sparrows’
Overall, the study showed that the method could be
applied by users unfamiliar with computational design
synthesis to formalise a simple design problem, to syn-
thesise solutions, and to interpret them as potential physical
embodiments. However, the participants were students and
junior researchers rather than engineers with experience in
the relevant design domain, which may affect the way they
conceptualise the problem and thus the range of solutions
obtained. Further research is necessary, in particular, to
establish a procedure for formalising a design problem that
allows for innovation while giving the designer the clarity
and confidence to make rapid progress.
6.2 Applicability and usefulness
6.2.1 Method
To investigate the applicability and usefulness of the pro-
posed method, it was applied to the design problem elicited
during the case study described in Sect. 3 concerning the
design of the mounting arrangement for the engine com-
ponents in generator and pumping applications. The aim
was to establish whether the method led to more archi-
tecture concepts than the original brainstorming (which
would demonstrate applicability) and whether the best
architecture concept was better (demonstrating usefulness).
Based on the six original architecture concepts, the first
author constructed a schema for this design problem,
shown in Fig. 21. The scope and level of detail were
chosen to match the original architectures. Synthesis was
carried out using the configuration in Table 5; here, the
maximum search depths were chosen to match the size of
the original architectures. To evaluate the synthesised
123
44 Res Eng Design (2012) 23:17–52

Fig. 21 The schema used for the engine block mounting problem

architectures, four metrics were developed by the first Table 5 Synthesis configuration for the engine block mounting
author based on the four highest-weighted criteria in the problem
initial Pugh analysis: market competitiveness, product Schema As shown in Fig. 21
price, assembly complexity and technical confidence.
Synthesis start point Automatically generated minimal
These four criteria by themselves gave the same rank architecture: one ‘Cooler group’
ordering of the original architectures as the full set of cri- Elementary operations Adding components and
teria, and thus were considered a representative subset. The connections of all types
metrics were defined by assigning positive or negative scores Maximum search depths Adding components: 5
to specific structural features (components of particular types, Adding connections: 6
specific connections etc.) and evaluated by summing the Search algorithm Exhaustive depth first search
scores of the features present in an architecture. To allow CPU timea 2 min 13 s
comparison with the original design problem, the metrics Number of 256
returned the same scores for the original architectures as the architectures
engineers’ evaluations. This meant that larger metric values synthesised
correspond to ‘better’ architectures. Since these metrics used a
Intel Core 2 Duo P8600 processor at 2.4 GHz, 4 Gb RAM, Java
knowledge about the interpretation of the different component Runtime Environment version 1.6.0_20 on Windows Vista 32-bit

123
Res Eng Design (2012) 23:17–52
types in their definition, this is an example of the second
method for assessing quality in a specific design context
described in Sect. 4.3.2. The definitions of the metrics were
presented to engineers from the case study company and, after
improvement, were acknowledged to be appropriate measures
of the corresponding criteria.
6.2.2 Results
A comparison of the ‘quality’ of the six original architec-
tures and the 256 synthesised architectures is shown in
Fig. 22; note that the original architectures also appear in
the synthesis results. Interestingly, all six original archi-
tectures are comparatively high in quality. Only 78 out of
the 256 synthesised architectures (30.5%) had quality
values greater than or equal to that of the ‘worst’ original
architecture (-50.3); if six different architectures were
sampled randomly from the 256 in the design space, the
probability that they would all lie within the top 78 is
78 77 76 75 74 73
256  255  254  253  252  251 ¼ 0:07%: This small value
suggests that the original concepts were well chosen,
although other possible explanations are discussed at the
end of this section. Nonetheless, after removing trivial
variations and those that were realisable but would not
serve a useful purpose, exhaustive search found two
architectures of a higher quality than the ‘best’ of the six
original architectures (quality values of 35.0 compared to
20.3), and four further architectures whose quality equalled
or exceeded that of the second-highest-quality original
architecture (values of 14.7 and -0.6 compared to -0.9).
Fig. 22 A histogram showing the overall quality of the 256
synthesised architectures (grey) and the six original concepts (black),
using the four highest-weighted criteria from the original Pugh
analysis
45
Since the formalisation was carried out by the authors
outside the original design context, to investigate the
results further, the highest-ranked synthesised architectures
were presented to engineers at the case study company.
Their opinions were mixed. The approach was praised by
one engineer for bringing systematic approaches (which he
used in parametric design) into conceptual design:
‘‘What I think you’ve come up with which I like, is
that rather than doing our normal type analysis to
identify the optimum design you can actually come
up with a more rigorous approach… [It takes]
some of the subjectivity away, but the subjectivity
comes in the business’ understanding of what’s
important.’’
In addition, the automated evaluation and particularly
the ability to change metric weightings were viewed as
valuable:
‘‘The weightings can change through a project …the
market could change, the data that you’ve got to start
with maybe isn’t as good as the data maybe you’ve
got later on in the project… And therefore if you have
got a really robust model that you’ve generated, you
can actually change the weightings and see how the
[rankings change].’’
However, the specific results obtained were viewed as less
significant. One engineer criticised the schema for being
simultaneously underconstrained and overconstrained:
‘‘I’m reasonably happy that you’ve [formalised the
design problem accurately], I mean it would have
been lovely if you’d come up with something we
haven’t done… there are more constraints that would
go in, I think, and then you probably wouldn’t get
[256] solutions, you may only get eight, but those
eight would potentially be workable solutions.’’
As for the quality of the synthesised architectures, their
rankings were regarded as contingent on the weightings,
perhaps because of their similarity to the original six
architectures:
‘‘So then it’s then a question of weighting, isn’t it? If
you change your weighting…’’
The two latter points reflect the fact that the schema was
constructed by researchers with no direct experience of the
design domain in question. A specific potential issue with
the metrics is that only the structural features that occurred
in the original architectures were incorporated into the
metric definitions; novel features exhibited only by the
synthesised architectures, whether beneficial or detrimen-
tal, could not be included due to the authors’ lack of
knowledge. In practice, both of these problems would be
123
46
less severe since the engineers would either use the method
themselves or work closely with those who did.
This evaluation suggests that the proposed method can
increase both the number of architecture concepts exam-
ined during conceptual design and the quality of those
selected at its conclusion, which leads to a preliminary
conclusion that the method is both applicable and useful.
6.3 Initial validation
To give a better perspective on the value of the method in a real
engineering context, particularly ‘side effects’ both positive and
negative, one of the engineers at the case study company (who
participated in the presentation of synthesis results) was asked to
apply it to the design problem immediately subsequent to that
described in the previous section. After an explanation of the
method and software tool similar to that delivered in the usability
experiment, and with assistance from the first author, within
52 min the engineer had constructed a simple schema and syn-
thesised 3 architectures which between them represented (at a
low level of detail) the 9 concepts originally brainstormed. Lack
of time prevented the elaboration of the schema to represent the
problem at a higher level of detail and with a wider scope, which
would allow more architectures to be synthesised and evaluated.
The engineer believed that the method would be useful:
‘‘I think this is, an excellent tool to tease out and make
people think, perhaps a little differently. […] Because really
what you’re trying to do is you’re trying to understand what
used to be tacit knowledge in amongst a few people and
interpret it into [a] capability that anyone can use.’’
Interestingly, this echoes the comments made in the
usability study regarding the thought process involved in
formalising a problem.
He also commented positively on some specific aspects
of the method:
• The need to model even ‘common sense’ in NSC form,
a corollary of giving the designer complete control over
the syntax and semantics of models to fulfil Require-
ments F2 and F3—particularly helpful for training
novice designers;
• The ability of the method to provide quick interactive
feedback to a designer, in contrast to other more accurate
analysis methods with a higher computational cost;
• The constraint validation mechanism described in Sect.
4.1.3, which was used during the study to diagnose
modelling problems.
Overall, despite the limited nature of this validation, it
demonstrated that the method was usable by an engineer
who also expressed positive opinions of the method’s
potential usefulness—both in the strict sense of Sect. 6.2
and through other, less direct mechanisms.
123
Res Eng Design (2012) 23:17–52
7 Reflections on the approach and method
7.1 Challenges of formalisation
The method presented in this paper requires an architecture
design problem to be formalised into a schema and starting
point for synthesis. The first step is to abstract either
physical products or mental concepts into sets of compo-
nents connected by relations, which may not be straight-
forward. For instance, a challenging part of the example in
Sect. 5 was representing the flow of air through the vacuum
cleaner, which required the components ‘Duct’ and
‘Compartment’, neither of which exists independently but
is formed (‘comprised’) by a combination of other
components.
Constructing the schema may also be challenging, in
particular identifying the ‘correct’ set of NSCs for a par-
ticular product. ‘Hard’ constraints may follow from phys-
ical principles or the ‘function’ of the components
concerned (such as the need for an electric motor to be
supplied with electricity), or from semantics (such as the
fact that one object cannot simultaneously contain and be
contained by another). As discussed in Sect. 4.1.2, other
restrictions limiting the scope of the schema may be
derived from the design context. However, the intention in
developing the method has been that the scope should be as
wide as possible and selection should be made through
quantitative evaluation as described in Sect. 4.3.2, with the
metrics and their weightings embodying the designers’
preferences; objective definition of metrics assures their
consistent application.
The applications, particularly the vacuum cleaner
example in Sect. 5, demonstrated the importance of the
issues of underconstraint and overconstraint discussed in
Sect. 4.1.3, and of the methods for overcoming them: when
due simply to a mismatch between the designer’s intent and
the schema, such errors may be resolved by testing the
schema for consistency against modelled architectures (to
check for overconstraint) and inspecting the realisability of
synthesised architectures (to check for underconstraint),
and incrementally refining the schema corresponding to the
‘Refinement of formalisation’ iteration in Fig. 1. Possible
improvements to the support tool to tighten this feedback
loop could include, respectively:
• Allowing the designer to construct models directly in
the language of component and connection types
defined by a schema, rather than using generic ‘com-
ponents’ and ‘connections’ as in Fig. 3, or by importing
product models from other software environments.
• Facilitating interpretation and implicit evaluation by
presenting synthesis results in a way that better
resembles a potential embodiment than the force-
Res Eng Design (2012) 23:17–52
directed layouts described in Sect. 4.3.1. In particular,
although structural connections (e.g. ‘attached to’) are
represented intuitively in force-directed visualisations,
geometrical relations (e.g. ‘contains’) are not. An
alternative would be to create preliminary geometrical
embodiments as in Fig. 20c, even if such embodiments
are not themselves feasible (the ‘topological solutions’
of Medjdoub and Yannou (2000)). A mechanism for
doing so would be to use the connections in the
architecture to define geometrical constraints in
embodiment sketches, which may then be resolved
using a numerical constraint solver (Mullineux et al.
2005).
• Allowing the designer to ‘preview’ the impact of
possible schema modifications on the synthesis output.
A more serious potential issue arises if the designer’s
mental model of the space of possible architectures does
not match reality; in particular, if their understanding is
overconstrained (the ‘fictitious constraints’ of Pahl et al.
(2007)). For instance, in the experiment in Sect. 6.1, many
participants assumed that the bicycle light should be bat-
tery-powered, although this was not specified (and indeed
the source material included bicycle lights powered by
some form of dynamo, such as Fig. 19b–d). However, as
stated in Sect. 2.2.1 and reinforced in Sect. 6.3 the use of a
formal representation makes the assumptions about the
solution explicit (and thus reviewable) rather than implicit
within the thought processes of the designers. More
importantly, the authors’ experiences in the example
described in Sect. 5 and the participants’ comments in
Sects. 6.1 and 6.3 show that constructing the schema may
itself stimulate thought on the part of the designer to guide
them towards new solutions. In particular, formalisation
encourages questioning assumptions by attempting to
(mentally) construct realisable architectures that do not
conform to the schema; the resulting iterations involve an
increase in the understanding of the designer. To improve
the efficacy of this mental constraint-challenging process, it
could potentially be made explicit and documented, by
explicitly questioning each NSC as it is entered into the
support tool, along the lines of systems used to challenge
the ‘normal flow’ of events when eliciting use cases
(Maiden 1998).
From a practical point of view, Sect. 6.1 demonstrated
limitations with the procedure for constructing a schema
based on a single architecture, in terms of the tendency
towards overconstraint. Further research is necessary to
identify a more appropriate procedure for formalising
design problems that avoids this issue but is sufficiently
prescriptive that experienced designers who have signifi-
cant domain knowledge but are novices to the method are
able to follow a clear series of steps. Alternatively, the
47
method could be modified to allow formalisation of a
design problem using only architectures, without the con-
struction of an explicit schema by the designer. For
instance, the designer might start from an architecture and
indicate on it where variation was allowed (e.g. alternative
ways in which components may be linked together). Such a
representation of the problem might be easier to construct,
since there would be no need to obtain or generate multiple
alternative concepts before constructing the schema.
However, it would potentially be less general: where more
sweeping design changes are allowed, it may be difficult to
show on a single architecture all the changes that would be
necessary to convert it to a very different architecture.
Lastly, while the representation has proved sufficiently
powerful to express the problems considered to date, there
may be situations where greater expressive power is
required. Particular directions for improvement include
extending the language of network structure constraint
types to include Boolean combinations of constraints and
non-universal, i.e., existential quantification; and allowing
components to have multiple distinct ports to which con-
nections can be made.
7.2 Decomposing design problems
An advantage of the approach is that, as shown by the
applications, the separation between the ‘real world’ and
the models (traversed by the formalisation and interpre-
tation processes) make it possible to find solutions to a
specific subpart of a design problem—as illustrated in the
example in Sect. 5, where the arrangement of the motor,
fan etc. were not considered during synthesis. This may
be more practical than complete redesign in a real-life
context and reduces the scale of the problem, making it
more tractable. Increasing the complexity of the schema
and the size of the design problem increases the likeli-
hood that erroneous assumptions will have been included;
while these may be resolved as discussed in the previous
section, this may require significant effort. On the other
hand, restricted focus will limit the possible solutions,
potentially missing solutions that are significantly ‘better’
but that require changes outside the scope of consider-
ation—for instance, the simplified vacuum cleaner rede-
sign problem could not generate an architecture where the
fan is located before the dust separator in the airflow path
(the ‘dirty-fan’ configuration found in upright vacuum
cleaners).
7.3 Exploiting results from the method
Once potential architectures have been synthesised, those
which show most promise and should be taken forward into
later design must be identified. Previous research by
123
48
Langdon and Chakrabarti (2001) has indicated the diffi-
culty of navigating large numbers of automatically syn-
thesised abstract solutions using only the solution structure.
However, the use of metrics to quantify solution quality,
potentially in combination with Langdon and Chakrabarti’s
structure-based clustering, may make navigation of the
solution space easier. Interpreting individual solutions may
be facilitated by creating rough geometrical embodiments
as discussed in Sect. 7.1. It may also be important to pro-
vide guidance to designers on how to choose alternative
architectures if the one ranked highest according to the
metrics used is not realisable.
In addition, as described in Sect. 3.2, product architec-
tures are often not designed in a single event but as a series
of linked subproblems, and the architecture may not be
finalised before the end of design. Thus, if an architecture
is chosen based only on its own ‘quality’, subsequent
changes might cause it to become less desirable. Therefore,
the robustness-to-change of an architecture should be
considered as a selection criterion (Fricke and Schulz 2005;
de Weck et al. 2007).
In many situations, the key to architecture choice is
some aspect of ‘technical performance’. However, as
stated in Sect. 4.3.2, it is not possible to evaluate the
technical performance of an architecture based purely on
the information contained within a model of it. Indeed,
an architecture cannot be said to have a particular level
of technical performance, as that is dependent on the
design parameters of the components that comprise it.
Nonetheless, the architecture does define the set of
relationships that determine the overall performance from
individual component parameters (or, equivalently, the
component parameter values required to achieve a par-
ticular overall performance). Inasmuch as the properties
Fig. 23 The relationships
between search depth, number
of architectures synthesised and
time taken for exhaustive
synthesis in a simple design
problem. Intel Core 2 Duo
P8600 processor at 2.4 GHz,
4 Gb RAM, Java Runtime
Environment version 1.6.0_23
on Windows 7 64-bit
123
Res Eng Design (2012) 23:17–52
of the numerical relationships defined by an architecture
could themselves be parameterised, they would form
appropriate criteria for selection when combined with
specific performance requirements. Developing methods
for generic performance-based selection is an important,
though challenging, future direction for this research
area.
In Sect. 2.2, it was suggested that the models of schemas
and architectures could also, in principle, contribute to
design documentation; however, as seen in the example
such schema and architecture diagrams can be complex
despite their visual nature. Nonetheless, the participant in
Sect. 6.3 indicated the possibility for using the models to
communicate previously tacit information. Further research
is necessary to investigate further how readily they could
be interpreted by someone not involved in their
construction.
The computational cost of the method remains an issue
for large problems. Characterising the scaling of the
method is not straightforward, since each problem mod-
elled has a typical size of the architectures that might
solve it, and different problems can have significantly
different properties. Figure 23 shows the exponential
increase in both synthesis time and design space size with
search depth for a simple problem; however, this over-
estimates the complexity for more complicated problems
with larger numbers of component and connection types,
since at present isomorphic graphs with different node
ordering are regarded as distinct. This source of ineffi-
ciency could be addressed within the existing state space
search framework through graph canonisation (McKay
1981). Alternatively, Jackson (2006) proposes that similar
‘model-finding’ problems in software engineering may be
addressed using Boolean constraint satisfaction (SAT)
Res Eng Design (2012) 23:17–52
techniques. To assess whether such techniques offer
improvements in efficiency over state space search, an
attempt has been made to implement a translator from the
formalism described in this paper to the Alloy language
defined by Jackson. However, using the ‘natural’ repre-
sentation for an architecture in Alloy (representing com-
ponents by instances and connections by relations),
certain constructs from the method proposed in this paper
are not translatable. Specifically, an ICC may be trans-
lated using the Alloy reflexive transitive closure construct
but this is purely a test for the existence of at least one
path and cannot test the size of the set of paths or the
presence of components or connections on a path. This
means that, while the models can be exported and run in
Alloy, the results do not correspond to those produced
from our tool (typically including additional unrealisable
architectures). Additionally, Alloy cannot remove com-
ponents or connections from a start point, preventing
exploration of architectures derived from an existing
product. Work is continuing to establish whether trans-
lation is possible and whether SAT is superior.
7.4 Applicability to different forms of design
An important issue is the suitability of the method for
different forms of design—original, incremental and
adaptive, in the terminology of Pahl et al. (2007). Since the
method requires the possible types of components and
connections to be specified during formalisation, original
design in the sense described by Pahl et al. (starting from a
description of the product’s function) is not supported. At
the same time, the method’s applicability goes beyond the
redesign of existing products, since a novel product may be
(and frequently is, as discussed in Sect. 2.2.2) constructed
from known ‘partial solutions’. Indeed, as noted in Sect.
4.1.2 it is possible to incorporate a notion of ‘function
embodiment’ into a schema using abstract component
types. A possible extension of the method to increase its
applicability in original design would be to allow abstract
component types representing functions to be linked to
concrete component types from a predefined ‘library’, to
allow the system to suggest function embodiments auto-
matically. Potential issues include maintaining the library
and ensuring consistency of terminology (Hirtz et al.
2002). Furthermore, Requirement F3 and the initial vali-
dation in Sect. 6.3 indicate that such an approach may not
be appropriate in practice.
The solution of technology infusion problems such as
that described in Suh et al. (2008), where the infused
technology is not a single component but rather a system of
multiple components may be facilitated on an implemen-
tation level by allowing multiple schemas and synthesis
start points to be combined during synthesis.
49
7.5 Further evaluation
While initial evaluation of the method has been carried out
and has proved positive, as described in Sect. 6, further
evaluation is needed. In particular, while any formal
approach has potential advantages over informal approa-
ches, it also has an associated cost due to the need to
formalise the problem and interpret the results. In an
industrial context, it may be advantageous to consider a
lower-quality solution (Fricke 1992) if it saves time.
Evaluation should cover both the direct cost and benefit
of using the method and other, less tangible benefits such as
increasing the designer’s understanding of the set of pos-
sible solutions, as described in Sect. 7.1.
8 Conclusions
The design of product architectures is a challenging and
important part of the design process. This paper has
explored the use of formal computational approaches to
assist product architecture design. Specifically, the paper
proposes that alternative architectures for a product may be
synthesised computationally starting from formal declara-
tive descriptions of the ‘design space’, termed a ‘schema’
for a design problem, and of existing product architectures.
This method has the advantages of searching systemati-
cally for possible architectures, making explicit any
assumptions about the form of the solution, and evaluating
the generated architectures objectively, while meeting
requirements elicited from a case study of product archi-
tecture design in a diesel engine manufacturing firm. The
method has been illustrated through an example application
to a hypothetical realistic design problem: adapting a
vacuum cleaner to use a cyclonic dust separator instead of a
bag. Preliminary evaluation suggests that the method is
usable, applicable and useful in practice. Usability was
assessed through laboratory experiments, in which five out
of six participants could use the method to develop new
architectures for bicycle lights when provided with
appropriate training and support. A historical design
problem from the case study company showed that the
method was applicable, in that it generated more solutions
than were originally considered by the engineers, and
useful, in that a small number of the solutions were ‘better’
(according to the quality metrics used in the original design
problem) than some of the original architectures. Finally,
use of the method by an engineer from the case study
company supported its usability and overall value, as well
as additional potential benefits. Future work will consider
practical procedures for formalising specific design prob-
lems and will investigate the cost-benefit ratio of this
approach compared with that of other methods for
123
50
designing architectures, through further evaluation in real-
life settings.
Acknowledgments The authors thank the engineers at the case
study company and Claudia Eckert of the Open University for her
assistance with carrying out the interviews. They also thank the
members of the Cambridge Engineering Design Centre who took part
in the usability evaluation described in Sect. 6.1, and the three
anonymous reviewers for their insightful comments. Figure 2 is
reproduced from Starling and Shea (2005), originally published by
ASME, and the images of bicycle lights in Fig. 19b–d are reproduced
by kind permission of Pedalite International Ltd (http://www.
pedalite.com), Reelight ApS (http://www.reelight.com) and Brando
WorkShop (http://www.gadget.brando.com). This research was
funded by the George and Lilian Schiff Studentship and the UK
Engineering and Physical Sciences Research Council (grant reference
EP/E001777/1).
References
Alexander C (1964) Notes on the synthesis of form. Harvard
University Press, Cambridge
Allwood JM (2007) A structured search for novel manufacturing
processes leading to a periodic table of ring rolling machines.
J Mech Des 129:502–511
Andreasen MM (1992) Designing on a ‘designer’s workbench’
(DWB). In: Proceedings of the 9th WDK workshop. Rigi,
Switzerland
Antonsson EK, Cagan J (2001) Formal engineering design synthesis.
Cambridge University Press, Cambridge
Berliner C, Brimson JA (1988) Cost management for today’s
advanced manufacturing: the CAM-I conceptual design. Harvard
Business School Press, Boston
Bermell-Garcı́a P, Fan I (2002) A KBE System for the design of wind
tunnel models using reusable knowledge components. In:
Proceedings of the VI Congreso Internacional de Ingenierı́a de
Proyectos. Barcelona, Spain
Blessing LT, Chakrabarti A (2009) DRM, a design research
methodology. Springer, London
Bradley DA, Bracewell RH, Chaplin RV (1992) Engineering design
and mechatronics: the Schemebuilder project. Res Eng Des
4:241–248. doi:10.1007/BF02032467
Brimble R, Sellini F (2000) The MOKA modelling language. In:
Proceedings of the 12th international conference on knowledge
engineering and knowledge management (EKAW2000). Juan-
les-Pins, France
British Standards Institute (1986) Cycles–specification for photomet-
ric and physical requirements of lighting equipment. British
Standard 6102–3:1986
Cagan J, Campbell MI, Finger S, Tomiyama T (2005) A framework
for computational design synthesis: model and applications.
J Comput Info Sci Eng 5:171–181. doi:10.1115/1.2013289
Campbell MI, Cagan J, Kotovsky K (2000) Agent-based synthesis of
electromechanical design configurations. J Mech Des 122:61–69.
doi:10.1115/1.533546
Chakrabarti A (2002) Engineering design synthesis: understanding,
approaches and tools. Springer, London
Chakrabarti A, Bligh TP (1996) An approach to functional synthesis
of mechanical design concepts: theory, applications, and
emerging research issues. AIEDAM 10:313–331
Chomsky N (2002) Syntactic structures. Mouton de Gruyter
Clarkson PJ, Simons CS, Eckert CM (2004) Predicting change
propagation in complex design. J Mech Des 126:788–797
123
Res Eng Design (2012) 23:17–52
Corallo A, Laubacher R, Margherita A, Turrisi G (2009) Enhancing
product development through knowledge-based engineering
(KBE): a case study in the aerospace industry. J Manuf Tech
Manag 20:1070–1083. doi:10.1108/17410380910997218
Crawley EF, de Weck OL, Eppinger SD, Magee C, Moses J, Seering
WP, Schindall J, Wallace D, Whitney DE (2004) The influence
of architecture in engineering systems. Massachusetts Institute of
Technology Engineering Systems Division monograph
Cross NG (1994) Engineering design methods: strategies for product
design. Wiley, Chichester
de Weck OL, Suh ES, Chang D (2007) Flexible product platforms:
framework and case study. Res Eng Des 18:67–89
Dyson J (1986) Vacuum cleaning appliance. Patent number 4593429,
United States Patent Office
Eades P (1984) A heuristic for graph drawing. Congressus Numer-
antium 42:149–160
Eckert CM, Clarkson PJ, Zanker W (2004) Change and customisation
in complex engineering domains. Res Eng Des 15:1–21. doi:
10.1007/s00163-003-0031-7
Fricke G (1992) Experimental investigation of individual processes in
engineering design. In: Cross N, Doorst K, Roozenburg N (eds)
Research in design thinking. Delft University Press, The
Netherlands, pp 105–109
Fricke E, Schulz AP (2005) Design for changeability (DfC):
principles to enable changes in systems throughout their entire
lifecycle. Sys Eng 8:342–359. doi:10.1002/sys.20039
Giffin ML, de Weck OL, Bounova G, Keller R, Eckert CM, Clarkson
PJ (2009) Change propagation analysis in complex technical
systems. J Mech Des 131:081001.1–081001.14. doi:10.1115/
1.3149847
Golkar AA, Keller R, Robinson B, de Weck OL, Crawley EF (2009)
A methodology for system architecting of offshore oil produc-
tion systems. In: Proceedings of the international design
structure matrix conference (DSM’09). Greenville, South Car-
olina, USA, pp 343–356
Gordon WJJ (1961) Synectics. Harper and Row
Heer J (2007) The prefuse information visualisation toolkit.
http://www.prefuse.org
Hellenbrand D, Lindemann U (2008) Using the DSM to support the
selection of product concepts. In: Proceedings of the international
design structure matrix conference (DSM’08). Stockholm, Sweden
Helms B, Shea K, Hoisl F (2009) A framework for computational
design synthesis based on graph-grammars and function-
behaviour-structure. In: Proceedings of the ASME international
design engineering technical conferences and computers and
information in engineering conference (IDETC/CIE 2009). San
Diego, California
Hirtz J, Stone R, McAdams D, Szykman S, Wood K (2002) A
functional basis for engineering design: reconciling and evolving
previous efforts. Res Eng Des 13:65–82
Huang GQ (1996) Design for X—concurrent engineering imperatives,
1st edn. Chapman & Hall, London
Jackson D (2006) Software abstractions: logic, language and analysis.
MIT Press, Cambridge
Jarratt TA, Eckert CM, Weeks R, Clarkson PJ (2003) Environmental
legislation as a driver of design. In: Proceedings of the
international conference on engineering design (ICED ‘03).
Stockholm, Sweden, pp 231–232
Jiao J, Tseng MM (1999) A methodology of developing product family
architecture for mass customization. J Intell Manuf 10:3–20
Keller R, Eckert CM, Clarkson PJ (2006) Heuristics for change
prediction. In: Proceedings of the international design confer-
ence (DESIGN 2006). Dubrovnik, Croatia, pp 873–880
Kerzhner AA, Paredis CJ (2009) Using domain specific languages to
capture design synthesis knowledge for model-based systems
engineering. In: Proceedings of the ASME international design
Res Eng Design (2012) 23:17–52
engineering technical conferences and computers and informa-
tion in engineering conference (IDETC/CIE 2009). San Diego,
California, USA
Knuth D (1998) The art of computer programming, volume 3: sorting and
searching, 2nd edn. Addison-Wesley, Reading, Massachusetts
Kurtoglu T, Campbell MI (2009) Automated synthesis of electrome-
chanical design configurations from empirical analysis of
function to form mapping. J Eng Des 20:83–104. doi:
10.1080/09544820701546165
Langdon PM, Chakrabarti A (2001) Improving access to design
solution spaces using visualisation and data reduction tech-
niques. In: Proceedings of the international conference on
engineering design (ICED ‘01). Glasgow, UK
Lindemann U, Maurer MS, Braun T (2008) Structural complexity
management: an approach for the field of product design.
Springer, Berlin
Lipson H, Pollack JB (2000) Automatic design and manufacture of
robotic lifeforms. Nature 406:974–978. doi:10.1038/35023115
Maiden NA (1998) CREWS-SAVRE: scenarios for acquiring and
validating requirements. J Autom Softw Eng 5:419–446
Maier MW, Rechtin E (2000) The art of systems architecting, 2nd
edn. CRC Press, Boca Raton
McDermott J (1980) R1: an expert in the computer systems domain.
In: Proceedings of the first national conference on artificial
intelligence (AAAI-80). Stanford University, California
Mckay BD (1981) Practical graph isomorphism. Congressus Numer-
antium 30:45–87
Medjdoub B, Yannou B (2000) Separating topology and geometry in
space planning. Comput-Aided Des 32:39–61. doi:10.1016/
S0010-4485(99)00084-6
Mesihovic S, Malmqvist J (2000) PDM system based support for the
sales-delivery process of engineer-to-order products. In: Pro-
ceedings of product models. Linköping, Sweden
Mintel (2008) Vacuum cleaners. Consumer report, Mintel Interna-
tional Group
Mullineux G, Hicks B, Medland A (2005) Constraint-aided product
design. Acta Polytechnica 45:31–36
Murdoch TN, Wallace KM (1992) An approach to configuration
optimization. J Eng Des 3:99–116
Object Management Group (2006) Meta object facility (MOF) Core
Specification v2.0
Ogawa A (1984) Separation of particles from air and gases. CRC
Press, Boca Raton
Osborn A (1957) Applied imagination. Scribner, New York
Pahl G, Beitz W, Feldhusen J, Grote K-H (2007) Engineering design:
a systematic approach, 3rd edn. Springer, London
Paredis CJJ, Diaz-Calderon A, Sinha R, Khosla PK (2001) Composable
models for simulation-based design. Eng Comput 17:112–128
Port O, Schiller Z (1990) A smarter way to manufacture. Business-
Week 110–117
Pugh S (1990) Total design: integrated methods for successful
product engineering. Addison, Wesley
Purcell AT, Gero JS (1996) Design and other types of fixation. Des
Stud 17:363–383. doi:10.1016/S0142-694X(96)00023-3
Ranta M, Mantyla M, Umeda Y, Tomiyama T (1996) Integration of
functional and feature-based product modelling—the IMS/
GNOSIS experience. Comput-Aided Des 28:371–381. doi:
10.1016/0010-4485(95)00056-9
Rohrbach B (1969) Kreativ nach Regeln–Methode 635, eine neue
Technik zum Lösen von Problemen. Absatzwirtschaft 12:73–75
Russell SJ, Norvig P (2003) Artificial intelligence: a modern
approach, 2nd edn. Prentice Hall, Englewood Cliffs
Schmidt LC, Cagan J (1997) GGREADA: a graph grammar-based
machine design algorithm. Res Eng Des 9:195–213. doi:
10.1007/BF01589682
51
Shapiro A (2002) TouchGraph version 1.22. http://www.touchgraph.com
Shea K, Cagan J, Fenves SJ (1997) A shape annealing approach to
optimal truss design with dynamic grouping of members. J Mech
Des 119:388–394
Simon HA (1996) The sciences of the artificial, 3rd edn. MIT Press,
Cambridge
Sosa ME, Eppinger SD, Rowles CM (2007) A network approach to
define modularity of components in complex products. J Mech
Des 129:1118–1129
Stanković T, Shea K, Štorga M, Marjanović D (2009) Grammatical
evolution of technical processes. In: Proceedings of the ASME
international design engineering technical conferences and
computers and information in engineering conference (IDETC/
CIE 2009). San Diego, California
Starling AC, Shea K (2005) A parallel grammar for simulation-driven
mechanical design synthesis. In: Proceedings of the ASME
international design engineering technical conferences and
computers and information in engineering conference (IDETC/
CIE 2005). Long Beach, California
Stiny G (2006) Shape: talking about seeing and doing. MIT Press,
Cambridge
Stone RB, Wood KL, Crawford RH (2000) A heuristic method for
identifying modules for product architectures. Des Stud 21:5–31.
doi:10.1016/S0142-694X(99)00003-4
Stumptner M, Friedrich GE, Haselböck A (1998) Generative
constraint-based configuration of large technical systems. AIE-
DAM 12:307–320. doi:10.1017/S0890060498124046
Suh ES, Furst MR, Mihalyov KJ, de Weck OL (2008) Technology
infusion: an assessment framework and case study. In: Proceed-
ings of the ASME international design engineering technical
conferences and computers and information in engineering
conference (IDETC/CIE 2008). Brooklyn, New York, USA
Summers JD, Shah JJ (2010) Mechanical engineering design com-
plexity metrics: size, coupling, and solvability. J Mech Des
132:021004.1–02100411. doi:10.1115/1.4000759
Sun Microsystems (2006) Java SE version 6. http://java.sun.com
Ulrich KT (1995) The role of product architecture in the manufac-
turing firm. Res Policy 24:419–440
Ulrich KT, Seering WP (1989) Synthesis of schematic descriptions in
mechanical design. Res Eng Des 1:3–18
Umeda Y, Ishii M, Yoshioka M, Shimomura Y, Tomiyama T (1996)
Supporting conceptual design based on the function-behavior-
state modeler. AIEDAM 10:275–288
Wood KL, Greer JL (2001) Function-based synthesis methods in
engineering design. In: Antonsson EK, Cagan J (eds) Formal
engineering design synthesis. Cambridge University Press,
Cambridge, pp 170–227
Wyatt DF, Eckert CM, Clarkson PJ (2009a) Design of product
architectures in incrementally developed complex products. In:
Proceedings of the international conference on engineering
design (ICED ‘09). Palo Alto, California
Wyatt DF, Wynn DC, Clarkson PJ (2009b) Exploring spaces of
system architectures using constraint-based classification and Euler
diagrams. In: Proceedings of the international design structure
matrix conference (DSM’09). Greenville, South Carolina
Wynn DC, Nair SM, Clarkson PJ (2009) The P3 platform: an
approach and software system for developing diagrammatic
model-based methods in design research. In: Norell Bergendahl
M, Grimheden M, Leifer L, Skogstad P, Lindemann U (eds)
Proceedings of the international conference on engineering
design (ICED ‘09). Palo Alto, California, USA, pp 559–570
Xie YM, Steven GP (1997) Evolutionary structural optimisation.
Springer, London
XML Schema Working Group (2004) XML Schema. http://
www.w3.org/TR/xmlschema-1
123
52
Yang MC (2008) Observations on concept generation and sketching
in engineering design. Res Eng Des 20:1–11. doi:10.1007/
s00163-008-0055-0
Yassine AA, Wissmann LA (2007) The implications of product
architecture on the firm. Sys Eng 10:118–137
123
Res Eng Design (2012) 23:17–52
Ziv-Av A, Reich Y (2005) SOS–subjective objective system for
generating optimal product concepts. Des Stud 26:509–533
Zwicky F (1969) Discovery, invention, research–through the mor-
phological approach. Macmillian, Toronto