Product

Complexity
An structured approach to design
engineering

Juan Manuel Jauregui Becker

5/12/2014
 Introduction 1

Contents
CHAPTER I ................................................................................................................... 3
INTRODUCTION TO PRODUCT COMPLEXITY ........................................................... 3
1 Introduction ........................................................................................................ 3
2 Complexity in Emergent System ....................................................................... 3
2.1 An emergent based theory of design....................................................... 4
2.2 Complexity: The definition ........................................................................ 4
2.3 Product Complexity ....................................................................................5
3 Complexity in Axiomatic Design Theory ...........................................................5
3.1 Axiomatic Design Theory ...........................................................................5
3.2 Complexity model ..................................................................................... 6
CHAPTER 2 ................................................................................................................. 8
FUNCTION BEHAVIOR STRUCTURE ......................................................................... 8
1 Introduction ....................................................................................................... 8
2 The FBS Model ................................................................................................... 8
3 Design Problem in FBS ..................................................................................... 10
4 Classification of Design Problems .................................................................... 11
CHAPTER 3 ................................................................................................................ 12
DESIGN PROCESS UNITS (DPUS) ............................................................................. 12
1 Introduction ...................................................................................................... 12
1 The Design Process .......................................................................................... 12
2 Types of knowledge in design ......................................................................... 15
3 The Analysis Model........................................................................................... 16
4 Design Process Unit ......................................................................................... 17
5 DPUs based knowledge structures ................................................................. 18
CHAPTER 4 ................................................................................................................ 19
MODEL IMPLEMENTATION AND DESIGN ............................................................... 19
1 Introduction ...................................................................................................... 19

Juan Manuel Jauregui Becker

2 Modeling Artifacts ............................................................................................ 19
2.1 Modeling Properties.................................................................................20
2.2 Modeling Relations .................................................................................. 22
3 Common design problem formulations .......................................................... 22
CHAPTER 5 ................................................................................................................24
STRUCTURE VS. COMPLEXITY .................................................................................24
1 Introduction ......................................................................................................24
1 Structure in Science .........................................................................................24
2 Design Structuring Framework .......................................................................26
2.1 Undefined Problem .................................................................................. 27
2.2 Problem Class ........................................................................................... 27
2.3 Problem Instance .....................................................................................28
2.4 Problem Solution ......................................................................................28
2.5 Example: Spring Design ...........................................................................28
3 Translating ADT terminology .......................................................................... 30
4 Model of Complexity in Routine Design ........................................................ 30
4.1 Complexity of Problem Classes .............................................................. 30
4.2 Complexity of Problem Instances ........................................................... 32
Time-independent Real Complexity ................................................................ 32
Time-independent Imaginary Complexity ....................................................... 32
Time-dependent Combinatorial Complexity ................................................... 32
5 Complexity Management ................................................................................ 33
5.1 Problem classes ........................................................................................ 33
5.2 Problem instances .................................................................................... 33

Product Complexity
 Introduction 3

CHAPTER I
INTRODUCTION TO PRODUCT COMPLEXITY
The goal of this Chapter is to present an overview of the main theories
of complexity. These theories have served as basis for the
development of approaches to help engineers deal with the
complexity of their design processes.

1 INTRODUCTION
Complexity of systems can be studied from two different perspectives: the
physical domain and the functional domain. On the one hand, complexity in the
physical domain is seen as an inherent characteristic of physical things, including
algorithms and products. According to this view, systems with many parts are
more complex than those with less. Examples of such studies are computational
complexity and complex emergent systems. On the other hand, complexity in
the functional domain is seen as a relative concept that evaluates how well we
can satisfy what we want to achieve" with what actually is achievable". From
this perspective, axiomatic design theory [1], incompleteness of information [2]
and multi-disciplinary complexity [3] are some of the different models to
understand the complexity of systems.

2 COMPLEXITY IN EMERGENT SYSTEM

Emergence is the way in which behaviours arise in systems out of a multiplicity
of relatively simple interactions. Behavioural emergence is central to the theory
of complex systems, as it describes the result of complex interactions.
Behaviours, indistinctively of their domain, emerge in nature following a
constant pattern. This pattern, shown in Figure 1, states that if an object is
exposed to an external energy input, it will undergo a change in state, and that
this state transition is ruled by a principle of nature. In this sense, the laws of
nature describe the emergence of behaviours as well as their related states and
states transitions. When behaviour cannot be explained by any existing law of
nature, research is required to model that behaviour.

Juan Manuel Jauregui Becker

 Figure 1: Behaviour emergence pattern

2.1 An emergent based theory of design

Designing consists of creating a new artefact model (the physical description)
that achieves a wanted function by displaying a specific chain of specific
behaviours. Therefore, an artefacts functioning depends on the behaviours it
undergoes and the specific order in which these behaviours occur over time and
space. Furthermore, in order to analyse the quality of a designed artefact,
relevant behaviours have to be identified first, models of these behaviours have
to be constructed and numerical or logical calculations have to apply to
determine the performances. Therefore, the degree of sophistication of a design
process depends on the designers awareness of existing behaviours as well as
hers/his model making abilities.

2.2 Complexity: The definition

Complexity can be defined as a property of a system that describes how all of its
characteristics are connected and interrelated among each other, as well as
which the nature of that relation is. The more properties involved, and the more
interrelations between the emergent behaviours, the more complex the system
is. For example, the system in Figure 2(a) has a lower complexity than the
system shown in Figure 2(b), as the number of behaviours and interconnections
in the first case is lower than those in the second one.

