Conceptual Design

Conceptual
design
automation
Abstraction complexity reduction by feasilisation
...............
and knowledge engineering
Joost Schut
Conceptual design automation
Abstraction complexity reduction by feasilisation and knowledge engineering
Proefschift
ter verkrijging van de graad van doctor
aan de Technische Universiteit Delft,
op gezag van de Rector Magnificus prof.ir. K.Ch.A.M. Luyben,
voorzitter van het College voor Promoties,
in het openbaar te verdedigen op vrijdag 12 november 2010 om 12.30 uur
door
Erik Joost SCHUT
ingenieur in de luchtvaart en ruimtevaart
geboren te Gouda
Dit proefschrift is goedgekeurd door de promotor:
Prof.dr.ir. M.J.L. van Tooren
Samenstelling promotiecommissie:
Rector Magnificus voorzitter

Prof.dr.ir. M.J.L. van Tooren Technische Universiteit Delft, promotor
Prof.dr. R. Curran Technische Universiteit Delft
Prof.dr. T. Tomiyama Technische Universiteit Delft
Prof.dr.ir. F.J.A.M. van Houten Universiteit Twente
Ass.prof.dr. S. Ahmed-Kristensen Technical University of Denmark
Dr.ir. J. Hofstee Airbus Germany GmbH
Dr.eng. J. Sobieski NASA Langley Research Center
Prof.dr. Z. Gürdal Technische Universiteit Delft, reservelid
ISBN/EAN: 978-90-9025787-7
Copyright © 2010 by Erik Joost Schut
All rights reserved. No part of the material protected by this copyright notice
may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying, recording, broadcasting, or by any
information storage and retrieval system, without permission in writing from
the author
Printed in the Netherlands

Summary
In order to keep innovating, engineers are working more and more with
engineering software, providing them a way to cut away their routine and
repetitive activities. Computer aided design and simulation software are for
instance considered standard tools in most engineering companies. Today,
to solve complex engineering design problems, multidisciplinary design
optimisation (MDO) is increasingly used to automate the design process to
support the engineer in finding a solution faster. To effectively use MDO, design
frameworks such as the design and engineering engine (DEE) are required.
More and more does engineering software provide a seamless integration
of computer software and human knowledge, a focus point of the field of
knowledge engineering (KE). This will free engineers from repetitive and
routine tasks and allow them to use their full creative capacity and learn
faster, increasing their productivity. This work contributes to the development
of KE applications within the DEE to support the MDO process. The focus is on
the conceptual design phase of complex systems engineering, responsible for
providing an initial start vector for MDO. Aircraft design is taken as a guiding
example as it is a typical case of a complex system.
The hypothesis is that a feasible method can be obtained by following an

engineering way of working and translating that into engineering software,
using knowledge engineering techniques.
To find an initial solution that can be used to start a MDO problem the engineer
has to cope with various complexities. To reduce the problem complexity
of the problem the engineer uses an abstract description of the problem
properties, addressing requirements, concepts, and tools. Iteratively, the
engineer has to adapt this abstract description, such that the abstract problem
represents the real problem. This complexity is inherent to conceptual design
of complex systems and is in this work referred to as abstraction complexity.
Feasilisation is introduced as an approach to address the abstraction

complexity. Feasilisation is a combination of approaches used by engineers in
the conceptual design phase, namely; simplification, decomposition, and trial
and error. To support the engineer in a continuous use of these methods in
the future, engineering software should support these approaches. This work
addresses this future requirement by formalising the feasilisation approach.
Through example design conceptual design problems the feasilisation building
v
Summary
blocks and trial and error processes are identified.
The formal feasilisation process description, the building blocks and trial and
error processes are combined with concepts from KE and DEE developments
to a design and engineering software framework that can support engineers
in feasilisation. The developed framework is based on engineering primitives
that are based on a combination of abstraction levels identified in MDO
frameworks and knowledge based engineering (KBE) modelling concepts. The
implementation of the primitives framework in a engineering software proved
feasible.
The main conclusion is that the feasilisation approach can be supported by the
primitive framework. This relieves the engineer from process management and
execution tasks, allowing to focus on the definition of requirements, concepts,
and tools, and the evaluation of the solution performance. This allows the
engineer to understand the consequences of design decisions.
vi
Samenvatting
Conceptueel ontwerp automatisering
Om te kunnen blijven innoveren werken ingenieurs steeds meer met

specialistische ingenieurssoftware. Dit geeft hen de mogelijkheid om
routine en repetitieve activiteiten te reduceren. Computer gesteund
ontwerpen en simulatiesoftware zijn bijvoorbeeld standaard middelen in
de meeste technische bedrijven. Om complexe technische problemen op
lossen wordt momenteel steeds meer gebruik gemaakt van multidisciplinair
ontwerp optimalisatie (MDO). MDO wordt gebruikt om het ontwerpproces te
automatiseren en zodoende de ingenieur te ondersteunen in het sneller vinden
van een oplossing. Om effectief gebruik te maken van MDO zijn er ontwerp
frameworks nodig die het ondersteunen, zoals de ‘design and engineering
engine’ (DEE). De ontwikkelingen in de specialistische ingenieurssoftware
zorgen steeds meer voor een integratie van software en kennis. Dit is een
aandachtspunt van ‘knowledge engineering’ (KE). De integratie van software
en kennis stelt ingenieurs in principe in staat om zich te ontdoen van routine
en repetitieve activiteiten, waardoor ze hun volledige creatieve vermogen
in kunnen zetten en sneller kunnen leren, wat de productiviteit verhoogd.
Dit onderzoek draagt bij aan de ontwikkeling van KE toepassingen binnen het
DEE framework om MDO te ondersteunen. De focus van het onderzoek is de
conceptuele ontwerpfase van complexe systemen, verantwoordelijk voor het
bepalen van een startvector voor MDO. Vliegtuigontwerpen is gebruikt als
toepassing, aangezien het een typisch geval is van een complex systeem.
De hypothese is dat een haalbare methode kan worden gevonden door

de manier van werken van een ingenieur te volgen en dit met gebruik
van ‘knowledge engineering’ technieken te vertalen in specialistische
ingenieurssoftware.
Bij het vinden van een initiële oplossing, waarmee de MDO gestart kan worden,
wordt de ingenieur geconfronteerd met verschillende complexiteiten. Om de
complexiteit van het probleem te reduceren gebruikt een ingenieur vaak een
abstracte beschrijving van probleem eigenschappen, waarbij eisen, concepten
en middelen in acht worden genomen. Met behulp van een iteratief proces past
de ingenieur het abstracte probleem aan om het werkelijke probleem zo goed
mogelijk te benaderen. Dit proces is inherent aan het conceptuele ontwerp
van een complex systeem, in dit onderzoek wordt hier naar gerefereerd als
‘abstraction complexity’.
vii
Samenvatting
Om met deze ‘abstraction complexity’ om te kunnen gaan wordt gebruik

gemaakt van feasalisatie. Feasalisatie bestaat uit een combinatie van
technieken die door een ingenieur gebruikt worden tijdens de conceptuele
ontwerpfase, zoals simplificatie, decompositie en trial-and-error. Om in de
toekomst de ingenieur continu te kunnen blijven ondersteunen, zouden deze
technieken onderdeel moeten zijn van de specialistische ingenieurssoftware.
Dit onderzoek gaat in op deze toekomstige eisen door de feasalisatie
methode te formaliseren en met behulp van voorbeelden van conceptuele
ontwerpproblemen de feasalisatie bouwstenen en trial-and-error processen te
identificeren.
De formele procesbeschrijving, de bouwstenen en het trial-and-error proces

worden gecombineerd met concepten uit de KE en DEE ontwikkelingen, om
zo een framework voor specialistische ingenieurssoftware te ontwikkelen dat
ingenieurs kan ondersteunen in feasalisatie. Het framework dat is ontwikkeld
is gebaseerd op ‘engineering primitives’. Deze ‘engineering primitives’ komen
voort uit een combinatie van abstracties die geïdentificeerd zijn in het MDO
framework en model concepten die gebruikt worden bij ‘knowledge based
engineering’ (KBE). Het is bewezen dat de implementatie van het ‘engineering
primitives’ framework in een specialistische technische software haalbaar is.
De belangrijkste conclusie is dat het ‘engineering primitives’ framework

feasalisatie kan ondersteunen. Dit verlicht de ingenieur van procesmanagement
taken, waardoor de ingenieur zich kan concentreren op de definitie van de
eisen, concepten en middelen en de evaluatie van de oplossing. Dit stelt de
ingenieur in staat om de consequenties van zijn of haar ontwerpbeslissingen te
begrijpen.
viii
Contents
Summary v
Samenvatting vii
Chapter 1: Introduction 1
1.1 Complex systems engineering 1

1.2 A new conceptual design paradigm 5
1.3 Objective 7
1.4 Approach 7
Chapter 2: Complex systems design 9
2.1 Introduction 9
2.2 Complex systems 9
2.3 System design process 16
2.4 Multidisciplinary design optimisation 23
2.5 Abstraction complexity 28
2.6 Conclusions 29
Part I
Chapter 3: Conceptual design feasilisation 33
3.1 Introduction 33
3.2 The feasilisation approach 33
3.3 The feasilisation process 40
3.4 Design process formalisation 44
3.5 Feasilisation process formalisation 47
3.6 Conclusions 50
Chapter 4: System simplification 51
4.1 Introduction 51
4.2 Example simplifications 51
4.3 Integrating levels of simplification 66
4.4 Observations and conclusions 72
ix
Contents
Chapter 5: System decomposition 75
5.1 Introduction 75
5.2 Example decompositions 75
5.3 Decomposed concept definition 84
5.4 Model synthesis 88
5.5 Test case decomposition 91
5.6 Performance synthesis 93
5.7 Observations and conclusions 95
Chapter 6: Trial and error 97
6.1 Introduction 97
6.2 Example trial and error processes 97
6.3 Design problem definition 102
6.4 Solution generation 105
6.5 Performance evaluation 110
6.6 Observations and Conclusions 113
Part II
Chapter 7: Feasilisation building blocks 119
7.1 Introduction 119

7.2 Knowledge engineering 119
7.3 Building block concepts 126
7.4 Engineering primitive abstractions 130
7.5 Conclusions 132
Chapter 8: Engineering primitive framework 135

8.2 Actors 135
8.3 Framework architecture 138
8.4 Environment primitive design 140
8.5 System primitive design 141
8.6 Process primitive design 144
8.7 Property primitive design 146
8.8 Framework software design 148
8.9 Framework implementation 150
x
Chapter 9: Framework prototype 155

9.2 Property primitives 155
9.3 Process primitives 157
9.4 System primitives 159
9.5 Environment primitive 168
9.6 Application review 172
9.7 Conclusions 173
Chapter 10: Conclusions and recommendations 175

10.2 Conclusions 175
10.3 Recommendations 178
References 181
Appendix
Appendix A: System search process 189
Appendix B: Example data 191
Acknowledgements 193
About the author 195
xi
Contents
xii
Complex systems engineering
Chapter 1: Introduction
1.1 Complex systems engineering
In order to keep innovating, engineers are working more and more with
engineering software, providing them a way to cut away their routine and
repetitive activities. Computer aided design and simulation software are for
instance considered standard tools in most engineering companies. Today,
to solve complex engineering design problems, multidisciplinary design
optimisation (MDO) is increasingly used to automate the design process to
support the engineer in finding a solution faster. To effectively use MDO design
frameworks such as the design and engineering engine (DEE) are required.
More and more does engineering software provide a seamless integration
of computer software and human knowledge, a focus point of the field of
knowledge engineering (KE). This will free engineers from repetitive and
routine tasks and allow them to use their full creative capacity.
This work contributes to the development of KE applications within the DEE to

support the MDO process. The work extends on DEE research and development
at the Delft University of Technology (Van Tooren, 2003 & La Rocca, 2007).
The focus is on the conceptual design phase of complex systems engineering,
responsible for providing an initial start vector for MDO. In the context of this
work conceptual design entails both functional as physical concept design.
figure 1-1: Aircraft design as typical example of complex systems

engineering, illustrated by this sketch of the F35 system complexity
1
Aircraft design is taken as a guiding example as it is a typical case of a complex

system, illustrated by figure 1-1. This thesis will show a conceptual design
paradigm shift is required to fulfil the future demands on conceptual design
capability.
1.1.1 An engineering challenge
In design, the only constant is change. In a vision for 2020 (Argüelles et al.,
2001) this is clearly reflected in the change of vision imperatives for future
transport: a generation ago the focus was on ‘Higher, Further, Faster’, today
aircraft designers have to focus on building ‘More affordable, Safer, Cleaner,
Quieter’ aircraft. To keep meeting the market demands, aircraft manufacturers
do not only face the challenge of finding viable concepts, but have to produce
them in a larger volume, while reducing their time-to-market as well.
To clarify the level of expected innovation required to meet this challenge,

ACARE (2002) expects that these future concepts will differ as much from
today aircraft as todays aircraft differ from those of the 1930s. To obtain
these concepts new combinations of design options and technologies have
been integrated. Today's examples are the Airbus A380 and the Boeing 787,
both incorporating new materials to a high degree. Nevertheless, when looking
at the skies, all aircraft have an almost identical signature. Where are the
blended wing body, Prandtl plane, and flying saucer?
History tells that such new and innovative concepts are difficult to implement.
A designer aims at finding the most attractive system concept. In search for
the most attractive concept, designers try new combinations. In general,
the more combinations are tested the higher the probability of finding an
attractive concept. However, as designers push their knowledge into uncharted
territories, they are bound to encounter unexpected behaviour, such as the
introduction of metal in aircraft lead to the rediscovery of fatigue. To prevent
these problems, companies constrain themselves to low risk concepts, not
allowing designers to stray too far from known solutions. Unfortunately this
also decreases the level of innovation. Although, even in designing these
relatively low risk concepts companies struggle to meet their goals, which can
be deduced from the delays in development of both the Airbus A380 and Boeing
787.
Clearly, aircraft manufacturers are faced with continuously increasing problem

complexity, which results in more engineering work. First, to meet the market
demands, more technologies need to be investigated, translating into more
potential concepts, resulting in more engineering work. Secondly, to meet the
innovation required, designers need to be able to address higher risk concepts.
2
Complex systems engineering
Consequently, to make the vision for future transport viable much more
engineering work has to be performed in a shorter time.
Increasing the productivity of the available engineers could be the solution.

Trends (Drucker, 1999) also indicate an increase in productivity by a shift
in production factor from physical labour (such as assembly line work) to
knowledge work (such as research). Engineering is regarded for a large part as
knowledge work. Drucker (1999) calls increasing the productivity of engineers,
or knowledge workers in general, one of the main management challenges for
the 21st century.
1.1.2 Increase engineering productivity
When freed from routine and repetitive activities, the productivity of an

engineer can be increased significantly through automation by engineering
software. Looking at engineering work today, it is already highly computer
based (see figure 1-2). Computers excel in repetitive work and are used to
support engineers in especially these repetitive areas (although not implicitly
the case). This development is strengthened by the continuously decreasing
cost over performance ratio of processors. This promotes the development of
ever more capable engineering software to support engineers in their daily
activities.
Today, much of the current engineering software is focused on supporting

the simulation and analysis parts of the design process. However, to find new
viable solutions engineers need to generate, analyse, optimise, and select new
concepts. An engineer is looking for a concept structure with behaviour that
fulfils the required function. However, limited knowledge of and experience
with the system is available when starting a new system design. That
knowledge can be acquired by trial and error, a process with inherent recurring
and routine activities.
figure 1-2: Different examples of engineering software used for geometrical design
and simulation of an aircraft wing; CATIA (left), PATRAN (centre), VSAERO (right)
3
figure 1-3: In the future virtual design rooms will be a standard

engineer software that assist the engineer in the design process
To support the engineer the engineering software should support the engineer
in creating new knowledge of the concepts, it should support learning.
Senge (2006) states that the most powerful learning comes from experience.
However, in order to learn from our actions we have to see the consequences.
Senge calls this the core learning dilemma that confronts organisations:
“We learn best from experience but we never directly experience the
consequences of many of our most important decisions”
Senge (2006) states that in order to learn we need to find the relation between
the system concept structure and behaviour. The main problem in finding this
relation is that by defining a concept structure the behaviour is not implicitly
defined. Senge identifies systems thinking as the discipline that can tackle this
issue and assist in identification of so called ‘circles of causality’, capturing the
physics of a system by using simplified models of the system concept structure
and related behaviour. In engineering design the systems thinking is addressed
by the field of systems engineering.
1.1.3 Extend engineering software
Senge (2006) stresses that learning depends heavily on practical experience.

Experience can be obtained by using experimentation in a ‘virtual world’, a
constructed representation of the real world. This world can be created on a
sketch pad or in a virtual design room. The major benefit of a virtual world is
the freedom it allows for experimentation (see figure 1-3).
4
A new conceptual design paradigm
Today, these virtual worlds are common in the (serious) gaming industry,
providing users an interactive environment to find the best feasible design
solution (such as the best character gear). In order to interactively find
potential design solutions in design rooms, the design concepts need to be
generated, analysed, optimised, and selected by, addressing all relevant
aspect of the design, such as structures, aerodynamics, ergonomics, etc.
1.2 A new conceptual design paradigm
In the traditional conceptual design process a new system concept is selected

by interpolating or extrapolating existing system concept. Examples methods
are suggested by Torenbeek (1982), Roskam (2003), Rentema (2003) or Raymer
(2006). An illustrative example is the estimation of weight through parametric
formulas by Torenbeek. These formulas are composed of the driving weight
parameters, and determined based on existing aircraft. An example composed
of wing weight over gross weight is illustrated below. The formula is based
on aircraft and wing related design parameters and is derived specifically for
civil airplanes with Al-alloy cantilever wings, and is valid for wing-mounted
retractable undercarriage, but not for wing-mounted engines.
�� ⁄��

� �� (1)
�� ⁄�
These methods are very powerful when extending on existing system concepts,
because the method inherent simplifications shorten the conceptual design
process. However, these methods can not be used (as effectively) for different
system concepts as they intrinsically has different behaviour, invalidating the
simplifications. Consequently, new concepts need an extensive trial and error
process to determine the system concept with the proper behaviour, which
in case of complex systems involves multiple disciplines (see figure 1-4).
Therefore, a different paradigm is required for conceptual design that supports
engineers in the trial and error process.
1.2.1 Multidisciplinary design optimisation
The field of multidisciplinary design optimisation (MDO) is in development to

support the engineer in automating this trial and error process. MDO aims at
flexibly integrating the relevant disciplines into a single optimisation problem
(Vanderplaats, 2007). This integration is not straightforward as all disciplines
have a different system view and thus design objective (see figure 1-4). For
instance, in aircraft wing design the aerodynamics discipline wants a thin wing
having little drag, but the structures discipline wants a thick wing, having
5
figure 1-4: In complex systems engineering, such as aircraft,

multiple disciplines are involved in the design
much stiffness. MDO aims to integrate these views to find the overall best
solution based on the required function. In order to find this best solution,
MDO integrates optimisation techniques that mimicked the original concept
trade-off and selection process.
However, whether a feasible solution can be obtained with MDO depends

highly on the initial design solutions that are used to start the MDO process.
Before starting a MDO process the engineer should be confident the offered
initial design solution is (close to) a feasible design, because the MDO process
is very resource and time intensive. Much like the classical design process,
the MDO detailed design phase follows after a conceptual design phase that is
responsible for finding that initial solution. This work addresses this conceptual
design phase in relation to MDO.
1.2.2 Knowledge engineering
To come up with engineering software that can automate part of the

knowledge work involved in the conceptual design process, the knowledge
inherent to the activities need to be captured by that software. In this
context, knowledge can for instance be design rules (area equals length times
width) or system objects (an aircraft is composed of wings, a fuselage, and a
tail). In order to create such knowledge based solutions, artificial intelligence
technology is integrated in engineering software (Cooper, 2007). A typical
example is the parametric description of a geometric objects, for instance
a square has only one parameter that defines both length and width. The
knowledge captured is that a square has equal sides.
6
Objective
The field of knowledge engineering focuses on obtaining the knowledge

involved in the activities (Sveiby, 2009). Based on a formalised methodology
the human knowledge can be translated into for instance design rules and
objects (Schreiber, 2000). The knowledge systems integrate these rules and
objects into an application. Knowledge based engineering (La Rocca, 2009) is a
technology to build such knowledge systems in an engineering domain, and can
support (part of) the activities originally performed by an engineer.
1.3 Objective
The objective is to develop engineering software based on knowledge

engineering principles that automates the routine and repetitive activities of
an engineer in the conceptual design phase of complex systems engineering
such that multidisciplinary design optimisation can be initiated. Aircraft
systems design will be taken as guiding example as it is a typical example of
complex systems engineering.
The hypothesis is that a feasible method can be obtained by following an

This yields three sub-objectives;
(1) Define a formalised approach an engineer uses in the

conceptual design phase for complex systems
(2) Design a system that can support the engineer in performing
this formalised conceptual design approach
(3) Developed an engineering software prototype for
an example conceptual design problem
1.4 Approach
The research approach is based on iterative development (Leffingwell,

2003) and addressed different research areas (such as systems engineering,
knowledge engineering, and software engineering). Through the development
of various prototype applications for different conceptual design problems the
approach is formalised and the routine and repetitive activities are identified.
The research is presented here as a sequential process, with a special
attention to the developed prototype applications before the final design and
implementation are discussed.
Therefore, the thesis is composed of two parts (see figure 1-5). The first
focuses on the development of conceptual design methodology for complex
7
Intro: chapters 1-2 Part 1: chapters 3-6 Part 2: chapters 7-9 Close: chapter 10
Context on complex Design methodology Knowledge engineering Summary, conclusions
system design in the formalisation and application and recommendations
conceptual design example development and
phase implementations implementation
figure 1-5: Thesis structure based on two parts; design methodology

formalisation and knowledge engineering application development
systems, such as aircraft. This part addresses the approach of engineers to a

complex system design problem, and the various prototype applications. The
second part focuses on the design and implementation of engineering software
to support the methodology based on knowledge engineering.
The first part comprises chapters three through six. Chapter three introduces
the feasilisation methodology, an approach to conceptual system design, and
provide a formal definition of the design and feasilisation processes. Chapters
four, five, and six discuss the concept applications addressing the three
components of feasilisation: simplification, decomposition, and trial and error
methods. This part is concluded with an overview of the main observations and
conclusions derived from the concept applications.
The second part addresses the development of engineering software to

support the feasilisation approach. First, in chapter seven the required
system properties are defined based on knowledge engineering principles,
formalising the interface between the engineer and the software. In chapter
eight, the system software design is presented based on knowledge system and
knowledge based engineering properties. Chapter nine discussed the prototype
application of the developed engineering software for an example conceptual
design problem. The thesis is concluded with conclusions and lessons learned in
chapter ten.
However, first chapter two starts with defining complexity and how it is
addressed by engineers in the (conceptual) design process. The second part
of chapter two elaborates on multidisciplinary design optimisation (MDO)
frameworks and the need for a start vector to initiate MDO. The chapter
concludes with the introduction of abstraction complexity as the complexity
addressed in conceptual design.
8
Introduction
Chapter 2: Complex systems design
2.1 Introduction
The introduction stated that a new conceptual design paradigm is required to

reduce the trial and error inherent to the design process of complex systems.
Trial and error is a result the system complexity as complexity disables us to
understand the complete system design at the start.
The objective of this chapter is to identify the complexities in conceptual

design complex systems, such as aircraft design. The second objective is to
assemble the approach engineers use to address these complexities in the
design process. Key questions to be answered:
»» What are complexities in design of complex systems?

»» How do we address complexity in the design process?
»» What are the properties of the conceptual design process?
»» How can automation reduce perceived complexity?
First, we will define complexity and introduce systems engineering and the
design process in section two. Secondly, the complexities are associated to
the design process in section three, elaborating on the design process steps.
Finally, multidisciplinary design optimisation as approach to automate the
design process is discussed in section four.
2.2 Complex systems
Suh (2005) defines two ways to deal with system design and complexity:
algorithmic and axiomatic. In the purely algorithmic approach the process is
prescribed so that in the end a solution is obtained. The axiomatic approach
uses general principles based on which a solution can be defined. This
research belongs to algorithmic design approach.
First, an initial set of complexities is obtained from literature used to

define complexity for complex systems and axiomatic design and related to
engineering design. Secondly, systems engineering is introduced as the general
approach engineers use to address complexity in design of complex systems.
Thirdly, the design process is presented, giving an overview of its structure and
trial and error nature.
9
2.2.1 Complexity
Sussman (2007) defines a system as complex when that is system is composed

of a group of interrelated components and subsystems, for which the degree
and nature of the relationships between them is imperfectly known, with
varying directionality, magnitude and time-scales of interactions.
Different definitions of complexity exist. Sussman (2000) describes twenty

views on system complexity. The system complexity views described by
Sussman address different fields and include, among others, social, biology,
transportation, and architecture systems. Complexity is generally associated
with the number of interconnections between the parts of the system or as
the number interconnected and interwoven parts and with the uncertainty in
predicting the behaviour of the system. In this section a subset of complexity
types are discussed that are relevant in context of the work.
Sussman is primarily concerned with four types regarding the complexity

of complex, large-scale, interconnected, open, and sociotechnical systems
(CLIOS):
»» Structural complexity
»» Behaviour complexity
»» Nested complexity
»» Evaluative complexity
Structural complexity exists when a system is composed of many

interconnected parts. Behaviour complexity exists when the predictions of
system behaviour is difficult. Nested complexity exists when the system is
composed of other interacting systems. Evaluative complexity exists when
multiple stakeholders are involved in defining the system performance. For
examples, see the next section.
These complexity types address the system itself. Another categorisation

is offered by Suh (2005) in context of axiomatic design. Suh defines the
complexity types for the process of defining a system. In this context,
complexity is defined as “a measure of uncertainty in understanding what is
we want to know or in achieving a functional requirement”. Suh defines the
complexity types:
»» Real complexity
»» Imaginary complexity
»» Combinatorial complexity
»» Periodic complexity
10
Complex systems
figure 2-1: The Airbus A380, a large-scale system, composed of many

parts that are interconnected (source: Flight international)
The first two are time independent and the latter two are time dependent.
Real complexity exists when the problem does not necessarily yield a feasible
solution; the engineer has to find the correct set of values to find a feasible
solution. This is an integration of the complexity types suggested by Sussman.
Imaginary complexity arises from a lack of knowledge and understanding of
the engineer. Combinatorial complexity exists when the number of possible
solutions increase continuously with time, for instance whether a new
technology should be integrated. Periodic complexity exists only in a finite
time period, resulting in a finite and limited number of solutions, for instance
a weekly system update due to design changes.
As this research addresses both complex systems and the design process to
come up with a system, both complexity categorisations are used.
2.2.2 Examples of complexity in engineering design
Complex system design is also referred to as engineering design, because in

design of such system the emphasis is on engineering required to address the
inherent system complexities. An example is given for each of the previously
defined complexities for aircraft design.
11
Structural complexity is apparent as an aircraft is composed of multiple

components and systems, as illustrated in figure 2-1 and figure 1-1 from
the previous chapter. That the interconnection of parts introduces extra
complexity surfaces, for instance, in the design of a blended wing body aircraft
concept, where the wing and fuselage are one structure. Engineering this
fuselage-wing interconnection is the main challenge of this concept.
Behaviour complexity surfaces in the determination of system behaviour. The

process to estimate the behaviour requires much engineering. An example is
the extensive numerical models required to accurately estimate behaviour of
the aircraft for various manoeuvres which can take hours of calculation for a
single case. On their turn the discretised models feature structural complexity
as they are composed of millions of interconnected elements.
Nested complexity surfaces, for instance, in the supply chain of aircraft

integrators. The integrator addresses the aircraft system, and its supplier is
responsible for a component, such as the wing system. Both have their own
system definition, design process, and both feature the defined complexities.
In this case, the wing system is nested in the aircraft system.
Evaluative complexity surfaces in the definition of the overall best concept,

taking into account all stakeholders. The customer will have a different view
on best then the aircraft integrator. Another example is the multidisciplinary
character of aircraft design, illustrated in figure 1-4 of the previous chapter.
The views of the disciplines are different, but need to be integrated in order
to come to an overall best solution.
Real complexity surfaces when searching for a system concept that meets all
design requirements. The requirements are composed of many constraints
which all need to be met. To find a system concept that meets all constraints,
the requirements need to be related to a concept solution. The relation is
evaluated to for the posed constraints in the requirements and the concept
solution is adapted until a feasible relation is obtained. This complexity
features the before mentioned: structural, behaviour, nested, and evaluative
complexities.
Imaginary complexity surfaces in design of new (hence different) systems. This

requires the engineer to gain knowledge and experience through learning by
trial and error. This trail and error process is required to obtain the necessary
knowledge and experience. This is reflected in the design phases used to phase
complex design processes, such as conceptual and detail design.
12
Complex systems
Combinatorial complexity surfaces during design process when the number

of requirements, possible solution concepts, and technologies increase. This
can deteriorate the quality of the selected system concepts in regard of other
concepts, which can result in a re-evaluation of the selected system concept.
Periodic complexity surfaces also during the design process. Some changes are
periodic, for instance, the periodic release of system concept changes. This
requires a periodic system redesign to encompass for the system changes.
2.2.3 Systems engineering
As mentioned in the introduction, systems engineering is commonly used to

address complexity in the development of complex systems. The scope of
systems engineering is the complete system development life-cycle (INCOSE,
2004). Systems engineering is an interdisciplinary engineering management
process that evolves and verifies an integrated, life-cycle balanced set of
system solutions that satisfy customer needs (Department of Defence, 2000).
The Department of Defence (2002) defines the systems engineering process is

a top-down comprehensive, iterative and recursive problem solving process,
applied sequentially through all phases of development (see figure 2-2). The
process is divided into phases that each:
»» Transform needs and requirements into system properties

»» Generate information for decision makers
»» Provide input for the next level of development
Concept Studies
DESIGN DEFINITION
System Definiiton
(Functional Baseline)
DESIGN DEFINITION
Preliminary Design
(Allocated Baseline)
DESIGN DEFINITION Detail Design

(Product Baseline)
figure 2-2: Development phasing used in systems engineering (DoD, 2000)
13
P
R
O
C
E
S Requirements System Analysis
S Analysis and Control
(Balance)
I Requirements
N Loop
P
U Functional Analysis
T and Allocation
Design
Loop
Verification
Design Synthesis
PROCESS OUTPUT
figure 2-3: Systems engineering process (Department of Defence, 2000)
These phases illustrate some of the iterative nature of the systems engineering
process. Within each phase the fundamental systems engineering activities are
requirements analysis, functional analysis and allocation, and design synthesis,
balanced by system analysis and control (see figure 2-3). During the systems
engineering process architectures are generated to better describe and
understand the system. The word “architecture” is used in various contexts in
the general field of engineering. It is used as a general description of how the
components join together to form the system.
The design loop addresses the functional and physical architectures. The
functional architecture identifies and structures the allocated functional and
performance requirements. The physical architecture depicts the study of
enabling large-scale complex technical systems system product by showing how
it is broken down into subsystems and components. The system architecture
identifies all the products (including enabling products) that are necessary
to support the system and, by implication, the processes necessary for
development, production/construction, deployment, operations, support,
disposal, training, and verification (Department of Defence, 2000).
Here, the focus in on the conceptual design problem, thus the systems
engineering focus is on the system design loop illustrated in figure 2-3.
INCOSE (2004) defines system design as an iterative process performed by
engineers, in cooperation with others, to transfer the customer/user’s needs
into a cost effective solution. “Cost effective” implies finding a solution that
appropriately balances the solution for a user’s needs with an acceptable
14
Complex systems
amount of risk. Not surprisingly, this definition is similar to Suh’s (2005)

complexity definition.
2.2.4 Design process cycle
Gero (1993) states the system design problem is to find a (feasible) relation
between function, structure, and behaviour. This relation was implicitly
mentioned for the systems engineering process, addressing the functional and
physical architecture. In this work, function is part of the requirements, and
structure part of the concept.
To relate these elements engineers use a design process. Different design

process models are used (Roozenburg, 1998), which depend on the domain.
Roozenburg (1998) defines a basic design cycle, illustrated in figure 2-4 on
the left. On the right side, in the same figure, a similar basic design process
is illustrated suggested by Van Tooren (2003). The design cycles address the
requirements, concept, and behaviour relation. The first step involves the
requirements or criteria definition. The second step involves definition of
a concept. The third step defines the behaviour properties by analysis or
function function
analysis specification
criteria requirements
concept
synthesis
generation
concept concept
simulation analysis
behaviour properties
evaluation evaluation
values values
acceptable
solution
design
figure 2-4: Different design processes; (left) basic design process cycle suggested
by Roozenburg (1998), (right) design process suggested by Van Tooren (2003)
15
simulation. The fourth step evaluates the performance by comparing the

behaviour properties with the requirements. The design cycle used by Ulrich
(2008) in the conceptual development phase features the same steps as these
design processes.
In the design process steps two distinct stages are used in which the
engineering uses different approaches (De Bono, 1990). In the diverging stage
lateral thinking is used to generate alternative potential solutions. Lateral
thinking is based on inductive logic and is used to structure processes related
to creativity. In the converging stage designers use logic and inference to
evaluate potential solutions. By using rules deductively, solutions are analysed,
compared, and selected. De Bono (1990) defines this as vertical thinking.
Vertical thinking is an analytical approach used to identify feasible solutions,
based on deductive logic.
2.3 System design process
In the following section the design process steps are discussed, addressing the
objective, involved complexity types, and system engineering methods that
address that complexity.
2.3.1 Requirements definition
Requirements are input for the system design. The importance of proper
requirements analysis is illustrated in figure 2-5, showing the impact
of repairing a defect along the life cycle. Generally requirements are
categorized. Van Tooren (2008) uses categories:
»» Functional requirements
»» Performance requirements
»» Constraint requirements
Functional requirements define the purpose of the system, and hold for every
potential system concept.
The performance requirements describe the extent to which system must