Therefore, a distinction can be made between understanding the complexity of

a system and managing it. Understanding complexity is about uncovering the
properties and the connections among them such that the interdependency
among parts can be understood. Managing complexity is about finding forms,
operations and methods to take decisions in these networks of properties.

Product Complexity
 Complexity in Axiomatic Design Theory 5

Figure 2: Product Complexity

2.3 Product Complexity

Is a property of a product that describes the network of behaviours that rise up
the ultimate desired and designed emergent behaviour of the product. There are
4 concrete challenges that designers constantly face when designing new
products:

Identify the relevant behaviours that need to be modelled

Formalize the interrelations among the identified behaviours in an engineering
model suited for taking decisions.
Organize the design process in a project management structure that takes into
account the interrelations inherent to the product being designed.

The course product complexity offers tools and theories to answer these
questions.

3 COMPLEXITY IN AXIOMATIC DESIGN THEORY

The basic idea of complexity in Axiomatic Design Theory is that without difficulty
in understanding (or making, operating, etc.), a system is not complex. In this
sense, complexity is the property of a system that makes it difficult to
understand with the available knowledge about its constituents parts.

3.1 Axiomatic Design Theory

ADT is based on the hypothesis that there are fundamental principles that
govern good designs [4]. Its two founding axioms are: (1) maintain the

Juan Manuel Jauregui Becker

independence of the Functional Requirements (FRs) and (2) minimize the
information of the Design Parameters (DPs).

FRs are the set of requirements that characterize the needs of the artefact in the
functional domain, while DPs are the variables that characterize the design in the
physical domain. The relation between the FRs and the DPs is represented in
equation form as:

FR [ A]DP (1)

where A is the Design Matrix (DM) of the problem.

Depending on the DM, a design can be coupled, decoupled or uncoupled.

Consider for example a problem with two FRs and two DPs. When the design is
coupled, the FRs cannot be satisfied independently because of the
interdependence with both DPs, as shown in Equation 2. In a decoupled design,
shown in Equation 3, the DPs have to be solved in a particular order so that FRs
are achieved. In uncoupled designs (Equation 4), the FRs are independent from
each others, and no particular order is required for solving the DPS.

FR1 x x DP1
(2)
x DP2
Coupled :
FR 2 x

FR1 x 0 DP1
Decoupled : (3)
FR 2 x x DP2

FR1 x 0 DP1
Uncoupled (4)
FR 2 0 x DP2

3.2 Complexity model

In ADT, complexity is defined as the measure of uncertainty in achieving the
functional requirements of a system within their specified design range. When
the range of a system changes as a function of time, it is regarded as a system
with time-dependent complexity. When the range does not change as a function
of time, it has a time-independent complexity. Time is used in a general sense,
signifying the progression of events''.

Product Complexity
 Complexity in Axiomatic Design Theory 7

Time-independent complexity is related to design tasks whose description does

not change in time and it is classified into two groups:
Time-independent real complexity: is a consequence of the system range not
being inside the design range. In other words, having Functional
Requirements not being able to be achieved with the predefined Design
Parameters.
Time-independent imaginary complexity: Occurs when there are many FRs
and the design is a decoupled design. It is called imaginary because this
corresponds to a situation in which the different orders in solving the design
matrix have different attributed levels of difficulty. A system with imaginary
complexity can satisfy the FRs at all times if we vary DPs in the right order.
Time-dependent complexity is the uncertainty caused by the increase or
decrease of the number and types of DPs during the design process itself. ADT
classifies time-dependent complexity into two groups as well:
Combinatorial complexity is related to systems that experience a continued
growth of their DPs in time. For example, constructing a sentence by the
combination of words has combinatorial complexity. As the number of words
(the DPs in this case) increases, keeping semantic and syntactic consistency
among them becomes more difficult.
Periodic complexity is the case in which the increase of parameters is
restarted after a period of time (or succession of actions). An example
described in [5] is air traffic control. Air traffic in large airports follows a wave
pattern that depends on the time of the day. When the traffic is at its peak,
air controllers deal with very complex situations. However, at low traffic
times their task becomes significantly simpler.
ADT suggests three main strategies for managing design complexity: (1)
minimize the number of FRs, (2) eliminate time-independent real complexity and
time-independent imaginary complexity, and (3) transform a system with time-
dependent combinatorial complexity into a system with time dependent
periodic complexity.

Juan Manuel Jauregui Becker

CHAPTER 2
FUNCTION BEHAVIOR STRUCTURE
The goal of this chapter is to present an approach for understanding
the different levels of knowledge used in designing a new product and
how these influence the nature of the design process.

1 INTRODUCTION
FBS stands for Function Behaviour Structure. It is a descriptive method for
modelling a product from its functions up to its physical properties that was
developed with two proposes: understand better the rationales of design, aid
engineers in structuring the information and types of process involved in a
design process. It allows describing the relationship between a function and a
design parameter. FBS is the result of over 20 years of worldwide research to
ways to represent knowledge of design as well as to explain how design
processes occur. First, in the seventies, Rodemark [6] proposed a method
whereby functions were taken as the starting point of design. In the 80s,
Yoshikawa and Tomiyama looked for a scientific understanding of design for
developing CAD systems. In this period of time, Gero also proposed a Function-
Behavior-Structure model to derive the Design Prototype method. In the 90s the
first FBS based application appeared and 10 years later the first CAD systems
based on FBS existed. Nowadays, the FBS theory is used to analyse complex
systems and is used as a way of initiating model making.

2 THE FBS MODEL

FBS models a design artefact by distinguishing the following levels of object
representation: Function, Behaviour/State and Structure, as shown in Figure 1.
The basis of the FBS model is that the transition from function to structure is
performed via the synthesis of physical behaviours. Therefore, behaviours allow
characterizing the implementation of a function. As many different views of the
FBS model have been developed and researched, this reader adopts the unified
FBPSS model presented by Zhang et al [6]. This model is based on the analysis
and generalization of the Japanese ([7], [8]), European ([9]), American ([10])
and Australian ([11]) schools of design modelling.

Product Complexity
 The FBS Model 9

Figure 1: Graphic representation of the FBS model

The FBPSS model uses the following definitions:

Function: It is about the usefulness of a system. For example, in Figure 2, one

possible function of this system is to compress gas.
Behaviour: Represents the response of the structure when it receives stimuli.
Since the Structure is represented by States and Structure variables,
Behaviours are quantified by the values of these variables. In the case
presented in Figure 2, the two Behaviours are Generate torque and Convert
torque into force.
Principle: Is the fundamental law that allows the development of a
quantitative relation of the States variables. It governs Behaviour as the
relationships among a set of State variables. For the example in Figure 2, two
possible principles are electromagnetism ruling the operation of the electric
motor, and solid mechanics ruling the function of the crank mechanism.
States: Are quantities (numerical or categorical) of the Behavioural domain
(e.g. heat transfer, fluid dynamics, psychology). States change with respect
to time, implying the dynamics of the system. For example, in Figure 2, the
states of the structure are represented by the distance L0 between the
electric motor and the piston, the torque T of the electric motor, or the
displacement of the piston s. Initiators ignite a change in the artefact, while
followers follow from the emergent behaviour. The type followers can be
subdivided in two groups: principals, which have the strongest effect; and

Juan Manuel Jauregui Becker

 secondary, which are usually side effects.
Structure: Is a set of entities and relations among entities connected in a
meaningful way. Entities are perceived in the form of their attributes when
the system is in operation. For example, in Figure 2 the Structure is
represented by an electric motor and a crank mechanism. Here, the two
possible entities (structures) are the lengths of the bars L1 and L2.

Figure 2: FBS of a crank compression mechanism.

3 DESIGN PROBLEM IN FBS

In the context of the FBS scheme, a design problem can be said to be one in
which a design object has not been fully described in its different representation
levels. Solutions are then found by completing these descriptions, which
represent coherently a design object, by performing different synthesis
activities, like generating sub functions that specify the scope of the general
functional statements of the design, reasoning about the behaviours that allow
the existence of the given functions, generate concept structures that allow the
existence of the expected behaviours and finally instantiating the conceptual
design object to meet the characteristics of the expected behaviour.

Product Complexity
 Classification of Design Problems 11

4 CLASSIFICATION OF DESIGN PROBLEMS

If one considers a design artefact as an object with a complete FBS description, a
design problem can be defined as one with an incomplete set of descriptions. As
shown in Figure 3, according to the types of incomplete representations design
is classified in:

Routine design: One in which the space of functions, behaviours and

structures is known, and the problem consists of instantiating structure
variables.
Innovative design: One in which the functions and behaviours are known, and
the design consist of generating new structures that satisfy them.
Creative design: One in which the functions are known, and the problem
consists in determining the structures and behaviours required to satisfy
them.

Figure 3: FBS based design problem classification

Nature encompasses a vast variety of behaviours (physical, chemical, human,

etc.). Considering physical and human behaviours, design can be classified in:

Engineering design: Behaviours are characterized by principles stated in the

laws of physics. Depending on the discipline of study, engineering design can
be further classified into mechanical, electrical, chemical, geological, etc.
Human cantered design: behaviours are characterized by physiologic,
psychological and emotional human reactions. Two examples are
architectural design and industrial design.
Under these definitions, the scope of this course lies within the boundaries of

Juan Manuel Jauregui Becker

engineering design.

CHAPTER 3
DESIGN PROCESS UNITS (DPUS)
This chapter presents Design process Units as the minimum set of
information required to undergoing a design process.

1 INTRODUCTION
Modern products encompass more and more multidisciplinary features. This
makes the design and manufacturing of these products also more complex.
Multi-domain criteria need to be analysed and evaluated, and quite often in the
interest of a rapid time-to-market the design team settles for a working
solution rather than an optimized solution.

To improve the product development process and shorten design times, there is
a clear need to structure knowledge of the design process. By having a
comprehensive overview (i.e. a knowledge structure) of the design artefact in
question, designers and engineers are aided in the processes of organizing,
modelling and solving design tasks.

1 THE DESIGN PROCESS

In general, the product development process can be divided into 4 main phases:
(1) planning and clarifying the task; (2) conceptual design; (3) embodiment
design; and (4) detail design. The first phase regards the problem statement,
while the last phase aims at planning the manufacturing. Both are organizational
processes. It is in the conceptual and embodiment design phases where the
artefact is actually designed. For both cases, the design process follows the
steps shown in Figure 1. The model consists of sets of information and sub-
processes that operate upon the information to add new information. Figure
1(b) shows an example of the design process. Each set of information and
process is explicitly known on parametric level. The design process contains sets
of information that contain parameters. Parameters receive a value during the
design process. In the case of routine design, the values of the parameters can
be different for each new design process, but the parameters remain static. In
the case of innovative or creative design, the parameters themselves may
change, including the knowledge to generate feasible designs.