function, and hold for every system concept. Performance can be measured
for instance in terms of weight, cost, or time. Performance requirements
can be defined relative (e.g. minimise or maximise) or absolute (e.g. upper
or lower bound). Absolute performance requirements are regarded here as
constraint requirements. The overall system objective integrates the relative
performance values, showing evaluative complexity (see section 2.3.5). The
performance requirements can also be seen as flexible constraints as they
16
System design process
Importance of requirements analysis

20
18
16
14
relative cost
12
10
0
requirements design coding unit test acceptance test maintenance
analysis
lifecycle phase
figure 2-5: Importance of requirements analysis; relative cost of repairing
a defect at different lifecycle phases (Leffingwell, 2003)
define a system preference instead of a system boundary. That constraints

can be ‘soft’ is for instance illustrated by Vermeulen (2007) for a detail design
problem in which the system performance is optimal by a minimisation of the
constraint violation.
Constraints define the boundaries in which the system function should be

performed, hence they constraint the allowed concept and its behaviour.
Leffingwell defines constraints as: “a restriction on the degree of freedom
we have in providing a solution”. Constraints are an important driver of
complexity as they result in real complexity. Constraints complicate the search
for a feasible system solution by reducing the acceptable concept solutions.
Suh (2005) differentiates between two types of constraints, input constraints
and system constraints. Input constraints (e.g. constraints posed on the system
by the customer) are specific to the overall design goals, thus all potential
system solutions are subject to theses constraints. System constraints (e.g.
constraints posed on the system that depend on the design or are derived from
it) are specific to a given system concept and depend on its design options (see
next section). In optimisation theory constraints are categorised along another
axis, in bounds and constraint functions (Vanderplaats, 2007). The bounds
define the constraints on the degrees of freedom on the system model, and the
constraint functions define the constraints on the degrees of freedom on the
system behaviour. Integrating these two sets yield four constraint types:
17
»» Input bounds
»» System bounds
»» Input constraint functions
»» System constraint functions
2.3.2 Concept definition
A system concept is defined through identification of the design options that

together fulfil a function. Per function design options are identified by using for
instance a design option tree (Van Hinte, 2008). Together design options form
a design concept. For complex systems design options are identified based on
functional induction (Armstrong, 2008) or zigzagging (Suh, 2005). Both methods
decompose a system function by coupling it to a design option which translates
into subsystem functions (see figure 2-6). For instance the function ‘provide
lightning’ can be realised with the design option ‘lamp’ or ‘candle’. On its
turn the design option ‘lamp’ induces the function ‘provide electricity’, which
can be realised by a ‘battery’ or ‘power grid’ design option. A design concept
is obtained by combining these design options, showing nested complexity.
The resulting decomposition is object decomposition, a structural and nested
complexity.
Gero (2003) identifies analogy, combination, mutation, and first principles,

as methods designers use to find a new design concepts (see figure 2-7).
Analogy takes a known design concept and reuses that in a different domain.
Combination means that a new design concept is build by combining known
component concepts. Mutation implies a change in a known design concept,
often a strong relation with the original concept is kept. Mutation is for
instance used in the traditional conceptual design approach discussed in the
provide
light
lamp candle
provide
electricity
power grid battery
figure 2-6: Principle of functional induction (Armstrong, 2008) or zigzagging (Suh, 2005)
between function and design option illustrated for the ‘provide lightning’ function
18
figure 2-7: Concept definition based on combination,

mutation, analogy, and first principles (Gero, 2003)
introduction. Using first principles a concept is build from the ground up, using
a functional analysis, including functional induction.
To predict the behaviour of complex systems sophisticated analysis methods

and engineering software is used (see section 2.3.3). The engineering software
often requires a relative high level of detail for the concept geometry model.
This is illustrated by figure 1-2, from the previous chapter. In this work a
model is the instantiation of a concept, such as a geometric instantiation. To
generate these geometric models computer aided design (CAD) is generally
used. These CAD models are traditionally built from small discrete elements,
such as points and lines, which translate into many variables. To reduce
structural complexity, these geometric models are generally made parametric,
defining the dimensions of the model with parameters (Ledermann, 2005). For
instance a circle can be defined by multiple points along the edge or based
on a single ‘circle’ function using the centre and radius as parameters. These
parameters can be discrete and continuous. For instance, a table has three
or four legs with continuously varying height. Geometry is used here as an
example, but this also holds for other system properties, like cost. Today, the
model parameterisation is extended by using for instance knowledge based
engineering (KBE), see chapter seven for more details.
Design options are defined by parameter sets, composed of discrete and

continuous parameters. The discrete parameters define design sub-options.
19
The continuous parameters are used to size the system concept. If they are
variable during the design process, they are also referred to as variables.
2.3.3 Behaviour definition
To determine system behaviour the system concept is tested. The system

behaviour is based on the system concept and a test case. The test addresses
a specific function of the system for which the behaviour is to be verified. The
Department of Defence (2000) defines a test as;
“The use of system, subsystem, or component operation to obtain

detailed data to verify performance or to provide sufficient information
to verify performance through further analysis”
To evaluate the system function generally multiple test (cases) are used. These
tests define a certain scenario, defining among others environment conditions
and system operation. An example structural tests are load cases and example
aircraft tests are flight manoeuvres.
In complex system design the prediction of the behaviour needs to accurate.

Consequently, multiple disciplines are involved in the design that each address
a specific behaviour property set, such as aerodynamic or structural properties.
To predict the behaviour these disciplines all use different system models and
test case models. The different system models are illustrated in figure 2-8. This
system decomposition is called aspect decomposition and features evaluative
figure 2-8: Various discipline models used in aircraft design (La Rocca, 2009)
20
SVR System Level

System Level SFR
Design Requirements
t
Tes
De
Subsystems
sig
te &
n
gra
Item Level Configuration Items
Design Requirements
PDR
TRR
nte
te, I
rica
Assemblies
Fab
Components
CDR
All Design Requirements Complete
SFR = System Functional Review TRR = Test Readiness Review

PDR = Preliminary Design Review SVR = System Verification Review
CDR = Critical Design Review
figure 2-9: Systems engineering and verification (department of defence, 2000)
complexity, since the design performance (see section 2.3.4) is a deliberation

between the discipline views.
2.3.4 Performance evaluation
The system function performance is obtained by verifying behaviour to the

stated requirements (see section 2.3.4), where constraint requirements define
feasibility and performance requirements define optimality. To structure the
verification process the V-model (department of defence, 2000) is commonly
used (see figure 2-9). The illustrated verification process uses object
decomposition (see section 2.3.2) to structure the verification of the system at
all abstraction levels, featuring nested complexity.
The best feasible solution is identified via a trade-off (Van Hinte, 2008). First,
the requirements are translated into a set of criteria to which the system
concept and its behaviour are scored. Although the concepts are dissimilar,
having different properties, the criteria objectify the performance. By
evaluating these criteria for every system concept the performance values
are normalised. By adding weight factors to the various criteria a single
performance value is obtained per concept that can be used to trade the
concepts. The determination of these weight factors is determined by multiple
stakeholders, featuring evaluative complexity. An example trade-off tool used
in management is the ‘balanced scorecard’, which is used to trade between
financial and internal process aspects. (Kaplan, 1996).
21
In optimisation theory the system performance definition is formalised by

using separate objective and constraint functions. The objective function is
similar to the criteria function introduced in the first paragraph. The constraint
functions do not contribute to the performance value of the system solution,
but only define the validity of that concept (e.g. if a constraint is violated, the
system solution is invalid). Constraints can be defined for both concept and
behaviour. This is discussed in more detail in the following section.
2.3.5 Trial and error
The design process is an iterative process to find a (best) feasible system

solution as efficiently as possible. The methods deployed in the search for the
feasible solution are often based on experience and heuristics developed over
the years (Suh, 2005).
Gero (1993) identifies three design categories; routine, innovative, and

creative design (see figure 2-10). For consistency definitions from Gero are
used, Innovative and creative designs can be defined differently. In case
the design problem is a routine design, the design lies within the range of
solutions found in previous designs. By using interpolation, hence analogy, a
new solution can be found based on experience. Innovative design addresses
design problems that lie a bit out of the known design space, e.g. designing
a bit larger aircraft then normal. In that case, analogy can be used to some
extend, by using extrapolation. These design categories are addressed by
the traditional conceptual design approach. However, the more dimensions
the design space has the faster prediction accuracy deteriorates, and the
experience must be extended to encompass also this design space. The last
category addresses creative designs, which are based on combination or even
on using first principles. In that case limited knowledge on and experience with
universal design
space
new design
extended design space
space
known design
space
routine design innovative design creative design
figure 2-10: Different design categories; routine,

innovative, and creative design (Gero, 1993)
22
Multidisciplinary design optimisation
the concept is available. This new product architecture must be created by

trial and error before a decision can be made (hence imaginary complexity).
In design of complex systems, trial and error is required to find that feasible
solution. Today, optimisation theory, in combination with engineering
software, is used to support the trial and error process. Vanderplaats (2007)
suggests that design can be defined as the process of finding the minimum
of some parameter which may be called the objective function. The search
for this parameter value is constrained, since it is subject to the constraint
requirements. For the design to be feasible, the design must meet the in the
requirements defined constraints. A trade-off can be performed by performing
this analysis per system concept.
A standard optimisation problem is defined by design variables, objective

function, and constraints (Vanderplaats, 2007), defined by formula 1. The
variables ‘x’ are used to vary system parameter values (see section 2.3.2),
e.g. changing the wingspan or material thickness. The objective ‘f(x)’ and
inequality constraints ‘g(x)’ and equality constraints ‘h(x)’ embody the
performance and constraint requirements.
(2)
Today, complex systems challenge current optimisation capabilities.

Tosserams (2008) identifies three complexities: a system can be large scale,
multidisciplinary or multi-scale, or a high performance is required. Large
scale relates to the number of systems that are involved in the design,
e.g. aircraft consist of over a million parts (hence structural complexity).
Multidisciplinary relates to finding a feasible solution that meets all the tests
of multiple disciplines (featuring evaluative complexity). Multidiscipline design
optimisation or MDO in short, addresses this problem (Vanderplaats, 2007). The
high performance problem relates to finding not only a feasible, but also the
best or even optimal solution and may pose the greatest challenge according
to Tosserams (featuring behaviour complexity). Design of complex systems such
as aircraft features all three problems.
2.4 Multidisciplinary design optimisation
Besides automation, the motivation for using multidisciplinary design
23
optimisation (MDO) is the premise that the sum of optimum components is not
an optimum system (Vanderplaats, 2007). This premise suggests that there
is a coupling among the subsystems that affect the overall optimum. Today,
MDO is used for complex system design in the conceptual design phase. In the
conceptual design phase only a few experts are active in the design process,
where in the detailed design phase many experts are involved (Vanderplaats,
2007). Vanderplaats defines the goal of the concept design phase as:
“Conceptual design aims to provide as much information as possible in

as short time as possible and in a consistent manner, so that competing
concepts can be reasonably compared”
Vanderplaats (2007) identifies especially system concept sizing as a process

where optimisation can be used effectively, as it is both time consuming and
relatively uninteresting. Sizing involves changing system concept dimensions
(not the system concept) to optimise its performance, while ensuring that all
constraints are respected. An MDO approach is addressed in section 2.4.1.
In aircraft design, MDO is being used since the 1960s and 1970s (Vanderplaats,
2007). Vanderplaats states three important lessons learned from these early
implementations. First the physics should be properly modelled to ensure
realistic results. Secondly the choice of design variables is importance, and
third time consuming design iterations can often be replaced by constraints.
La Rocca (2009) states that MDO frameworks are required that addresses more
then optimisation techniques alone. A MDO framework concept is discussed in
section 2.4.2.
2.4.1 A decomposition approach
Tosserams (2008) refers to decomposition as a natural and often used approach

to address a MDO problem. The decomposition process is composed of two
steps:
»» Partitioning
»» Coordination
Three partitioning approaches are possible: object-based, aspect-based,

or a combination of them. As explained before, an example object based
partitioning is that an aircraft system design problem is partitioned into wing
and fuselage system design problems (e.g. hierarchic concept definition). An
example aspect based decomposition is that an aircraft system design problem
is partitioned into a structural and an aerodynamic system design problem
(e.g. different behaviour analyses). In general, an aircraft system design
24
system (multi-level)
subsystem B
design
system (single-level)
subsystem A
design design analysis

subsystem C
analysis
subsystem A
subsystem B subsystem C
analysis
analysis
analysis design
analysis
figure 2-11: Subsystem authority in coordination methods
problem features both partitioning approaches. Another example of combined

partition is a matrix organisation, seen at many large engineering companies,
decomposing an organisation into functional and project organisations
(Tosserams, 2008).
Coordination aims to integrate the partitioned system parts towards an optimal

and consistent system concept design. Traditionally, coordination is performed
by project managers by means of budgeting, using experience, intuition, and
heuristics to resolve inconsistencies and provide direction towards system
optimality (Tosserams, 2008). Tosserams states that the increased complexity
requires more sophisticated methods, based on mathematical modelling,
and suggests that this could be the only solution for new systems for which
experience is limited.
In general, two coordination methods exist; single-level and multi-level

(Tosserams, 2008). The single-level approach allows analysis autonomy at
the individual subsystems, but no design autonomy. The multi-level approach
allows both at system and subsystem level. Today, most coordination methods
use a centralised structure in which the system problem is coordinated over
the subsystems (e.g. single-level). The two approaches are illustrated in figure
2-11.
Although single-level methods are regarded more efficient, multi-level

methods fit the organisation of the design process itself (Tosserams, 2008).
These methods support separate discipline analysis and respect design
autonomy of different design teams. The commonality with the design process
is respectively in the separate behaviour analyses (section 2.3.3) and the
hierarchic verification structure (section 2.3.5).
25
Another benefit Tosserams mentions is that these multi-level methods provide

a framework to decouple the design activities at subsystem level from system
level through the use of surrogate models. Each subsystem constructs a
surrogate model of the design space, which can be used to perform the system
optimisation. The surrogate models are abstract descriptions of the design
space making the system optimisation process considerably faster. An example
of such a multi-level method is Bi-Level Integrated Systems Synthesis (BLISS,
Sobieszczanski-Sobieski, 2003).
The discussion on MDO so far addressed the (formal) optimisation problem

and presumed that all required engineering tools are available, as well as a
problem space (e.g. system requirements) and a solution space (e.g. system
concept solutions).
2.4.2 Design and engineering engine
That the success of a MDO framework does not solely depend on optimisation
tools already surfaced in the lessons learned from the first generation
MDO implementations (Vanderplaats, 2007) mentioned before. La Rocca
(2009) extends this dependency to a need for an overall development of
computational frameworks geared toward flexibility, automation, and
exploitation of high-fidelity analysis systems, of which faster computers and
more powerful optimisation tools are a part. La Rocca defines six framework
requirements:
(1) Easy to adapt to different design cases respecting the

specific demands of the design process phases
(2) Support the integration of different tools scattered across
distributed and heterogeneous computer networks
(3) The system should be able to integrate both commercial
off-the shelf and in-house developed tools
(4) Integrate both low-fidelity and high-fidelity tools
(5) Guarantee the coherence and synchronization of the data and models
(6) Support automation of all the repetitive activities
related to the iterative nature of design
The design and engineering engine (DEE) is a framework concept based on

these six requirements (Van Tooren, 2001; Morris, 2002; Cerulli, 2006; La Rocca
2009). The DEE process structure is illustrated in figure 2-12. The DEE is a
version of the design process discussed in section 2.3, with a mode detailed
system behaviour definition step.
26
To respect the multidisciplinary character of complex system design (see

section 2.3.3), the behaviour definition step decomposed into a set of
(parallel) steps. The behaviour is defined per discipline using discipline specific
analysis tools.
To provide each discipline with consistent input, the concept definition step
is decomposed into two steps. The first step, performed by the so-called
‘initiator’, is the identification of a concept model, defining its parameter
values. The second step is performed by the so-called ‘multi-model generator’
or MMG. The MMG first translates the parameters into a generic (geometrical)
system model and generates, based on the generic model, discipline specific
models, such as structural models (Nawijn, 2006) or aerodynamic models
(Cerulli, 2006). For more information see chapter seven.
To define the performance the behaviour is evaluated to the requirements for

compliance. The compliance determines whether the trial and error process is
finished or a new concept needs to be defined by the initiator starting a new
iteration.
figure 2-12: Design and engineering engine concept (La Rocca, 2009)
27
2.5 Abstraction complexity
The previously defined initiator is the focus of this research. To perform a MDO
problem by using the DEE framework the initiator needs to provide a start
vector. This start vector allows the use of MDO. The start vector is the required
output of the initiator. On the other side the initiator has only requirements
as formal input. In the initiator phase engineers use their knowledge and
experience to translate the top level requirements into one or more potential
system solutions, embodied by a sized system concept. That this is not a
straightforward activity is illustrated in this chapter.
Due to the associated complexities (e.g. Sussman’s complexities or Suh’s real

complexity) an engineer has too few resources to incorporate all requirements,
concepts, and tools. Consequently, the engineer is not able to analyse all
possible relations between these components. Moreover, the designer has
no mathematics available to physically relate requirements, concepts, and
behaviour at system level for a new concept. This disables the engineer to
describe the problem only at system level, which is the case for the traditional
conceptual design approach.
In order to start a system design, the designer has to reduce the associated
complexities. Often used approaches are to simplify or decompose the system,
reducing these complexities. The approach is for instance visible in the
different phases used in systems engineering. Rechtin and Maier (Sussman,
2007) refer to the approach from a complexity reduction point of view and
state:
“Model (abstract) the system at as high a level as possible, then

progressively reduce the level of abstraction. In short, simplify.”
Abstraction allows a designer to reduce Sussman’s complexities and Suh’s real

complexity. However, system abstraction itself introduces uncertainties in the
definition of the system that need to be tacked. In this work, the resulting
complexity due to abstraction is referred to as:
»» Abstraction complexity
The abstraction complexity addresses the complexity involved in system

abstraction, a derivative from a reduction of the other complexities.
In order to reduce this complexity an engineer needs to understand the

implications of the system abstraction in respect to the real design problem.
This is similar to the case new design concepts are addressed. For these new
28
Conclusions
concepts limited knowledge and experience is available, which introduces

imaginary complexity. In order to reduce the imaginary complexity a designer
needs to learn. To learn a common approach is to use trial and error. The
application of abstraction and trial and error in conceptual design is discussed
in more detail in the following chapter.
2.6 Conclusions
Complex system design involves system and system design complexities.

Engineers use systems engineering and the design cycle to reduce these
complexities. To reduce complexities in system design automation through
multidisciplinary design optimisation can be used. To effectively use MDO a
supporting framework needs to be available to structure the design process
and to integrate the various tools involved in that process. The DEE is such
a framework. However, in order to perform MDO an initial system solution is
required. To find this solution engineers need to translate a set of requirements
into a conceptual solution. The complexity involved in the conceptual design
process due to abstraction is referred to as abstraction complexity.
The contribution of the work presented in this chapter is the assembly of

different methods available in literature that are used to address a conceptual
design problem. The selected methods can be used to structure and formalise
the conceptual design approach. Secondly, the complexities associated
with conceptual design are described. The term abstraction complexity is
introduced to integrate the difficulty abstraction encountered in conceptual
design.
The following chapter will address the synthesis of the tools and methods
described in this chapter in an integrated approach that can be used to
address the conceptual design problem. The approach is formalised in support
implementation with knowledge engineering. However, first the application
of the approach for various examples is discussed in chapters four, five, and
six, to understand and bring to surface the inherent recurring and repetitive
activities. In chapter seven the formal approach is coupled with these
repetitive and routine activities and extended into the field of knowledge
engineering.
29
Chapter 2: 2
30
Part I
Development of a conceptual design
methodology
Introduction
Chapter 3: Conceptual design

feasilisation
3.1 Introduction
The objective of this chapter is to introduce a formalised approach to

define a conceptual design problem, called feasilisation (Schut, 2007). The
formalisation discussed in this chapter is partly based on the experience
derived from the example applications discussed in the successive chapters.
From the previous chapter it became clear that multidisciplinary design

optimisation (MDO) can support automation of the design process. Therefore
a framework needs to be available to structure the design process and to
integrate the various tools involved in that process to use MDO. Such a
framework is the design and engineering engine (DEE). This work belongs on
the DEE development and extends on the principles and methods used within
that context. However, an initial system solution is required in order to use
this framework and perform address a MDO problem. To find this initial solution
engineers need to relate a set of requirements to a conceptual solution. To find
this conceptual solution an engineer uses an abstract description of the design
problem. During this process the engineer must ensure that the obtained
abstract description represents the real problem. The complexity involved
in this process is referred to as abstraction complexity. Key questions to be
answered:
»» How do we address abstraction complexity?

»» How can automation be integrated in the design process?
»» What is the formal description of the design process?
»» What is the structure of the automated search process?
First, the methods used in an approach to address abstraction complexity

will be discussed, called feasilisation (Schut, 2007). The subsequent sections
address the formalisation of the feasilisation process. First the DEE will
be positioned as process building block. Secondly, the design process is
formalised, represented by a single DEE. Finally, feasilisation process is
formalised, represented by a multiple DEEs.
3.2 The feasilisation approach
The discussion in the previous chapter surfaced that at the start of a design
33
Chapter 3: Conceptual design feasilisation
example panel locations
figure 3-1: Example panel locations in an aircraft
problem an engineer has little knowledge of and experience with new design
concepts. On top of that the engineer is faced with too few resources to
incorporate all requirements, design concepts, and tools. To address this
problem the engineer uses system simplification.
The feasilisation approach (Schut, 2007) is defined as a set of methods an

engineer uses in conceptual design to find a feasible system solution for a
complex system design problem, addressing abstraction complexity. The
feasilisation approach is composed of three methods:
» Simplification
» Decomposition
» Trial and error
By using system simplification the engineer obtains a simplified and

decomposed system design problem. By means of trial and error the engineer
iterates to find a feasible and acceptable solution. The three methods are
discussed in the following sections. A conceptual panel structural design
problem will be used as guiding example (see figure 3-1). The panel is, for
instance, a fuselage of wing skin panel that can be curved and have variable
dimensions. The panel can be based on different material types, e.g. metal
or composite, and is can be stiffened by for instance blade-stiffeners or
hat-stiffeners.
3.2.1 Simplification
Simplification involves system abstraction. The abstraction can be performed
34
The feasilisation approach
for the various part of the system. For instance, the system concept can
be simplified and then exact physics can be used to determine the exact
behaviour of this system. Besides that also the physics can be simplified
resulting in an estimation of the behaviour of the system. Another example is
to take only a reduced set of requirements into account, estimating the driving
requirements. Simplification is used to reduce the dimensions of the design
space, reducing real complexity.
Simplification addresses the three steps of the design process; requirements,

concept, and behaviour prediction. Simplification of the design process results
in:
»» Reduced set of requirements

»» Simplified concept design options
»» Schematic behaviour models
A reduced set of requirements is obtained by addressing only the driving

functions, performances, and constraints. The obtained problem is a simplified
version as it has to meet fewer requirements. A result can be that the driving
requirements are not addressed, invalidating any obtained solution. Therefor,
these driving factors are determined based on experience and knowledge
of the engineer. For fuselage panel design this could for example result in
selecting driving functions ‘to maintain structural integrity’ and ‘to transport
loads’, disregarding other functions such as ‘provide maintainability’ or
‘protect from environment’. Performance requirements in panel design could
be to minimise weight and cost, which can be subject to a certain allowable
maximum. Other performance requirements such as minimum life span are
then left out. Example driving constraint requirements in panel design could
be ‘allowable loads’ on material strength and stability. Other constraints such
as fatigue or impact resistance are then disregarded.
original shape schematic shape
3D 2D 2D
surface prism rectangle
figure 3-2: Simplification of a hat-stiffened panel concept
35
h
px
simply supported free
figure 3-3: Blade-stiffened panel schematic behaviour model of stiffener in

compression. The stiffener is modelled and analysed as separate element
Simplified design options define the simplification of the concept considered

to be a solution for the design problem. Only the principal design options
are included, describing a simplified model of the concept. The result is that
fewer concepts are addressed and that a concept can be described with fewer
parameters. This can result in disregarding a beneficial concept solution.
Therefor, a proper principal design option selection is based on experience.
A design concept is a collection of design options, and is modelled using
a set of parameters. For the panel design example, the principal design
parameters are the planform dimensions length, width, and thickness. Other,
such as curvatures are disregarded. Depending on the stiffening design option
(e.g. hat-shaped), design parameters involve stiffener spacing, height and
thickness. Varying stiffener angle and curved corners are not addressed in the
simplified model. In figure 3-2 is illustrated how a 3D panel is simplified to a 2D
rectangle.
Schematic behaviour models involve simplified system physics. The system

physics is simplified by addressing the behaviour properties separate. By
separating the behaviour, specific schematic models are obtained that estimate
a specific behaviour. An example is the determination of the allowable load in
panel stability analysis. The panel is decomposed in several elements that are
analysed separate. For a blade-stiffened panel, the blade interaction with the
environment is simplified by translating a 3D problem into a 2D problem. This is
realised by assuming it to be simply supported at all edges and by introducing
the pressurisation loads in-plane instead of out-of-plane. This enables the
engineer to obtain an estimation of the behaviour. This is illustrated in figure
3-3 for stiffener stability evaluation (see next chapter for more information on
this example).
Simplification is used to reduce the dimensions of the design space, reducing

real complexity. The simplification process results in a discrete set of system
design problems with decreasing level of simplification that initiate each other.
36
That this is a common approach can be deduced from the systems engineering
process, which featured also these different phases. See the next chapter for
examples.
3.2.2 Decomposition
Decomposition is mentioned several times in the previous chapter as an

approach to address complex systems, for instance in the discussion on MDO.
Decomposition is a result of the systems view. By viewing the world as a set of
separate systems the ‘world system’ is decomposed. This enables engineers to
assess the systems individually. Decomposition is used to reduce the dimensions
of the design space, this reduces real complexity.
As was mentioned in the previous chapter (section 2.4.1), two decomposition

approaches are possible:
»» Object decomposition
»» Aspect decomposition
Aspect decomposition divides the system based on behaviour or characteristic,

resulting in a set of disciplines that analyse a specific set of behaviour
properties. Object decomposition results in a set of subsystems or components
that represent the system. Aspect decomposition is generally associated with
analysis in engineering design. Aspect decomposition is the decomposition
of the behaviour prediction definition step of the design process. The DEE of
function sustain panel load
has principle of solution
principle of
discrete stiffened Panel
solution
has technical
solution
technical
stringer-stiffened
solution
has conceptual structure
conceptual interface
plate stringer 1 stringer N
structure system
figure 3-4: Structured functional induction based on the MOKA functional view
37
panel
system
skin stiffener
system system
layup layup layup

system system system
layer layer
... ...
system system
material material
system system
figure 3-5: Example object decomposition: from panel up to material
the previous chapter provides an example aspect decomposition (figure 2-8).

The system behaviour is evaluated by analysis of the properties by different
disciplines, e.g. aerodynamic or cost properties. As is explained for the DEE in
the previous chapter, aspect decomposition requires an initial generic model
that generates the specific discipline models, to ensure consistency.
Object decomposition divides the system based on function and design

concept, resulting in a set of objects that together represent the system
object. Object decomposition is also known as sub-structuring in the structures
discipline. To fulfil the function a system concept is selected that induces
a set of sub-functions (Armstrong, 2008; Suh, 2005). Then again, for each
sub-function, a new concept is selected and the induction continues. The
design option tree used in systems engineering is a common method of linking
a function to a system design option (Van Hinte, 2008). A formal model to
relate function to concept is the functional view of the MOKA ontology (MML
working group, 2000). A function has one or more principles of solution, e.g.
transport load can be provided by for instance a panel or cable. A principle of
solution is realised by a technical solution, e.g. a panel can be a hat-stiffened
panel. The technical solution is embodied by concept structure, e.g. stiffener
and skin plates, illustrated for an aircraft in figure 3-4. The decomposition
process produces a hierarchical (hence multilevel) system tree, with each
system addressing a design problem. This is illustrated in figure 3-5 for the
aircraft panel example. In this work ontologies are used as inspiration to
structure information, but no formal ontology is developed. This is out of scope
38
for this work and the definition of an ontology is recommended for further
work.
Decomposition is used to reduce the dimensions of the design space, as the

system is decomposed into subsystems that are addressed individually. This
reduces real complexity as the subsystem design space is smaller then the
system design space. When applied recursively this yields a hierarchic system
tree. That decomposition is a common approach is illustrated by the discussion
in previous chapter on the decomposition approach to MDO and the design
option tree used in systems engineering. See chapter five for examples.
3.2.3 Trial and error
The design process and also MDO are based on trial and error to address system
complexity. The complexity of the design problem, caused by the abundance
of requirements, design options, and tools, make a direct identification or
calculation of a feasible relation impossible. The selection of the design
options is based on experience which is limited in new design problems,
resulting in imaginary complexity. Trial and error is used to increase knowledge
of and experience with a system concept, decreasing imaginary complexity.
The available experience affects the trial and error process, reusing that
experience can reduce the required iterations. However, for new system design
problems, experience can be limited. Gero (1993) identifies three design
categories; routine, innovative, and creative design (see figure 3-6). In case
the design problem is a routine design, the design lies within the range of
solutions found in previous designs. By using interpolation, hence mutation, a
new solution can be found based on experience. Innovative design addresses
design problems that lie a bit out of the known design space, e.g. designing
a bit larger aircraft then normal. In that case mutation can be used to some
extend, by using extrapolation. However, the more complex the design space
universal design
space
new design
extended design space
space
known design
space
routine design innovative design creative design
figure 3-6: Design problem categories; routine, innovative, and inventive
39
figure 3-7: Composite concept performance space,

build from design concept solution spaces
the faster prediction accuracy deteriorates, and the experience must be

extended to encompass also this design space. The last category addresses
creative designs, which are based on combination or even on design by
first principle. In that case, no or little experience with the design space is
available. This must be created by trial and error before a decision can be
made.
As discussed in the previous chapter, MDO is used to simulate or mimicked

(part of) the trial and error process. The optimisation problem is defined by an
objective, constraints, and variables. The individual concepts can be optimised
using these techniques, to make a selection between concepts a trade-off
is generally used. If this trade-off is defined in terms of requirements, the
trade-off becomes a basic selection. This is illustrated in figure 3-7, where
the performance of two system concepts is plotted to these requirements. By
integrating these figures a composite concept performance space is obtained
that can be used by the engineer to identify the ‘best’ system concept.
Trial and error is used to increase knowledge of and experience with a system
concept, decreasing imaginary complexity. Using optimisation techniques
this process can be mimicked. The result of the trial and error process is a
composite concept solution space that integrates the various concepts and
requirements into a single design space. That trial and error is a common
approach is illustrated by the feedback loops in the design process. See
chapter six for examples.
3.3 The feasilisation process
The previous section described the structure of the feasilisation approach.

In order to integrate feasilisation and MDO the search process needs to be
explicit. As will be explained the feasilisation process can be modelled by
multiple design and engineering engines (DEEs). First the feasilisation process
is constructed with the DEE as generic building block. Secondly, the search
40
The feasilisation process
process is made explicit for the design process discussed in the previous
chapters. Finally, the DEE structure is adapted to for the explicit definition of
the search process.
3.3.1 The DEE as building block
This research focuses on the initiator module of the DEE (section 2.4.2).
However, the DEE process can be used as building block to construct the
feasilisation process, modelling the simplified and the decomposed process
structures.
As stated before, simplification results in a discrete set of system design

problems with increasing level of complexity (such as the design phases). Each
of these systems can be modelled as a DEE. Consequently, the first DEE is the
initiator of the second DEE and so forth. For example, first a panel is designed
using analytical formulae, that are input for a more detailed analysis using
numerical methods, which are more time consuming. This DEE chaining is
illustrated in figure 3-8.
Decomposition results in a hierarchical system, as was illustrated in figure 3-5.

Each system in the multilevel system representation of the design problem can
be modelled as a DEE. Although in this case, the communication is different.
The DEEs are coupled through their internal processes. This yields a process
very similar to the verification process model used in systems engineering.
product
requirements
DEE (conceptual phase) DEE (preliminary phase) DEE (detailed phase)
INITIATOR MODELER INITIATOR MODELER INITIATOR MODELER
CONV. & CONV. & CONV. &

TESTERS TESTERS TESTERS
EVAL. EVAL. EVAL.
1: converged? 1: converged? 1: converged?
2: acceptable? 2: acceptable? 2: acceptable?
no no no
1 1 1
yes yes yes
no no no
2 2 2
yes yes yes
conceptual preliminary
specification specification
product
specification
figure 3-8: DEE modelling of simplification and decomposition
41
top level DEE

system level of abstraction
test-
n
conc
sis
finitio
e
case
ynth
ept d
el de
ce s
analy
efinit
mo d
rman
sis
ion
perfo
bottom level DEE
figure 3-9: Multilevel system performance process yields a W-diagram

of design process steps; concept, model, test, and performance
First the concept is defined for system and subsystems. Then the system model
is synthesized from the subsystem models. Thirdly the system test case is
translated to subsystem test cases. Finally, respectively the subsystem and
system behaviour and performance can be determined. The resulting double
V-model for the multi-level DEE system is illustrated in figure 3-9.
The repetitive use of the DEE concept to construct the overall design process
provides a first mimic of a repetitive task performed by the designer. However
to use the DEE concept, its process needs to be slightly adapted.
3.3.2 Separate search and design
To effectively use MDO the search process needs to be explicitly defined in the
design process. The inclusion of engineering software for search in the design
process requires a separation of engineer and software tasks.
The design process discussed in the previous chapter features four steps:
requirements definition, concept definition, behaviour definition, and
performance evaluation. The process is illustrated in figure 3-10a. In this
model the search is implicitly included in the decision triangle at the bottom.
The feedback depends on case: converged, optimal/feasible, or acceptable.
When including MDO these cases are partly the responsibility of the engineer
and partly taken up by the optimisation algorithms.
To visualise the inclusion of MDO on the design process, the process needs
to be adapted to differentiate between the engineer’s activities and the
engineering software tasks. This process is presented in figure 3-10b. Both the
engineer and the optimisation software address the four steps of the design
process. However, the engineer is responsible for problem definition and
evaluation, determining if the system solution is acceptable. The optimisation
42
The feasilisation process
(3)
requirement problem
definition definition
(2)
concept solution requirements requirements
definition generation generation definition
(1) (2)
behaviour performance concept concept
definition evaluation generation definition
1) acceptable?
(1)
performance no behaviour behaviour
evaluation generation definition
1) converged? yes
2) optimal/feasible?
3) acceptable? solution problem
evaluation evaluation
1) converged? 1) acceptable?
no 2) optimal/feasible?
yes
yes no yes no
(a) (b)
figure 3-10: Placing the designer outside the design loop; (a) traditional
coupled design process; (b) explicit search in the design process
engineering software is responsible for finding a converged, optimal, and