Product Complexity
 The Design Process 13

Figure 1 (a) design process model (b) example case

Juan Manuel Jauregui Becker

The information sets are five in total:

1. The requirements contain all parameters used during the design process. A
requirement for a parameter relates to its value, which can be a fixed or
desired value, or allowed value range. Translating desired product properties
into parametric requirements is an activity that the specialist is able to
execute.
2. The design parameters state the core of the design process. This set contains
the minimum information that describes a design artefact or system, with
sufficient level of detail to be analysed. The design parameters are under
control of the designer.
3. Scenario parameters describe a usage situation in which the design is placed
to determine its quality. Scenarios are externally determined and not
considered a degree of freedom for design. An example of a scenario is a load
case on a bridge.
4. Performance is the measure of quality, quantified by an analysis method. The
performance is used to evaluate the quality of a design and can only be
indirectly manipulated by modification of the design parameter values.
5. The solution is the collection of design parameters and values that satisfies all
requirements. The information content of the solution depends on the level
of detail.

Stating the sets of information explicitly requires the design process to be

known. In order help recognizing the nature of each parameter the following
guidelines can be followed:

Design parameters are independent parameters with values that can be

manipulated by a designer. Design parameters are grouped into design
elements to allow topological variation, such as multiple springs (the design
elements) into an assembly.
Scenario parameters are externally prescribed information about a usage
situation. A designer is not allowed to manipulate these parameters freely.
Performance parameters are information that is quantified after a design is
created and analysis performed. Calculated by placing a design into a
scenario, the performance parameters cannot be influenced directly.

The design process at a single hierarchical level begins with requirements and
ends with a design solution. The level of detail of the design solution depends on

Product Complexity
 Types of knowledge in design 15

the hierarchical level. A design process is modelled as a number of sub-

processes, shown in Figure 1(a).

The sub-processes are four:

1. Synthesis: the sub-process where an initial design is generated. The input

information is the set of requirements and the output is a fully specified
design, ready for analysis.
2. Analysis: the process that quantifies the performance values. The input of
analysis is a collection of design parameter values and scenario parameter
values. Analysis methods can only be executed after a scenario is given and a
design is produced by synthesis.
3. Evaluation: this process compares the performance values with the
requirements and decides what to do next. As shown in Figure 1, three
options exist:
a. A design seems promising: a modification is made to it, after which
it re-enters analysis. An automated loop of analysis, evaluation and
modification results in an optimization process
b. A design does not meet the requirements, nor is it expected to. It is
abandoned and synthesis is initiated again to create a new design
c. The requirements are met and the design is added to the solution
list or the design process descends one level in the hierarchy.
4. Modification: Improving a design involves an adjustment process with the
goal to better meet the requirements. The difference with synthesis is that
both the design and its performance are known. Therefore, the parameters
already have a value assigned, which is a different situation than synthesis
where not all values are known. The available performance information can
be used to steer the adjustment process.

2 TYPES OF KNOWLEDGE IN DESIGN

The knowledge used to support each of these phases can be classified into two
categories, namely, declarative and procedural. Declarative knowledge describes
static entities, like for example types of components, parameters and relations.
Procedural knowledge describes dynamic processes, like for example design
strategies and algorithms. On the one hand, procedural knowledge in design
depends on the specific requirements of the problem being solved. As a

Juan Manuel Jauregui Becker

consequence, it cannot be used for describing the essence of a design process.
On the other hand, declarative knowledge remains independent on the
requirement settings. This property makes declarative design knowledge
convenient for producing models of design artefacts in a generic fashion. The
declarative knowledge present in a design process can therefore be regarded as
knowledge on design parameters, scenario parameters and performance
parameters.

The relation between these three types of knowledge varies according to the
design phase (Figure 1) they are applied to. In the synthesis phase, embodiment
knowledge is specified such that it meets certain performance values for a given
scenario, as shown in Figure 2(a). In an analysis phase, performances are
quantified or qualified for an embodiment that is undergoing a given scenario by
using analysis equations, as shown in Figure 2(b). The evaluation phase uses
performances to determine the following action to undertake with an already
generated candidate solution. Finally, the adjustment phase applies small
changes to some embodiment variables to improve the performance of the
solution.

(a) (b)

Figure 2: Knowledge structure in the analysis and synthesis process

3 THE ANALYSIS MODEL

Relations used during the synthesis, analysis, evaluation and adjustment phases
are also considered to be declarative knowledge. This is because these relations
do not determine design procedures as such and hold for the design process
independently of the specific characteristic of the requirements. For example,
the equations used for calculating the deformation and stress of a spring are
independent of the specific process order in which the spring is designed.

Product Complexity
 Design Process Unit 17

Similarly, rules of thumb to be used in the synthesis process for determining the
diameter of a spring are also independent on the specific procedure that might
be used to design it. Yet, only analysis relations are required to be known when
completing a design process, as they represent the way in which the quality of a
design solution is determined [12]. The group of analysis relations used for
quantifying the performances of an embodiment is here regarded as the analysis
model. An analysis model relates all relevant embodiment and scenario variables
to performances, and therefore, it determines the level of detail and
specification of the design process. This also means that embodiment and
scenario variables that are not regarded in the analysis model have no role in the
design process as they do not affect the qualification of the solution.
Additionally, depending on the type of design process (innovative, creative or
routine) and its the level of detail (conceptual, embodiment detail), analysis
relations range from qualitative descriptions to numeric ones, and from simple
if-then rules down to analytic relations, numerical simulation analysis and test
bed based experimental analysis [13].

4 DESIGN PROCESS UNIT

According to the previous, there is a triplet of declarative knowledge that is
required to be known for a design process to occur, namely, embodiment,
scenario and performance. This triplet is defined as a Design Process Unit (DPU),
as it accounts for the core knowledge that is either gathered or available when
designing. As the information in a DPU is hold consistent by the analysis model,
this model is also regarded as part of ta DPU. Figure 3 shows an example of a
DPU for the design of a mass spring system. As the figure shows, the mass and
the stiffness are regarded as the embodiment (design) parameters. Force and
frequency are regarded as scenario. Finally, the performance parameter
displacement specifies the behaviour of the system for a given scenario. The
analysis equation shows the relation between these parameters. DPUs can be
graphically displayed as in Figure 3: embodiment parameters on top of the
analysis model, scenario parameters on either the right or left hand side of the
analysis model and finally performance parameters on the bottom of the
analysis model.

Juan Manuel Jauregui Becker

 Figure 3: DPU of a mass-spring system

5 DPUS BASED KNOWLEDGE STRUCTURES

DPUs can be seen as design knowledge building blocks, and as such, a design
artefact can be modelled as a web of different DPUs representing knowledge at
different levels of detail and for different components and assemblies. Either
embodiment, scenario or performance serves as starting point to join artefacts
constituent DPUs. This is schematically shown in Figure 4. By making DPU maps
of an artefacts components, one can get an overview of the level of
multidisciplinary and interconnectedness between the different knowledge
chunks. Knowledge structure maps can be used to determine product
development strategies, knowledge fields interfaces and build-up analysis
models of the artefacts being designed. When embodiment, scenario and
performance parameters are known, but the analysis equations are unknown, an
analysis model has to be assembled prior to starting the design process. When
developing a simulation or analytic model is not possible because of time
constraints or complexity of the principles, an experimental set-up can be used
as analysis model. This is addressed in the next chapter.

Figure 4. Knowledge structure: each colour represents a different DPU.

Product Complexity
 Introduction 19

CHAPTER 4
MODEL IMPLEMENTATION AND DESIGN
The goal of this Chapter is to present different types of mathematical
model used in design and how those models affect the nature of the
technical design process.

1 INTRODUCTION
The previous chapters have provided different approaches to organize the
knowledge and information that is utilized during the design process as well as
models detailing how this occurs. This Chapter presents models that can be used
to represent artefacts and its elements as well as relations to be used during the
synthesis, analysis, evaluation and adjustment phases. The aim is to further
structure the information and knowledge such that it can be used as basic
building blocks for formulating artefact design problems. Doing so allows design
organizations to standardize the knowledge they are using during their design
processes and helps them determining technical strategies to solve their
challenges.

2 MODELING ARTIFACTS
Products can be described by three different types of entities: (a) vocabulary of
elements, (b) descriptions of elements and (c) the configuration of elements.
Consider the case of the gear device shown in Figure 1. Here, the vocabulary of
elements is two gears and two shafts. Descriptions determine the attributes of
the artefact, like the diameter (D) and angular velocity (w). Configurations
determine the disposition of the elements in the structure, as for example the
connectedness between elements represented by the relations in the figure.
Configurations can be classified into topologic relations and physical coherence
constraints. While the former define the topology of the elements in the
structure, the latter is used to assure no physical impossibilities are committed
by the artefact being designed. For example, two gears cannot share the same
place in space. Furthermore, when formulating design problems, only relevant
descriptions need to be taken into account. Consider the gear device design, if
the designer is only interested in determining the gears diameters to deliver a
given angular velocity, no further variables should be taken into account.

Juan Manuel Jauregui Becker

 Figure 1: Gear device: elements, descriptions and configurations.

2.1 Modelling Properties

Descriptions are classified in five model categories: parameter, field, space,
shape and topology. Each category represents a complexity dimension in the
problem space, as different problem solving approaches are required to
generate solutions (see Section 4). Design problems formulated as a function of
more than one dimension have a higher degree of complexity and require
different methods to facilitate the design of new solutions.

Parameter
Parameters model properties valid for the entire element. They are used to
represent attributes as material properties, colour, weight, density, etc. These
can be of different nature, as for example numeric, symbolic, logic, predicate,
and combinations among them. For numeric parameters, confinement
constraints define a continuous or discrete space of possible values. For
symbolic, predicate and logic ones, all possible values have to be specified. That
is for every A A1 An , exists an Ai such that:

Ai ( N , Z , Q, R, C ) , or Ai true, false, or Ai Symbol .

Space
Describe positional attributes of the elements in a topology. Positional
descriptions depend on the chosen coordinate system Cartesian, Cylindrical of
Spherical and the dimensions of interest -1D, 2D, or 3D. These can be
considered as numeric parameters related by a model that is determined by the
chosen coordinate system. Values can either be continuous or discrete.

Field
Use parameters and geometric vectors to describe properties that are valid in
specific regions of the elements. Fields are specified together with an incident
zone, shown in the Figure 2 as cubic. Incident zone is the spatial place where the

Product Complexity
 Modeling Artifacts 21

field influences an element. An incident zone can be a volume, an area, a line or a

point. Meshed CAD models are used in Computer Aided Engineering (CAE)
software to specify incident zones. Vectors and parameters can then be
attributed to each mesh-element. In Figure 2 an example illustrates how a
parameters and vectors are related with their incident zones

Figure 2: Example of a field attribute.