feasible solution to the defined problem. This has the logical implication that
if the problem does not yield such a system solution the engineer’s evaluation
will not be acceptable, and requires a redefinition of the design problem. In
appendix A a diagram is included that addresses this process in more detail.
3.3.3 Design and engineering engine process adaption
This explicit definition of the search process influences the process

architecture of the DEE concept introduced in the previous chapter. In the
original definition, the design vector is defined and updated by the initiator
while the objective and constraint evaluation is performed by the evaluator.
In case of MDO both functions are performed by the optimisation algorithm.
The previously introduced DEE structure is adapted to make the position of the
search functionality explicit. This is illustrated in figure 3-11.
The initiator is redefined to be responsible for the start vector definition of

the optimisation problem. The search is integrates the evaluator, converger,
and initiator responsible for design variable updating. Next to the search
component also a performance component is included that translates the
behaviour to the objective and constraint values used by the search component
to direct the search.
43
MULTI MODEL GENERATOR

REQUIREMENTS (Parametric Product Model)
(problem definition)
LOR Model Model Model

Data Data Data Data
INITIATOR R
(Start Vector)
(Aerodynamics)
(Manufacturing)
DISCIPLINE A
DISCIPLINE C
(Structures)
DISCIPLINE
SEARCH H
DISC
DISC
C
tr
(Aero
(St
(Optimization)
on)
1: feasible?
2: optimal?
no
1
yes
no Test Test Test

2
Data Data Data
yes
Specs
Data PERFORMANCE
(Objective and Constraint Values)
figure 3-11: Adapted DEE process with an explicit search function
3.4 Design process formalisation
The following two sections address the formalisation of the feasilisation

process. Since the feasilisation process is a multi-level design process, first the
design process is formalised. In the next section 3.5, the process described
in this section is translated to a multi-level formulation for the feasilisation
process. For both respectively the problem, search, and evaluation steps are
discussed (see figure 3-10b).
3.4.1 Problem definition formalisation
The problem is defined by requirements, concept, behaviour, and evaluation.

The required information definition per step is discussed to support solution
generation.
Requirements definition
Requirements are composed of functional requirements, performance

requirements, and constraint requirements. To support the search process, the
44
Design process formalisation
functional requirements are embodied by a set of test cases. The performance

requirements were defined as variable performance requirements, defining
the utility function for the search process, e.g. the objective function. The
constraint requirements are segmented into system and model constraints.
The system constraints were concept independent and define the constraint
functions used in the search process. Requirements define:
»» functional requirements
»» performance requirements
»» constraint requirements
Concept definition
The concept definition entails the definition of a concept and its parameters.
To size the concept these parameters can be variable. The model constraints
depend on the system concept. These constraints define the bounds on the
concept variable parameters, e.g. lower or upper bound.
»» parameters
»» variables
»» bounds
To provide input to the behaviour analysis, the disciplines required specific

models. This means that tools need to be defined which are responsible for
generating these models.
»» model generation tools
Behaviour definition
Behaviour is determined by several disciplines. The behaviour is based on a

test case and model. By comparing behaviour and criteria a constraint value is
obtained. This requires specific tools to perform these translations.
»» behaviour analysis tools
Performance evaluation
The performance evaluation entails the evaluation of the objective and

constraint values, and the selection of a new set of variable values. These
activities are performed by a search tool. This tool needs to be defined.
»» search tools
45
3.4.2 Solution generation formalisation
To automate the design process its steps need to be defined formally, such that
these can be captured by engineering software.
Requirements generation
Based on the previous section this is formalised by the following formulae:
test-cases = f1(requirements)
objectives = f2(requirements, performances) (3)
constraints = f3(requirements, performances)
Concept generation
A concept is defined by its design concept and its model by the concept
parameter values. A concept model is obtained by a set of parameters and
tools that generate that model. To allow for variations within a concept,
certain parameters are variable. However, the concept variable parameters are
generally bounded, constraining the system model variability, e.g. maximum
allowable dimensions. This is formalised by the following formulae:
concept = f5(requirements, design-options)

parameters = f6(concept) (4)
variables = f7(parameters)
bounds = f8(variables)
Behaviour generation
The behaviour definition uses an instantiation of the concept based on variable

values and a set of test cases. The behaviour generation yields the behaviour
values. The behaviour values are determined by analysing the relation between
test case and model. Compared to the requirements the behaviour criteria
are determined. The behaviour is compared to these criteria to obtain the
performance values. This process is formalised by using the formulae:
performances = f9(behaviour, criteria, variables, bounds)

behaviour = f10(model, test-case) (5)
criteria = f11(model, test-case)
model = f12(variables, parameters, concept)
46
Feasilisation process formalisation
Solution evaluation
The search process is used to couple the elements of the other processes in
order to obtain a design solution. The search process depends on the problem
involved and as discussed in the previous chapter can involve different
strategies. The engineer is responsible for defining the design problem. This
design problem is translated to a search problem. This process is formalised by
using the formulae:
solution = f14(objectives, constraints, test-cases, variables, bounds) (6)
This process defines whether the obtained system solutions are acceptable.
The system abstraction inherent to conceptual design will result in a deviations
between the modelled and real problem, thus a feasible solution is not directly
an acceptable solution. This decision is based on engineering judgement and
is regarded as a creative activity that can be supported by automation. This
process is discussed in more detail in chapter six.
3.5 Feasilisation process formalisation
The discussion in the previous section on design process formalisation is

extended to the multi-level feasilisation approach. The formalisation is
separated in three steps: problem definition, solution generation, and
performance evaluation.
3.5.1 Problem definition formalisation
Requirement definition
The multi-level approach requires definition of the requirements at all system

levels. This generally involves constraint requirements, as the global system
function and objective are defined at system level.
Concept definition
The concept is defined by concept design options at every level. The top level
system concepts are obtained by combining these sub-system concepts. By
making explicit at system level which sub-system concepts are used to define a
system concept, the number of system concepts is reduced.
47
For the multi-level case also the model constraint requirements need to be
defined at every system level.
Behaviour definition
The multi-level approach requires translation of test-cases from system to

sub-system. Another possibility is that the functional induction yields the
definition of specific test-cases at subsystem level.
The performance evaluation tools depend on the type of search strategy.

In the discussion on MDO in previous chapter two general approaches were
introduced: single-level and multi-level. The single-level approach integrated
the sub-system design problems in a system design problem. The multi-
level approach allowed for sub-system design autonomy, which required
coordination. For more information see section 3.6.
min(x) obj = f(m0,b0)

c≤0, c=[c0,c1,c2]
lb≤x≤ub, x=[x0,x1,x2]
m0=f01(x0,mi)
b0=f02(m0,t0)
c0=f03(m0,t0)
mi=fi1(m1,m2)
[t1,t2]=fi2(t0,m0,m1,m2)
c1 m1 m2 c2
2
t1 1 x1 x2 1
t2 2
m1=f11(x1) m2=f21(x2)
c1=f12(m1,t1) c2=f22(m2,t2)
figure 3-12: Standard constraint nonlinear optimisation problem

extended with internal multilevel system definition
Symbol Description Symbol Description
fi function mi system model
ci constraint bi system behaviour
xi system variables ti system test-case
48
Feasilisation process formalisation
(1a) (2a)
system
DEE
define define define define
concept model test case behaviour
sub-system
DEE
define define define define
concept model test case behaviour
(1b) (2b)
figure 3-13: Multi-level feasilisation process steps. Respectively define

concept top-down (1a), define model bottom-up (1b), define test case
top-down (2a), and define behaviour performance bottom-up (2b)
3.5.2 Solution generation formalisation
The multi-level definition complicates the design process, as surfaced in

section 3.3. The standard optimisation problem (see equation 1) is extended
to illustrate the communication between the different system levels. This
formulation is illustrated in figure 3-12.
Iteratively an optimisation algorithm changes the values of the design

variables to obtain the best feasible solution. In this process the performance
process directly couples all systems in four steps; concept definition, model
generation, test analysis, and performance synthesis, see figure 3-13.
First the concept is defined (1a), assigning per system level the design variable
values to the concept parameters. Secondly, a based on the concept variable
values a model is generated (1b), by bottom-up definition of the model
properties. The result is a system model, containing all information required to
define the test case for the sub-systems. In the third step per top-level defined
test-case, the test-case properties are decomposed to the subsystems (2a).
In this manner, per system, a test-case is defined that can be used to obtain
the required behaviour performance values (2b), determined in the fourth and
final step. These performance values are translated to objective and constraint
values, input to the search tool.
In this thesis the single-level approach is used for the implementation. This is a
simpler approach and is used for the proof of concept described in this thesis.
49
Especially in conceptual design experience needs to be included in the

evaluation. To support part of this decision, the designer can be given a
range of system concept solutions meeting a certain set of criteria, such
as robustness of the solution (sensitivity of the performance on changing
requirements). This provides some information on the quality of the solution.
How experience can be supported is discussed for an example wing design
problem in chapter six.
3.6 Conclusions
This chapter introduced feasilisation as an approach to address abstraction

complexity in conceptual design. The feasilisation approach is composed of
three complexity reduction methods: simplification, decomposition, and trial
and error. The previously introduced DEE concept could be used as process
building block to construct the feasilisation process. As could be expected,
the resulting process has many similarities to the systems engineering process
discussed in the previous chapter. The design process is adapted to separate
the efforts of the engineer and the MDO framework. The change was included
in the DEE concept, to support its modularity as building block. The design and
feasilisation process are formalised in order to support the integration with
engineering software. The integration of feasilisation is discussed in chapter
seven and beyond.
The contribution of the work presented in this chapter is the formalisation

of the conceptual design approach, introduced as feasilisation. The approach
synthesised existing methods with the design process and DEE concept. The
DEE concept was adapted to encompass for this application, and is introduced
as process building block. The application of the DEE building block to the
simplification and decomposition methods formalised the application of these
methods. The multi-level system design process illustrated in figure 3-13 is an
example result.
Examples of the formal application of simplification, decomposition, and trial

and error are discussed respectively in chapters four through six. The examples
are focused on the different aspects of each method and focuses on the
associated recurring and routine processes.
50
Introduction
Chapter 4: System simplification
4.1 Introduction
The objective of this chapter is to illustrate the use of simplification in

conceptual design. The second objective is to bring to surface repetitive and
routine activities inherent to this method. Such that the process automation
building blocks can be identified.
In the previous chapter feasilisation is presented as an approach to address

abstraction complexity in the conceptual design problem. Simplification is
one of the three methods of the feasilisation approach. Simplification uses
problem abstraction to obtain a simplified design problem. The simplification
involved: reduced set of requirements, simplified design options, and
schematic behaviour models. In this chapter conceptual design examples will
be presented. Key questions to be answered:
»» How are design problems simplified?

»» How are levels of simplification integrated?
»» What are repetitive and routine activities?
»» What are potential building blocks?
The first part focuses on example applications of simplification, focussing

on structural design problems. The second part addresses the integration of
multiple levels of simplification in a single example. The chapter is concluded
with observations and conclusions, focussing on translating the observed
repetitive and routine activities in potential building blocks.
4.2 Example simplifications
As discussed in the previous chapter simplification entails three areas;

simplification of requirements, concept, and behaviour. The simplified
problem embodies the (perceived) relevant physics behind the problem. The
simplified requirements translate in fewer requirements, thus a reduced set of
objectives, test cases, and constraints. The simplified concept model reduces
the degrees of freedom. Therefore the number of design variables. The
simplified behaviour is based on simplified behaviour models. Consequently the
complexity is reduced of behaviour analysis methods, drastically decreasing
the evaluation time of such tools. On the whole simplification should reduce
time, but still provide a good indication of the performance of a concept
subject to certain requirements.
51
panel length (L) skin web width (b)
stiffener height (h)
0o layers
normal load (P) panel width

shear load (P)
+/- 45o layers
figure 4-1: Panel functional requirements (left) and panel concept (right)
To illustrate the use of simplification in aircraft conceptual design, four

examples are discussed. The first addresses a set of panel design problems that
is based on structural and manufacturing design considerations. The second
example handles a vertical tail design problem, discussing the implications of
a change in material concept on the overall performance of the tailplane. The
third example handles a conceptual wing structural design problem, based
on high level mission requirements and aircraft concept. The fourth example
discusses the impact of using different fuselage material concepts on the
fuselage performance.
4.2.1 Simplified panel design
The first example elaborates on the guiding example, a panel conceptual

design problem (Schut, 2007). In first principle conceptual design a panel
design can be highly simplified to obtain an initial idea of the weight and
stiffness of a panel in response to a certain applied load. In the following an
overview is given of the main simplifications and the results of the obtained
model are presented.
The panel problem objective is reduced to weight minimisation, leaving

out for instance cost, or manufacturability. The design is constrained by
requirements on stability and strength. To enforce that the behaviour of the
panel is relatively easy to predict the panel structure is required to be stiff
enough to prevent initial buckling. Secondly, the material is not allowed to
be loaded beyond its ultimate load, represented by the maximum material
strength. Other constraints are not included, such as for instance fatigue. To
reduce the design freedom, the material, lay-up and panel concept are fixed.
This highly reduces the degrees of freedom. The remaining degrees of freedom
are: panel length; stiffener height; skin-web width (e.g. stiffener spacing);
and material lay-up for the skin and stiffener. The material concept is Toray
T700 CF. The lay-up concept has a fixed stacking order of [[±45]n,[0]m,[±45]
n
] with a continuously varying number of plies (equal to 2*n+m). The panel
concept is rectangular and blade stiffened. The test cases are reduced to an
52
Example simplifications
in-plane static test case. For the panel a range of test cases are defined that
span the expected applied loads. The test case is composed of a load in the x
and y direction in either compression or tension, and a shear load. The panel is
presented in figure 4-1. The optimisation problem is:
(7)
In formula 6, ‘W’ is weight, ‘c’ is constraint, ‘TH’ is the TsaiHill strength

criterion, and ‘f’ is the objective function. The other symbols can be found in
figure 4-1.
The representation of the stiffeners on the panels is simplified by placing

the stiffeners on the panel based on uniform stiffener spacing per panel. The
plates are composite materials, which are simplified by taking a fixed stacking
sequence and by allowing the number of layers to vary continuously (instead of
discretely, e.g. 1, 2, ...). To analyse the panels, the set of analytical formulae
is used that does not require a detailed model (e.g. a finite element model)
of the structure, but is based on the structural stiffness matrices. These
matrices are obtained by integrating the material properties by using classical
laminate theory (CLT). This is a common procedure in the structural analysis of
composite materials, and is described by, among others, Jones (1975). CLT is a
collection of assumptions, e.g. using simplified equations nullifying thickness
in respect to length and width of a plate, and presumes uniformity of the
material properties. The panel stiffness matrix is obtained by using a method
proposed by Collier (1994), which extends on CLT by addressing stiffeners as
‘smeared’ layers with stiffness properties only in stiffener direction. For a
more detailed description, the reader is referred to section 5.3.
The behaviour is simplified by dividing the behaviour in separate behaviour

types, see figure 4-2. The stability behaviour is for instance uncoupled into
global panel buckling local skin buckling local skin buckling local stiffener buckling
(compression) (compression) (shear) (compression)
figure 4-2: Separate panel stability behaviour types
53
stiffener (local) buckling, skin-web (local) buckling, and panel (global)

buckling. Next to that the load case is also decomposed into compression
and shear cases. For each combination of behaviour effect and load case a
different analytical formula is used to describe that relation (Kollár, 2003).
By using an interaction formula proposed by Rothwell (1999) the separate
effects are glued together. Whether the structure will buckle is determined by
relating the obtained initial buckling load with the applied load on the specific
structural element, see next section for more details on this translation.
A similar method is used for the strength evaluation of the material. The
load on a ply is decomposed in the principal material directions, and a shear
load. Per load case the material strength is determined. By using the Tsai-Hill
method these separate material strengths are integrated in a single material
strength (Jones, 1975). The used formulas are:
Strength:
(8)
Stability:
(9)
In formula 7, ‘σi’ is the stress, the ‘τ12’ is shear, and ‘Fi’ is the allowable stress
or shear. In formula 8, ‘Dij’ is an element of the stiffness matrix ‘D’, ‘ti’ the ply
thickness, ‘b’ is the stiffener spacing, ‘E’ tensile stiffness in direction of the
principal material axis, ‘I’ second moment of area, ‘L’ panel length, and ‘A’
area.
To give an indication of the capabilities of this simplified problem, a range

of panel designs are performed for different load cases. In these designs
the panel length is fixed, since otherwise the length would be minimised in
concurrence with the objective of minimise weight and the applied stability
constraint. The results are presented in figure 4-3. The upper graph shows
the change in variable values with increasing compression load intensity. The
weight value changes smoothly with increasing load indicating the robustness
of the search. The bottom graphs show the accompanying constraint values, in
which values close to zero indicate an active constraint. For a validation of the
simplified models see section 4.3.1.
54
figure 4-3: Panel designed for pure shear, for a range of load cases;
design variable values (top) and design constraint values (bottom)
55
ACPAM
REQUIREMENTS (Parametric Product Model)
(problem definition)
Model Model Model

Data Data Data
LOR
Data
PATRAN
(Structural
model)
ACPAM
(old values)
VARLOADS
(Structural dynamics)
SEARCH
(Converger)
1: converged? TWISST
(Structures)
no
1
yes Test
Data
Specs
Data
Script
(Objective and Constraint Values)
figure 4-4: Example vertical tail design and engineering engine
Observations
This example illustrates that feasilisation can be used to obtain a simplified

problem, by addressing requirements, design concept, and behaviour models.
In this case, this allows the designer to obtain a quick estimate on the design
space.
In the simplified problem, requirements are defined by objective function,

constraint functions, variable vector, and test load cases. The concept is
defined by parameters to support the definition of the variable vector. To
integrate different concepts the numbers of layers are defined as continuous
variables during the optimisation. The behaviour is determined by analytical
models per specific behaviour.
4.2.2 Conceptual vertical tail redesign
The second example discusses the redesign of a vertical tail (Cerulli, 2005).
The objective of the study is to investigate the weight effects of using a
different material in the tail of an existing long range passenger aircraft. After
the problem is introduced, the underlying design simplifications (and hence the
56
assumptions) are discussed. The example is concluded with the feasilisation

results. The author contributed to the example the conceptual sizing of tail
structure.
The problem addresses the sizing of the vertical tailplane of the tail of a
long range passenger aircraft. The sizing involves the scaling of the tail span
and the underlying structure. The investigation is focussed on the impact
of changing the material concept from metal to composites on the overall
performance of the vertical tail, aimed at finding possibilities for weight
reduction. The analysis involves a modelling tool, called ACPAM (Meijer, 2003),
a load analysis tool, called VARloads (Hofstee, 2003), a structural sizing tool,
called TWISST (Schut, 2005), a communication environment, called MATE
(Berends, 2005), and a simple converger application that stops the loop after a
number of cycles or if the total tail weight and the applied load are converged.
The process (Cerulli, 2005) starts with the preparation of an input file for
ACPAM according to the baseline aircraft measures. From ACPAM, the vertical
tailplane models are requested and exported into a PATRAN/NASTRAN
environment. A Guyan reduction of the tail structure is performed to obtain
a reduced stiffness model. The complete mass model of the tailplane is used
to calculate the lumped mass model. These models are used to update the
original aircraft model. Next the modes of the aircraft model are obtained
through a modal analysis in NASTRAN. These modes are combined with an
skin pxy = Fx/(2*width) +

My/(2*width*height)
py = Fy/[2* (width + height)]

Mz
width – Mx/(width*height)
My Fz
Fy Mx
Fx
spar height
rib
length pxz = My/(2*width*height)
pyz = Fz/(2*height) +
My/(2*width*height) py = Fx/[2* (width+height)] pcrush
- Mz/(width*height)
figure 4-5: Conceptual load translation estimation from

external to internal using only box dimensions
57
aerodynamic model of the aircraft (based on 2D panels). In VarLoads a yawing

manoeuvre is performed, determination the nodal loads of the tailplane. These
loads are translated to internal structural loads are then used by TWISST to
resize the structure. The weight of the tailplane is passed to the converger.
If the converger does not stop the process, the updated structure is provided
to ACPAM that updates the aircraft model and initiating the second loop. An
overview of the framework is illustrated in figure 4-4.
The simplification of the problem translates in a reduced set of objectives, test

cases, and constraints. In the tail problem the objective was reduced to weight
minimisation, leaving out for instance cost, or aerodynamic performance.
To prevent large deteriorations in aerodynamic performance, the model shape

is constrained, which is allowed to change 15% in spanwise direction. This
highly reduces the degrees of freedom; the remaining degrees of freedom are
the result of the individual panel designs, which vary in stiffener dimensions,
stiffener, spacing, and material lay-up.
The behaviour is reduced to the response to a composite static test case, build
from a dynamic test case. The static test case is composed of the maximum
occurring loads in the dynamic test case, a checked manoeuvre. The main
simplification is that the dynamic test case is assumed to be the driving
load case for the tail design. In a second simplification the dynamic load is
translated to a set of static loads defined by the maximum occurring loads in
the dynamic load case. The static load magnitude is the highest occurring load.
Thirdly, the load is translated from the nodes to the internal structure based
on the basic geometry of the structure only, disregarding other structural and
material properties (see figure 4-5). The unavailability of the stiffness at the
initial design step requires this conceptual approach.
crush
upperskin
lowerskin
crush
Box - Front view
figure 4-6: Rib crushing load estimation based on the

deformations of the upper and lower skin panels
58
max max
min
min
figure 4-7: Tail sizing weight result
To further simplify the behaviour, fatigue is also disregarded. The behaviour

itself is constrained by strength and stability requirements, based on
respectively the maximum allowable stresses in the material, and the initial
buckling of structural components.
The model simplification of the model focuses on reducing the degrees of

freedom of the problem, as well as reducing the complexity of the analysis.
The model simplification associates both system and its environment.
The tail system model is simplified by addressing all panels as flat and
rectangular panels. Consequently, the tail is composed of a set of rectangular
boxes. The representation of the stiffeners on the panels is simplified by
placing the stiffeners on the panel based on one stiffener spacing per panel.
The plates are made from composite materials, simplified by taking a fixed
stacking sequence, and by allowing the number of layers to vary continuously
(instead of discretely, e.g. 1, 2, etc.).
The environment model of the tail is simplified by fixing the rest of the aircraft
model. Secondly, the aerodynamic behaviour is determined in a simplified
aerodynamic environment. By using the Doublet Lattice method a simplified
model is obtained assuming, for instance, the tail is an infinitely thin sheet.
The environment model of the panel is simplified to in-plane load conditions at
the edge of the panel, uncoupling the panel analysis. This simplification is also
used for the other structural components.
Since the simplifications initially disregard interference between the

components, these effects must be included separately (if they are regarded
as important design criteria). In case of tail (or wing) design problems the
59
table 4-1: Overall average Calculation Times; averaged and based on

mixed computers with average speed of an Intel Pentium
IV 2.5 GHz processor or comparable
Process In loop Calculation time
per iteration
ACPAM No 120s
Patran - mesher Yes 180s
Nastran - stiffness condensation Yes 30s
Matlab - Mass condensation Yes 180s
Nastran - assembly Yes 60s
VarLoads Yes 420s
Twisst Yes 1620s
Framework - overhead Yes 240s
Total time 2730s
crushing of the ribs is such an interference effect that it is important to take

into account. The crushing load can be conceptually estimated based on the
deformation of the upper and lower skin (Rothwell, 1999), see figure 4-6.
Therefore, after the skin panels are sized, the deformation of these panels is
obtained and used to update the composite load case of the rib panels. The
ribs are then dimensioned based on that load case.
The behaviour is simplified by simplifying the description of the physical

relation between the tail and its environment in the defined test cases.
The analysis methods further simplify the model. For instance, in structural
design an analytical method is used to estimate the buckling based on only
geometrical dimensions and material properties of the panel. A more detailed
method would be by discretising the panel to a set of finite elements (instead
of one), and using the similarly called method (FEM). To determine the
aerodynamic behaviour of the tail model, the model is simplified to a set of
condensed masses and stiffnesses, and by using the doubled lattice method the
lifting surfaces are assumed to be infinitely thin.
The structural models are simplified to length and width dimensions, and
by a set of stiffness matrices (Jones, 1975). These matrices are constructed
based on assumptions implied by the classical laminate theory (CLT). Strength
is determined based on a composite approach. The load distribution within
the layers is simplified to be uniform across the thickness. The strength is
determined in the principal directions and then summed (using the Tsai-Hill
strength criterion) to obtain a single value for the layer strength (Jones, 1975).
60
The panel weight results of the tail sizing example are presented in figure 4-7.
The values are given in relative terms. The increase in weight from tip to root
is clearly visible, as was to be expected. However, the real benefits of the
simplifications are found not in prediction capability of the framework (which
should only be in range of the real values, and be sensitive to changes in the
design), but in the time performance of the framework. The simplifications
enable the designer to do more in the same time, because the method delivers
significant time savings. The tools in the architecture are run on a mixed
architecture (Linux and Windows) with an average processor power equal to a
Pentium IV 2.5 GHz. The complete process can be carried out automatically. In
table 4-1, the calculation time for each process step is depicted and the total
calculation time per configuration is calculated. On average, panel feasilisation
takes 10 seconds, which adds up to about 30 minutes for 171 panels. In total a
complete loop takes 45 minutes, with an extra 2 minutes for the initial loop for
the instantiation of the initial aircraft model with ACPAM.
Observations
The example is a typical application of feasilisation, reducing the real

complexity of the problem in order to obtain an estimation on the solutions.
The discussion illustrated simplifications used in different disciplines in the
conceptual design phase. The example also shows that these tools can be
integrated into a single environment that can be used to explore the impact of
design decisions, such as the use of different material in a vertical tailplane.
In this example the elements used in the previous example could be reused to
define the structural sizing part of the design problem. The application of the
previous example was used here as part of a larger design problem.
4.2.3 Fuselage panel concept trade-off study
The thrid example is a fuselage panel concept trade-off study (Baluch, 2008).
That aims to obtain the lightest structural concept subject to a dynamic load
analysis. The test case addresses a twin-jet aircraft encountering a discrete
gust load. The information of the flight condition is included in appendix B.2.
The previously discussed panel design routine, extended with a sandwich
concept, is used within this example. The author contributed to this example
the conceptual modelling and sizing of the fuselage structure.
The objective is to obtain minimum weight. Next to the panel design, the
lengths of the elementary barrel are used as design variables. However, to
evaluate the structure of the fuselage, major simplifications are made in
respect to the included behaviour and structural elements. To simplify the
61
behaviour, the global stability behaviour (buckling over multiple frames) of the
fuselage is not be included. The reason for this simplification is also based on
a lack of a proper simple method to size the fuselage frames, which made it
impossible in include them in the analysis and hence include global stability
behaviour. However, stability at aircraft level was included.
The loads are defined by a load analysis tool, called DARloads (Baluch, 2009).
DARloads is very similar to the previously discussed VarLoads, but uses a fully
flexible aircraft model instead. The loads are determined in nodes along
the length of the fuselage. By interpolation and translation the loads in the
centre of each elementary barrel is obtained. The earlier discussed panel
design example is reused by simplifying the circular shape of the barrel into a
dodekagram (a 12 sided shape). The load in the centre of the barrel is divided
over the twelve panels, based on geometry only (similar to the tail design
example). This is illustrated in figure 4-8.
This process is used to evaluate two panel concepts; a sandwich, and a foam-
filled hat-stiffener concept. In the current setting the foam-filled hat-stiffened
concept is much lighter then the sandwich concept, respectively 340 kg/m
and 450 kg/m. This could be expected, since the real advantages of using the
sandwich concept in fuselages is not taken into account, the increased stiffness
and thus reduction of the number of frames (Van Tooren, 1998).
To give an idea of the conceptual structure and the panel weights along the
length of the aft-fuselage the results for the foam filled hat-stiffened panel
are presented in figure 4-9. More details on the weight and the test cases are
included in appendix B.2. For further details the reader is referred to Baluch
(2008).
R
p0
figure 4-8: Translation of fuselage geometry and loads

to section and panel dimensions and loads
62
figure 4-9: Fuselage weight results for a foam-filled hat-stiffened panel concept
Observations
The simplifications used in this example illustrated the use of effective design
concept modelling. The concept was modelled such that simple methods could
be used to estimate the dimensions of the fuselage skin.
This example shows that smart model simplification can support the reuse of
the existing methods, such as in this case the earlier discussed panel design
methods. The panel design problem was adapted to address a different design
concept, hat-stiffened instead of blade-stiffened. Therefore the variable
vector changed as well as constraint functions, which addressed different
behaviour methods.
4.2.4 Conceptual wing design
The fourth example addresses the conceptual design of a wing based on

regulatory requirements, aircraft mission, and a top level aircraft concept
(Schut, 2008), e.g. wing planform dimensions. The wing is part of a small
business jet, subject to the requirements specified in EASA CS-23. The previous
two examples are used again within this example. The top-level aircraft data is
presented in appendix B.1.
The objective of the design is to obtain an initial estimate of the structural

dimensions. The objective of the design is formalised to be a minimum weight
design, based on structural and aerodynamic design considerations. To obtain a
makeable solution, manufacturing considerations must be taken into account.
These are accounted for by including a human designer in an outer design loop,
around the automated inner design loop. In design feasilisation often not all
relevant knowledge is formalised and a composite approach, e.g. including
a human in the automated design process, is critical to obtain a realistic
63
addresses structural
and aerodynamic
definition design considerations
process
search search
process process
evaluation
process
addresses
manufacturing design
considerations
figure 4-10: Wing search process partly automated, partly

performed by expert to evaluate other considerations
solution. This process is illustrated in figure 4-10.
The wing concept is a double spar wing, with a variable number of ribs. The
distance between the ribs is a design variable, defined as the distance from
root to the tip. The distance between the final two ribs at the tip is defined
by the obtained rib distances and the predefined wing span. The wing sweep
and dihedral are also predefined. Based on the aircraft mission, defined in the
V-N diagram, four driving load cases are selected (see figure 4-11). All loads
are limit loads unless otherwise specified. The first condition (1) having the
highest positive load factor, defines the critical test cases for the wing ribs
and wing upper skin. The second condition (2) with the highest negative load
factor drives the design of the wing lower skin. The maximum angle of attack
at Vs-n, at stall speed (4), defines the critical load case of the front spar and
the maximum drag at dive speed (3) determines the sizing of the rear spar.
This direct linking between load case and structural element is a good example
of how design experience can be directly applied to reduce the number of test
cases, and thus calculation time.
The loads are distributed along the wing by using methods suggested by Corke
(Corke, 2003), that are used to obtain both lift and drag distributions. The
spanwise lift is assumed to have an elliptical distribution. The spanwise drag
distribution of the wing influences the bending moment. The total drag is
obtained from the drag polar. The total drag is distributed along the wing. The
distribution is such that from the root to 80% of the half-span, the average
ultimate drag per span-length is 95% of the average ultimate drag per length.
From that point on up to the tip the spanwise drag distribution is 120% of
the average ultimate drag per length. This external load is translated into an
64
figure 4-11: Aircraft operating envelope (V-N diagram);

four points are taken as driving load cases
internal load using the same method described for the vertical tail example.
The design is constrained by strength and stability as discussed in the previous

two examples. Also the rib distances are geometrically constrained to a
minimum distance.
The manufacturing discipline was not included in the analysis due to a time
restriction on the application development. Therefore it was decided to
include these judgements based on experience rather then through analysis.
To support judgement, the design has been performed four times with varying
minimum rib pitch (see figure 4-12). In the performed design cases the effect
of the missing manufacturing consideration is clearly visible. In all cases, the
rib distance converged to the minimum allowed distance. This can be easily
explained by the influence of the length of the panel on the panel weight.
If the length increases, the required stiffness must increase to cope with
the buckling constraint (which scales with length). An increased stiffness
effectively implies more material, and thus more weight. The result of the
design problem for different minimum rib spacings is presented in figure
4-12. Based on these results the designer selected the 500 mm case as best
performing design case.
Observations
This example illustrated that simplification can result in a design problem
65
250
Lower Skin
Upper Skin
200 Ribs
Spars
Total Weight
150
Weight [kg]
100
50
0
250 300 350 400 450 500 550 600 650 700 750
Rib Pitch [mm]
figure 4-12: Wing weight results for a range of rib spacings
that does not model the real design problem sufficiently. To address this
problem the design problem can be adapted or the disregarded properties
are integrated by the engineer, as illustrated here. This illustrates the
importance of keeping the designer responsible for evaluation, which requires
understanding of the design problem. The designer plays a critical role in
filling up the gaps in the modelled design problem, such as the manufacturing
considerations in this case.
In this case the decision not to extend the design problem was driven by time
constraints. The adaption of the design problem was regarded to be too time
intensive in respect to the manual inclusion by the engineer during design
evaluation.
4.3 Integrating levels of simplification
In the end a design has to meet the complete set of requirements, stated
in the real world. As said, simplifications are used by a designer in order to
be able to engineer the problem. Iteratively the simplifications are lifted,
becoming closer to reality. Therefore, the design process addresses multiple
simplification levels. Even in the conceptual design phase designers use
multiple simplification levels, for instance to validate simpler models or for
inclusion of the required behaviour.
66
Integrating levels of simplification
4.3.1 Different behaviour analysis inside the design loop
In design, analyses are often used side by side with different levels of
simplification. For example; if a panel model is at the edge of applicability
of the simple analysis a more detailed analysis is required to better estimate
the response of the panel to the specific test case. Another application of this
double analysis is to validate the simpler analysis, thereby double checking the
assumptions on which the simple model was selected. This is illustrated here
by an example addressing the determination of the structural behaviour of a
panel based on a compression or shear load case (see figure 4-13). The panel
example, based on a blade-stiffened concept, is explained in mode detail in
section 6.1.1.
The panel is constrained by stability and strength, which in principle are

determined by using conceptual analysis methods, based on analytical
formulae. The criterion to ensure stability is initial buckling, which is
REQUIREMENTS panel model

(problem definition) (parametric model)
Model Model Model

Data Data Data
LOR
Data
DoE
(analytical method)
(analytical method)
(initial variable values)

(FE method)
strength
stability
stability
SEARCH
(Optimiser)
1: optimum?
no
1 Test Test Test
yes Data Data Data
Specs
Data performance
(Tsai-Hill, initial buckling)
figure 4-13: process of analytical/FE analysis methods
67
evaluated for the blade-stiffener, skin-web, and the panel. The used analytical
formulae hold for infinitely long rectangular plates, and disregard interference
between the individual elements. Therefore an engineer will expect that the
estimation is inaccurate and when the panel length shortens, this estimation
error will increase. To evaluate the quality of the estimation a finite element
(FE) method is integrated. But an FE model is also based on assumptions that
can invalidate the solution. However, FE methods are regarded to provide
better estimation capabilities then analytical models. A pre- and postprocessor
are built to translate the analytical model into a FE model (based on a text
file). The FE model is evaluated by a FE package, called UNA (Rudic, 2002). The
output of the package is post processed to provide the initial buckling load. By
a switch in the process the designer can select to use the analytical method,
the FE method, or both methods (using the most conservative value).
Two FE models are used that are depicted in figure 4-14. One model to
determine the initial buckling load of the blade-stiffener in compression (on
the left) and one to determine the initial buckling load of the plate-webs
under shear (on the right). The number of nodes is selected such that the
buckling behaviour of the element can be represented, but the model is as
small as possible. This is specific for the model and must be determined and
validated before it can be integrated in an automated process. The FE method
provides buckling by node deviation values. Since the buckling behaviour is
known, a designer knows which nodes to monitor. The initial buckling value of
the element is obtained by taking the lowest occurring buckling value of the
monitored nodes. The same logic is used in the automated process.
The performance of both methods in the prediction of the local stiffener

buckling is presented in figure 4-15a. The implication of changing the model
shape on the prediction is included for a change in the number of cross-plies,
stiffener height, and stiffener length. Both methods deliver almost the same
length 3 * stiffener spacing

height
th
ng
le
height
px
pxy
figure 4-14: FE models: stiffener (left), panel (right)
68
(a) (b)
figure 4-15: Performance of buckling prediction of analytical versus finite element

method, variable on x-axis is defined in header; (a) the difference for compression
load case; (b) difference for shear load case; design variable vector, X = [skin-
web-width, stiffener-height, number-layers-0deg-skin, number-crosslayers-45deg-
skin, number-layers-0deg-stiffener, number-crosslayers-45deg-stiffener, length]
69
prediction of the initial buckling load. The behaviour seems independent of a

change in length, although the FE method decreases the initial buckling load in
case of very short panels. However the differences are still minor regarding the
scale of the y-axis (also in respect to the other two graphs).
The same process is performed for both methods in the prediction of the
initial buckling of the skin-web under a shear load. These results are presented
in figure 4-15b. Here the differences in prediction of both methods are
significant. The influence of changing the number of cross-plies, skin-web
width, and panel length is investigated. With increasing number of cross-
plies both methods predict similar values. Although in small thicknesses
the analytical prediction is probably far too optimistic, predicting up to 3.5
times the initial buckling load as the FE method. Also in this case a change in
skin-web width seems not to really influence the initial buckling load value.
The difference in prediction value of both methods is caused by the fixed
number of cross-plies (in this case three). The most illustrative example is
the impact of the length of the panel on the predictive capabilities of both
methods. Since the analytical method is based on the assumption of infinitely
long plates, the length has no influence on the prediction. On the other
hand, the FE method clearly changes with increasing length. Concluding, the
prediction capability of the used analytical methods can be used to obtain an
indication of the initial buckling load. Although if a realistic value is required
in shear (and not indicative), the predicted value needs to be multiplied with
a correction factor, taking into the account the length and thickness of the
skin-web.
Observations
The example shows that methods with different problem simplifications can
be used together. For instance, the simpler methods can be used to make a
global scan of the design space, using the more elaborate methods in specific
cases that demand extra accuracy or across the design space to validate the
predictive capability of the simple method.
The example shows that the behaviour models can be replaced in order to
change the estimation method, improving the estimation quality and increasing
calculation time. The engineer changes these models to obtain the best
deliberation between estimation quality and calculation time.
4.3.2 Different analysis methods outside the design loop
A typical initiation problem is that assumptions have to be made regarding

the decomposition of a system test case to subsystems test cases. The load
70
case decompositions of the tail (section 6.1.2) and of the fuselage (section
6.1.4) are two examples in which these assumptions were made in order to
start of the design process. For a designer it is useful to know whether these
assumptions are valid. In order to validate the process the design solution
is often captured in a less simplified model together with the original test
case. This process is illustrated below for the previously discussed wing design
example.
As the validation of the wing load and the designed structure are combined in
a finite element (FE) model, the goal is to check whether the load intensities
obtained with the FE method concur with the load intensities estimated based
on the geometric shape. Since the material properties are not known at the
start of the design process, the FE model is build from equivalent sandwich
panels that mimic the stiffness of both skin and stiffener. The equivalent panel
is based on identical membrane stiffness and bending stiffness. The test is
performed for the load case driving the upper skin (case 1). The FE model is
analysed using NASTAN. The load intensities are taken halfway the wingbox
(chord wise) and are presented in the spanwise direction from root to tip.
The NASTRAN load intensities are the average stress in the two facings of the
sandwich in the cross section. The result is presented in figure 4-16.
figure 4-16: Conceptual load intensity estimation (WISST) validated by

running the design solution through a finite element analysis (NASTRAN)
71
In the figure, the step near the root of the wing is the consequence of the load
condensation and the boundary conditions of the finite element model. Part
of the load is condensed to the root rib of the wing, which is ‘fixed’ by the
boundary conditions and is therefore disregarded in the FE method. The results
from the FE method compare well with the estimated value and considering
the conceptual nature of the design, the error in the estimated load intensity
(~7.5%) is acceptable. Also the total deformation of the wing at the tip as a
result of the ultimate load case of ~72 cm is considered reasonable.
Observations
The example shows that different simplifications can also be used in

succession in order to validate initial assumptions, such as in this case the
load distribution in along the wing. This illustrates that estimations can be
validated by checking is the solution and problem match in a different tool.
The validation can also include specific tools that can invalidate the solution,
requiring the engineer to change the simplifications.
4.4 Observations and conclusions
The discussed examples show how simplification is used in a conceptual design

problem, addressing requirements, concepts, and behaviour models. The panel
example illustrates that such a simplified problem can be used to obtain an
overview of the design space. The tail example illustrates that the simplified
problem can be combined with more detailed discipline tools within structural
redesign problem, reducing the influence on other properties as much as
possible. The examples also indicate the importance of the designer in the
application of these conceptual methods. This is particularly illustrated by
the wing example, showing the importance of keeping the designer included
in the design loop to address excluded design considerations. The fuselage
example illustrates the reuse possibilities available through the simplification,
making the same models applicable in different design problems. The last two
examples illustrate the use of different simplifications to validate behaviour
analysis results or conceptual estimations. The examples show how the
detailed models can be used effectively to support the use of the simpler
conceptual models.
The two main observations in relation to the possible automation involve

that simplification can be formalised as an optimisation problem. The main
repetitive activities involve the set-up and ‘trimming’ of the design problem to
obtain the desired results. The definition of new design problems is eased by
allowed effective reuse of elements from previous design problems.
72
Observations and conclusions
4.4.1 Conclusions
Although these examples all address different problems, major parts can be
reused between the applications. This suggests that although designers have to
tailor every specific problem, they still are able to reuse much of the available
knowledge, e.g. requirements, concepts, and behaviour models. To support the
designer in defining the specific design problem the requirements, concepts,
and behaviour models need to be addressed as separate building blocks as they
are changed individually.
The contributions of this chapter are the illustrated examples and prototype
applications of a formalised simplification approach. This work focused on
the formalisation and application of decomposition in respect to the DEE,
addressed in the following chapter. To extend the application of simplification
presented in this chapter, the reader is recommended to formalise the
multi-level system simplification process touched upon in section 4.3. The
formalisation is expected to require discrete search methods to capture and
control the discrete reductions in simplification.
The following chapter addresses the application decomposition methods within

the feasilisation approach. The chapter addresses the application of the multi-
level system design process. Chapter six integrates the conclusions from this
chapter and the following to integrate the routine and repetitive activities
addressed in these chapters.
73
Chapter 4: 4
74
Introduction
Chapter 5: System decomposition

5.1 Introduction
The objective of this chapter is to illustrate the use of decomposition to

address the conceptual design problem. The second objective is to bring to
the surface routine and repetitive activities involved in system decomposition.
Such that the process automation building blocks can be identified that can be
used to support automation by engineering software.
In chapter three, decomposition is presented as one of the methods of the

feasilisation approach, which an engineer uses to address the conceptual
design problem. There was explained that system decomposition can be
either an object or aspect decomposition. In the implementation the focus
is on object decomposition from a structural viewpoint. Key questions to be
answered:
»» What are discipline decompositions?

»» How is a concept defined in a decomposed structure?
»» Which repetitive and routine activities occur?
»» What are possible building blocks?
The chapter is composed of two parts. The first part (section 5.2) discusses
example system decompositions from different aspect perspectives. The
second part (sections 5.3 through 5.6) elaborates on the W-diagram and multi-
level design process introduced in chapter three. The chapter is concluded
with an overview of the main observations and conclusions.
5.2 Example decompositions
5.2.1 Flexible aerodynamic concept model definition
The first example addresses the decomposition of an aircraft from the

viewpoint of controllability and aerodynamics (Grotenhuis, 2007). The
application addresses the specific model generation based on a generic model,
using the multi-model generator (Brouwers, 2007) discussed in chapter two.
The generic aircraft model is defined in ACPAM and is translated into a specific
aerodynamic panel model. The controllability performance is determined by
COALA, a specially developed tool. To determine that performance, the tool
adapts control surface deflections in the specific panel model and evaluates
75
REQUIREMENTS ACPAM
(problem definition) (parametric movable model)
COALA
(parametric movable model)
LOR
Data Model
Data Model
Data
COALA
(controllability analysis)
ACPAM (aircraft model)
(aerodynamic analysis)
(aircraft model)
(stability analysis)
COALA
VSAERO
COALA
COALA
SEARCH (converger)
(single step) 1: converged?
1: converged?
no
no 1
1 yes
yes
Test
Data Test
Data
Specs COALA
Data (stability definition)
COALA
(stability definition)
figure 5-1: DEE process for controllability
the aerodynamic performance. This performance is obtained by using an

off-the-shelf aerodynamic analysis tool, called VSAERO. This process is
performed automatically and is illustrated in figure 5-1.
To optimally reuse the controllability capability a wide range of models

should be accepted by the COALA tool. This is achieved through efficient
decomposition and parameterisation. The main objective of the decomposition
was to obtain a generic language to describe the aircraft such that an
aerodynamic panel model can be created whatever the type of aircraft model.
The decomposition results in a product tree, illustrated in figure 5-2. The

decomposition makes use of five system levels, called; aircraft, top-level-
primitive, high-level-primitive, medium-level-primitive, and low-level-
primitive. These systems refer respectively to; assembly, component, patch,
section, and point. The levels are used to distinguish between different
abstractions in functions and information used to determine the controllability.
Here the functions are at aircraft level test case definition, at top level the
wake modelling and lifting surface parameterisation, at high level the control
modelling and deflection, and at the medium and low levels respectively the
span-wise and chord-wise interpolation (see figure 5-2). The same is done for
information, which entails for instance controllability behaviour at aircraft
level.
76
Example decompositions
figure 5-2: [multi-level definition of COALA]
To flexibly communicate the information at every level a text based

communication format was developed. To capture the multilevel definition
XML was used. The information addresses for instance geometry definition of
model, using [x,y,z] point definitions at the low-level-primitive. However, in
order to capture all design relevant information, a generic information format
is used applied for all primitive levels. Per level, information is divided into
properties, design space, test cases, criteria, method, behaviour, parent level,
and child levels. Properties define the intrinsic information of the element,
e.g. geometry. The design space contains the design variable definition, which
are a subset of the parameters with per parameter an upper and lower bound.
The test cases consist of environmental information, e.g. Mach number. The
method describes the method to be used for analysis, such as ‘LPF-solver’
(e.g. linear potential flow). The behaviour includes the behaviour parameters,
e.g. aerodynamic force due to a control deflection. Finally, the criteria are
used to grade the behaviour resulting in a certain performance value, e.g.
controllability.
This generic format makes it possible to on the one hand generate very
different aerodynamic models. The decomposition is tested for different
concepts, e.g. V-tail, H-tail, and T-tail, which are automatically translated to
an input model for VSAero. The decomposition is used to structure the generic
interface and the translation tool. The separation of information at different
77
levels allows the designer to flexibly change subsystem configurations, while

maintaining the system configuration. For more information see Grotenhuis
(2007).
Observations
This example illustrates the decomposition from the viewpoint of the

aerodynamic discipline. The hierarchic structure shows that the information
can be partitioned into generic groups, independent of the specific system.
The repetitive tasks involved the definition of the model. The decomposed
structured allowed for a flexible definition that could be used for a range of
aircraft types, by reusing the primitives defined at each level.
5.2.2 Elevator decomposition
The second example addresses a design space exploration for an elevator (Van
Dijk, 2008 & Berentsen, 2009). The decomposition was driven by structural
design considerations. The objective was to obtain an overview of the solution
space considered for the design of an elevator by an aircraft component
manufacturer.
The approach follows the “function - principle of solution - technical solution

- structural concept” decomposition analysis described in chapter three. In
order to properly address the elevator solution space the analysis is started
one abstraction level higher, at horizontal tail level. From design experience
it is known that the horizontal tail is a solution concept that embodies the
controllability and stability functions. Also is required that a solution maintains
structural integrity. These are the three main functions that guide the
decomposition. The decomposition architecture is illustrated in figure 5-3.
The principle solutions of a horizontal tail are reduced to the one including
an elevator, the separated elevator-stabiliser principle of solution. Other
principles of solution are, for instance, an all-moving tail or a flexible tail. The
technical solution addresses the number of elevator sections in the stabiliser.
Consequently, the structural concept is always composed of a stabiliser,
elevator(s), and connection elements. The connection elements are hinges and
actuators.
By cascading the top-level functions, the elevator functions are identified. The
functions are; allow control, maintain shape and maintain structural integrity.
The defined elevator functions can be implemented based on three principles
of solution; multi-spar, multi-rib, or unstiffened shell. The multi-rib is taken
as guiding example. The technical solution defines a specific number of ribs
78
stiffening the skin. The structural concept is translates the concept to skin
panels, rib panels, spar panels, and a set of connection elements that connect
the various panels. These connection elements can be flanges and glue or
rivets. Following the same method, the structural solution of both the multi-
spar and stiffened shell is implemented by panel and connection element
systems.
Movable
Slice Multiple box structure
single spar dual spar
Box Solid structure Discrete stiffened structure
Extra
No extra
Full depth internal ribs
ribs in box
in box
Constant Discrete stiffened

Panel stiffened panel panel
Unstiffened panel
Stringer
Sandwich stiffened
Plate Single layer Composite
1 layer N layers
Orthotropic
Layer
Uni-
crossply
directional
Material Honeycomb Solid core Isotropic Thermoset Thermoplast
figure 5-3: Decomposition of moveable system
79
The panel functions are to transport loads, and maintain structural integrity.
For the panel three principles of solution were identified; continuously
stiffened, discrete stiffened, and unstiffened. The unstiffened technical
solution is always a thin panel and the structural concept is a plate. The
continuously stiffened technical solution is thick panel, such as a sandwich
panel. The structural concept is composed of a core, skin plates, and a
connection element, e.g. glue. The discrete stiffened panel has multiple
technical solutions, based on the number of stiffeners that are used. The
structural concept features a skin plate, stiffener elements, and connection
elements, such as rivets.
The stiffener functions are; to provide stiffness, and to transport loads.

The stiffener principles of solution are; open section, and closed section.
The open section stiffener has multiple technical solutions, depending on
the number of sections, familiar types are; blade (single section), L (two
sections) and Z (three sections). A structural concept is composed of these
sections, conveniently considered to be thin plates, and connection elements.
The closed section stiffener has comparable principles of solution and the
structural solutions are based on the same components.
The core functions are similar to a stiffener, although the main function is
to provide stiffness in depth direction, to maintain the distance between
the faces. The principles of solution are; continuously of discrete stiffened.
Effectively, these boil down to respectively a foam type of core or a
honeycomb type of core.
The plate functions are (mainly); to transport loads, and maintain integrity.
The plate principles of solution are twofold; integral or composite. In contrast
to the integral principle of solution, the composite solution has multiple
technical solutions, based on the number of layers that are considered; two,
three, etc.. The structural solution of the integral technical solution is a layer
component. The structural solution of the composite is composed of multiple
layers and layer connecting elements (e.g. glue).
The layer functions are; to maintain integrity, and to transport loads. The
layer has two principles of solution; integral or composite. The integral
refers to a single structure used to build the layer. The composite principle
of solution features multiple material structures, such as the fibre reinforced
matrix technical solution. Multiple technical solutions are possible based on
the number and direction of fibres, a weave of fibres in two directions is for
instance a technical solution. The composite structural concept features fibre
and matrix material. To define a composite material, these separate elements
are integrated into a single surrogate material.
80
The material functions are; to transport load, and maintain integrity.

The material has three principles of solution; isotropic, orthotropic, and
anisotropic. The technical solutions are plural, spanning the domain of known
materials.
Observations
This example illustrates the use of the formalised method for concept
definition, based on; function, principle of solution, technical concept, and
conceptual structure. The example also shows that a decomposition definition
is relatively extensive in order to include all design options.
5.2.3 Decomposed wing structural sizing
The final example (Schut, 2008a) addresses a wing composition based on

structural design considerations. The wing is part of a business jet, subject to
airworthiness regulations defined in part 23 (CS23). The design objective is to
obtain minimum wing weight. To simplify the problem, the design concept is
fixed, yielding a sizing problem.
To flexibly define a wing concept, the used decomposition is driven by

structural abstractions and its design options. The wing is decomposed in a
set of trunks (with specific sweep and taper, among others). The trunks are
composed of a set of slices. Structurally, the slices decomposition is used to
define rib locations. On the other hand, aerodynamically, the slices are used
to define control surfaces. Obviously, the discipline decomposition definitions
are tightly coupled, but are different in lower system level abstractions. In the
structural decomposition, the slices are composed of boxes, defining the spar
locations. In this particular example, the wing consists of a single trunk. The
aircraft wing
wing trunk
trunk
trunk slice
...
slice
slice box
box
box panel
...
panel
panel plate
plate layer
...
layer
layer material
figure 5-4: Wing structural decomposition
81
table 5-1: Decomposition of a panel on structural and manufacturing considerations

concept model test performance
wing span weight airloads weight
trunk taper - - -
slice rib-spacing, - - -
double-spar
box length, width, weight load weight state
height
panel hat-stiffener, weight, stiffness load intensity, stability state
length allowable
stability load
plate width, length, weight, stiffness load intensity, stability state
layer stacking allowable
stability load
layer thickness, weight, stiffness load intensity -
orientation
material type density, allowable and strength state
engineering applied stress
constants
slice consists of three boxes. Only the central box is used, and the leading and
trailing boxes are excluded for simplicity. Consequently, the wing and trunk,
and slice and box are one and the same system. The boxes are decomposed
into panels, commonly specialised to skin, spar, and rib panels. A panel consists
of a skin and stiffener plate, which may have a number of layers composed of
a material. The decomposition is illustrated in figure 5-4.
The sizing is performed such that from root to tip the boxes are sized for
optimal rib spacing to obtain minimum weight, while taking manufacturing
considerations into account. Manufacturing performance is evaluated outside
the loop, and was included in order to obtain realistic rib spacings. Otherwise
the rib-spacing will be minimised such that the skin weight, driven by buckling,
is in balance with number of rib panels. This would result in unrealistically
short rib spacings. See the previous chapter for more details.
The multilevel sizing process is schematically represented in table 5-1. The

design knowledge is divided over and defined per the system level. Per system
abstraction level the design knowledge is separated into concept, model, test,
and performance knowledge, as was described in chapter 3 in the formalised
search process. The wing sizing process is translated into a multi-panel sizing
process. This enables an effective reuse of the panel design knowledge, for
82
all skin, rib, and spar panels. A comparable panel design problem (including
manufacturing considerations) is discussed in more detail in sections 5.3
through 5.6.
Observations
This example illustrates that at higher abstraction levels the structural

decomposition matches the aerodynamic decomposition, e.g. trunk and
slice. At lower levels a discipline specific decomposition is used to include all
relevant design options, e.g. stiffener and stacking types in case of structures.
The example shows that the formalised process introduced in chapter three
can be used to decompose the process into separate steps. This W-diagram is
discussed in more detail in the following sections.
5.2.4 Fuselage structural decomposition
The second example involves the fuselage design problem introduced

in the section 4.2.3 (Baluch, 2008). The fuselage design problem was a
material trade-off, and included structural and structural dynamic design
considerations. In the design problem the concept is fixed, obtaining again a
sizing problem.
The decomposed problem is illustrated figure 5-5. The problem composed of

the fuselage, fuselage-section, and panel abstractions. The relation between
these levels is illustrated in figure 4-8.
The decomposition used in this example is comparable to the one described

in the previous example. In this case, the system level is a fuselage system
instead of a wing system, the trunk level is replaced with fuselage-section
(e.g. aft fuselage), and slice with elementary barrel, which is separated by
aircraft barrel
...
barrel
barrel section
section
section panel
...
panel
panel plate
plate layer
...
layer
layer material
figure 5-5: Decomposed fuselage design problem
83
frames instead of ribs. The lower level system decomposition remains intact,
meaning that much of the design knowledge used in the wing design can be
reused in the fuselage design problem.
Observations
The example illustrates the decomposition based on a structural point of view.

The example shows the benefits of problem decomposition for reuse of lower
level systems. In this example, the panel design problem presented in the
previous chapter could be completely reused for the fuselage design.
5.3 Decomposed concept definition
This section addresses the first step of the W-diagram (see figures 3-9 & 3-13),
the definition of a panel concept. The definition is from top-level to bottom-
level. Per system level design options are identified. All systems levels are fully
separated, as well as design options within a system. The design knowledge,
such as functions, is coupled to the specific systems and design options. In
the definition of a specific concept the concept knowledge can be assembled
automatically.
In the guiding example (Schut, 2008b) the system levels are; panel, plate,
layup, layer, and material. Per system the design options are defined, and
possibly also the subsystem design options (to reduce the number of concepts).
In total ten different design concepts are obtained, by combining the various
design options. The design options are illustrated in figure 5-6.
The decomposition is based on structural and manufacturing design

considerations. In parallel to the structural design options, the manufacturing
design options are discussed. These are the required to eventually determine
the system cost (Van der Laan, 2007).
5.3.1 Panel system
The panel’s functions were; take-up and transport loads, maintaining structural
integrity. In order to maintain integrity, a derived function is to maintain
stability under these loads.
The panel was simplified to a flat rectangular panel. Consequently, the panel
can be modelled with two parameters, length and width, both fixed at a
higher level. Here, a panel is decomposed into a set of plates. The number of
plates, the boundary conditions, and relations depend on the stiffening type.
For a panel-type product, three general stiffening options can be identified;
84
Decomposed concept definition
Panel function
1
OR
Lay-up function
Has principle of solution Has principle of solution
Discrete Unstiffened
Composite
stiffened Panel Panel
Has technical solution Has technical solution
OR
discrete-
unstiffened
stiffened
Has technical solution
Has conceptual structure

Stacking A: Stacking B:
[±450,00,±450] [±450,00,00,±450]
unstiffened
stiffener skin
skin
Has conceptual structure Has conceptual structure
Has function Has function Has function

o
Layers Layer 45
layers layers
Plate function Plate function Plate function
Has function
Has principle of solution Has principle of solution Has principle of solution

Layer function
stiffener skin skin

Has principle solution
OR
Orthotropic
unstiffened-
Hat-stiffener L-stiffener stiffened-skin Cross ply
skin
Has conceptual structure Has conceptual structure Has conceptual structure Has conceptual structure Has conceptual structure
Bidirectional
plate plate plate plate carbon
fabric
Has function
Lay-up function
figure 5-6: Decomposition of a panel
un-stiffened, discrete stiffened, and continuous stiffened panels (not

illustrated in figure 5-6).
The un-stiffened panel consists of a single subsystem, a plate. Discrete

stiffened panels have two sub-system types, a skin-web and a stiffener. Both
can be modelled using the plate system. Multiple stiffener topologies are
possible, e.g. blade-stiffened, I-stiffened, L-stiffened, hat-stiffened, etc.
Taking the hat-stiffened panel as example, a hat-stiffener consists of a set
of plate systems. All plates have the same properties, which are determined
based on the most critical section, tested for stability. The stiffener top
is taken as most critical. The boundary conditions of the skin web plate
85
depend on the stiffener concept. Since the hat-stiffener constrains the skin
web buckling, the boundary conditions of the skin web at the long sides are
assumed clamped. To be conservative the width of the skin web is defined as
the distance between the centres of two stiffeners. The sandwich panel has
three components, face, core, and face. All are plates. These components are
all layer-type products; respectively a thin layer (a 2D layer-type), and a thick
layer (a 3D layer-type).
In this example, a hat-stiffened panel concept is used. In the requirements is

assumed that the load intensity in the panel is constant through the width of
the panel. Consequently, the panel can be decomposed into a single stiffener
section and a skin section. For simplicity the flanges are fixed to 20 mm and
the angle is fixed to 45 degrees with the horizontal y-axis measured in the
yz-plane.
The manufacturing design options are simplified to only the bonding design
option, in case the panel is a stiffened panel. This means that the plates are
required to be finished products that only need assembly to obtain the final
product.
5.3.2 Plate system
A plate’s functions were; take up loads, and maintain structural integrity. To

maintain integrity, a derived functional constraint is to maintain stability under
these loads.
In this example, the plate topology depends on the plate type, either skin or a
stiffener type. For instance, a skin type is defined by two parameters, width,
and length. Since length depends on the panel parent system, this leaves plate
width as only variable parameter (at this level). Another example, an L-type
stiffener plate is defined by three parameters, height of the stiffener blade,
width of the flange, and length, which reduces to two with the panel length
defined. Other stiffener types are hat, Z, and blade, among others.
The plate can have different layups, e.g. the blade of the L-stiffener can have
a different layup as the flange. Per different element in the plate a layup
subsystem should be defined.
The manufacturing design option is simplified to hand-layup. This requires

the layups to be a kind of pre-preg which can be formed to the required plate
shape using hand-layup.
86
Decomposed concept definition
5.3.3 Layup system
A layup’s functions were; take up loads, and maintain structural integrity. In

this example the latter one is excluded and could be implemented by taking
delamination considerations into account.
In the example, layer topology is defined by three parameters, number of

layers, width, and length. Since length depends on the panel parent system,
this leaves two variable parameters. To reduce the number of concepts
commonly the lay-up concept defines also the layer and material design
options, e.g. [+45,-45,0]S . In traditional metal structures, a separate lay-up
system level makes no sense, since no extra design options are involved.
The manufacturing option is that the layup should be a pre-preg. No other

manufacturing design options are included.
5.3.4 Layer system
A layer functions were; take up loads, and maintain structural integrity. In the
CLT case this is simplified to in-plane loads. The function is tested using load
or load intensity (load per width) case. The structural integrity function is
excluded in this example.
The layer concept is defined by thickness, and principle material angle. Using
these two parameters an infinite number of layer types are possible. However,
thickness is commonly driven by manufacturing options, and material principle
angle is often restricted to set of discrete angles, e.g. 0o, ±45o and 90o. The
layer is composed of a material.
The manufacturing design option is a fixed standard layer thickness.
5.3.5 Material system
The basic material functions were; take up stress, and maintain structural
integrity. To test the first function, test cases are defined in either stresses or
strains. The function maintain structural integrity is validated using a strength
criterion, e.g. Tsai-Hill or Tsai-Wu (Jones, 1975).
The material concepts are; isotropic or composite. In principle the composite

material, made of fibres and matrix, could be defined based on integration
of the separate material properties. In this example, the commonly used test
derived (composite) material properties (based on β-values) were taken as
material properties, which were assumed to be constant.
87
The manufacturing design option is the material, a bi-directional carbon

fabric. Now, all variables and bounds are known. These variables can be used
by an optimisation algorithm to obtain the best feasible set.
5.4 Model synthesis
This section addresses the second step of the W-diagram, the definition of a
panel model. The definition is from bottom-level to top-level. The model has
different levels of abstraction. To optimise a model at a certain system level,
the model should contain only the information relevant for the test process.
Ideally, a system model is synthesised from its subsystems such that only this
information is preserved. A similar method, used specifically in finite element
modelling, is called substructuring.
The method presented here is based on an integration of different analytical

methods, found in literature. The example is based on an integration of
structural properties that can be used to synthesise a structural model
from material system level up to box system level. Using these methods per
abstraction level both a lower fidelity and a reduced set of parameters in
contrast with the more common finite element analysis can be obtained. The
synthesis is discussed in three steps. First, material through plate level is
discussed for completeness, shortly elaborating on common classical laminate
theory (CLT) methods (Jones, 1975). Secondly, panel level is discussed,
introducing an approach of Collier (1994) that extends on CLT. Thirdly, box
level is discussed, addressing a method that extends the elementary beam
theory or EBT (Kollár, 2003).
In parallel to the structural stiffness system models, the mass (e.g. weight),
and cost models are discussed. The cost is determined using a method
described by Van der Laan (2007).
CLT is used to obtain an integrated model of material properties. For simple

structural purposes the material stiffness matrix is used as system model. See
Jones (1975) for the definition of this matrix. The stiffness matrix is used in
Hooke’s Law to relate strains to stresses. The relation is presented in equation
9.
ߪ௫ ܵଵଵ ܵଵଶ ܵଵ଺ ߝ௫
ߪ
൝ ௫ ൡ ൌ ൥ܵଵଶ ܵଶଶ ܵଶ଺ ൩ ൝ ߝ௬ ൡ
(10)
߬௫௬ ܵଵ଺ ܵଶ଺ ܵ଺଺ ߛ௫௬
88
Model synthesis
Here ‘σi’ is normal stress, ‘τi’ is shear stress, ‘εi’ is normal strain, ‘γi’ is shear
strain, and ‘Si’ is an element of the material stiffness matrix.
The material cost is a price per volume.
5.4.2 Layer system
By combining the compliance matrix of the material with principal material

angle, using common CLT logic the stiffness matrix in the layer system can
be obtained. By integrating the thickness with the stiffness matrix the ABD
stiffness matrices can be obtained:
(11)
Here ‘Ai’, ‘Bi’, ‘Di’ are elements from the layer stiffness matrix, ‘h’ is the layer
thickness, and ‘Si’ is an element from the material stiffness matrix.
The ABD-matrix (Jones, 1975) or stiffness matrix relates the deformations to

the loads per unit width. The Aij terms give the membrane stiffnesses of the
panel, the Dij terms include the bending stiffnesses and the coupling between
bending and membrane strains is included in the Bij terms. The relation
between the load intensities in a panel and the strains is defined as:
(12)
Here ‘Ni’ are loads, ‘Mi’ are moments, ‘εi’ are strains and ‘ρi’ are curvatures.
The layer cost is the same as the material cost with a fixed thickness, hence
yielding a cost per area.
5.4.3 Lay-up system
An equivalent definition of the plate can be obtained by using the earlier

mentioned ABD matrix. CLT provides a method to synthesize the layers,
allowing for the calculation of the membrane- and bending stiffnesses, as well
as the membrane-bending coupling, which may occur for asymmetric laminate
lay-ups. The variation of the strains over the cross section can be calculated by
assuming Kirchoff’s hypothesis. Assumed is that the layers are perfectly bonded
together and that these bonds are infinitesimally thin. The plate formulation
can be defined based on the layer stiffness matrices:
89
(13)
Another approach would be use the material stiffness matrix for calculation
of the plate stiffness, commonly used in CLT literature (Jones, 1975). This
approach is not used here, since it skips the layer system model definition.
However, the approach would be effective in case of metal structures.
To obtain the layup cost the layer costs are summed yielding a cost per area.
5.4.4 Plate system
As a result of the discrete stiffening, stiffeners usually have orthotropic

properties and this may lead to coupling effects, developing when the panel
is loaded. For example, a tensile load can lead to a bending deformation.
Coupling can occur also when the panel is constructed with conventional
isotropic materials. It is important to accurately include these effects in a
structural analysis, because they may significantly influence the mechanical
response of the panel.
Collier (1994) has formulated a method to include the coupling effects and
composite lamina and laminate data in the structural analysis of a stiffened
panel. The method tries to reduce the cost of the numerical evaluation of
the structure by deriving an equivalent model of the structure, using less or
less complex finite elements. The classical laminate theory is an efficient
way to capture the asymmetric response in an equivalent model, consisting
of two-dimensional planar elements. When this type of element is used, it
is possible to construct a model of a full structure. In general, this method
can be applied to any stiffener shape, by choosing the appropriate geometric
parameters and stiffness terms. However, it is necessary to critically determine
which segments of a stiffener have a significant contribution to the equivalent
stiffness terms of the panel, based on each specific panel concept. Lisandrin
(2007) describes a comparable method to obtain an equivalent formulation for
the behaviour of structures.
To determine the cost a method is used that estimates the total cost based on
an assumption of an average cost per hour combined with the layup cost.
90
Test case decomposition
5.4.5 Panel system
Collier (1994) adapts the classical laminate theory to a stiffened panel to

derive an equivalent model for a stiffened panel, see equation 14. In this
method the skin panel and stiffeners are treated as the different “lamina”
in the model, and the stacking sequence and lamina material properties
are included to determine the orthotropic properties of the stiffened panel
structure. These properties are added similarly to the classical laminate theory
to obtain a stiffness matrix for the stiffened panel. This matrix relates the
deformations of the stiffened panel to the loads per unit width applied to the
panel.
A similar approach as for the lay-up system is used. By summing the stiffness of
the skin and stiffener plate systems, the panel stiffness is obtained.
This analytical approach can be extended to encompass also box structures,

extending on elementary beam theory. For more information see Berendsen
(2009).
The cost is determined with a method that estimates the total cost based on
an assumption of an average cost per hour, combined with the plate cost.
5.5 Test case decomposition
This section addresses the third step of the W-diagram, the definition of the
test cases. The definition is from top-level to bottom-level. Test cases define
the properties of the system environment. Consequently, they are commonly
stated in terms of the top-level system. The system test cases need to be
decomposed in order to obtain the subsystem test cases.
To reduce the number of test cases, a designer simplifies the test cases to
include only the driving test cases. For instance, in bending of a plate, the
load at the faces of the plate is the highest. With the plate made out of a
single material, the material at the faces will encounter the highest stresses,
and consequently will fail first. To validate the material strength, in this case,
the designer only has to check the faces of the plate.
The test case decomposition is explained for the panel design example,
elaborating on the five system abstraction levels. The test cases are structural
loads, which are decomposed based on the previously determined structural
models.
91
5.5.1 Panel system
The panel’s functions were to take-up and transport loads, and maintain
structural integrity. To maintain integrity, a derived function was to maintain
stability under these loads.
The loads on the panel are simplified to in-plane loads, hence two forces and
a moment. These loads are cascaded to the skin and stiffener plates, by first
determining the panel deformations under these loads, combining the test
case loads with the concept model. Deformations are composed of strains and
curvatures. Secondly, the generic deformations are translated to subsystem
specific deformations. This can be done, because the relevant subsystem
properties are known at system level. Finally, the deformations are cascaded
to the subsystems as test cases.
In this example the stiffener is a hat-type plate and the skin is a flat plate. The
deformations of the panel are translated to deformations of both plates and
cascaded to the subsystems as test case. This is illustrated in figure 5-7.
5.5.2 Plate system
A plate’s functions were to take up loads and maintain structural integrity. As

explained the plate system can either be a skin or stiffener type. The plate
consists of one or multiple lay-ups.
The deformation test cases, obtained through the panel system, are cascaded
to the lay-ups by translating the plate deformations into layup deformations.
In this example the plate system was simplified such that each plate has one
layup type. Secondly, the test case for each layup is composed of strains
determined at plate system level, curvatures are disregarded. To simplify
the evaluation one location per plate was selected as design driving location
to define the subsystem test case. The hat-stiffener top is taken as driving
location for the stiffener layup design and the bottom of the skin as driving
location for the skin layup design. The load cases can be easily extended, in
case multiple locations have high deformations. In that case, per location, a
test case should be defined for the subsystem.
5.5.3 Layup system
A layup’s function was to take up loads. The strains are assumed to be constant
along the thickness of the layup. Consequently, these strains are directly
translated into subsystem test cases.
92
Performance synthesis
figure 5-7: Test case cascading; from panel, plate, layup, layer, up to material
5.5.4 Layer system
A layer function was to take up loads, in this case in-plane loads. As explained
a layer consists in this example from a material system.
To obtain the material test case, the deformation obtained through the layup
system is translated into a deformation in the principal material direction.
These deformations are cascaded to the material system.
The basic material functions were to take up stresses, for example due to
deformations, and maintain structural integrity (thus the material should not
be damage while the stress is taken up). To test the function, test cases are
defined in either stresses or strains.
The strains defined for the material are translated into stresses, which can be
used in the strength performance evaluation discussed in the next section.
5.6 Performance synthesis
This section addresses the fourth step of the W-diagram, the definition of the
performance values. The definition is from bottom-level to top-level. The
performance of the systems can be determined based on the defined system
and environment models (test cases). At system level the constraint and
objective performances are assembled.
In this example, the weight and cost objective performances are synthesized
concurrently with the structural stiffness.
In this example the material system is based on a composite material. The
93
derived function to maintain structural integrity was validated using a strength

criterion. In this case the Tsai-Hill strength criterion is used (Jones, 1975), see
formula 7 from the previous chapter.
5.6.2 Layer system
At layer level no performance value is determined.
5.6.3 Layup system
At layup level no performance value is determined. As stated also this level has
a function to maintain structural integrity. For the layup system this can be for
instance prevent delamination. However, this is disregarded in this example for
simplicity.
5.6.4 Plate system
The plate system function to maintain structural integrity requires a stability

performance value to test the criterion. In this case stability is assumed to be
maintained as long as initial buckling does not occur.
To evaluate the initial buckling, formulas suggested by Kollár (2003) are used.
The skin plate is schematically modelled for the buckling analysis as a flat
rectangular plate subject to in-plane loads, with all sides simply supported.
The formula suggested by Kollár is:
(14)
In case of the hat type plate the initial buckling is evaluated for the top of the
hat-shape. The hat is modelled as a flat rectangular plate with all edges simply
supported. Then the same formula can be used. In case of an L type plate, the
plate is modelled with three edges simply supported and one edge free (the
top edge along the plate length). The used formula is (Rothwell, 1999):
(15)
These formulas give the load at which the plate will buckle initially. The
stability state of the plate is obtained by comparing these allowable loads with
94
Observations and conclusions
the applied loads.
5.6.5 Panel system
To maintain integrity, the derived function was to maintain stability under the
applied loads.
The stability is evaluated similarly to the skin plate. Initial buckling is taken to
determine the allowable load, using the same formula. By comparing this load
with the applied load the stability state of the panel is obtained.
By collecting per system the constraints of the subsystems at the panel system
all the constraint performance values are available. These values can be used
to define the objective and constraint values of an optimisation routine.
5.7 Observations and conclusions
This chapter addressed the use of decomposition within simplified system

design problems. In the discussion on simplification the reuse of application
element was already identified. In this chapter, the knowledge reuse became
more apparent in the reuse of lower level systems.
Firstly, decomposition allowed for effective reuse of architecture at higher

system level and reuse of systems at lower system levels. This was discussed
in the first section, where four examples addressed the definition of
decomposition architectures from the viewpoint of different disciplines, its
error
panel
plate error trace
lay-up root cause
layer
figure 5-8: Error traceability in a decomposed panel system
95
benefits regarding reuse, and the extensiveness of a structured definition. The

past four sections addressed the W-diagram process in more detail. Secondly,
decomposition allowed the knowledge to be defined separate for system and
design option. This supports the maintenance of knowledge. This rose in the
discussion on the W-diagram, especially in the decomposed concept definition,
where the separated knowledge to system and design option was automatically
assembled for a concept definition. Thirdly, the structured model definition,
test case cascading, and performance synthesis per system provides a
structured approach to capturing all design problem and solution related
knowledge. Consequently, decomposition supports traceability, illustrated in
figure 5-8. This is discussed in more detail in the next chapter.
5.7.1 Conclusions
An effective decomposition should match the engineers’ model of the

system and can differ per discipline. This means that the effectiveness of
decomposition depends heavily on the addressed problem. For reusability,
it is important that decomposition is flexible. The system levels need to be
addressed as separate building blocks as they can be replaced individually. This
also holds for the steps in the multi-level process, which illustrated that these
steps themselves are building blocks of the overall process.
This work presented in this chapter contributes the application of the formal
approach presented in chapter three. The chapter showed the building
blocks of decomposition and illustrated the structured application of concept
decomposition to define at each system level design options and analysis
methods. It is illustrated how this can be applied in aerodynamic and structural
design examples. The structural examples also illustrate how behaviour is
addressed at a specific system abstraction level based on abstracts model and
analysis methods based on known methods from literature. To extend this
work the reader is advised to formalise the concept decomposition using for
instance an ontology. A second field of interest is the abstract structural model
definition. The work took a first step (Berendsen, 2009) towards the definition
of structural models at wing level
The following chapter integrates the conclusions from this chapter and the
previous chapter to integrate the routine and repetitive activities addressed in
these chapters.
96
Introduction
Chapter 6: Trial and error
6.1 Introduction
The objective of this chapter is to illustrate the trial and error characteristics
of the feasilisation approach. The second objective is to surface routine
and repetitive activities involved in trial and error. Such that the process
automation building blocks can be identified that can be used to support
automation by engineering software.
In chapter three, trial and error is introduced as one of the methods of the
feasilisation approach. Trial and error is used to address real, imaginary, and
abstraction complexity. Optimisation techniques are used to support much
of the trial and error process formalised in the solution generation step of
the formalised process. Secondly, the overall design process will feature trial
and error processes related to problem definition and solution performance
evaluation, caused by the abstraction complexity. Key questions to be
answered:
»» How is the optimisation problem implemented?

»» What are the trial and error processes?
»» What are the routine and repetitive activities?
»» What are the building blocks?
The chapter consists of two parts. The first part addresses example trial
and error processes, focussing on the optimisation process. The second
part addresses the formal feasilisation process introduced in chapter three,
addressing respectively; problem definition, solution generation, and
performance evaluation. The chapter is concluded with a discussion on the
observations from the feasilisation examples presented in this and the previous
two chapters.
6.2 Example trial and error processes
This section elaborates on different trial and error processes that are
used during this work. The examples focus on the search process of which
an optimisation algorithm is used. For all three applications a SQP based
optimisation algorithm from the Matlab optimisation toolbox is used. This
method is used because of the nonlinear and constraint nature of the
addressed engineering problems and the availability of this method.
97
SQP is referred to as a constrained nonlinear optimisation or nonlinear

programming. The reader is referred to Vanderplaats (2007) for a more
detailed discussion on SQP principles.
6.2.1 Panel sizing
The first example addresses a panel sizing example (Schut, 2007). The example
is addressed in section 4.2.1 for simplification and similar panel example
decomposition is illustrated in section 5.2.4. The trial and error process is
implemented as a single-level optimisation problem. The panel is illustrated in
figure 4-1.
The requirements are simplified to an objective to minimise weight, subject

to constraints defined by strength and stability criteria. The panel concept
is blade-stiffened and based on composite material with a fixed stacking
sequence. The design variables are stiffener spacing, stiffener height, number
of 45o layers and number of 0o layers. The behaviour methods are based on
analytical behaviour models.
To simplify the optimisation process the last two variables, defining the
number of layers are defined as continuous variables. However, in reality, these
two parameters can only assume discrete values. To solve this inconsistency
these values are rounded after optimisation to the most optimal feasible
nearby point. Secondly, to increase the probability to find the global optimum,
multiple start vectors are used to execute the optimisation problem in
parallel, and only feasible start vectors are used to start the optimisation
process. From the obtained optima the optimum is selected. The optimisation
process has the following steps:
»» Define feasible start vectors

»» Per start vector; optimise panel
»» Select overall optimum
»» Round number of layer variables to ‘real’ optimum
Observations
The application illustrates that discrete parameters can be redefined to

continuous parameter to support the optimisation process. In this case the
numbers of layers are made continuous. This made the optimisation process
relatively fast. This approach does not work to include varying stacking
sequences. In that case the optimisation problems still need to be solved
separate and traded afterwards. The same holds for different stiffener
concepts, such as ‘blade’ or ‘z’. Secondly, the multiple start vectors do
98
Example trial and error processes
not guarantee that the global optimum will be found. For this problem the
approach is suitable as it is an effective method to come up with a near
feasible optimum relatively fast.
Another panel design example is discussed in section 6.3, addressing each

panel concept separately.
6.2.2 Fuselage design
The second example addresses the fuselage design problem presented in

sections 4.2.3 and 5.2.2 (Baluch, 2008). The fuselage design problem addresses
a fuselage shell concept trade-off. The trial and error process is implemented
as a multi-level optimisation problem. The fuselage is illustrated in figure 4-8.
The requirements are to minimise fuselage weight under the dynamic loads
due to the gust, subject to constraints on strength and stability. The fuselage
concept is simplified to the set of successive sections, each composed of a
set of panels in circumference (see figure 5-4). The panel concept is either a
sandwich panel or a foam-filled hat-stiffened panel, which holds for all panels
such that overall the fuselage has two concepts. The design variables are the
elementary barrel lengths, and the previously discussed panel design variables.
To simplify the optimisation process the fuselage concept is fixed. The

optimisation process is a defined in three layers, illustrated in figure 6-1.
The first layer addresses the complete fuselage. At this layer the fuselage is
figure 6-1: Fuselage optimisation process
99
constraint by stability requirements. At this level the structural properties are

converged to meet this constraint. This means that the trial and error process
at this level is a convergence process. The second layer addresses the sizing
of the section length. The section lengths are determined successively from
centre to tail. Starting with the first section, the optimum length of the section
is determined, through an optimisation at the second level. Successively the
length of the second section is determined. This process continues until the
determined length of section ‘i’ is larger then the remaining fuselage length.
That section is defined as the final section, constraining its dimensions to the
remaining length. The second level addresses an optimisation of the section
length to obtain the best weight over length ratio. The section is represented
by a set of panels that are optimised at the third level. The weights of the
panels are summed to obtain the overall section weight. The trial and error
process at the second level is a successive (and uncoupled) optimisation of the
section lengths. The third level addresses the optimisation of the individual
panels, which is performed similar to the previous example.
Observations
An advantage of this optimisation approach is that the sections and the panels
can all be optimised individually. This is possible because the coupling between
the sections is included at the first level and the coupling of the panels is
neglected. This simplification could be used because the addressed structure is
statically determined.
A disadvantage of this procedure is that the convergence process at the

first level can require a substantial amount of time and does not necessarily
converge (this was the case for the tail design problem, discussed in section
4.2.2). To include different panel concepts the sizing is performed for each
concept and then traded afterwards. Another disadvantage is that the length
of the final fuselage section is generally suboptimal. To obtain an improved
solution the sections should be designed in parallel (although this method may
still be required in order to determine the amount of sections).
A similar application for wing design is illustrated by Schut (2008a). That

example is used in the following section, but combined with a different
optimisation method that can optimise the section lengths at the same time.
6.2.3 Wing design problem
The third example addresses a wing design problem (Varkevisser, 2010), based
on an optimisation approach suggested by Tosserams (2008). Similar wing
design examples are addressed in sections 4.2.4 and 5.2.4. The trial and error
100
Example trial and error processes
panels widthbox-root
heightbox-root
heightbox-tip
lengthbox-root
lengthbox-tip
widthbox-tip
figure 6-2: Wing concept, simplified to two boxes
process is implemented as a multi-level optimisation problem. The wing design

example is illustrated in figure 6-2.
The requirements are simplified to minimise weight, constraint by panel

strength and stability criteria. The concept is a foam-filled hat-stiffened panel,
similar to the previous example. The concept is simplified to two boxes, with a
fixed panel concept.
The optimisation is implemented with Augmented Lagrangian Coordination

(ALC), a coordination approach for distributed optimisation. The solution to
the overall problem is obtained by coordinating the subproblems by relaxation
of the coupling constraints. Iteratively the constraint relaxation is reduced
until all constraints are met. The relaxation is implemented with penalty
parameters which increase during this process. The basic process is illustrated
in figure 6-3. The coordination involves the relaxation of the length of the two
boxes. To validate the results the single-level implementation (see section
5.2.4) is used as base-line. The panels are optimised according to the first
addressed example.
Observations
The implementation of the approach for this type of problem showed feasible.
The main advantage of the approach is that Integrated optimisation approach
yielding a more optimal solution. Secondly it is possible to address highly
coupled problems that can not be simplified similar to the second example.
However, the implementation illustrated that the ALC algorithm used in the
outer loop is very sensitive to the inner loop performance. The SQP algorithm
is not a global search strategy, meaning that it will end up in a local optimum
101
outer loop
update penalty parameters
constraint violations
inner loop
solve
wingbox
solve solve
panel-1 panel-N
figure 6-3: The ALC multi-level optimisation process, illustrating

the outer loop in which the penalty parameters are updated and
the inner loop in which the design problem is solved
sometimes. This results in irregular inner loop solutions that can not be
handles by the used outer loop formulation. In this case the global optimum
is consistently found by using a very high number of start vectors. This highly
deteriorated the performance of the overall optimisation, but did result in a
feasible solution.
6.3 Design problem definition
The following section addresses the overall trial and error process inherent
to the feasilisation approach. The optimisation process is a part of that trial
and error process. To simplify the discussion the used optimisation process is a
single-level optimisation approach.
At the start of a design process the designer iteratively changes requirements,

concepts, and tools in order to find an initial feasible process that can
eventually yield a feasible concept solution. During this process, the problem
definition is continuously changed by the designer, to identify the definition
that suits the actual design problem. Inherent to trial and error process are
errors in the requirements, concept, and behaviour definition, which occurred
frequently in the examples discussed in the previous chapters. However,
the inherent trial and error process should only occur in case of new design
problems, requiring the designer to incorporate new requirements, concepts,
and tools. Examples are the extension of a structural design problem with
manufacturing cost calculations and the extension of metal design problem
with composite material design options. The engineering software to support
feasilisation should target exactly these processes.
102
Design problem definition
6.3.1 New requirements definition
To find the best problem definition, the designer changes, requirements,

concepts, and tools. This was also the case in the implementation of the
examples discussed in the previous two chapters.
A designer assembles new design requirements to gain insight into or

obtain a feasible solution for a problem in reality. Since this real problem
is itself generally part of a larger system, any modelled problem is already
a simplification of the reality, disregarding those relations. The application
of simplification and decomposition make the problem modelling feasible.
However, the modelled problem becomes disconnected from the real problem,
and the connection is only maintained by the designer. However, the designer
does not know which requirements should be modelled to suit the problem
best. Therefore the designer changes the definition, not just to find the best
feasible solution, but to obtain a suitable set of requirements.
To support this process a design problem should be defined such that it

can be easily changed, changing requirements, concept, and tools. The
implementation of the examples illustrated that by standardisation of the
problem this could be achieved. The problem is defined to suit the formalised
process, and embodies objective, constraint, model, and test properties.
6.3.2 New concept definition
The new concept definition is performed by the designer. Generally, concept

knowledge of similar problems is reused, extended with new design options
and/or tools. The knowledge is assembled to form a new design concept. As
was explained in the previous chapter on decomposition, the extension can
result in different system levels.
As mentioned in section 5.2.3, the fuselage design problem could be based

on much of the wing design example. However, concept specific knowledge
needed to be changed and added, e.g. stiffener types were changed, ribs were
replaced by frames, and rib crushing behaviour changed into global fuselage
stability behaviour (although left out for simplicity).
The concept definition trial and error process surfaced especially in the
extension of panel design example with manufacturing considerations,
used in the wing and fuselage design problems. The result was a changed
decomposition to encompass manufacturing knowledge. A differentiation
between plate and layup was required to encompass on the one hand
structural stacking design options (addressed by layup), and on the other hand
103
manufacturing cost (of the skin of stiffener plate). The structural knowledge
could be reused, but an extra system level was added to include the plate
manufacturing properties. The changed decomposition is illustrated in figure
6-4.
In case new concepts, disciplines, test cases, or performances are involved the
definition needs to be adapted to encompass the new knowledge. In building
up a new definition the designer is bound to overlook or forget something.
Since the definition is performed ‘off-line’ or in static conditions, the designer
will not notice whether the concept definition is complete until the design
problem is processed.
The implementation of the examples illustrated that the use of a predefined

format and a structured decomposition support both the concept reuse and
new concept definition. This reduced the probability of errors in the concept
definition.
6.3.3 New behaviour definition
The behaviour process depends on the requirements and concept definitions.

By redefining the requirements or concept, implicitly the performance process
definition is changed. As a result the possibility exists that an error pops up
somewhere in the process. This error can be the result of an incomplete
definition (e.g. missing tools), an incorrect definition of a tool, or an incorrect
use of a tool outside its applicable domain. Another typical error involves, for
instance, unavailability of a tool or method during the execution of the design
A
panel model shape decomposition
structural structural & manufacturing

design considerations design considerations
figure 6-4: Changed panel model decomposition to

include manufacturing design considerations
104
Solution generation
process. For more details on these kinds of problems that relate more to
problems that surface in integration with existing IT environments, see Berends
(2008).
The error identification and classification depends on the experience of the

designer. For instance, knowing when a property value is outside its expected
domain (e.g. weight is twice its expected value). The process time is mainly
influenced by the time it takes to identify the cause of the error. This
means that the error should be easily traceable (which was addressed in the
discussion on decomposition).
Consequently, the iterative nature is a result of the tight coupling of the

process with the requirement and concept definitions. By changing the
definition, the performance process needs to be adapted, although the overall
design process may not even change. By separating the different elements in
the process definition, in principle, the efforts required for the redefinition of
the process can be highly reduced.
The discussed example implementations have shown that this separation

can be realised by using four formalised abstraction levels, addressing
environment, system, process, and property. This makes any errors traceable
allowing the designer to efficiently identify, classify, and remove the error.
6.4 Solution generation
Second to definition is the search for the best feasible solution. As explained
in chapter three, these search methods are generally encompass optimisation
routines. As described before, the designer has a critical role in the trial and
error process to ensure that the real problem is solved instead of the modelled
problem.
In this thesis, the design problem is defined as a centralised search

optimisation problem definition. Although in case of decomposed design
problems a decomposed search is attractive the centralised approach
is simpler which fits the proof of concept of this thesis. A preliminary
investigation (Varkevisser, 2009), of the use of one of these distributed
methods in the presented panel design problem, showed that these methods
pose yet another problem, robustness. For more information, and examples on
the use of these methods in engineering design problems, see Tosserams (2008)
and Sobieszczanski-Sobieski (1998), among others.
First the impact of optimisation method selection on the design process

performance is discussed shortly. Secondly, the mixed trial and error
105
process of a designer and a centralised optimisation method is discussed

for the previously addressed wing example. Finally, the effect of concept
parameterisation on the search process is discussed for the same example.
6.4.1 Optimisation routine selection
This first example addresses an elevator design example, implemented within a

business environment (Van Riet, 2008). The elevator design problem is coupled
design problem (being structurally undetermined). In differs from the wing
design example such that the solution at the wing root would influence again
the wing tip.
In this example no proper optimisation algorithms were available that could be

used by the designer. To solve the problem, heuristics were used to build up a
new optimisation routine, based on examples used in similar cases. However,
the implementation focused on a prototype development and limited available
time. The bottleneck surfaced to be lead time of the trial and error process
required to develop the optimisation routine. A single design problem took too
much time, such that a final the optimisation routine did not reach maturity.
As was observed in the previous example implementations, the optimisation

routine drives, for a large part, the performance of the overall process. The
integral development of an optimisation routine and a design problem should
be done with great care, in order not to end up in an endless trial and error
process. This was also one of the results of performed by Varkevisser (2009),
in a preliminary study on integration of optimisation algorithms in engineering
1 3
m = [mass, t = [load
panel x = [length]
stiffness] intensity]
c = [stability]
x = [width, m = [mass, t = [load

plate nbr-layers] stiffness] intensity]
c = [stability]
m = [mass, t = [load
layer x=[]
stiffness] intensity]
c=[]
m = [material
material x=[] t = [stress] c = [strength]
properties]
2 4
figure 6-5: The systems in the panel problem form a W-shaped process; define
concept (1), generate model (2), define test case (3), generate performance (4)
106
Solution generation
design problems.
6.4.2 Designer and optimisation methods
This section addresses an integration method for simplification, decomposition

and trial and error. The wing design example (Schut, 2008a) discussed in
section 5.2.2 is taken as guiding example. As discussed in the previous chapter,
every system level process features the same four process steps, addressing;
concept (defined by variable values), model, test, and performance (defining
objective and constraint values). Concept variables and performance
constraints are defined for all systems. However, only the top level system has
a performance objective.
The system optimisation is an integration of the system objective and the

system and subsystem variables and constraints. Since the design vector of
the subsystems is known, the system level design vector (hence the variable
concept parameters at system level) can be simply extended to incorporate
the subsystem level design vectors. To obtain the objective and constraint
functions the subsystems are called twice; once for model properties based
on design vector, and once for performance properties based on the test case.
Figure 6-5 illustrates these relations for the panel, plate, layer, and material
systems.
The wing structural design example featured six abstraction levels; wing,
box, panel, plate, layer, and material. The trial and error process of wing is
elaborated top-down.
Wing and box level
At wing level, the number of boxes and its individual lengths need to be
optimised for minimum weight. For simplicity, the boxes were assumed to
have an identical length. To fit within the external shape, the length of the
tip box is adjusted. A fixed box length approach is used, because the weight
criterion is not ‘strong’ enough to obtain a manufacturable length of the box.
The box length will be reduced to improve skin panel stability, which results
in unrealistic short boxes. To take into account manufacturing requirements a
human is needed (only at this level) to make a trade-off between weight and
box length.
At box level, no trial and error methods are necessary, because the shape
of the box is fixed. This also fixes the panel planform dimensions. As was
explained, the effects of the deformation of the skin are introduced to the ribs
during the same iteration, so no convergence process is required.
107
Panel level
At panel level, a search problem is defined. The search is used to obtain the
best deliberation between the lower level systems, e.g. skin and stiffener
plate systems. The panel system has no variable parameters, having rib spacing
and thus length and width fixed by the designer. The components of the
panel must be optimised to obtain the lowest panel weight. In this problem
the search concerns a continuous domain. The search problem is a nonlinear
constrained optimisation problem, defined as:
(16)
The problem is implemented with an optimisation routine from the Matlab

optimisation toolbox, based on a sequential quadratic programming (SQP)
algorithm. The selection was based on availability. In this implementation, the
lower level systems are optimised together with the panel system. At this level
only the nonlinear constraint vector g(x) is filled with a value indicating the
buckling state of the panel.
Plate level
The optimisation problem defined at panel level encompasses the trial and
error process of the plate system. The design vector, x, is extended with a
value representing the plate width, and the non-linear constraint vector g(x)
is extended with a value indicating the buckling state of the plate. A layer is
based on one material. No trial and error methods are required at this level.
Material level
At material level the optimization problem defined at panel level encompasses

the trial and error process of the material system. The non-linear constraint
vector g(x) is extended with a value for the strength state of the material.
The results of this problem have been discussed in the previous two chapters
and the reader is therefore referred to those chapters for more details on the
results.
This example shows the feasibility of flexible integration of a designer trial

and error method with optimisation techniques. However, only a single
108
Solution generation
optimisation method and level of simplification are used. A more extensive

investigation is required to understand the physics between multiple levels of
simplification and optimisation and integration of more complex optimisation
techniques, such as in case of the mentioned distributed optimisation.
6.4.3 Effective parameterisation
The design variables are determined by the parameterisation used by the

designer. The parameterisation influences the performance of the optimisation,
because they implicitly define the design variables.
In the previously discussed wing example, the panel layup was parameterised
to address them with the SQP optimisation algorithm. SQP uses the current
design point and the second derivative (in the form of a Hessian) of the
design space to obtain a new design point. To obtain this second derivative,
the design space must be smooth. However, the layup consists of a set of
discrete layers. In order to integrate the deliberation of the number of layers
in the optimisation problem, the stacking order was fixed and the number of
layers was defined as a continuous variable. This allowed the use of the SQP
algorithm for the layup optimisation. The main drawback is that the obtained
design result is never a feasible design solution (since partial layers are
allowed). The best feasible solution was assumed to be near this theoretical
optimum. By evaluating all nearby feasible design points (by setting the
number of layers values to nearby integer values), the best nearby feasible
design solution was obtained.
Two observations were made, firstly the continuous number of layers design
variables resulted in a tightly coupled set of responses. This increased the
required optimisation time. Secondly, the post-processing required to obtain
a feasible design solution requires considerable evaluation time. For instance,
a blade stiffened panel with skin and stiffener having the general stacking
sequence [±45°, 0°, ±45°] yields four layup design variables, two for both
skin and stiffener layup. To evaluate all nearby feasible solutions, 16 (e.g. 24)
number of design points need to be evaluated.
The other approach would be to define a range of panels with different layups,
then solve each panel individually, and finally select the best feasible panel.
As a consequence, the panel design problem has four design variables less.
However, the probability increases that no feasible design solution can be
obtained, since only skin width (remember stiffener spacing) and stiffener
height can be changed by the optimisation routine. The major drawback is
that the number of discrete panels that need to be optimised is enormous. For
instance, allowing layups up to 10 layers per type this yields over one million
109
(e.g. 410) different panel concepts. For a single design problem this results in
much more evaluation time. In the previous approach, the optimisation routine
is used to identify the best 16 of the million design points.
However, when the number of similar design problems increases this changes.
In that case the design problem can be approached again differently. First an
overview of the design solution space is obtained by strategically evaluating
a great number of design points. Secondly, these design points are integrated
obtaining a surrogate model of the design space. This model is used to
evaluate the actual design problems. This is discussed in more detail in the
next section.
6.5 Performance evaluation
This section addresses the trial and error involved in performance evaluation.
The evaluation is based on a comparison between the stated design problem
and the provided system solution. If requirements change this relation is
invalidated and the design has be repeated.
Experience learns which changes in requirements can be expected. However,

the exact change is not predictable, but the range of the change is. Based
on this range it is possible to define a set of design problems that span the
expected changes in requirements. Designing these design problems in advance
allows the engineer to reuse of these existing design solutions when a change
occurs. In principle, the reuse of solutions can reduce the overall trial and
error character.
A second application that surfaces in the feasilisation approach is occurrence

of many similar design problems due to decomposition, such as the panel
design problems. Although, for these problems the changes in requirements are
known, many design problems can be solved by interpolation of the existing
design solutions (hence use mutation). This is the approach used in traditional
conceptual design, discussed in chapter two.
To illustrate this solution space generation, the previously discussed panel

design problem is taken as guiding example. The panel example (Schut, 2008b)
developed in response to multiple design problems that involved the same or
similar design problems.
6.5.1 Panel concept solution space
The generic panel design problem has a varying set of requirements which
consist of a certain load case, length, and width. Per specific design problem
110
widthskin
widthstiffener-top
widthpanel
lengthpanel
figure 6-6: Panel concept model
these are fixed. In principle, also variable bounds and constraints should be
included. However, these are left out for simplicity.
As explained before, a design problem addresses a fixed panel concept. In

this example, two concepts are addressed. The concept is defined at multiple
levels; panel, plate, layup, layer, and material, and is illustrated in figure 6-6.
Two stiffener types are included: hat-stiffener and L-stiffener type. The skin
plate lay-up is [±45,0,±45], and the stiffener plate lay-up is [±45,0,0,±45].
Consequently, two layer types are used: 0, and ±45. One material type is
used, a carbon fibre composite quasi-orthotropic material. The resulting two
concepts are coupled with the requirements.
The panel is structurally designed to sustain the load case and is constrained
by strength and stability. The material strength of every layer is evaluated
with Tsai-Hill, the skin and stiffener plate stabilities are evaluated by initial
buckling determined with conceptual analytical formulas. The panel overall
stability is evaluated by initial buckling determined with similar analytical
formulas. The cost estimation (Van der Laan, 2007) is based on a time
estimation performed for all steps taken in the production process. The skin
and stiffener plates are manufactured by hand lay-up. The panel is assembled
by bonding the plates. The steps are analysed based on cost estimation
relations, which depend on the design and in part on the machines and people
performing the process. The machine and people data is provided by static
manufacturing process data. The assembly joint cost analysis is based on the
shape of the joint and the parts that are involved in the assembly joint. The
positioning times of the parts into the mould are estimated based on surface
area of the parts involved.
The search process generates a solution per design problem. The example
design space, illustrated in figure 6-7, addresses two parameters: the relative
111
cost per volume and Youngs modulus. The design space included multiple
concepts, e.g. polymers and alloys. The panel design example addressed two
panel concepts: hat-stiffened and L-stiffened. The example panel design space
is defined by five parameters: varying in cost versus weight objective, normal
load, length, cost, and weight. The first three dimensions are input parameters
and the last two are output parameters.
The two concepts are addressed for a range of parameter combinations.

To obtain an even distribution along the domain of the design space, a full
factorial design is used. Per parameter, four design locations are used, adding
up to a total of 64 discrete design problems per panel concept. In concurrence,
also the solution domain must the evenly scaled to obtain the proper
distribution of design cases. This is important to obtain an even distribution
of design points along the Pareto front, defined by the cost versus weight
objectives. Therefore, the objective values need to be scaled to the same
range. To obtain the scaling values, first the design problems with a single
objective are solved. In these cases either the cost or the weight importance is
set to zero. The obtained minimum and maximum objective values are used to
scale the cost and weight objectives. Secondly, the design problems addressing
an objective trade are solved.
The results are presented in figure 6-4. A design problem point is printed in
every graph. To illustrate the dependencies between the separate graphs an
example design problem point is circled in every graph. On the whole, the
resulting figure gives a general overview of the addressed design problem
space of the two topologies.
To reduce calculation time, the problems are sized based on one start vector,
assuming that the optimisation algorithm will find the optimum solution. The
results in figure 6-4 illustrate that this is the case, except for a few L-stiffened
panel design cases, which appear to deviate from the expected trend. One
of these L-stiffened design problems addressed a single weight objective. As
a consequence, the design solution is not sensitive to cost, this explains the
higher cost. To solve this problem, either design problems addressing a single
objective must be repeated with a less extreme objective trade, such as 0.95
and 0.05 instead of 1 and 0. Another method is to use the obtained objective
value as a constraint in the same design problem, although addressing the
other objective parameter.
Two observations are made. First, in order to capture a design solution, an

elaborate method of documentation is required that fully defines the specific
design case. If this definition is imprecise, design solutions could reused for
different design problems.
112
Observations and Conclusions
figure 6-7: Design results for a hat-stiffened and L-stiffened panel concept
Secondly the search for the correct design solution in order to reuse it may be
more extensive then resolving the design problem. Thus in that case solution
reuse would actually increase design process time.
6.6 Observations and Conclusions
The discussion in this chapter illustrated that an important part of feasilisation

is trial and error. The trial and error process is used to define a modelled
problem such that a concept solution is obtained that is an abstract of the
eventual detail solution.
The main observation is that much of the trial and error process is performed
by the designer. Optimisation routines are effective, in the use of the
formalised search process, introduced in chapter 3. However, that process
depends on the proper definition of the requirements, concept, and tools,
combined with the proper search method. The iterative nature in combination
with the designer surfaced in the problem definition phase. The trial and
113
error process required the designer to iteratively adapt the design problem,
changing requirements, concept, and tools. The applications showed that, by
reusing the formalised search process, the design problem could be remodelled
without too much cost. Effectively the design problem is broken into separate
design problem modules that capture part of the requirements, concept,
and tools. The modules are matched to the decomposition, described in the
previous chapter. This allows efficient redefinition of a new problem. An added
benefit, already mentioned in the previous chapter, is that this decomposition
results in a traceable information structure. In the final part of the chapter,
the reuse of known solutions is addressed. The discussed showed that reusing
design solutions, in combination with surrogate models, can potentially reduce
much of the trial and error process. The example showed also the use of these
methods to preselect specific concepts based on the required performance,
much the same as materials are selected based on their properties. However,
in order to make the reuse effective an elaborate storing method and
application is required.
6.6.1 Conclusions
The system simplification discussed in chapter four suggested that engineers

are able to reuse much of the available knowledge, although they have
to tailor every specific system design problem. This surfaced again in the
discussion in this chapter. The system decomposition discussion showed that
it is important to stay close to the engineer, to support reuse the decomposed
system. The discussion in chapter five surfaced that for reusability, it is
important that decomposition is flexible. Any implementation should not
enforce a certain system model on the specialist. This chapter illustrated that
this reuse can be achieved by dividing the process into separate similar process
modules, here represented by the formalised search process discussed in
chapter three.
Concluding, the past three chapters showed that although the examples all
address different system design problems, major elements can be reused
between the examples. The reuse is based on the formalised process, as
well as a structured system decomposition that yielded building blocks.
Simplification required building blocks for the requirements, concepts, and
behaviour models. Decomposition used building blocks per system level and for
the separate steps of the formalised process.
This chapter contributes an overview of the routine and repetitive activities

inherent to the feasilisation approach based on examples addressed in
chapters four through six. The chapter contributed to the integration of
optimisation techniques with the decomposed systems through a single level
114
Observations and Conclusions
optimisation problem. The work took a first step to integrate a multilevel

optimisation problem. The integration showed feasible, but illustrated that
special attention is required from the field of optimisation to obtain a robust
implementation. Follow up work is recommended to integrate the multilevel
domain with special attention to the application of multilevel optimisation
methods.
The following chapters focus on the development of engineering software

based on knowledge engineering principles. The engineering software is to
support the feasilisation process by automating the repetitive and routine
activities illustrated in this chapter and the previous chapters.
115
116
Part II
Development of a knowledge engineering
application for conceptual design
Introduction
Chapter 7: Feasilisation building blocks
7.1 Introduction
The objective of this chapter is to define a set of basic building blocks that
can be used to support the feasilisation approach with engineering software.
The building blocks are based on the observations and conclusions from the
previous chapters.
In chapters three the formal process model of the feasilisation approach and
the design process are discussed. In the following chapters the application
of this formal model in context of the three feasilisation methods are
presented. These elements together provide the structure and behaviour
of the feasilisation approach. From the previous chapter surfaces that
abstraction complexity is addressed through trial and error, hence learning.
The importance of learning was introduced in the first chapter to be of essence
in the development of engineering software that can support knowledge work.
This chapter translates these observations using knowledge engineering (KE) to
generic building blocks that form the basis for engineering software that can
support the feasilisation approach. Key questions to be answered:
»» How can engineering software support learning?

»» What are the properties of ‘smart’ software?
»» How can building blocks be used effectively?
»» What are building blocks of the feasilisation approach?
First, two concepts from knowledge engineering are presented, addressing the
learning cycle and knowledge model. Secondly, knowledge based engineering is
introduced, elaborating on the concept of high level primitives and capability
modules as useful example building blocks. Then the engineering primitives
are introduced as building blocks for the initiator. Their implementation is
discussed in the following chapters.
7.2 Knowledge engineering
Classically, knowledge management (KM) involves management of people, and

addressed assessing, changing and improving human individual skills and/or
behaviour (Sveiby, 2009). In this context knowledge are processes, a complex
set of dynamic skills, know-how etc., that is constantly changing.
At the moment, a new KM track is growing very fast, assisted by new
119
to
tacit explicit
knowledge knowledge
knowledge
tacit
socialisation externalisation
from
knowledge
explicit
internalisation combination
impact of engineering software
figure 7-1: The learning cycle or Nonaka’s model (1995), relates tacit and explicit
knowledge: externalisation, combination, internalisation, and socialisation
developments in IT, addressing management of information (Sveiby, 2009).

This track is involved in construction of information management systems,
such as artificial intelligence, re-engineering, and group ware. In this context,
knowledge are objects that can be identified and handled in information
systems. In this thesis, this track is referred to as knowledge engineering (KE),
and fits within that track. Feigenbaum (1983) defines knowledge engineering
as: “an engineering discipline that involves integrating knowledge into
computer systems in order to solve complex problems normally requiring a high
level of human expertise”.
First a concept from the classical KM is discussed from the view point of
learning to define the possible interface between the engineer and the
engineering software. Secondly, a concept from the KE track is discussed to
define the structure that is used to integrate knowledge into engineering
software.
7.2.1 The learning cycle
As stated in the introduction engineers are knowledge workers, and have to
120
Knowledge engineering
learn constantly for a proper execution of their primary tasks. An example is

the trial and error process inherent to problem assembly discussed in chapter
six.
In knowledge management Nonaka’s model (1995) or the learning cycle is

often used as a model for the learning process, illustrated in figure 7-1. It
divides knowledge into two categories, tacit and explicit. Explicit knowledge
is codified knowledge captured in rules, procedures, and handbooks, among
others. It can be transferred by teaching and can be obtained by study. On
the other hand, tacit knowledge is contained within an individual. It is based
on experience, skill, and attitude. Implicit knowledge can be transferred by
demonstration and can be obtained by copying or imitation.
Tacit and explicit knowledge are related to each other through the learning
cycle (Weggeman, 1997; Schreiber, 2000). The learning cycle steps are:
(1) Externalisation (from tacit to explicit knowledge): knowledge-

intensive practices are clarified by putting them on paper,
such as formulate them in formal procedures
(2) Combination (from explicit to explicit knowledge): creating knowledge
through the integration of different pieces of explicit knowledge
(3) Internalisation (from explicit to tacit knowledge): performing
a task frequently leads to a personal state where we can
carry out a task successfully without thinking about it
(4) Socialisation (from tacit to tacit knowledge): we can teach each
other by showing rather then speaking about the subject
Looking at the nature of knowledge engineering, it could logically

support three of the four steps, namely externalisation, combination, and
internalisation. Based on a need new knowledge is identified, formalised
and captured in explicit rules, addressed by the CommonKADS methodology
(Schreiber, 2000). The explicit knowledge can be captured in engineering
software that can be effectively used to make new combinations of explicit
knowledge, which can be supported by engineering software. By making new
combinations the designer gains more experience internalising knowledge by
doing.
To support combination with an engineering software system, it should be have

building blocks of explicit knowledge components.
7.2.2 Knowledge model
In the CommenKADS methodology (Schreiber, 2000) knowledge engineering
121
is regarded as the construction of different aspect models of human

knowledge. A knowledge model is used to capture and structure the different
knowledge aspects involved with a system. A knowledge model is a schematic
representation of (part of) the world, such as a system. It consists of domain
knowledge, inference knowledge, and task knowledge.
Schreiber (2000) describes domain knowledge as: “the main static information
and knowledge objects in an application domain”. Domain knowledge is
composed of two elements, a domain schema and knowledge base. The domain
schema is a schematic description of the domain knowledge through type
definitions, e.g. a chair is of type furniture. The domain schema is similar to
the domain model used in software modelling (e.g. Larman, 2005). The schema
describes the static structure by using modelling constructs, such as concepts,
relations, and rule types. Where a domain schema defines knowledge types,
a knowledge base contains instances of these knowledge types. The domain
schema defines the model of the world and the knowledge base contains
specific systems that exist in that world. For example, the domain schema
defines the possible table concept, and the knowledge base contains table
instantiations filling the schema. This static structure is based on ontologies
or taxonomies. In this work ontologies are used as inspiration to structure
information, but no formal ontology is developed. This is out of scope for
this work and the definition of an ontology is recommended for further work.
The semantics and information structures presented in this work have been
developed is based on a mix of existing ontologies and pragmatic development.
x0 x0 x0
tool A tool A tool A
xA xA xA
tool B tool C tool B tool C tool B tool C
xB xC xB xC xB xC
tool D tool D tool D
xD xD xD
xC? xC xC
figure 7-2: Inference based either on forward or backward chaining
122
Inference knowledge describes the logic or reasoning of the domain

knowledge. Inference is a term commonly used in artificial intelligence (e.g.
Russell, 2003). By inference a system is able to react on its environment by
using both procedural and propositional knowledge. This knowledge relates
to the specialist methods used to test the performance of a design. The main
reasoning occurs inside the system, using knowledge rules to determine the
proper action. A system can be seen as an entity that can respond to changes
from the environment. By changing its properties, the system is able to meet
certain external and internal constraints and an objective. The inference
process is called chaining, and can be either forward or backward, see figure
7-2. Forward chaining is a push process, backward chaining a pull process. The
backward chaining process is more complex. However, also more efficient,
since it only uses the tools that are required to obtain a certain set of
information.
Task knowledge refers to the purpose or reason behind the reasoning. It

embodies the goals of the system. In our case, the system design is subject to
requirements, which embed the task knowledge, for instance the functional
tests that are used to obtain the system performance. This describes the
system design context, e.g. a scenario or chain of events. The task knowledge
ensures that the system is designed for a specific environment. In engineering
design task knowledge consists of among others, load-cases, flight manoeuvres,
pilot actions, or missions. The task knowledge is used by task methods, for
instance the formalised search process explained before. It embeds a reasoning
function how the requirements and the inferences can be combined in order to
achieve a feasilised design.
7.2.3 Knowledge systems
Software systems that capture knowledge in software are referred to as

knowledge-based system or knowledge systems in general (Schreiber, 2000).
Milton (2008) defines a knowledge based system (KBS) as a computer program
that uses artificial intelligence (AI) techniques to solve complex problems that
would normally be performed by a person with a specific expertise. These
knowledge systems have five components (Milton, 2008):
»» Knowledge base
»» Inference engine
»» Working memory
»» Interface
»» Editor
The knowledge base contains the previously discussed domain knowledge. The
123
knowledge system
knowledge
editor
base
user
inference working
interface
engine memory
external
software system
figure 7-3: Basic architecture of a knowledge system (Milton, 2008)
inference engine uses the inference knowledge to infer the domain knowledge.
The working memory defines the specific state or representation of the system,
such as information on the original system design problem and intermediate
results. The interface is an interface between the knowledge software and
engineers or other software systems. The editor allows the engineer to inspect
and adapt the knowledge base. The relation between these components is
Schreiber points out that no fixed borderline exists between knowledge

systems and ‘normal’ software systems. The main distinction is that knowledge
systems some explicit representation of knowledge is available in the system,
which requires special modelling techniques. As explained in chapter six,
due to the conceptual nature of the feasilisation approach engineers have
to remodel the design problem relatively often. This promotes the use of
a separate design problem knowledge base and a feasilisation approach
inference engine.
7.2.4 Knowledge based engineering
Complex system design such as aircraft design is model driven, based on

(for a large part) geometry model. Computer aided design (CAD) technology
developed to support engineers in building such a geometry model. This system
model is also the baseline for the object decomposition, discussed in chapter
five, and is therefore an importance element of the domain knowledge of the
feasilisation approach.
The KBE technology is a synthesis of knowledge systems and computer aided

design (CAD). La Rocca (2009) defines knowledge based engineering as “a
technology based on the use of dedicated software tools that are able to
capture and reuse product and process engineering knowledge”. Applications
of KBE aim at reducing time and cost of product development, by reducing the
124
routine tasks and supporting knowledge integration between the disciplines.

KBE is used today to support and improve design of complex systems, with
aircraft and car manufacturers as main users.
The development of KBE applications is based on a formalised process, such

as the one proposed used in the MOKA methodology (Oldham, 1998) for the
development of knowledge-based engineering applications. The KBE system
life-cycle entails four steps; identify, capture, store, and reuse (see figure
7-4). The cycle describes to fulfil a specific need which knowledge has to be
formalised and how it should be translated to a successful application.
Business New
need knowledge
provides a
Stimulus
to
Identify
Identify
What is involved
in order to
Justify
either or
New KBE maintenance of
no longer
development KBE system
justified
requiring
Capture
And verification of the required knowledge
before the knowledge
engineer can
Capture
Formalise
And include into knowledge base
prior to extracting the appropriate
knowledge in order to
Package Store
In a KBE system, and test application
ready to
Distribute
KBE system to intended users
and then
Introduce
KBE system and train users Reuse
so that they can
Use
To obtain benefits and identify new knowledge or business need
which may trigger a
cycle of development
figure 7-4: The knowledge based engineering life-cycle (Oldham, 1998)
125
As explained in the introduction this research is based on iterative

development, which results in the several iterations of this process. However,
this thesis is structured to a single iteration. The first and second chapter
address the identification step. Chapters three to six address the capture step.
This chapter and the next involve the store step, and the final two chapters
address the reuse step.
7.3 Building block concepts
To define the knowledge model first the domain knowledge is formalised. As

explained, the domain schema is the static structure of the domain knowledge.
The domain schema are building blocks of the knowledge system to support
the feasilisation approach is based on two other knowledge system application
concepts.
7.3.1 MDO framework abstraction level concept
As concluded in chapter two, MDO frameworks are critical in effective

application of MDO in industry. An example MDO framework concept is
suggested by Berends (2008) who defines four system abstraction or scoping
levels related to the MDO framework, illustrated in figure 7-5. The abstraction
levels are respectively:
»» Organisation level
»» Framework level
»» Tool level
»» Data level
On the organisation level the MDO problem is executed and managed,

responsible for resource management. The aim at organization level is to
find a solution that meets all the system design requirements. At that level
the necessary resources are allocated and schedule and resource constraints
guarded. The design engineers are located at this level. The framework
function is to produce a MDO problem-solving environment, responsible for
resource interfacing. The framework connects and integrates individual tools,
such that the problem can be solved. The search engineers are located at
this level. At the tool level the function is to transform information, typically
performed by discipline analysis tools. The discipline engineers belong to this
level. The data level function is to contain information.
In the discussion of the DEE concept, an example MDO framework concept,

three of the four abstractions are represented. The framework is represented
by the DEE, the tools are represented by, among others, the multi-model
126
Building block concepts
organisation
level
framework
level
tool in
level
out
data
level
figure 7-5: Abstraction levels used by Berends (2008) in

an example MDO framework implementation
generator and analysis tools, and the data is output and input of these tools.
From the MDO framework requirements defined by La Rocca (2009) in chapter
two the data abstraction surfaced. This model from Berends adds a fourth
abstraction level of which the MDO framework is a subsystem, the organisation
or social system.
7.3.2 High level primitive modelling concept
The multi-model generator mentioned in the DEE discussion is a typical

example of a KBE application. La Rocca (2009, 2002) uses two concepts to
obtain a flexible modelling application. The two concepts are:
» High level primitives

» Capability modules
High level primitives (HLPs) are used as building blocks to obtain a geometric
system model. Chapter five illustrated that system decomposition allows
engineers to construct a system from subsystems. For instance, an aircraft is
build from among others, wings and fuselage system components. The HLPs of
an aircraft are exactly that; wing, fuselage, engine and connection element
127
figure 7-6: High level primitives can be used to build a range

of different aircarft concepts (La Rocca, 2007)
primitives. Combined they can describe a range of different aircraft concepts,

illustrated in figure 7-6. The HLPs are high level building (geometrical) blocks
that a designer can use as a kind of rubberised LEGO blocks.
The HLPs are coupled with capability modules (CMs) to generate discipline
specific system models. The capability modules translate the generic model
format into a specific model format. Every specific model application requires
a separate capability module. Its strength is that all models are deduced from
a single unique system model, preserving consistency between the discipline
specific system models. This is illustrated for several discipline system models
in figure 7-7.
7.3.3 Feasilisation approach building blocks
To define the base of domain model of the feasilisation approach the MDO
framework abstractions (Berends, 2008) are used. Although, the abstraction
levels are renamed to fit within the feasilisation approach. The abstraction
levels used in the feasilisation approach are:
»» Environment
»» System
»» Process
»» Property
128
Building block concepts
concept
model
generic
model
specific
models
figure 7-7: Specific models based on a single generic model defined

using the multi-model generator (La Rocca, 2007)
The environment determines the system context and its purpose. Therefore
the organisation level is renamed to ‘environment’. As explained in chapter
three, the feasilisation approach uses the DEE concept as building block to
define the overall process. The DEE addresses a system design problem and the
framework level is therefore referred to as ‘system’. As typical characteristics,
the system is composed of a search routine and can be decomposed into
subsystems. As explained in chapter four, in conceptual design tools are
often simple formulas to define a model or behaviour values. Both process
information from one from to another, and are therefore renamed to ‘process’.
Systems have property values to define their state. Therefore data level is
referred to as ‘property’.
The HLP concept is used at each abstraction level. Properties can be

decomposed into different types that together can construct the overall
property information, for instance text of numbers. Let us take a document
as an example. A document is composed of paragraphs, headers, figures,
tables, and so on. These primitive data components can be used to define the
overall document. The same can be done for a process, where a process is
defined by process steps and/or sub-processes with specific process type, such
transformation functions or optimisation algorithms. A system can be composed
of various others systems, of which the DEE system is an example. The
environment is composed of elements that define the organisation processes,
the systems engineering process is an example environment type.
The CM concept is used to specify the specific views on each HLP. In this work
the CM concept is used only to define a specific model which can be used to
reload the generic model again. Other applications are not included, such as
129
environment
system
process x
property
[x,y]
figure 7-8: Abstraction levels inherent to the feasilisation

approach; environment, system, process, and property
a number can be represented in different programming languages. Another

example is the use number sets, which can be represented as a list, array,
matrix, or programming language specific data format.
7.4 Engineering primitive abstractions
The process primitives related to these abstraction levels are called

‘engineering primitives’ (Schut, 2008a). The previously introduced knowledge
model (Schreiber, 2000) is used to formalise the engineering primitives. As
explained, a knowledge model consists of; domain knowledge, inference
knowledge, and task knowledge. These components are elaborated for the
engineering primitives. The discussions are based on the conceptual design
phase and the feasilisation approach. In other phases the domain, inference,
and task knowledge may be different.
7.4.1 Environment primitive abstraction
The environment abstraction is the design process performed by the

organisation. The feasilisation approach is situated at this level. Engineers
define requirements, concepts, and tools, using simplification, decomposition
130
Engineering primitive abstractions
and use trial and error methods to find the set of requirements, concepts, and
tools that model the design problem.
The environment domain knowledge is composed of the design problem

knowledge (requirements, concepts, and tools) and the design experience
(previous design solutions) of engineers. The basic components are the
actors and the design knowledge. The architecture of a knowledge system
(see figure 7-8) illustrates the relation between the knowledge outside the
system captured by engineers and other systems and inside the system, by the
knowledge base.
In conceptual design, the environment inferences are the feasilisation

methods used by engineers to address the design problem. These methods
are addressed in the previous chapters. The result of these inferences is a
specific feasilisation problem with a simplified and decomposed design problem
combined with a specific trial and error method.
In conceptual design, the environment task knowledge is to obtain a simplified

and decomposed set of requirements, concepts, and tools that models the
actual design problem accurately enough to obtain a (near) feasible design
solution.
7.4.2 System primitive abstraction
The system abstraction involves the system decomposition and is embodied

by the formal feasilisation process, the multi-level DEE process (introduced in
chapter three), having a fixed set of requirements, concepts, and tools.
System domain knowledge is a specific feasilisation problem with a simplified

and decomposed design problem combined with a specific trial and error
method represented by the architecture is the (multilevel) DEE process.
System inferences are the processes used to search for a feasible solution
to the feasilisation problem. Within a system DEE this is the execution and
coordination of tools in the system search process, respectively defining
concept, model, test, and behaviour. In a multilevel system this included the
cross-level communication, such as the coordination of the subsystems at
system level.
System task knowledge is defined by the requirements. The task is to find the
best and feasible system configuration, defined respectively by the objective
and constraints.
131
7.4.3 Process primitive abstraction
The process abstraction involves the system process components, such as tools
or functions. It addresses the processes used in analysis and synthesis of the
system.
Processes are used to translate information from one form into another. The
process level domain knowledge is the knowledge captured in specialist tools
to translate input information into output information.
The process inference knowledge is to infer the input information with the
domain knowledge captured in the process into the output information. The
specific inference depends on the specialist tool.
Process task knowledge is to provide output information when required. The

task can be performed if the input information is available.
7.4.4 Property primitive abstraction
The property abstraction involves system parameters. The property primitives

structure and maintain system parameter information.
The domain knowledge is the structure and specific parameter information

captured by the property primitive. Possible parameter types are for instance
number and matrix.
Inference knowledge is to store and retrieve the information.
The task knowledge is to provide parameter information when requested.
7.5 Conclusions
This chapter translated the observations done in the previous chapters to a

feasilisation framework based on a discussion on knowledge management and
knowledge engineering. The knowledge management discussion showed that
engineering software can support part of the learning cycle, which is important
to increase the engineer’s productivity. The knowledge engineering discussion
showed that in engineering knowledge systems are based on the knowledge
based engineering (KBE) technology.
To define the building blocks of for an engineering software application

to support the feasilisation approach a concepts from MDO frameworks is
combined with a KBE concept. The MDO concept is based on abstraction,
132
Conclusions
identifying four MDO framework abstraction levels. The KBE concept uses
abstraction to identify high-level primitives with object decomposition and
capability modules with aspect decomposition. These concepts are combined
into the so-called engineering primitives, which are the building blocks for an
engineering software application to support the feasilisation approach.
Concluding, the feasilisation methodology can potentially be supported

by the used of engineering primitives that embody the MDO framework
abstraction and the decomposition approach used by KBE. Combining this with
results from chapter six these primitives should relieve the engineer from
process management and execution tasks, allowing focus on the definition of
requirements, concepts, and tools. In the following chapter, the framework
prototype design and implementation are presented. The application of the
framework prototype is discussed in chapter nine.
This chapter contributes a formal approach to the development of a

feasilisation knowledge system and an assembly of application concepts
that can be used to develop the feasilisation knowledge system. The
chapter introduces and discusses a framework of four engineering primitive
abstractions that can be used to develop the knowledge system.
The next chapter addresses the design of the feasilisation knowledge system
based on the engineering primitive framework.
133
134
Introduction
Chapter 8: Engineering primitive

framework
8.1 Introduction
The objective of this chapter is to define a framework design for the

engineering primitive concept introduced in the previous chapter. The
engineering primitive framework design focuses on functional design.
The building blocks of feasilisation approach introduced in chapter three are

defined in the previous chapter. These building blocks are based on the MDO
framework abstraction levels: environment, system, process, and property. The
building blocks of these abstraction levels are called engineering primitives.
This chapter elaborates on this concept, addressing functional design and
software design of the engineering primitive framework. Key questions to be
answered:
»» Which actors interact in the framework environment?

»» What is the primitive functional design?
»» What is the primitive software design?
»» How is the framework prototype implemented?
First the framework actors are discussed. Secondly, the functional design
is presented, followed by an overview of the software design. Finally an
implementation of the framework is addressed.
8.2 Actors
The engineering primitive framework supports activities of the engineer in the

feasilisation approach. In that approach the engineer can have different roles.
In the feasilisation approach multiple actors are involved. In the previous
chapter a basic configuration of a knowledge system is presented (see figure
7-3). From the discussion surfaced that these knowledge systems have both
human and software system actors. For the framework four principal actors are
identified:
»» Design specialist
»» Search specialist
»» Performance specialist
»» Specialist software system
135
Chapter 8: Engineering primitive framework
system boundary
design
specialist
specialist
engineering primitive tool
framework
search
specialist
performance
specialist
figure 8-1: Engineering primitive framework system and actors
Three different human specialists are involved, from the fields of design,
search and performance (or analysis disciplines), and a software system actor
is involved, the specialist software system. The actors are illustrated in figure
8-1.
8.2.1 Design specialist actor
The design specialist objective is to obtain a feasible system solution, changing

requirements, system concept, and analysis tools. This was discussed in
chapter 6, in which the main activities of the designer are to change the
design problem, and to inspect design problem and solution.
Changing the design problem involves the ability to change requirements,

concepts, and tools. The change in requirements implies changing objectives,
test cases, and constraints. The change in concepts must allow the design
specialist to define their own problem structure. Given a certain structure, the
design specialist changes tools to meet a certain trade-off between calculation
accuracy and time.
The framework reporting must be such that the design specialist is able to
inspect the results and trace information by dependency. This also surfaced in
the definition of a new design problem, where a design specialist made errors
in the description, such as leaving out required capabilities or constraints. Part
of these errors surfaced during the execution of the design process, since some
136
Actors
information could not be obtained. The design specialist must be able to trace
the error. The design specialist requires the system, process, and property
objects to be easily compiled into design problems. The design specialist is
involved in adapting environment primitives to encompass specific task and
domain knowledge that together define a specific design problem.
8.2.2 Search specialist actor
Another user of the framework is the search specialist. Although the search
and design specialist are often the same person, in principle, the search
specialist provides a service to the designer by providing tools that search for
the optimal system concept, given a certain set of objectives and constraints.
The actor functions at the environment abstraction level of the framework.
These methods differ per search problem (e.g. the example in chapter six
featured a nonlinear constraint solver). The search specialist applies methods
that optimise the search strategy for the given problem. The search specialist
adds inference knowledge to the system through the addition of the search
methods in a process primitive.
To perform these activities, a search specialist needs to flexibly deploy

different search tools and strategies. This implies that a system design problem
is addressed differently depending on the search strategy, such as single-level
or multi-level optimisation.
8.2.3 Performance specialist actor
The performance specialist or discipline specialist is a user of the framework,

located at the environment abstraction level. The performance specialist main
objective for use is to support the design specialist with discipline inference
knowledge. The inference knowledge is captured in modelling and analysis
tools (see chapter three), enabling the design specialist to relate requirements
to concept. The specialist must be able to change or replace the tool in the
framework.
The main activities of a performance specialist are to integrate tools. To

support inclusion of new tools the integration must be simple.
8.2.4 Specialist tool actor
A specialist tool provides to the framework specialist inference knowledge

captured in its software. For instance, the search tools provide search
knowledge, and the performance tools provide concept, model, test, or
137
performance knowledge to process objects. The actor functions at the system

and process abstraction levels of the framework.
The software system type ranges from script to executable program. For
inference the tools need to be able to connect to the framework. In case of a
script, the execution is required to take place in the proper environment. The
related application itself can be located on a different machine, working under
a different operating system, and within a different network.
The main activity is the execution of inference rules embedded in its software.
Generally input information must be available in a specific format to start
execution. The output information is also provided in a specific format.
8.3 Framework architecture
At environment level the engineering primitive framework (EPF) functions

as a knowledge system actor. In the previous chapter thee basic knowledge
system components are introduced: knowledge base, inference engine, editor,
interface, and memory. These components are discussed here for the EPF.
Editor
The editor allows the human actors to define the knowledge base for the
specific design problem. The editor uses a different representation of the
knowledge base. With the editor the design problem is assembled based
on the engineering primitive building blocks, domain knowledge, inference
knowledge, and task knowledge. An example simple editor is presented in the
following chapter, see section 9.3.4.
Knowledge base
The knowledge base contains the design knowledge. The editor is used to
fill and configure the knowledge base. The knowledge base contains a static
definition of the design problem. This includes definition of the requirements,
concepts and tools based on domain knowledge, inference knowledge, and
task knowledge. The concept is defined by the ‘system primitives’ define the
(object) decomposition. The requirements are defined by ‘property primitives’
within these system primitives. The tools are represented by ‘process
primitives’ that can contain knowledge rules that can be used to infer the
static definition. These tools are not available within the knowledge base, only
a reference to these tools (and their capabilities) is used, such as a reference
to a tool executable function. The tools itself are represented by the specialist
tool actors.
138
Framework architecture
knowledge base memory

system design inference system
problem
engine instantiation
solution
specification
figure 8-2: Inference engine 2-way interface between knowledge

base and memory, and the system design solution is an extension of
the system design problem with the solution specification
Inference engine
The inference engine is used to generate the solutions and contains the
system, process, and property engineering primitives. The inference engine
uses the knowledge base to define the feasilisation problem. After solution
generation these solutions are stored in the knowledge base. To support
storage of the system solutions in the knowledge base the system solution
and system problem are based on the same domain schema. Thus the system
solution is the system problem, including the design results. This means
that the system solution can also be input to the inference engine. This is
The inference engine uses the instantiation of the knowledge base in memory
to obtain the system solution. To find a solution the feasilisation process
discussed in chapter three is used by the inference engine. This process is part
of the system primitive, discussed in more detail in section 8.4.3.
To include the specialist tool actors the inference engine is required to provide
the correct input information, optionally has to start execution, and has to
retrieve the output information. This is part of the process primitive activity
and is explained in section 8.5.2 in more detail.
Interface
The interface allows the inference engine to connect to the various specialist
tool actors. This interface is addressed by the process primitive, discussed in
more detail in section 8.5.2.
Memory
The memory is used by the inference engine to instantiate the design problem
defined in the knowledge base.
139
8.4 Environment primitive design
The environment primitive is the highest abstraction and involves MDO

organisation; the actors and engineering primitive framework. The
environment primitive functional flow is based on the design process. In this
section the different environment types and its generic functional flow are
presented.
8.4.1 Types
The environment primitive is the design process in the organisation. As

explained in chapter two, the design process of complex systems features
different phases, each with different features. In this work the environment is
considered for the conceptual design process of complex systems implemented
with the feasilisation approach. Other design process types are out of scope.
Environment primitive types are:
»» Feasilisation approach
8.4.2 Functional flow
The environment primitive process is the feasilisation approach. The process

discussed in chapter three is presented here in figure 8-3. The process flow
presented in chapter three (see figure 3-10) is extended with two steps;
generate system input, and store system output.
Assemble system design problem
As explained in chapter six, the first step is to define the design problem. This
activity is performed by the human actors. The design problem is based on
the feasilisation approach and thus features simplification and decomposition.
First, the design specialist actor defines the requirements, and the system
concept. The performance specialist actor supports the design by providing
input on the available tools (hence specialist software system actors) that can
be used to evaluate the system concept. Together the tools are selected and
appended to the design problem. The search specialist actor integrates an
optimisation strategy and the required search tools (hence specialist software
system actors) into the system design problem. This defines the design problem
knowledge base.
Generate system input
The knowledge base is translated to input for the inference engine. The
140
System primitive design
e?
bl
ta
p
assemble generate store evaluate
ce
generate yes
ac
system design system system system
system input
problem solutions output performance no
figure 8-3: Environment primitive functional flow
knowledge base can contain multiple design problems. For each design
problem an input for the inference engine is generated.
Generate system solutions
The design problem input is provided to the inference engine to generate the
solutions. First the inference engine validates the design problem. If valid
the solutions are generated, otherwise the error in the problem definition is
provided to the human actors. During the solution generation the inference
engine makes use of the tools (hence specialist software system actors) that
the performance and search specialist have appended to the design problem.
The result of the optimisation problem is appended to the design problem,
specifying the solution.
Store system output
This solution specification captured in memory is stored in the knowledge base

and provided to the human actors for inspection. The design solution is stored
in the same format as the design problem input, such that output can be used
as input (see figure 8-2).
Evaluate system performance
The solutions are evaluated by the human actors to inspect the solution
results, and effectiveness of the optimisation strategy and tools. If the solution
is acceptable the design process is completed, otherwise the human actors
need to identify the required change in the design problem and initiate a next
iteration.
8.5 System primitive design
The system primitives are the second abstraction level and involve the MDO
framework, the search problem represented by the DEE process. The system
primitive core includes the inference engine and memory of the framework
components. In this section the different system types and its generic
functional flow are presented.
141
8.5.1 Types
The system primitive embodies the DEE process. In chapter three, the DEE is
used as a single MDO framework and as component to build the feasilisation
MDO framework. This defines two system types: ‘single-level’ and ‘system-
of-systems’ (hence multilevel). Both types are based on a fixed set of
requirements, concepts, and tools, defining one system sizing problem. System
primitive types are:
»» Single-level
»» System-of-systems
However, in the previous chapter also surfaced that many iterations are
caused by changing requirements. The domain of this requirements change
can often be estimated by the engineer. As explained in chapter six, these
variable requirements can be discretised to a set of requirements, yielding
a set of similar design problems. In the case of variable requirements
the system primitive has to find the best feasible solution range for the
variable requirements domain, defined by the discrete set of requirements.
Here, a ‘surrogate-system’ type is included as an example to evaluate the
effectiveness of this discretised problem domain. A third type is:
»» Surrogate-system
See chapter six on performance evaluation or the following chapter for

application details. The surrogate system uses a requirements domain. In case
of multiple objectives this is a deliberation between the objectives. Other
variations are bounds on the system and model constraints
The generic functional flow (see figure 8-4) of the system primitives is
discussed here. The differences between the types are addressed during this
discussion.
Instantiate system
The environment primitive generates input for the system primitive used to
instantiate the system primitive into memory. During this instantiation the
lower level primitives are instantiated as well. The instantiation capability is
an aspect of the system, process, and property primitives. The result of the
instantiation is an optimisation problem.
142
System primitive design
instantiate validate operate store

system system system output
figure 8-4: Basic functional flow of the system primitive
Validate system
Before the optimisation problem can be addressed first the problem needs to
be instantiated and validated. This instantiation involves the formal definition
of the optimisation problem. By interrogating all lower level systems the
top-level system obtains the optimisation properties. Secondly, each system
is responsible to validate itself whether the objective and constraint function
output can be related to input parameters or variable parameters.
The process and property primitives are chained to generate the objective and
constraint output parameters based on the available input parameters. This
chaining is based on the request based approach, called backward chaining.
The required objective and constraint parameters are appended in a list and
iteratively matched to respectively input parameters, model parameters, test
parameters, and behaviour parameters. If found, the input of the process (with
these parameters as output) is appended to the list. If the input of a process is
based on subsystem parameters, the parameters are defined at the subsystem
as required output. This is performed until all the parameters are related to
input or variable parameters. The validation yields the multi-level DEE process
(see chapter three). This process flow is illustrated in appendix A.
Operate system
The system operation is responsible for finding the best feasible set of variable
parameter values. During the operation the validated process is used to
translate the variable parameters into objective and constraint parameters.
The operation is performed in the three steps (see figure 8-5); define variable
parameter values, update processes, and evaluate performance. Update
internal processes involves the formalised process discussed in chapter
three; define concept, define model, define test, and define behaviour. The
concept is defined by defining values for the variable parameters. The system
model properties are synthesised based on the concept and subsystem model
properties. The system test properties are translated to the subsystem test
properties. The test properties are used to define the behaviour properties at
every system level.
The operation of the ‘surrogate system’ type extends on the previous one. The
type uses a requirements domain, which is translated into a set of discrete
143
define perform
check search store provide
optimisation system
problem output output
process optimisation
?
b le
ta
p
ce
yes
define variable update internal evaluate
ac
values processes performance
no
figure 8-5: Basic functional flow of the system primitive ‘operate system’ function
unique requirements sets. For instance in case of a multi-objective problem

the deliberation between the objectives is defined by weight factors multiplied
to each objective. This is for instance discretised to three weight factor cases;
0:1, 1:1, and 1:0. First these discrete search problems are defined. Secondly,
for each search problem a system primitive is defined, which is operated as
described before. The search results of these systems are collected and stored
by the ‘surrogate system’. This is illustrated in figure 8-6.
Store output
To store the solution captured in memory the primitives are stored in the
knowledge base in the same format as is used to instantiate them.
8.6 Process primitive design
The process primitives are the third abstraction level and address the inclusion
of design problem inference knowledge, via the integration of external tools
and functions. In this section the different process types and its generic
functional flow are presented.
8.6.1 Types
The process primitives involve tools or functions. Three types are addressed
in this work. ‘Function’ is used to include functional scripts to process
information. ‘Agent’ is used to include external tools or applications to process
information, and is based on a MDO communication framework developed by
Berends (2008). Finally, ‘process-of-processes’ is used to include multilevel
processes, a process with multiple internal processes. The types are:
define search define operate store provide

problems subsystems subsystems output output
figure 8-6: Basic functional flow of the system primitive ‘operate

system’ function for the ‘surrogate system’ type
144
Process primitive design
instantiate validate operate store

process process process output
figure 8-7: Basic functional flow of the process primitive
»» Function
»» Agent
»» Process-of-processes
The generic functional flow (see figure 8-7) of the process primitives is
discussion.
Instantiate process
The process primitives are instantiated like the system primitives. The
instantiation yields a process primitive in memory.
Validate process
The validation of the process involves the validation of execution of the

external function or tool for the first two types, and the validation and
definition of the internal process for the third type. The validation of the
execution is a check if the input and output of the tool or function match the
process primitive input and output. The validation of the internal processes
is based on backward chaining of the output parameters through the internal
processes to the input parameters.
Operate process
During the operation, the process primitive is responsible to translate the input
execute
define external
check input external
function input
function
retrieve
store provide
external
output output
function output
figure 8-8: Basic functional flow of the process primitive ‘operate

process’ function for a ‘function’ type process
145
?
ed
at
pd
lu
update yes store provide
al
check input
sub-processes output output
no
define request retrieve

sub-process sub-process sub-process
input update output
figure 8-9: Basic functional flow of the process primitive ‘operate

process’ function for a ‘process of processes’ type process
parameters into output parameters. The operation function of the first two
types is specified in figure 8-8. The operation is performed in six steps. First
the input is checked for availability, then the input is translated to input for
the tool or function. Thirdly, the tool or function is executed, where after the
output information is translated to be captured by the process primitive. The
output is stored in memory and provided as output.
The operation of the ‘process-of-processes’ type is specified in figure 8-9. In

contract to the previous, here the sub-processes are updated from input to
output. Starting with the first process in the flow, the input of the sub-process
is defined, then the sub-process is updated, and finally the output of the
sub-process is retrieved. This is repeated until all sub-processes are updated.
Then the output of the process is stored in memory and provided.
Store output
To store the information captured in memory the primitives are stored in the
8.7 Property primitive design
The property primitive is the lowest abstraction level and involves the
parameters involved in the design process. In this section the different
property types and its generic functional flow are presented.
8.7.1 Types
The property primitives address parameter information. The types used are
based on simple parameters, such as ‘number’ and ‘text’, and composed
parameters defined by among others ‘array’ and ‘property-of-properties’,
these parameters are composed of sub-parameters. The types used in this work
146
Property primitive design
are:
»» Number
»» Text
»» Array
»» Property-of-properties
»» Structure
»» Cell-array
The latter two types are specific to the Matlab language, and included for the
implementation of the prototype (see section 8.9).
The generic functional flow (see figure 8-10) of the property primitives is
discussion.
Instantiate property
The property primitives are instantiated like the process and system
primitives. The instantiation yields a property primitive in memory.
Validate property
The validation of the property is to verify that the type of the property is
consistent with the parameter information in memory.
Operate property
In operation properties change parameter values and provide parameter

values. The property primitives also maintain other information on the
parameters. For example, a number property can be part of an objective
function and has therefore the objective to minimise of maximise its value.
Constraints are number properties with bounds and the property primitive
maintains the feasibility of the current parameter value.
instantiate validate operate

store
property property property
figure 8-10: Basic functional flow of the property primitive
147
Store
To store the information captured in memory the primitives are stored in the
8.8 Framework software design
The previous sections provided an overview of the framework functional

design. This section will elaborate on the primitive software design. The
framework is represented by the environment primitive and is designed based
on the structure of a knowledge system, illustrated in figure 7-3 and explained
in section 8.3.
The software design of the knowledge system modules is separated. This work
focused on the development of the inference engine module in relation to the
knowledge base, the other modules of the knowledge system are left out of
scope for the discussion.
In this work ontologies are used as inspiration to structure information.

However no formal ontology is developed. This is out of scope for this work and
the definition of an ontology is recommended for further work. The structure
presented in the following sections has been developed based on a mix of
existing ontologies and pragmatic development. The reader is referred to the
next chapter for example implementations of the designed structures.
8.8.1 Knowledge base software design
The knowledge base software design is restricted to a nested data container.

The data container is designed based on the system decomposition, addressed
in chapter three (see figure 3-4). The knowledge base is composed of generic
system domains. These generic system domains can have specific system
domain topology type, for instance a panel can be a stiffened of unstiffened
type.
Both generic system domain and system domain are divided into three
domains; properties, core, and subsystems. The properties are divided into
function, performance, constraint, and model domains. Each domain contains
property definitions. The core is divided into the two V domains of the
W-diagram, illustrated in figure 3-9. The first V addresses the system model,
the other V addresses the system test. The subdivision is used to allocate the
processes and properties to their domain within the system. Within each V the
process and property primitives are defined. The subsystem domain contains a
reference to another system domain.
148
Framework software design
The reader is referred to section 9.5 for examples.
8.8.2 Interface software design
The interface design is between the knowledge base and the inference engine
is a data format.
The data format is based on a representation of a single system design. The

generic and specific domains are integrated into a single system definition.
This holds also for the subsystem definitions which are nested in the parent
system definition.
The reader is referred to section 9.4 for example interface definitions.
8.8.3 Inference engine software design
The inference engine features the system, process, and property primitives.
The primitive software class architecture is presented in figure 8-11. Per class
an overview of the principal attributes and external methods are illustrated in
the figure.
The system, process, and property primitives are implemented based on

three class abstraction levels. The engineering primitives have one primitive
superclass. This superclass defines the generic attributes and methods for the
engineering primitives. An example generic attribute is ‘name’. An example
generic method is the xml-interface (see next section) used to instantiate and
to store the engineering primitives.
In the previous sections (sections 8.5 through 8.7) surfaced that every
primitive has different type specialisations. These types have common
attributes and methods. Therefore a second class abstraction level is included
per engineering primitive. A specific engineering primitive superclass is used
to define primitive specific attributes and methods. For example, the generic
functional flow that is the same for all primitive types.
To translate the interface format into primitive objects in memory a parser

is developed that iterates through the interface file and instantiates the
related objects in memory. On instantiation the configuration of the object is
determined by the information in the interface file. To generate the output,
the primitive class has a generic ‘to-xml’ method that writes the requested
object and its children to the same interface format.
The reader is referred to the next chapter for examples.
149
Single-level System-surrogate System-of-systems

-model -master -model
-test -systems -test
-search -surrogate -search
-subsystems
*
1
*
System
1
-objective
-constraint
1 -test
Propery-of-properties -model
-properties +get-properties()
*
1
Primitive
XML
Number -name
-variability 1* -type
-bounds +to-xml()
Property +update()
-value *
Text +get-value() 1
+set-value() Process
-input
*
-output
Array +request()
*
-size
-properties 1
Process-of-processes Function Agent XML-RPC

-processes -source -source
figure 8-11: Inference engine architecture; addressing the

system, process, and property primitive classes
8.9 Framework implementation
As mentioned in the introduction is this prototype (Schut, 2008) a based on

iterative development of earlier prototypes. This prototype is developed based
on test-driven development combined with a bottom-up approach, starting
development of the property primitives and working towards the environment
primitives.
The prototype implementation requirements are presented first. This is

followed by the implementation design option selection.
150
Framework implementation
8.9.1 Implementation requirements
The implementation adds constraint requirements to the development of

the prototype. The main constraint is a short development time, required to
ensure that the development will result in a working prototype within the
time span of this research. This promotes the use as much as possible off-the-
shelf capabilities, reducing development time for required capabilities. To
reduce the number of interfaces between the different modules, an integrated
development environment with many available off-the-shelf capabilities will
reduce the impact of interfaces on the development time.
In this case, an integrated environment with available capabilities is preferred.

These capabilities encompass a suitable optimisation routine for an effective
implementation of the optimisation problem. Secondly, the programming
language should support both object oriented programming for the engineering
class definitions and function scripts for the performance specialist and
specialist tool actors. The interface format should be of a hierarchical nature
and should be human inspectable.
8.9.2 Inference engine
For the implementation two programming language environments are

considered; Python and Matlab (see table 8-1). The Matlab version (2007b)
allowed for a kind of object oriented programming based on so-called class
directories (Matlab, 2007). Other environments are left out of this selection
process, such as Scilab (an open-source Matlab), which did not have the
object-oriented foundation, or C++, which involved a too long learning curve.
Five criteria are used to score the environments. In line with the requirements,
the available tools and the level of integration of the environment, weigh the
heaviest (score 5). The general platform language capability and usability are
moderately important (score 3). Platform cost is taken into account, but is
considered relative unimportant (score 1). The usability is added to encompass
for the available environment experience.
As basic programming languages, for Python many tools have been developed,
but these are not ready available and need to be identified and implemented
first. In contradiction, Matlab as commercial tool has many integrated
toolboxes that can be easily identified. The level of integration refers to the
efforts required to build up the prototype. Python scores poorly, because of
the extra required developments. Matlab is an integrated environment and
consequently scores best. The platform capabilities refer to programming
language capabilities. Here, Python scores best, and Matlab average.
151
Matlab is considered as usable environment, as commercial tool with proper

debugger and documentation. Python has similar usability, having a proper
debugger and the extensiveness of documentation through its open-source
network. Purchasing costs are high in case of Matlab and low for the open-
source Python package. After multiplication of the weights and grades a final
score is obtained (maximum 85). Matlab is traded to be the most promising
development environment for the prototype with a score of 69.
table 8-1: Primitive class language trade-off
integration
Language
Available
Usability
(max 85)
Level of
Total
tools
Cost
Weights 5 5 3 3 1
Python 3 1 5 3 5 49
Matlab 5 5 3 3 1 69
8.9.3 Knowledge base
For the implementation the considered knowledge base formats are XML and
SQL (see table 8-2). Other formats are left out, such as flat text, which has no
predefined hierarchical format, or knowledge base modelling tools, which are
expected to result in prototype scope creep.
Three criteria are used to score the design options. The importance of the
criteria is derived from the prototype requirement discussion. The possibility
of inspecting the data is considered important (score 5). Interfacing complexity
addresses the complexity of the implementation and is considered to be of
medium importance (score 3). The scalability is taken into account, but is
considered least important (score 1).
The inspectability of XML is considered best, especially since the file sizes are
expected to be small. The SQL database is inspected through a communication
layer, which is graded average. The interfacing complexity of XML files
are graded good, since they involve file read and write actions only. The
SQL database is considered relatively difficult to interface with especially
in the prototype setting, which changes continuously due to the iterative
development nature. On the other hand, the scalability of a SQL database
strongly outperforms the scalability of XML. After multiplication of the weights
and grades a final score is obtained (maximum 45). XML is traded to be the
most promising interface format for the prototype with a score of 40.
152
Conclusions
table 8-2: Interface language trade-off
Inspectability
Interfacing
Scalability
(max 45)
Total
Weights 5 3 1
XML 5 5 1 40
SQL 3 1 5 23
8.9.4 Editor
The selected editor is the Windows folder structure, used to define the
knowledge base. Thus for the editor no trade-off is performed. The editor is
selected based on simplicity and accessibility.
The folder structure offered a hierarchical interface that could be used to

capture the hierarchical primitive structure. The editor is extended with a
Python script file to translate the information captured in the Windows folder
structure into the proper XML structure that is used to interface with the
inference engine.
8.10 Conclusions
This chapter discussed the functional design and software design of the
engineering primitive framework. The framework features the basic
architecture of a knowledge system and has four different actors: design
specialist, search specialist, performance specialist, and specialist tool. To
support reuse, the primitives all have a generic aspect capability such that the
input used to instantiate the primitives has the same structure as the output
of the primitives. For the design of the engineering primitives abstraction is
used to optimally reuse the information. Per primitive specific types are used
to specialise the activities. Combined these primitives types represent their
primitive abstraction. To implement the framework prototype, Matlab is used
as programming environment based on the availability of tools and the level
of integration. XML is used as interface language as it is easy inspectable and
relatively simple to integrate.
This chapter contributes the design of the engineering primitive framework.

The functional design of the primitives is presented and an overview of the
software class design.
153
The following chapter addresses the framework prototype. The prototype

is developed in the Matlab environment and uses XML as data storage and
communication.
154
Introduction
Chapter 9: Framework prototype
9.1 Introduction
The objective of this chapter is to introduce the framework prototype, to

explain the implementation and usability of the framework. The framework is
based on the functional design and software design discussed in the previous
chapter.
The discussion is based on the panel design problem discussed in chapter six.
For details on the implementation of the design problem the reader is referred
to chapter six. The engineering primitive functional flows are discussed in the
previous chapter as well as the XML interface. The XML interface structure is
generated from the knowledge base and used to instantiate the engineering
primitives. The primitives output the design solution in the same XML
format. This chapter illustrates the implementation of the knowledge base,
the generation of the XML input files and the updating of the XML through
instantiation of engineering primitives. Key questions are:
»» What are the features of the XML interface?

»» What are the features of the knowledge base?
»» How does the prototype support feasilisation?
»» What are the prototype benefits and drawbacks?
First, example input and output XML structures for the engineering primitives
are discussed, addressing respectively property, process, and system
primitives. Secondly, the structure and details of the knowledge base are
discussed. This is followed by an example illustrating the use of the framework
for the feasilisation approach. Finally, observations and conclusions are
presented.
9.2 Property primitives
The property primitive addresses parameters used in the design process.

As explained in the previous chapter different parameter types are used.
To illustrate the property primitive inference, the initial and updated XML
structured are discussed. First the XML initial structures from the knowledge
base are discussed, followed by the XML structures after the updating by the
engineering primitives.
155
figure 9-1: Example engineering property primitive XML structure for

types; text (top left), float (bottom left), and array (right)
9.2.1 Initial definition
Example property primitives XML structures used to define the design problem
in the knowledge base are illustrated in figure 9-1; ‘text’, ‘number’ (with
subtype ‘float’), and ‘array’.
In the previous chapter the property primitive class architecture is introduced.

The information required to instantiate the property primitive classes is found
in this XML structure. For instance, all the XML structures feature the same
name ‘property’ and have a ‘type’ and ‘name’ specified. This information is
required to define the basic attributes of the property primitive. Also specific
information is defined. Examples are the ‘variability’ and ‘bounds’ attributes in
case of the number type, or the ‘size’ and ‘properties’ of the array.
input
output
figure 9-2: Example update of the XML structure for a bounded property primitive
156
Process primitives
input
output
figure 9-3: Example update of the XML structure for a objective property primitive
9.2.2 Updated definition
The basic property information is the ‘value’ attribute, defining for instance
the ‘text’ or ‘number’ value. At definition of the design problem not all
parameters have the ‘value’ defined, which is the task of the optimisation
process. The ‘value’ information of the property primitives is updated during
that process.
An example is illustrated in figure 9-2 for a bounded property called

‘bucklingState’. Next to an updated value field also the attribute ‘feasibility’
is added, which defined whether the value of the property is acceptable in
respect to its defined bounds.
Another example is illustrated in figure 9-3 for an variable property. The

property defines an objective as the variability has a preference to be
minimised. After updating the property includes a ‘value’ and an ‘objective’
attribute. This property is part of a multi-objective having a ‘fraction’ defined
for the ‘objective’. To normalise the value in the objective statement, the
value is scaled based on the lower and upper domain value. For more details
on the objective definition, see section 9.5.
9.3 Process primitives
The process primitive addresses functions and tools used in the design
process. As explained in the previous chapter different process types are used.
To illustrate the process primitive inference, the initial and updated XML
157
An example process primitive XML structure used to include functions in the

knowledge base is illustrated in figure 9-4.
In the previous chapter the process primitive class architecture is introduced.

The information required to instantiate the process primitive function class
is found in this XML structure. For instance, the XML structure features the
generic primitive attributes ‘name’ and ‘type’ and has the specific process
attributes ‘process’, ‘input’, and ‘output’. In the example, the ‘input’ and
‘output’ are composed of property primitives.
The illustrated example is of the function type, which involves a Matlab m-file
function, illustrated in the figure. In this implementation all the functions
address Matlab functions. The specific information related to this function type
is defined in the ‘source’. The location of the function is defined by the ‘path’.
To execute this function, the position order of the input and output properties
is required. These are defined by the ‘inputNames’ and the ‘outputNames’
attributes. The agent process primitive type uses the same implementation.
The process of processes process primitive type uses the same generic process
attributes ‘input’ and ‘output’, but has a different ‘source’ definition. At
Matlab m-function
figure 9-4: Example engineering process primitive XML knowledge

base structure for function type (Matlab m-file function)
158
System primitives
input output
figure 9-5: Example update of the XML structure for a function process
primitive; the output property ‘area’ is updated with a value
definition, the ‘source’ of that type is a list with process primitives, similar to
the ‘input’ attribute property list.
The basic process primitive information to be updated is the ‘output’

attribute. An example update is illustrated in figure 9-5. The instantiation and
update of the process primitives resulted in a value for the output property
‘area’. The property primitive value information is defined by the process
primitive after execution of the ‘source’.
For the function type the information in the ‘source’ does not change during
the update. This is different for the process of processes type. As explained
in the previous chapter the type is composed of multiple process primitives.
In order to provide the output information these processes are inferred such
the output information can be related to the input information. The result in
captured a fixed process tree.
An example is illustrated in figure 9-6. The ‘processes’ defined in the ‘source’

are related through the ‘tree’. Below the XML structure the tree process flow
is visualised that is captured by the ‘tree’ attribute. The processes in the
‘source’ are updated with the information that belongs to the final state of the
process primitive. This specifies the information of the process primitive and
makes ‘output’ traceable to ‘input’.
9.4 System primitives
The system primitive addresses the feasilisation process used in the design
process. As explained in the previous chapter different system types are used.
159
strain
material_
tsaiHill material_tsaiHill stress S
strainToStress
s22t
s11t
s12
s11c
s22c
figure 9-6: Example XML structure update of the process of processes type process
primitive. The ‘source tree’ is added that defines the process tree, relating the
‘output’ to the ‘ input’. The ‘source tree’ process diagram is illustrated below.
160
System primitives
The system
parameters define
the optimisation
problem
The system core

defines the
inferences used in
optimisation
figure 9-7: Example engineering system primitive XML

knowledge base structure for single level type
To illustrate the system primitive inference, the initial and updated XML
An example system primitive XML structure used to define an optimisation

problem in the knowledge base is illustrated in figure 9-7.
In the previous chapter the system primitive class architecture is introduced.

The information required to instantiate the system primitive singleLevel class
is found in this XML structure. For instance, the XML structure features the
generic primitive attributes ‘name’ and ‘type’ and has the specific system
attributes ‘system’, ‘properties’, and ‘core’. In the example, the ‘properties’
are composed of property primitives and define the optimisation problem. The
‘core’ defines the inferences used in the optimisation.
161
System properties
The search problem is defined by the ‘properties’. The objective properties

define the objective value. As explained for the property primitive, the
objective properties are integrated into a single value using an objective
fraction. To obtain a minimisation problem the objective value of ‘area’ is
subtracted from one before the value is summed with the ‘weight’.
The system constraints are defined by the constraint properties. As illustrated

for the property primitives, these properties have bounds defined which are
used in the optimisation problem definition. The model constraints are defined
by the model properties, defining the variable parameters and the bounds on
that variability.
The test properties define the test cases used to determine the behaviour.
The system constraints constrain the system behaviour. Consequently, they are
determined for each applicable test case.
These ‘properties’ are the same for all implemented systems. The type specific
information is included in the ‘core’ of the XML structure. However, in the
implementation the surrogate system is implemented different. As explained
in the previous chapter, the ‘system surrogate’ uses a requirements domain.
The ‘properties’ of the system example in illustrated in figure 9-8 define a
requirements domain of objective, test, and model. The objective domain is
obtained by not specifying the deliberation between the objectives. In the
example, the test domain is defined by the test case with a domain, defined by
bounds. The same is done to define the model domain.
System processes
The ‘core’ defines the processes used to solve the optimisation problem.
Through inference these processes are related. Here, the inference is the
feasilisation process, introduced in chapter three. This feasilisation process is
implemented with a trial and error or search process combined with the four
steps of the feasilisation process; define concept, define model, define test,
and define behaviour.
The feasilisation process is used to relate the variable parameters to the

objective and constraint properties. By changing the variable parameters and
inspecting the resulting objective and constraint property values, the search
process find the best feasible set of variable parameter values. The model
and test input are process of processes type process primitives. The initial
definition is a list with the processes that can be considered by the system
162
System primitives
The system
‘properties’ define
the requirements
domain; each set
defines the specific
properties of the
optimisation problem
The master system

‘properties’ define
the generic
properties of the
optimisation problem

knowledge base structure for system surrogate type
validation that defines the process tree used to relate the variable parameters
to the objective and constraint properties.
The ‘system of systems’ type of system primitive extend on the ‘single level’
type with ‘sub systems’ defined in the ‘core’. An example XML structure with
a multi-level system definition is illustrated in figure 9-9. The figure shows
the hierarchic use of the system primitive to model the decomposed system
architecture used in feasilisation. The ‘surrogate system’ type uses the
‘master’ system to define the system problem. Combined with the ‘properties’
it defines the complete problem.
163

knowledge base structure for system of systems type
The update is of the ‘properties’ of the system primitive. An example update

of these ‘properties’ is illustrated in figure 9-10. The figure shows the added
value to the objective, constraint, test, and model property primitives. The
update is a result of inference of the ‘source’, which depends on the system
primitive type.
The update of the ‘single level’ and ‘system of systems’ type ‘source’ is
realised through the update of the internal model and test process primitives.
The inference process discussed in the previous chapter relates the objective
and constraint properties to the model and test properties. The resulting
process tree is captured in the model and test primitives in ‘core’ of the
‘system of systems’ type, illustrated in the bottom of figure 9-10. The update
of the multi-level process is illustrated for the cascading of the test case (in
the example ‘testCase1’) in figure 9-11. The XML structure features can be
used to illustrate a similar traceability for the other steps of the formalised
process discussed in chapter three, such as the bottom-up multi-level system
model synthesis process. The search process used to update the system
properties is illustrated for the top-level system schematically in figure 9-12.
The update of the ‘surrogate system’ translates the ‘properties’ domain into
a discrete set of ‘properties’. The domain is discretised by specifying for
instance the objective fraction of the objective properties, as illustrated in
164
System primitives
figure 9-3. This yields a set of ‘properties’ and each is combined with the
‘core master’ system to obtain a specific system primitive search problems.
The update of these system primitives result in a solution specification for
each of these systems. However, the amount of information generated in this
fashion became too large to contain in a single XML file. To solve this storage
updated
updated
updated
updated
updated
updated
figure 9-10: Example updated ‘properties’ of the engineering system

primitive XML structure for system of systems type; the arrows illustrate
the updated property primitive values of the system ‘properties’
165
system
process
system
process
system
figure 9-11: Example cascading of a test case through the multi-level system
architecture captured in the XML structure; iteratively from system ‘properties’
through the system ‘core’ test process to subsystem ‘properties’
166
System primitives
panel system
search
variable objective
variables stiffener- update internal objective
pre- cost post-
‘x’ spacing processes ‘f’
processer processor
subSystem weight
stiffener
constraint
subSystem max-stiffener- constraints
spacing
post- ‘c’
skin
processor
min-stiffener-
sapcing
bucklingState
subSystem
stiffener
subSystem
skin
model process-
length cost
of-processes
width weight
max-stiffener-
costPerHour
spacing
stiffener- min-stiffener-
spacing spacing
testCase1
subSystem
agentInfo A process-of- stiffener
processes
dbFunction- subSystem
B
Path skin
batchSize D bucklingState
subSystem
zNeutral
stiffener
subSystem
width
skin
length
subSystem
skin length
figure 9-12: Search process used to find the system properties,

illustrated for the top-level system. The multi-level process
surfaces in data elements of its subsystems, coloured grey.
167
Windows folder structure
figure 9-13: Example output of the ‘surrogate system’ type; based

on a combination of XML and the Windows folder structure
problem the Windows folder structure is used to store the separate system
primitive XML structures, illustrated in figure 9-13. The storage problem is
discussed in more detail in section 9.6.
9.5 Environment primitive
The environment primitive addresses the conceptual design phase of the

design process and the definition of the feasilisation problem. The environment
primitive abstraction addresses the interface between the actors and the
engineering primitive framework. As explained in the previous chapter does
the environment primitive involve; the problem assembly, generate system
input, generate solutions, store system output, and evaluate solutions. The
steps are described respectively.
9.5.1 Problem assembly
The implementation of the problem assembly is focused on the generation

of the previously described XML structures. Figure 9-13 illustrates that these
structures become relatively large. For instance, the example panel problem is
composed of 13 system primitives, 432 process primitives, and 3560 property
primitives. To describe this problem, the XML file is composed of over 13
thousand lines. Consequently, definition of these XML files by hand is not a
viable option.
In the previous chapter, the Windows folder structure is introduced as editor

used to support the generation of the system input XML structures. The
example editor is layout is illustrated in figure 9-14.
The editor uses the system primitives as top level structure. The illustrated
panel example XML structure is based on 5 system primitives; panel, plate,
168
Environment primitive
Windows folder structure
figure 9-14: Editor based on the Windows folder structure, used to

support the definition of the previously discussed XML structures
layup, layer, and material. Using these 5 primitives the 13 system primitives in
the XML structure are defined. The illustrated example uses 96 Matlab function
process primitives in the editor, which translate to the 432 definitions in the
XML structure. Finally, the number of property primitives defined explicitly in
the editor is reduced to 63, highly reducing the definition effort.
The system primitives are composed of the earlier mentioned ‘properties’

and ‘core’. These define the system generic attributes and methods, such as
weight determination based on a summation of the subsystem weights. To
define system attributes and methods that are different for each concept the
‘topology’ folder is used. For instance, the example panel ‘stiffened’ concept
has the concept specific property ‘stiffener spacing’. The topology contains the
next to specific ‘property’ and ‘core’ information, also the ‘core subsystems’
169
definition. These subsystems define the subsystems of the system and implicitly
define the hierarchical system tree. The implicit definition of this hierarchical
system tree is illustrated in figure 9-15.
The process primitives are Matlab m-file functions. An example m-file function
script is illustrated in figure 9-16. The header of the function is used to
generate the XML used to define the process primitives. This is discussed in the
following section.
The property primitives are defined in the same XML structure as used to
instantiate them, see section 9.2 for examples.
9.5.2 Generate system input
The implementation was performed in the Matlab environment based on the

available capabilities. The interfaces were implemented with XML. To define
the XML interface the editor used the Windows folder structure. This reduced
the complexity of the interface definition by reducing the number elements
from 4000 to 500. The folder structure could be relatively easily changed, and
the XML interface files are generated automatically using a Python script. The
engineering primitives are automatically instantiated in memory based on the
XML. The system solution is obtained by updating the system, executing the
generic
subsystem
definition
subsystem name
within system
definition
specific
subsystem
topology
definition
figure 9-15: Editor based on the Windows folder structure, showing the
implicit multilevel system concept definition based on ‘topology’
170
Environment primitive
automatically
translated
figure 9-16: Matlab m-file function translated to the process primitive

XML structure based on the function definition and header
optimisation process. The solutions are captured in the same XML format used
to instantiate the primitive, extended with solution information.
To generate the system XML structures a Python script is defined that

translates the folder architecture, Matlab m-files, and property XML structures
into a set of discrete XML structures, each representing one specific concept.
This is done similar to the process illustrated in figure 9-15. Recursively, per
system its subsystems are identified using the ‘topology’ folder. If multiple
subsystems are possible the list of concepts is multiplied with the number of
possibilities. This yields the system tree.
The processes in the tree are translated to XML by using the header of the
Matlab m-file. The header contains the function statement (the first line of
the file) and a specification of the input and output properties (first section of
commented lines), including their types. This defines the ‘input’ and ‘output’
of the process. The ‘source path’ of the process is defined by storing the
location of the Matlab m-file, and the name order is deduced from the function
statement.
The property information is already defined in the proper XML format and is
simply added.
9.5.3 Generate solutions
The resulting XML files are used to instantiate the engineering primitives in
memory. The top-level system is requested to ‘update’ triggering the update
process discussed in the previous sections and chapter. The ‘update’ request is
171
manually, but the update itself is performed automatically.
9.5.4 Store system output
The top-level system or each other primitive can be requested (manually) to

translate itself to the XML structure. This yields the XML outputs discussed in
the previous sections.
9.5.5 Evaluate solutions
The solution evaluation is by inspection of the solution captured in the XML

structure. This activity is addressed in chapters five and six. In chapter five
the decomposed structure is addressed illustrated in section 5.2 how an error
is traced. Chapter six elaborates on the trial and error character that is a
consequence of a negative evaluation.
9.6 Application review
The prototype implementation is tested for the panel design problem discussed
in the second part of chapter six (section 6.3 to 6.5). The panel design problem
addressed a design problem space defined by a minimisation of cost versus
weight, panel length, and load-case. The panel design addresses several panel
concepts. The reader is referred to chapter six for information on the design
problem. This section reviews the operation of the framework for that panel
design problem example.
Feasilisation
Benefits are a complete storage of the solution and its architecture allowed
recreation of the solution. During development the traceable structure
showed its value in error tracking and debugging of the problem knowledge.
For example, the panel problem discussed in chapter six was extended with
the manufacturing knowledge, including cost objective, which required three
days to extend and validate the editor. The storing and reuse of engineering
primitives showed feasible and effective through the XML interface, further
reducing the problem definition time.
A point of attention for future implementations is that with an increasing

number of similar solutions, they become increasingly difficult to differentiate.
Framework
The main benefit is the automatic update and execution. XML format showed
172
Conclusions
its strength in small files, allowing for fast inspection.
The current implementation shows that the Matlab language required a lot of
time to perform all the extra overhead required for the engineering primitives.
Although, XML allowed for fast inspection, with increasing size the integrated
XML interface files became too cumbersome and eventually broke down the
Matlab environment. Amount of information creates a storage problem.
9.7 Conclusions
For the prototype development, the Matlab environment and the XML format
were proper design options. However, the reader is suggested to use a more
powerful programming and interface language for future implementations.
Secondly, the reader is advised to collect the required tools (such as an
optimisation routine) before starting a successive implementation.
The current implementation showed that the Matlab language required a lot of
Therefore, a more efficient language should be used to speed up the whole
process. Another possibility is to separate the management and the execution
tasks of the primitives. The management tasks are used to configure the design
problem. After configuration a problem instantiation script could potentially be
generated, which can execute the problem far more efficiently, and could even
be based on another language, such as FORTRAN. Secondly, XML format showed
its strength in small files, allowing for fast inspection. However, with increasing
size the integrated XML interface files became too cumbersome and eventually
broke down the Matlab environment. Two design option possibilities are
identified to solve this problem. Firstly, the XML files are stored distributed and
not nested in each other. This would result in a similar definition commonly
used in ontology definitions, which are in principle non-hierarchical. Another
option is to use a standard database to store the information, increasing the
allowable file size. This is also beneficial in case of the design space definition
in which many similar design solutions are obtained, in which the database
structure can be used to capitalise on these similarities.

Therefore, the problem identification becomes extremely important in order to
allow solutions to be reused. Any future implementation should be based on a
proper identification system in order to prevent loss of information.
The contribution of this chapter is the implementation of the engineering

primitive framework. The prototype implementation illustrate the effective
173
reuse of data structures by the framework.
174
Introduction
Chapter 10: Conclusions and

recommendations
10.1 Introduction
The objective of this thesis is to develop engineering software based on

knowledge engineering principles that automates the routine and repetitive
activities of an engineer in the conceptual design phase of complex systems
engineering such that multidisciplinary design optimisation can be initiated.
Aircraft systems design will be taken as guiding example as it is a typical
example of complex systems engineering.
The hypothesis is that a feasible method can be obtained by following the

This yields three sub-objectives;
(1) Formalise the approach an engineer uses in the

conceptual design phase for complex systems
(2) Design a system that can support the engineer in performing
this formalised conceptual design approach
(3) Developed an engineering software prototype for
an example conceptual design problem
10.2 Conclusions
The thesis illustrated that automation of complex engineering processes can

be achieved by following the engineer’s way of working. This is achieved by a
proper combination of systems engineering, knowledge (based) engineering,
and multidisciplinary design optimisation. In the opinion of the author
a combination of these three areas is required to find a feasible process
automation solution.
To obtain a scalable and relatively independent software platform

implementation of the automated process the use of engineering building
blocks is key. These building blocks allow a separation of the software domain
and the modelled engineering domain. These building blocks are referred to as
engineering primitives and are derived from scoping levels used by engineers
to model a complex engineering problem. In the opinion of the author these
175
Chapter 10: Conclusions and recommendations
building blocks are required for an effective implementation of both the

modelled engineering domain and software domain.
The framework described in the previous chapter meets the stated objective
of this thesis. To define the conceptual design process feasilisation is defined
in this thesis as an approach engineers use to address the complexities in the
conceptual design phase. To identify the routine and repetitive activities and
building blocks of feasilisation the elements of the approach are evaluated for
several example conceptual design problems. The results are integrated in the
definition of so-called engineering primitives, building blocks of feasilisation.
The implementation of the engineering primitive framework proved feasible.
The conclusions are discussed in more detail for the stated sub-objectives.
Sub-objective (1)
Complex system design involved system and system design complexities.

Engineers use systems engineering and the design cycle to reduce these
complexities. To reduce complexities in system design automation through
multidisciplinary design optimisation can be used. To effectively use MDO a
supporting framework needs to be available to structure the design process
and to integrate the various tools involved in that process. However, in order
to perform MDO an initial system solution is required. To find this solution
engineers need to translate a set of requirements into a conceptual solution.
The complexity involved in the conceptual design process due to abstraction is
referred to as abstraction complexity.
Feasilisation is defined as an approach to address abstraction complexity in

conceptual design (see chapter three). The feasilisation approach is composed
of three complexity reduction approaches: simplification, decomposition, and
trial and error. Examples of these three approaches are discussed respectively
in chapters four through six. The examples are focused on the different
aspects of each approach and the surfacing recurring and routine processes.
The DEE concept could be used as process building block to construct a
formal feasilisation process. The resulting process has many similarities to
the systems engineering process. To automate the process the design process
is adapted to separate the efforts of the engineer and the MDO framework
engineering software. The change was included in the DEE concept, to support
its modularity as building block. The design and feasilisation process are
formalised in order to support the integration with engineering software.
Sub-objective (2)
The system simplification discussed in chapter four suggested that engineers
176
Conclusions
are able to reuse much of the available knowledge, although they have
to tailor every specific system design problem. This surfaced again in the
discussion in this chapter. The system decomposition discussion showed that
it is important to stay close to the engineer, to support reuse the decomposed
system. The discussion in chapter five surfaced that for reusability, it is
important that decomposition is flexible. Any implementation should not
enforce a certain system model on the specialist. This chapter illustrated
that this reuse can be achieved by dividing the process into separate similar
process modules, here represented by the formalised search process discussed
in chapter three. Concluding, chapters four, five, and six showed that major
elements can be reused between the discussed examples. The reuse is based
on the formalised process, as well as a structured system decomposition
that yielded building blocks. Simplification requires building blocks for the
requirements, concepts, and behaviour models. Decomposition uses building
blocks per system level and for the separate steps of the formalised process.
The observations done in the previous chapters are translated to a feasilisation

framework based on a discussion on knowledge management and knowledge
engineering. The knowledge management discussion showed that engineering
software can support part of the learning cycle, which is important to
increase the engineer’s productivity. The knowledge engineering discussion
showed that in engineering knowledge systems are based on the knowledge
based engineering (KBE) technology. To define the building blocks of for an
engineering software application to support the feasilisation approach a
concepts from MDO frameworks is combined with a KBE concept. The MDO
concept is based on abstraction, identifying four MDO framework abstraction
levels. The KBE concept uses abstraction to identify high-level primitives with
object decomposition and capability modules with aspect decomposition.
These concepts are combined into the so-called engineering primitives, which
are the building blocks for an engineering software application to support
the feasilisation approach. Concluding, the feasilisation methodology can
potentially be supported by the used of engineering primitives that embody
the MDO framework abstraction and the decomposition approach used by KBE.
Combining this with results from chapter six these primitives should relieve the
engineer from process management and execution tasks, allowing focus on the
definition of requirements, concepts, and tools.
Chapter eight addressed the functional design and software design of

the engineering primitive framework. The framework features the basic
architecture of a knowledge system and has four different actors: design
specialist, search specialist, performance specialist, and specialist tool. To
support reuse, the primitives all have a generic aspect capability such that the
input used to instantiate the primitives has the same structure as the output
177
of the primitives. For the design of the engineering primitives, abstraction is

used to optimally reuse the information. Per primitive specific types are used
to specialise the activities. Combined these primitives types represent their
primitive abstraction. For the implementation of the framework prototype,
Matlab is selected as programming environment based on the availability of
tools and the level of integration. XML is selected as interface language as it is
easy inspectable and relatively simple to integrate.
Sub-objective (3)
Chapter nine addressed a prototype implementation of the engineering

primitive objects. The implementation was performed in the Matlab
environment based on the available capabilities. The interfaces were
implemented with XML. To define the XML interface the editor used the
Windows folder structure. This reduced the complexity of the interface
definition by reducing the number elements from 4000 to 500. The folder
structure could be relatively easily changed, and the XML interface files are
generated automatically using a Python script. The engineering primitives are
automatically instantiated in memory based on the XML. The system solution
is obtained by updating the system, executing the optimisation process.
The solutions are captured in the same XML format used to instantiate the
primitive, extended with solution information.
During development the traceable structure showed its value in error tracking
and debugging of the problem knowledge. For example, the panel problem
discussed in chapter six was extended with the manufacturing knowledge,
including cost objective, which required three days to extend and validate the
editor. The storing and reuse of engineering primitives showed feasible and
effective through the XML interface, further reducing the problem definition
time.
10.3 Recommendations
This work aims to increase productivity and quality of engineering processes

through automation. The current solution is based on a combination of
concepts from systems engineering, knowledge (based) engineering, and
multidisciplinary design optimisation. To progress towards an industrial grade
solution the reader is recommended to include concepts currently used in
industry. Currently, industry uses concepts such as knowledge management and
lean engineering to increase productivity and quality. Automation will be part
of the complete solution, which requires further investigation into the relation
between these concepts.
178
Recommendations
The engineering primitives are a proof of concept that outline the building
blocks to model and engineering problem. The building blocks focus on
reduction of repetitive tasks of the user. The current work addressed process
modelling and execution tasks. The functionality of the building blocks can be
extended to increase support of operational processes, addressing for instance
repetitive tasks in documentation, requirements verification, or presentation
the applicable design heuristics.
This work provides a first formalisation required to define the engineering

primitives. Further research can be done to formally define the ontology
behind the primitives, and relating that to current engineering ontologies such
as MOKA. Secondly, the formalisation of the interfaces to different engineering
domains can be investigated, addressing the relation between the formal
ontology and domain specific languages. This would require further research
into the interface required to model and review an engineering problem
effectively.
This work illustrated that storage and reuse of solutions requires further
investigation. The integration of previous solutions in a new design problem
can be investigated by integration of multilevel optimisation techniques.
This approach can uncouple the subsystem optimisation from the system
optimisation problem to a degree that previously calculated subsystem
solutions could be used during system optimisation. To obtain these subsystem
solutions, surrogate models can be potentially used that can be used to draft
the subsystem solution design space relatively quick.
For the prototype development, the Matlab environment and the XML format
were proper design options. However, the reader is suggested to use a more
fundamental programming and interface language for future implementations.
Secondly, the reader is advised to collect the required tools (such as an
optimisation routine) before starting a successive implementation.
The current implementation showed that the Matlab language required a lot of
Therefore, a more efficient language should be used to speed up the whole
process. Another possibility is to separate the management and the execution
tasks of the primitives. The management tasks are used to configure the design
problem. After configuration a problem instantiation script could potentially be
generated, which can execute the problem far more efficiently, and could even
be based on another language, such as FORTRAN. Secondly, XML format showed
its strength in small files, allowing for fast inspection. However, with increasing
size the integrated XML interface files became too cumbersome and eventually
broke down the Matlab environment. Two design option possibilities are
179
identified to solve this problem. Firstly, the XML files are stored distributed and
not nested in each other. This would result in a similar definition commonly
used in ontology definitions, which are in principle non-hierarchical. Another
option is to use a standard database to store the information, increasing the
allowable file size. This is also beneficial in case of the design space definition
in which many similar design solutions are obtained, in which the database
structure can be used to capitalise on these similarities.

Therefore, identification becomes extremely important in order to allow
solutions to be reused. Any future implementation should be based on a proper
identification system in order to prevent loss of information.
180
References
ACARE, "Strategic Research Agenda Executive Summary", Advisory Council For

Aeronautics Research in Europe, 2002
Argüelles et al., "European aeronautics: A vision for 2020", European Commission, Office
for Official Publications of the European Communities, Belgium, 2001
Armstrong, M., de Tenorio, C., Garcia, E., Mavris, D., “Function based architecture
design space definition and exploration”, 26th congress of international
council of the aerospace sciences, AIAA 2008-8928, Alaska, USA, 2008
Baergen, R., “Contemporary epistemology”, Harcourt Brace College, 1995
Baluch, H.,“Aeroelastic Loads Modeling for Composite Aircraft Design Support“, doctoral
thesis, Delft University of Technology, 2009
Baluch, H., M.J.L. van Tooren and E.J. Schut, “Design tradeoffs for fiber composite
fuselages under dynamic loads using structural optimization”, 4th AIAA
Multidisciplinary Design Optimization Specialist Conference, USA, 2008
Berends, J.P.T.J., M.J.L. van Tooren and E.J. Schut, “Design and Implementation of
a New Generation Multi-Agent Task Environment Framework”, 4th AIAA
Multidisciplinary Design Optimization Specialist Conference, USA, 2008
Berends, J.P.T.J., “MATE; Multi-Agent Task Environment”, MSc thesis, Delft University of
Technology, the Netherlands, 2005
Berendsen, R.P.A., “A Knowledge Based Engineering approach to Wing Structural
Analysis”, MSc thesis, Delft University of Technology, the Netherlands, 2009
Brouwers, J.J.J., “Parametric modelling of aircraft tail configurations to support
aerodynamic analysis”, MSc thesis, Delft University of Technology, the
Netherlands, 2007
Buskes, C., “The Genealogy of Knowledge”, doctoral thesis, Tilburg university press,
1998
Cerulli, C, E.J. Schut, J.P.T.J. Berends and M.J.L. van Tooren, “Tail Optimization and
Redesign in a Multi Agent Task Environment”, 47th AIAA/ASME/ASCE/AHS/ASC
Structures, Structural Dynamics, and Materials Conference, USA, 2006
Collier, C.S., “Thermoelastic Formulation of Stiffened, Unstiffened Composite Panels for
Finite Element Analysis if High Speed Aircraft”, 35th AIAA/ASME/ASCE/AHS/
ASC Structures, Structural dynamics and materials conference, USA, 1994
Cooper, D., La Rocca, G., “Knowledge-based techniques for developing engineering
applications in the 21st century”, AIAA Aviation Technology, Integration and
Operations conference, Belfast, Northern Ireland, 2007
Corke, T.C., “Design of Aircraft”, Prentice Hall, USA, 2003
De Bono, E., “Lateral thinking”, Harper and Row publishers, 1990
Department of Defence, “Systems Engineering Fundamentals“, Defence Acquisition
University Press, USA, 2001
Drucker, "Management Challenges for the 21st Century", Butterworth-Heinemann, UK,
181
References
1999
Feigenbaum, E.A., and P. McCorduck, “The fifth generation”, 1st edition, Addison-Wesley,
USA, 1983
Forrester, A., A. Sóbester, A. Keane, “Engineering Design via surrogate modelling“, first
edition, John Wiley & Sons Ltd., UK, 2008
Friedman, "The World is Flat", first edition, Farrer, Straus and Giroux, USA, 2005
Gero, J.S., Maher, M.L., “Modelling and creativity and knowledge-based creative
design”, Lawrence Erlbaum Associates, 1993
Grotenhuis, J., “Development of a conceptual controllability analysis tool”, MSc thesis,
Delft University of Technology, the Netherlands, 2007
Hahn, S., “Optimising KLM’s Airworthiness Definition process”, MSc thesis, Delft
University of Technology, The Netherlands, 2008
Hofstee, J., T. Kier, C. Cerulli, and G. Looye, “A variable, fully flexible dynamic response
tool for special investigations (Varloads)”, proceedings, international forum
on aeroelasticity and structural dynamics, 2003
Jones, R.M., “Mechanics of composite materials”, Hemisphere publishing corporation,
USA, 1975
Kaplan, R., Norton, D., “The balanced scorecard: translation strategy into action“,
Harvard business school press, USA, 1996
Kollár, L.P., and G.S. Springer, “Mechanics of Composite materials”, Cambridge
University Press, USA, 2003
La Rocca, G., “Knowledge-Based Engineering approach to support Aircraft
Multidisciplinary Design and Optimisation“, doctoral thesis, Delft University
of Technology, [to be published]
La Rocca, G., M. van Tooren, “Knowledge-Based Engineering Approach to Support
Aircraft Multidisciplinary Design and Optimization”, Journal of aircraft,
Volume 46, No. 6, AIAA, 2009
La Rocca, G. and M.J.L. van Tooren, “Enabling Distributed Multidisciplinary Design of
Complex Products: A Knowledge Based Engineering Approach”, Journal of
Design Research, Inderscience Enterprices Ltd., volume 5, no. 3, 333-352,
2007
La Rocca, G, L. Krakers, M.J.L. van Tooren, “Development of an ICAD Generative Model
for Blended Wing-Body Aircraft Design”, 9th AIAA/ISSMO Symposium on
Multidisciplinary Analysis and Optimization, Atlanta, Georgia, 2002
Larman, C., “Applying UML and Patterns: An introduction to Object-Oriented Analysis
and Design and Iterative Development”, Pearson professional education, USA,
2005
Ledermann, C., C. Hanske, J. Wenzel, P. Ermanni, R. Kelm,“Associative parametric
CAE methods in the aircraft pre-design”, Aerospace Science and Technology,
Elsevier, 2005
Leffingwell, D., and D. Widrig, “Managing software requirements; a use-case approach”,
second edition, Addison-Wesley, United States, 2003
Lisandrin, P., “Elements of Automated aeroelastic analysis in aircraft preliminary
182
design”, doctoral thesis, Delft University of Technology, the Netherlands,
2007
Malone, B., “On the Financial Impact of MDO on the Corporation,” 9th AIAA/ISSMO
Symposium on Multidisciplinary Analysis and Optimisation, AIAA, Paper 2002-
5495, Sept. 2002
Meijer, P.B., “Parametric modelling of an Airbus aircraft family for dynamic response
simulations in the preliminary design phase”, MSc thesis, Delft University of
Technology, 2003
Milton, N., “Knowledge technologies”, volume 3, Polimetrica, 2008
MML working group, “MOKA User Guide”, version 1, the MOKA consortium, 2000
Morris, A. J., “MOB: A European Distributed Multi-Disciplinary Design and Optimisation
Project,” 9thAIAA/ISSMO Symposium on Multidisciplinary Analysis and
Optimisation, AIAA, Paper 2002-5444, 2002
Murman et al., “Lean Enterprise Value”, first edition, The Lean Enterprise Value
Foundation, PALGRAVE, USA, 2002
Nawijn, M., and van Tooren, M. J. L., “Automated Finite Element Analysis in a
Knowledge Based Engineering Environment,” 44th AIAA Aerospace Science
Meeting and Exhibit, AIAA Paper 2006-947, 2006
Nielsen, H.B., S.N.Lophaven, and J.Søndergaard, ‘DACE: Design and Analysis of
Computer Experiments’, online resource, URL: http://www2.imm.dtu.
dk/~hbn/dace/, [visited 08-2009]
Nonaka, I., and Takeuchi, H., “The knowledge creating company”, Oxford University
Press, UK, 1995
Ogata, K., “Modern control engineering“, fourth edition, Prentice Hall, USA, 2002
Oldham, K., a.o., “MOKA - A methodology and tool oriented to knowledge-based
engineering applications”, Advances in Design and Manufacturing, Volume 8,
198-207, IOS Press, Amsterdam, 1998
Oxford Advanced Learner’s Dictionary, 6th edition, Oxford university press, 2000
Picheny, V., N. Kim, R. Haftka, “Conservative Predictions Using Surrogate Modeling”,
AIAA 2008-1716, 49th AIAA/ASME/ASCE/AHS/ASC Structures, Structural
Dynamics, and Materials Conference, 2008
Protégé, internet resource, “http://protege.stanford.edu/”, Stanford University, United
States, last visited November 2009
Raymer, D., “Aircraft Design: A Conceptual Approach”, Fourth Edition, Conceptual
Research Corporation, AIAA Education Series, AIAA, 2006
Rentema, D., “AIDA: artificial intelligence supported conceptual design of aircraft“,
doctoral thesis, Delft University of Technology, The Netherlands, 2004
Roskam, J., “Airplane Design”, Darcorporation, 2003
Rothwell, A., Structural design and optimisation 2, Delft University of Technology, Delft,
the Netherlands, 1999
Roozenburg, N., Eekels, J., “Productontwerpen, structuur en methoden”, 2de druk,
Lemma, 1998
Rudic, Z., “UNA Computer Program for Static and Dynamic Structural Analysis by Finite
183
References
Element Method”, User & verification manual, version 7.2, Structural Analysis
and Research Systems, 2002
Russell, S., and Norvig, P., “Artificial intelligence; a modern approach”, second edition,
Pearson education, 2003
Schreiber, G., a.o., “Knowledge engineering and management: : The CommonKADS
Methodology”, MIT press, 2000
Schut, E.J., M.J.L. van Tooren and J.P.T.J. Berends, “Feasilization of a Structural Wing
Design Problem”, 49th AIAA/ASME/ASCE/AHS/ASC Structures, Structural
Dynamics, and Materials Conference, USA, 2008a
Schut, E.J., and M.J.L. van Tooren, “A multi-level environment to support demand
driven design“, RAeS/CEAS Aircraft Structural Design Conference, UK, 2008b
Schut, E.J., and M.J.L. van Tooren, “Development and implementation of knowlege-
based design process primitives”, 26th international conference of the
aeronautical sciences, USA, 2008c
Schut, E.J., and M.J.L. van Tooren, “Design ‘feasilization’ using Knowledge Based
Engineering and Optimization techniques”, Journal of Aircraft, Vol. 44, No 6,
2007
Schut, E.J., “TWISST; development of a tail and wing initial structural sizing tool”, MSc
thesis, Delft University of Technology, 2005
Senge, P.,“The Fifth Discipline”, Random House Inc., USA, 1990
Sobieszczanski-Sobieski, J., J.S. Agte, and R. Sandusky Jr., “Bi-Level Integrated System
Sysnthesis (BLISS)”, NASA, TM-1998-208715, 1998
Suh, N., “Axiomatic design: advances and applications“, Oxford University Press, USA,
2001
Suh, N., “Complexity; theory and applications”, Oxford University Press, USA, 2005
Sussman, J., “Ideas on complexity in systems; twenty views”, Massechusetts Institute
of Technology, Internet resource, http://web.mit.edu/esd.83/www/
notebook/20ViewsComplexity.PDF [last visited 10-04-2010]
Sussman, J., “The ‘CLIOS process’”, course materials for ESD.04J Frameworks and
Models in Engineering Systems, Spring 2007, Internet resource, MIT
OpenCourseWare (http://ocw.mit.edu), [last visited 10-04-2010]
Sveiby, , http://www.sveiby.com/articles/KnowledgeManagement.html, 2009 [visited
28-7-09]
Torenbeek, E., “Synthesis of Subsonic Airplane Design“, Kluwer Academic Publishers
Group, The Netherlands, 1982
Tosserams, S., “Distributed optimization for systems design”, doctoral thesis, Eindhoven
University of Technology, The Netherlands, 2008
Ulrich, K.T, and S.D. Eppinger, “Product Design and Development“, 4th edition, McGraw-
Hill, 2008
Umeda, Y. Kondoh, S., Shimomura, Y., and Tomiyama, T., “Development of design
methodology for upgradable products based on function-behaviour-state
modeling”, Artificial Intelligence for Engineering Design, Analysis and
Manufacturing, 19, 161-182, Cambridge University Press, USA, 2005
184
Vanderplaats, G., “Multidiscipline design optimization“, first edition, Vanderplaats
Research & Development Inc., USA, 2007
Van der Elst, S.W.G., and M.J.L. van Tooren, “Domain specific modeling languages
to support model-driven engineering of aircraft systems”, proceedings of
the 36th congress of international council of the aeronautical sciences,
Stockholm, Sweden, 2008
Van der Laan, A.H., “Knowledge based engineering support for aircraft component
design“, doctoral thesis, Delft University of Technology, the Netherlands,
2007
Van Dijk, R.E.C., “A Knowledge Based Engineering Approach to Aircraft Movable Design“,
MSc thesis, Delft University of Technology, the Netherlands, 2008
Van Hinte, E., van Tooren, M., “First read this”, 010 publishers, the Netherlands, 2008
Van Riet, P., “A KBE-based optimization tool for design space exploration“, MSc thesis,
Delft University of Technology, 2008
Van Tooren, M., “Sustainable Knowledge Growth“, inauguration speech, Delft University
of Technology, The Netherlands, 2003
Van Tooren, M.J.L., “Sandwich fuselage design“, doctoral thesis, Delft University of
technology, 1998
Varkevisser, J., "Multi-level optimization to support conceptual aircraft design", MSc
thesis, Delft University of Technology, The Netherlands, 2010
Vermeulen, B., “Knowledge based methodology for solving complexity in design
problems“, doctoral thesis, Delft University of Technology, The Netherlands,
2007
Weggeman, M., “Kennismanagement”, Scriptum, Schiedam, 1997
Yang, K., B. El-Haik, “Design for Six Sigma: a roadmap for product development”,
McGraw-Hill, USA, 2003
185
References
186
Appendix
Appendix A: System search process
system system performances system system system subsystem
search (objective/constraints) concept model tests search
define objective and

constraints
objective defined?
yes
define performance output
no
iterate property a concept

properties property?
no performance a model
property?
yes
no performance a test
property?
yes
no
yes
define test output
test property related to

test case?
no
yes
test case defines

subsystem test case?
yes
define test case
define test case input
define model output
model property related to

model input?
no
yes
define model input
model requires subsystem

input?
189
yes
define objective
define model system input

test case?
Appendix A: System search process no
yes
test case defines

system system performances system system system subsystem

yes
search (objective/constraints) concept model tests search
define test case
define test case input
define objective and

constraints
define model output
objective defined?

model input?
yes
define performance output
no no
iterate property a concept yes

properties property?
define model input
no performance a model
property?
yes
input?
no performance a test
property?
yes
yes
define objective
no
yes
define model system input
define test output
define concept output

test case?
concept output related to

input?
no
yes
no
yes test case defines

all performance properties concept provides

defined? subsystem properties?
yes
define test case
no yes
define concept
yes define test case input
define variables define concept input
define model output
define subsystems define process

model input?
all subsystems defined?

no
yes
no
yes define model input
execute search

input?
yes
define objective
190define model system input
define concept output

Appendix B: Example data
B.1 Aircraft data (EASA CS-23)
table B-1: Aircraft specification

symbol value
Maximum Take Off Mass W [kg] 4327
Main wing surface area S [m^2] 26.1
Taper ratio lambda [-] 0.52
Slenderness Ratio A [-] 8
Span b [m] 14.45
Wing Loading W/S [N/m^2] 1625.80
Cruise speed VC [m/s] 180
Cruise height hC [m] 8839.20
Manoeuvring load factor(+) n_pos [-] 4.40
Manoeuvring load factor(-) n_neg [-] 1.76
Safety Factor j [-] 1.50
191
Appendix B: Example data
B.2 Fuselage design example
table B-2: Aircraft data (Baluch, 2009)

unit value
Airspeed, V(0) [m-sec-1] 250
Altitude [m] 7620.0
Wing span [m] 16.7
Mass [kg] 5884.23
Radius at the root of the aft [m] 0.7
fuselage
Radius at the tip of the aft [m] 0.06
fuselage
Total length of the fuselage [m] 7.1
Maximum panel width [m] 0.365
table B-3: Design result summary (Baluch, 2009)
Foam-filled sandwich Foam-filled stiffened Foam-filled stiffened

structure (case 1) structure (case 2) structure (case 3)
Section id length weight ratio length weight ratio length weight ratio
[m] [kg-m-1] [m] [kg-m-1] [m] [kg-m-1]
1 3.63 238.3 1.20 59.1 1.22 115.1
2 3.78 215.6 1.20 72.2 1.61 66.5
3 1.20 57.6 1.80 62.8
4 1.20 60.0 2.00 62.6
5 1.20 49.2 0.47 32.3
6 1.11 38.0
Total weight 435.9 336.1 339.3
192
Acknowledgements
To perform my PhD research was an extraordinary thing. Looking back at the

start I felt challenged to improve the reuse of knowledge and design decisions
made in industry. I started this venture based on my experiences from my
internship at Airbus in Hamburg combined with the promise of knowledge
based engineering. I want to thank Michel for giving me the opportunity and
for creating a challenging and entrepreneurial environment.
This thesis would not have been if it wasn't for my graduate students;
Sjoerd, Joris, Chiara, Sybren, Pernel, Reinier, Rens, Jurriën, Matthews,
and Stan. I enjoyed working together and you have helped me explore the
various boundaries of aircraft design. Every topic had its own dynamics and
frustrations, but always provided new insights and challenging results. Thanks!
I want to thank my colleagues from SIA for the task-force environment. I

enjoyed working together on KBE and the DEE. I still regard TailorMate as
the ultimate project. Thanks Chiara, Jochem, Gianfranco, and Marco for this
magnificent DEE. Also I want to thank Gelu for his out-of-the-anything projects,
which I enjoyed discussing.
"Research met een bijsmaak" will last. I want to thank my colleagues from DAR
for a wonderful time. From small things as coffee, cake, and birthday lights, to
our trips to Paris, Reno, and Anchorage. Nothing tops a chalet in the snow with
a view at lake Tahoe, although salmon fishing and bear country came close.
Thanks Dennis for walking in front. Especially, I want to thank Hans, Monique,
and Jochem for sushi, proper coffee, and day-to-day energy.
Through discussion and reflection ideas are shaped. The subjects of design,
automation, and organisations supported numerous discussions which would
not have been if Melle, Wijnand, Jorne, Frans, Michiel, Brent and many others
would not have fiercely defended their point of view. Thanks for providing me
with far too much inspiration, ideas, and information to incorporate in this
thesis alone.
Maybe starting KE-works during my research was not very time efficient, but
it did provide me with more then enough energy to finish this thesis. I want
to thank the whole team for the entrepreneurial, creative, and pragmatic
environment that contributed significantly in dealing with the abstract beast
that consumed large parts of my research. Especially, I want to thank Jochem
and Stefan for their inspiration, endurance, and unconditional support.
193
Acknowledgements
Special thanks goes to my family. Esmeralde, thanks for your efforts in making
this a human readable piece and Jochem you again amazed me with your
creative and professional makeover. Anco and Nen, I want to thank you for
providing an all year 'summer retreat' and critical reflections when I needed
them most. My greatest gratitude goes to Wouter for your proactive support
and to Lindy for your energy and putting things into perspective.
It's done. Up to the next challenge.
194
About the author
Joost Schut is born in Gouda in the Netherlands in 1980. During his childhood
he moved to Groningen, where he got his secondary education Athenaeum
degree at the Zernike College. In 1998 he moved to Delft to study Aerospace
Engineering at the Delft University of Technology. During his studies he has
done internships at Lloyd Aero Boliviano in Bolivia and Airbus Hamburg in
Germany. Within his Master of Science he focused on the fields of systems
engineering, knowledge based engineering, and conceptual aircraft design. In
2005 he obtained his MSc degree in Aerospace Engineering.
The promise and industrial challenges for wide application of knowledge

engineering motivated the continuation of his graduation work within a PhD.
The PhD research addressed industrial research projects. During the PhD
research he supervised multiple Aerospace Engineering MSc graduation projects
in various topics related to his research, which allowed him to incorporate
views and methods from experts from various fields. Next to that he supported
the systems engineering education within the Aerospace Engineering BSc
program. He finished the active part of the PhD research by the end of 2008.
In June 2008 he founded KE-works together with four colleagues from the
Delft University of Technology. Within KE-works he holds the position of Chief
Commercial Officer. KE-works’ mission is to commercialize the benefits from
knowledge engineering and, among others, the tools and methods developed
within his PhD research. In 2009, KE-works successfully sold their first solution
to Stork Fokker Elmo. Currently, KE-works is working in close cooperation with
their customers to increase the footprint of knowledge engineering in industry.
195
About the author
196
.........................
In order to keep innovating, engineers are
working more and more with engineering
software, providing them a way to cut away
their routine and repetitive activities. Com-
puter aided design and simulation software
are for instance considered standard tools in
most engineering companies. Today, to solve
complex engineering design problems, multi-
disciplinary design optimisation (MDO) is
increasingly used to automate the design
process to support the engineer in finding a
solution faster. To effectively use MDO,
design frameworks such as the design and
engineering engine (DEE) are required. More
and more does engineering software provide
a seamless integration of computer software
and human knowledge, a focus point of the
field of knowledge engineering (KE). This
will free engineers from repetitive and
routine tasks and allow them to use their full
creative capacity and learn faster, increasing
their productivity. This work contributes to
the development of KE applications within
the DEE to support the MDO process. The
focus is on the conceptual design phase of
complex systems engineering, responsible for
providing an initial start vector for MDO.
Aircraft design is taken as a guiding example
.........................
as it is a typical case of a complex system.

Conceptual Design

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Conceptual Design

Caricato da

Copyright:

Formati disponibili

Conceptual

ter verkrijging van de graad van doctor

aan de Technische Universiteit Delft,

op gezag van de Rector Magnificus prof.ir. K.Ch.A.M. Luyben,

voorzitter van het College voor Promoties,

in het openbaar te verdedigen op vrijdag 12 november 2010 om 12.30 uur

Erik Joost SCHUT

ingenieur in de luchtvaart en ruimtevaart

Prof.dr.ir. M.J.L. van Tooren

Rector Magnificus voorzitter

Copyright © 2010 by Erik Joost Schut

Printed in the Netherlands

Conceptual design automation

The hypothesis is that a feasible method can be obtained by following an

Feasilisation is introduced as an approach to address the abstraction

blocks and trial and error processes are identified.

Conceptueel ontwerp automatisering

Om te kunnen blijven innoveren werken ingenieurs steeds meer met

De hypothese is dat een haalbare methode kan worden gevonden door

Om met deze ‘abstraction complexity’ om te kunnen gaan wordt gebruik

De formele procesbeschrijving, de bouwstenen en het trial-and-error proces

De belangrijkste conclusie is dat het ‘engineering primitives’ framework

1.1 Complex systems engineering 1

Chapter 2: Complex systems design 9

Chapter 3: Conceptual design feasilisation 33

Chapter 4: System simplification 51

Chapter 5: System decomposition  75

Chapter 6: Trial and error 97

Chapter 7: Feasilisation building blocks 119

7.1 Introduction 119

Chapter 8: Engineering primitive framework 135

8.1 Introduction 135

9.1 Introduction 155

Chapter 10: Conclusions and recommendations 175

10.1 Introduction 175

Appendix A: System search process 189

Appendix B: Example data 191

About the author 195

1.1 Complex systems engineering

This work contributes to the development of KE applications within the DEE to

figure 1-1: Aircraft design as typical example of complex systems

Aircraft design is taken as a guiding example as it is a typical case of a complex

1.1.1 An engineering challenge

To clarify the level of expected innovation required to meet this challenge,

Clearly, aircraft manufacturers are faced with continuously increasing problem

Increasing the productivity of the available engineers could be the solution.

1.1.2 Increase engineering productivity

When freed from routine and repetitive activities, the productivity of an

Today, much of the current engineering software is focused on supporting

figure 1-3: In the future virtual design rooms will be a standard

1.1.3 Extend engineering software

Senge (2006) stresses that learning depends heavily on practical experience.

1.2 A new conceptual design paradigm

In the traditional conceptual design process a new system concept is selected

�� ���� ��� �� ⁄�� ���

1.2.1 Multidisciplinary design optimisation

The field of multidisciplinary design optimisation (MDO) is in development to

figure 1-4: In complex systems engineering, such as aircraft,

However, whether a feasible solution can be obtained with MDO depends

1.2.2 Knowledge engineering

To come up with engineering software that can automate part of the

The field of knowledge engineering focuses on obtaining the knowledge

The objective is to develop engineering software based on knowledge

1.1 Complex systems engineering 1

Chapter 2: Complex systems design 9

Chapter 3: Conceptual design feasilisation 33

Chapter 4: System simplification 51

Chapter 5: System decomposition 75

Chapter 6: Trial and error 97

Chapter 7: Feasilisation building blocks 119

7.1 Introduction 119

Chapter 8: Engineering primitive framework 135

8.1 Introduction 135

9.1 Introduction 155

Chapter 10: Conclusions and recommendations 175

10.1 Introduction 175

Appendix A: System search process 189

Appendix B: Example data 191

About the author 195

�� ⁄��