Shape
Describe the form of the elements or groups of elements present in the
design structure. Commonly used models are based on geometric relations and
graphs.

Geometry models the form by means of mathematic equations. Models are

defined with parameters related by geometric functions, the latest being usually
algebraic or differential. When the geometric function is known, parameters are
instantiated to produce new shapes. When not known, the problem becomes
one of finding the correct geometric relations. Polynomials are often used for
this purpose, having the polynomial degree and its coefficients as unknowns

Topology
For design problems whose elements can be instantiated several times, its
cardinality can be defined as a topology description. It reflects the number of
instances of one element present in the artefact. This variable allows controlling
the creation of elements instance when the design problem is one of generating
topologic structures. The cardinality of a topology can be constrained by
defining the number of element instances in one design artefact. The concept of
cardinality also applies to topology relations. In this case, the number of

Juan Manuel Jauregui Becker

allowable relations is determined by its cardinality. For example, in the case of
the gear device, a gear could be connected with more than one gear. If so, the
cardinality of this topology relation determines how many gears can be
connected one to another.

2.2 Modelling Relations

Different types of models are used in design to describe relations. Their
characteristics determine the approaches required to handle them, and are here
restricted to three basic types: algebraic, differential and logic models. However,
this set is not restrictive as others can also be considered.

Topology relation might be used in two different places in a design formulation.

The first is to define the set of logic states to hold in the design. The second is as
part of the embodiment being designed. In the first, algebraic models using
element descriptions are commonly used.

Physical Coherence constraints and objective functions are commonly modelled

with algebraic relations. In some cases, when the descriptions are symbolic
rather than numeric, logic models can be assembled. First order logic and
propositional logic models are the most common types of logic models in
design.

Analysis relations are often modelled by a combination of all three types.

Analytic methods are usually a combination of algebraic and logic models, while
simulations make use of numeric methods to solve differential equations.

3 COMMON DESIGN PROBLEM FORMULATIONS

Depending on the type of models involved in the formulation, different design
categories families can be enumerated. This section describes four common
types: parametric, configuration, layout and shaping. In Table 1 these design
problems are shown together with the types of models used for its
representation.

Table 1: Common design problems

Product Complexity
 Common design problem formulations 23

.
Parametric design
An artefact can be modelled by a set of parameters in order to simplify the
design task. The process of problem solving includes the assigning of values to
the parameters.

Configuration design
In this case the predefined design component and topologic relations are
known. The problem is how to assemble and configure the design elements.
Configurations can be generated by instantiating new relation types or by
generating new elements in the topology.

Layout design
The components and their volumes are known. The placement locations for the
components need to be determined so that they all fit within the product
housing or container.

Shaping
The problem is how to attribute shape to form and thus to determine the shape
of the embodiment elements. Solutions to this problem can be generated by
defining new mathematic relations or by assembling new graph structures.

Juan Manuel Jauregui Becker

CHAPTER 5
STRUCTURE VS. COMPLEXITY
This chapter presents a model that relates product complexity to the
structure of design problems. It allows for determining strategies to
manage product complexity

1 INTRODUCTION
In design, structure and complexity are two closely related concepts. Complexity
is a property related to the degree of difficulty or uncertainty for finding a
solution to a design problem [2], whereas structure is a property related to the
organization of the variables and relations describing the design problem itself
[14]. In order to analyse design complexity, it is necessary to understand the
structure of the problem. The structure of a design problem has three important
aspects to be studied:

The consistency of the design variables: all design variables have to be related
to each others by relations that are ultimately used to determine the
performances of the problem.
The distribution of design parameters along the problem model: all
parameters concentrated in one element vs. several parameters scattered
through several elements; one vs. several levels of detail.
The relation between what is known (design requirements) and what is
unknown (unattributed structure variables): scattered along the problem
model, concentrated in problem chunks, at the top (only functional
requirements), at the bottom (only design parameters) or as mix of all these
possibilities.
In order to develop a standard model of complexity, a standard way of
structuring design problems is first required.

1 STRUCTURE IN SCIENCE
Physicists model natural phenomena through differential and integral equations.
Specific problems are solved by setting boundary conditions on the differential
and integral equations, and applying solving procedures to obtain analytical
expressions. The resulting expression can then be used to calculate values of
variables by specifying the values of the input parameters. Consider for example
the law of heat conduction shown in Equation 1. This differential equation

Product Complexity
 Structure in Science 25

models the phenomena of heat transfer through matter from a region of high
temperature to a region of a low temperature. As this is done independent of
geometry, material properties or temperature distributions, the equation is
generic. To model a specific case of heat transfer the equation is rearranged by
introducing boundary conditions, cancelling unnecessary terms and performing
mathematical manipulations. For example, heat conduction in one dimension
between two flat plates results, after rearranging Equation 1, in Equation 2. The
obtained equation can now be used to introduce known values and calculate the
values of the required parameters, as for example in equation (3) the time
required to get temperature T = at a point x = is t = .

T 2T
=a 2
t x (1)

x2 8 T TW
t x,T = ln 2
a TMO TW
2
(2)

t x = , T = = (3)

If one would generalize this structure, one would notice that physicist model
natural phenomena at the hand of tree phases which are solved by two types of
procedures, as shown in Figure 1. On the one hand, the three phases are: the
differential/integral equation, the analytical expression, and the solution. On the
other hand, the procedures are: differential and integral calculus to transform
the differential equation (phase 1) into an analytical expression (phase 2), and
algebra or numeric methods to transform the analytical expression (phase 2)
into values of unknown parameters (phase 3).

Figure 1: Structure of problems in modelling natural phenomena

Juan Manuel Jauregui Becker

From a research perspective, this problem structure has allowed:

defining the types of representations required for modelling each domain

(i.e. operators),
studying the complexity of each domain by analysing the configuration of the
used representations (i.e. equation order, equation linearity),
developing procedures and operations to solve each problem domain (i.e.
Laplace Transformations, Newton-Raphson method)
identifying common problem structures (i.e. Poisson's equation, Laplace
equation)

On the other hand, some of the major advantages from an application

perspective are:

reusing existing problem formulation,

utilization of standard solving methods,
development of computer based simulation tools.

Structuring design problems as done in natural phenomena allows usage of

more generic approaches as well as it allows identification of features causing
complexity

2 DESIGN STRUCTURING FRAMEWORK

Design problems can be structured at four different states: undefined problem,
problem class, problem instance and problem solution. This is shown in Figure 2.
Undefined problems are transformed into problem classes by clearifyng the
involved functions and behaviours. Problem classes are transformed into
problem instances by specifying its requirements. Requirements are specified by
instantiating descriptions. Problem instances are transformed into problem
solutions by algorithms that generate instances to the unknown descriptions.

Product Complexity
 Design Structuring Framework 27

Figure 2: Framework to structure design problems

Under this view, solving routine design is analogues to solving problems with
known differential equations. Solving innovative design is analogous to
combining different differential equations to model various interrelated physical
phenomena. Solving creative design problems is analogous to developing new
differential equations.

2.1 Undefined Problem

In this phase the artefact is not defined yet. The undefined problem is structured
in:

Functions: Describing what the artefacts does.

Behaviours: The behaviours required to achieve the function may be known.
In most cases, these are implicitly known, but have not been formalized.

2.2 Problem Class

A problem class is structured in:

Elements: are considered class descriptions, and are used to represent both,
embodiment and scenario elements. Elements can also be differentiated by
assessing the functions and types of descriptors modelling a component.
Relations: are considered class descriptions and are of different types,
namely, topology, physical coherence, design rules, analysis relations and
objective functions [13]. Their descriptions can be declared within the scope
of the relation or by pointing towards descriptions of embodiment and
scenario elements.
Descriptions: are variables that characterize elements and relations by
mathematic models. These can also be of different types: parameters,
shapes, fields, topology and spatial, as described in [13].

Juan Manuel Jauregui Becker

2.3 Problem Instance
A problem instance is structured by:

Instantiated scenario: represent scenario specifications,

Partially instantiated embodiment elements or parameters: represent
embodiment requirements, and impose constraints to the space of possible
solutions.
Instantiated performance parameters: represent the performance
specifications the embodiment has to meet.

2.4 Problem Solution

Consist of fully instantiated elements, relations and parameters. For under-
constrained problem-instances, many solutions may exist. This depends on how
constrained the problem is. An under constrained will allow for multiple
solutions, while a systems of equation type of problem will have a limited
number of solutions.

Figure 3: Problem structure dependencies

2.5 Example: Spring Design

Consider for example the spring design formulation shown in Figure 4. Figure
4(b) shows that the problem class corresponds to the declaration of the
different types of parameters of the problem formulation. By setting
requirements, the problem class is transformed into one (1) problem instance.
However, by setting requirements to other parameters, other problem instances

Product Complexity
 Design Structuring Framework 29

can be obtained. The Figure shows one possible problem solution. Nevertheless,
for this problem instance, many possible problem solutions are possible.

Figure 4: Example of phases in design structure

Juan Manuel Jauregui Becker

3 TRANSLATING ADT TERMINOLOGY
ADT terminology is translated into the design structuring framework as follows:

Functional Requirements (FRs): correspond to the functions, performances

and scenario descriptions.
Design Parameters (DPs): correspond to the embodiment descriptions in the
routine design formulation, and model elements and parameters.
Design Matrix (DM): is formed by the analysis, topology and physical
coherence constraints.

4 MODEL OF COMPLEXITY IN ROUTINE DESIGN

The model of complexity explained in Theme 1 is here related to the different
concepts described in Theme 2, 3 and 4, and mapped onto the different levels of
design problem structure.

4.1 Complexity of Problem Classes

Time-independent complexity captures the complexity of a system in which the
time dimension does not limit achieving its functional requirements. In other
words, the range of the system does not change over time. The process of
moving from problem classes to problem instances is a human process that
involves specifying which are the parameters and elements characterizing the
input of the problem. Therefore, complexity here is related to how well the
problem has been formulated, and regards two types of uncertainties. One is
the uncertainty of having all the required information in the problem
formulation. The second is the lack of differentiation between problem chunks
and its interrelations. Figure 5 illustrates this idea by showing an inconsistent
and unstructured problem in Figure 5(a) and a consistent and structure one in
Figure 5(b).

Product Complexity
 Model of Complexity in Routine Design 31

(a) Inconsistent and unstructured

(b) Consistent and structured

Figure 5: Complexity in problem classes.

Juan Manuel Jauregui Becker

4.2 Complexity of Problem Instances

Time-independent Real Complexity

Real complexity appears in multi-objective problems, where one parameter has
to satisfy contradicting objectives. This is caused when several disciplines
determine artefacts behaviour. For example, the more lanes a highway has, the
more traffic it can accommodate. At the same time, as the number of lanes
increases, the number of accidents also increases. Designing highways with the
objectives of traffic maximization and accidents minimization has a
contradiction, and therefore is a problem with time-independent real
complexity.

Time-independent Imaginary Complexity

Imaginary complexity originates from the fact that design requirements are set
at different combinations of parameters and elements. As consequence, it is not
known a priori in which order the problem will be solved. Furthermore, when the
DM is uncoupled, a particular order is required for solving the problem.
Imaginary complexity depends on the relations between known and unknown
cardinalities as well as on the relation between instantiated and non-instantiated
elements and parameters. The former is regarded in this work as knowledge
distribution, while the latter is regarded as requirements distribution.

From a knowledge distribution viewpoint, the more cardinalities that are known
in a problem instance, the lower its uncertainty is regarding the number of
elements to instantiate. Moreover, as the cardinalities of elements are often
interrelated among each other, modifying one automatically leads to the
modification of others. In this sense, knowledge distribution refers to the
distribution of known cardinalities among the elements of the problem.

Requirements distribution refers to the distribution of instantiated and non-

instantiated elements and parameters. For elements, complexity regards the
uncertainty of having to apply bottom-up or top-down approaches, while for
parameters it regards the uncertainty of knowing in which order to solve the
constrained system.

Time-dependent Combinatorial Complexity

For problem instances, combinatorial complexity occurs when the design
problem consists in generating complex topologies or shapes in which
embodiment elements are instantiated several times within one design solution
(for example, the number of gears required in a gear box). This results in a DM

Product Complexity
 Complexity Management 33

with time-dependent varying size and terms. When no knowledge is available

about the number of instances required to satisfy the FRs, the problem presents
time-dependent combinatorial complexity. One way of recognizing this type of
complexity is by assessing the cardinalities of the elements in the problem
formulation. When the ranges of cardinalities are not known, or cannot be
written as function of other parameters, the design problem has combinatorial
complexity.

5 COMPLEXITY MANAGEMENT
5.1 Problem classes
Ignorance of FRs and DPs is related to the failure to properly understand them in
a design task. This is caused by a faulty or incomplete description of the
functions, performances and scenarios in the problem formulation. As result,
one would be addressing a wrong problem. Complexity emerging from
incomplete problem formulations is time-independent imaginary complexity. In
ADT, imaginary complexity is defined as the uncertainty that arises because of
the designer's lack of knowledge and understanding of a specific design itself. In
order to solve this, the FRs of the problem has to be identified and related to the
problem's DPs. Then, the problem can be reformulated in terms of the emerging
relations between FRs and DPs. By doing so, the imaginary component of the
complexity can be managed.

5.2 Problem instances

Time-independent real complexity can be managed by using constrain
satisfaction and optimization techniques. In the field of Multidisciplinary Design
Optimization [15] several techniques have been developed to cope with such
problems, as for example Collaborative Optimization (CO), Bi-Level Integrated
System Synthesis (BLISS) and Analytic Target Cascading (ATC).

Time-independent imaginary complexity can be managed by determining

strategies that establish in which order to solve the design problem. Notable
techniques are based on Design Structuring Matrix manipulations [16].

Juan Manuel Jauregui Becker

References
1. Suh, N.P., Complexity in Engineering. Annals of CIRP, 2005. 54(2): 581-598.
2. Suh, N.P., A Theory of Complexity, Periodicity and the Design Axioms. Research in
Engineering Design, 1999. 11(2): p. 116-132.
3. Tomiyama, T., Dealing with Complexity in Design: A Knowledge Point of View.
Design Methods for Practice, 2006: p. 137-146.
4. Suh, N.P., Axiomatic Design Theory for Systems. Research in Engineering Design,
1998. 10, pp 189-209.
5. Suh, N.P., Complexity: Theory And Applications. Mit-Pappalardo Series in
Mechanical Engineering2005: Oxford University Press.
6. Zhang, W.J., Y. Lin, and N. Sinha, On the Function-Behavior-Structure Model for
Design, in Canadian Design Engineering Network conference 20052005.
7. Umeda, Y. and T. Tomiyama. FBS modeling: Modeling scheme of Function for
Conceptual Design. in Working Papers of the 9th Int. Workshop on Qualitative
Reasoning About Physical Systems. 1995. Amsterdam.
8. Umeda, Y. and T. Tomiyama, Functional Reasoning in Design. AI in Design, 1997.
12(2): p. 41-48.
9. Pahl, G., et al., Engineering Design: A Systematic Approach2007: Springer.
10. Chandrasekaran, B., A. Goel, and Y. Iwasaki, Functional Representation as Design
Rationale. IEEE Compute, 1993. 26: p. 48-56.
11. Gero, J.S. and U. Kannengiesser, The situated function-behaviour-structure
framework. Design Studies, 2004. 25: p. 373-391.
12. Schotborgh, W.O., Knowledge engineering for design automation2009: University of
Twente.
13. Jauregui-Becker J.M, Tragter H, and F.J.A.M. van Houten, Structure and models of
artifactual routine design problems for computational synthesis. CIRP Journal of
Manufacturing Science and Technology, 2009. 1(3):120-125.
14. Simon, H., The Structure of Ill Structured Problems. Artificial Intelligence, 1973. 4(3):
p. 181-201.
15. Papalambros, P.Y. and D.J. Wilde, Principles of Optimal Design- Modeling and
Computation2000: Cambridge University press.
16. Browning, T.R., Applying the design structure matrix to system decomposition and
integration problems: a review and new directions. Engineering Management, IEEE
Transactions on, 2002. 48(3): p. 292-306.

Product Complexity