You are on page 1of 92

TMR4115 – Design Methods

Lecture Note #1

“Introduction to Marine Systems Design Models and
Methods”


Stein Ove Erikstad
August 2003
ii Table of Contents
Table of Contents
1 INTRODUCTION ........................................................................................................................ 1
2 THE PRELIMINARY SHIP DESIGN PROCESS.................................................................... 1
2.1 THE CONTENT OF THE PRELIMINARY SHIP DESIGN PROCESS ................................................. 3
2.1.1 Clarification of task.......................................................................................................... 3
2.1.2 Conceptual design ............................................................................................................ 4
2.1.3 Embodiment Design.......................................................................................................... 5
3 A REVIEW OF ENGINEERING DESIGN ............................................................................... 7
3.1 INFERENCE PROCESSES IN DESIGN ......................................................................................... 9
3.1.1 Representational building blocks of the design process................................................. 10
3.1.2 Generic inference processes........................................................................................... 12
3.1.3 Interpreting design descriptions..................................................................................... 13
3.1.4 Generating design descriptions from interpretations..................................................... 14
3.1.5 Syntactic generation ....................................................................................................... 15
3.1.6 Combined interpretation and syntactic generation ........................................................ 16
3.1.7 Interpretive and syntactic knowledge acquisition .......................................................... 16
3.1.8 Concluding remarks ....................................................................................................... 17
3.2 DESCRIPTIVE DESIGN MODELS............................................................................................. 18
3.2.1 Invariants of the Design Problem Space and Task Environment ................................... 18
3.3 PRESCRIPTIVE DESIGN MODELS ........................................................................................... 24
3.3.1 Design as a systematic decomposition and synthesis - the German VDI model ............ 25
3.3.2 Design as an iterative, sequential process ..................................................................... 26
3.3.3 Modelling preliminary ship design as a mathematical optimisation problem ............... 29
3.3.4 Design as a creative activity: Abductive generation in original design......................... 36
3.3.5 Knowledge-Based design models ................................................................................... 38
3.3.6 DESIGNER: A Focus on the Design Object................................................................... 39
3.3.7 Developing a task-structure of design - an integrating approach.................................. 42
3.3.8 Concluding remarks on knowledge-based design methods ............................................ 44
3.4 NEW DESIGN TECHNOLOGIES AND EMERGING TRENDS ....................................................... 44
3.4.1 Expert Systems................................................................................................................ 45
3.4.2 Case-Based Reasoning ................................................................................................... 45
3.4.3 Genetic Algorithms ......................................................................................................... 46
3.4.4 Artificial Neural Networks.............................................................................................. 48
3.4.5 Design Representation by Product Models .................................................................... 48
3.5 CONCLUSION........................................................................................................................ 49
4 THE TASK ENVIRONMENT AND PROBLEM SPACE OF PRELIMINARY SHIP
DESIGN................................................................................................................................................. 51
4.1 PRELIMINARY SHIP DESIGN TASK ENVIRONMENT................................................................ 53
4.1.1 Complex mapping between form and function ............................................................... 53
4.1.2 Multi-dimensional performance evaluation ................................................................... 57
4.1.3 High cost of error ........................................................................................................... 58
4.1.4 Shallow knowledge structure.......................................................................................... 59
4.1.5 Strong domain tradition ................................................................................................. 59
4.1.6 Strict time and resource constraints on the preliminary ship design process ................ 60
4.1.7 Predominantly “one-of-a-kind” and “engineered-to-order” solutions ......................... 60
4.2 PRELIMINARY SHIP DESIGN PROBLEM SPACE ...................................................................... 61
4.2.1 Satisficing rather than optimising .................................................................................. 62
Table of Contents iii
4.2.2 Personalised evaluation functions and stopping rules ................................................... 63
4.2.3 The decomposition of the design problem into leaky modules ....................................... 64
4.2.4 Sequential iterative limited commitment mode design strategy...................................... 65
4.2.5 Extensive use of empirical relations and previous cases................................................ 66
4.2.6 Multiple abstraction levels ............................................................................................. 67
4.3 CRITICAL FACTORS FOR A DESIGN MODEL .......................................................................... 68
4.3.1 Flexibility........................................................................................................................ 70
4.3.2 Expressiveness................................................................................................................ 71
4.3.3 Perceivability.................................................................................................................. 72
4.3.4 Efficiency ........................................................................................................................ 73
4.4 CHAPTER CONCLUSION........................................................................................................ 75
5 REFERENCES............................................................................................................................ 77
1
Introduction
The focus of this lecture note is the early stages of the design process. The context is
the design of marine systems, with special emphasis on merchant ship design.
It will centre on the main characteristics of the design process – not from a design
analysis perspective, but rather from the perspective of how a design engineer may
understand the design situation at hand in order to select and apply a suitable design
model and its corresponding set of methods.
Different design methods can be grouped together into what we call design
paradigms. These paradigms differ in their fundamental approach to the design
problem. It is important to understand these differences to make proper decisions
about when to use – and when not to use – a particular model or method. This require
us to take a slight sidestep into basic reasoning processes such as deduction, induction
and abduction, and from these derive a formal theory on elemental reasoning
processes in design.
I run the risk of leaving some of you at a level of abstraction that seems little relevant
to practical design situation. However, we will revisit these elementary processes
throughout the semester. Hopefully you will be patient enough to see how they are
useful to understand the different design paradigms beyond the step-by-step solution
techniques needed to solve text-book problems, but is of little use in most real-world
settings.
In addition, this lecture note contains a brief review of engineering design schools. It
is not comprehensive and it does not go very deeply into each – if you want to know
more you should dig into som of the references. Avoid getting fixed on details – it is
most important (and most relevant for your final exam) to get the broad picture.

Trondheim, Agust 2003
Stein Ove Erikstad


2
The Preliminary Ship Design Process
The term early stages refers to the part of the total ship design process in which the
main features of the ship is determined, taking high-level technical and economic
criteria into consideration. On a task-oriented time-line the early design stages
comprise the activities that starts with an identification of a need and a statement of
the design problem, and ends with a tender or a contractual specification of the design
solution. The features of the vessel to be determined usually include the main
dimensions, powering and propulsion arrangements, overall external and internal
geometry, and cargo access and handling equipment. Sometimes the selection of ship
speed is also covered.
In these early stages some of the most important decisions regarding the vessel are
made. Various sources estimate that between 60% and 80% of the total life cycle cost
is determined during this part of the design process [Dierolf, 1989]. All later design
decisions have to be taken within the frame set by the initial design, with only limited
influence on cost and overall performance.
At the same time the situation at this stage is characterised by a high degree of design
freedom, as illustrated in Figure 2–1. The design problem is open – no decisions have
yet been made that limit the options beyond the bounds given in the problem
definitions. All subsequent decisions will put constraints on this freedom. Since not
making decisions is hardly a viable alternative, the effort must be put on making these
early decisions correct. In [Suh, 1990] the situation is described as:
"Design decisions made at the initial or upstream stage of engineering
affect all subsequent outcomes". Fine-tuning of the later stages of
engineering operations may often have marginal effects on the total
outcome, and certainly cannot rectify the erroneous decisions made at
conception; yet we often relegate the design decisions to the least
experienced or the least educated of engineering professionals. The
reason why this practice has lasted for so long lies in our inability to
2 Chapter 2 –The Preliminary Ship Design Process
reduce design to absolute or scientific principles, rendering the
educated and uneducated alike handicapped in this field."
One of the main obstacles to achieving a more rational approach to preliminary design
is that the knowledge to support these early decisions is limited. By knowledge is
meant all types of facts, methods, heuristics, and experiences, and which at the same
time is explicitly available to support decisions regarding the design problem at hand.
The limited availability of knowledge can be attributed to several sources. One is the
inherent uncertainty related to the mapping between the design space and the
performance space, that is, the uncertainty in the transformation between the form and
the function of the vessel. This uncertainty can be related to the ship system itself,
e.g. available volumes, final weights, position of the centre of gravity, material
quality, or to the environment in which the ship system operates, e.g. freight rates,
cargo inflow, costs, transport demand, weather conditions. Because of this, it is
difficult to establish analytical relationships between the design variables and the set
of design criteria. To a large extent these relationships have to be modelled on the
basis of empirical data and heuristic rules.

Figure 2–1: As the design process proceeds, the knowledge
about the design increases, while the freedom to make
changes decreases
Another aspect of the limited availability of knowledge is the relatively high ratio of
qualitative to quantitative information. This makes it more difficult to transfer, share
and store design knowledge, and also makes the knowledge less available for
computer-based design tools which require a high degree of formalism.
Despite the importance of the decisions made in the early stages of the design process,
only a minor share of the resources are spend here. In [Levander, 1991] the time and
Chapter 2- The Preliminary Ship Design Process 3
money allocated to the pre-contract phase is estimated to only 1% - 2% of that of the
post-contract phase at a typical shipyard. Taking into consideration the complexity of
the structure to be built and the financial commitment made in the contract, this effort
may seem too limited. However, it needs to be traded off against the risk of not
receiving the contract, thus making the allocation of resources for preliminary ship
design a difficult decision problem in itself.
On the basis of the preceding description, it is clear that the decisions made in the
preliminary design phase are important, yet the provision of support for these decision
is made difficult by problem characteristics such as uncertainty, lack of knowledge,
and time and resource constraints.
2.1 The Content of the Preliminary Ship Design Process
From a temporal point-of-view, preliminary ship design comprises the activities from
the design project is initiated to a contract specification is delivered. This corresponds
to the three first stages of the design model of Pahl & Beitz [Pahl, 1984]: clarification
of task, conceptual design, and embodiment design. Each activity is bounded in time
by a set of events, as illustrated in Figure 2–2. Though the content of these activities
and events will vary with respect to both the actual design problem and to differences
in design practice, some similarities can be found that together can be used to form a
prototypical preliminary ship design process.
Clarif icat ion of
t ask
Concept ual
design
Embodiment
design
Design
init iat ion
Pr oblem descr ipt ion
(St at ement of need)
Out line specif icat ion
(Tender invit at ion)
Cont r act
specif icat ion

Figure 2–2: Activities and events in the preliminary design process
2.1.1 Clarification of task
The design process initiates with the identification of a need, and the corresponding
decision to seek the means for which this need can be satisfied. The first task to be
undertaken is the clarification of the design problem. The purpose is to produce an
operable problem description − a problem description that is sufficiently defined in
4 Chapter 2 –The Preliminary Ship Design Process
order to start the search for solutions. This includes the identification of promising
market segments, forecasting the development of market supply, demand, prices, cost,
etc., identification of market characteristics (customers, competitors, conferences,
entry and exit barriers, etc.), and the resolution of market constraints and restrictions.
Often this activity is performed by the owner or brokers, and not by the shipyard.
Ideally, the result of this activity is a set of pure functional requirements and
objectives that the final design solution should meet, that is, the formulation of the
design task should not presuppose any particular solution. This is important for
maintaining a creative element in the design process, hopefully leading to a new and
innovative solution. For instance, formulations like “design a bulker with less than 10
m draft” should be avoided, since important aspects of the solution will be implicitly
defined. A better alternative is the formulation: “design a transport system that can
unload bulk cargoes in port X where the maximum permissible draught is 10 m”
(example from [Erichsen, 1989]). In the latter formulation the emphasis is on the
problem, keeping the choice of solution open. However, in practice the openness of
the design problem is restricted due to factors such as risk avoidance, the adaptation
to existing production technologies and facilities, and sometimes an inherent
conservatism in the maritime industry as such.
2.1.2 Conceptual design
Generally, conceptual design involves the development of function structures, the
identification of solution principles, and the combination of these into concept
variants [Pahl, 1984]. In ship design the content of the conceptual design activity
varies substantially. In some cases the concept on which the design is to be based is
explicitly given by the potential customer. In other cases there is a number of given
alternatives from which the concept is to be chosen. There may also be situations
where all existing concepts are considered unsatisfactory, and a new concept has to be
developed from scratch.
The result of the conceptual design stage is typically an outline specification,
describing the main features of the selected solution, together with the most important
design constraints and restrictions. The design specification will serve as a tender
document from the purchaser, or as the main governing document for the embodiment
design phase for in-house projects.
In order to secure a rational trade-off between different design performances, it is
advantageous if the specification explicitly state the design goals of the customer,
preferably in operable terms indicating both the relative weight of each goal and how
goal satisfaction should be measured. In practice, however, this information is less
available, thus relying to a large degree on human expertise for evaluating and
Chapter 2- The Preliminary Ship Design Process 5
selection of the “optimal” solution taking both monetary and non-monetary goals into
consideration.
An example illustrating these characteristics for the outline specification is given in
Box 2-1. In paragraph (i) the intention of the outline specification of stating the
minimum requirements for the vessel to be designed. In (ii) the top-level preferences
of the potential customer is given, thus providing the basis for forming an evaluation
function that can be used to determine the overall performance of a particular design.
Paragraph (iii) in Box 2-1 states the selected conceptual solution, while paragraph (iv)
states constraints on the design solution by giving (minimum) performance and
operational requirements.
Box 2-1: Excerpts from an outline specification from [Statoil, 1991] illustrating
typical characteristics. The outline specification serve as a starting point for the
embodiment design phase
(i) “This outline specification contains design and minimum performance and
operational requirements of a tanker for cargoes as listed in DnV Rules (…). “
(ii) “On a competitive basis, the Charterer will give preference to vessels offering the
best design and operational characteristics for the following high-lighted items: (…)”
(iii) ”The vessel shall be a single screw fully welded motor tanker with bulb,
forecastle, pump room aft, and one semi-spade rudder. The vessel shall be built with
double bottom and double skin as ballast tanks, and preferably arranged with centre
longitudinal bulkhead in the cargo area. (…)”
(iv) “The vessel shall be constructed and outfitted for world-wide trade. Dimensions
for length overall, draft, and extreme beam will be subject for due consideration with
respect to limitations at major European and US terminals. Max. draft = 7.5 m. The
vessel’s deadweight shall be about 6000-8000 tonnes on design draft in SW. The tank
capacity is to be sufficient in order to carry a full deadweight with a cargo of specific
gravity 0.8 t/m3. The mean service speed for design loaded/ballast shall not be less
than 12.5 knots with main engine running at 90% MCR, and at head wind speed and
sea state up to and including Beaufort Number 5. (…)”
2.1.3 Embodiment Design
Using the outline specification as a starting point, the embodiment design phase is
concerned with identifying a design solution that is both feasible and preferable to
other solutions in terms of performance and cost. In ship design this involves three
main activities: determining the main dimensions, selecting a set of preliminary lines
for the hull, and developing the main aspects of the general arrangement.
6 Chapter 2 –The Preliminary Ship Design Process
The outcome of the embodiment design phase is a contract specification. This
document typically contains the following items [Kanestrøm, 1991; Statoil, 1991]:
❏ Main dimensions and capacities
❏ General arrangement
❏ Preliminary lines
❏ Preliminary weight calculations
❏ Preliminary hydrostatic calculations
❏ Cargo conditions/deadweight estimates
❏ Preliminary tonnage calculations
❏ Preliminary electric load balances
❏ Estimate of production hours
❏ Sketches of important arrangements
❏ Price estimates
❏ Masterplan for the production process
A principal difference between the conceptual and embodiment design phase is the
dominant type of decisions made. According to [Mistree, 1991] there are two types of
primary decisions: selection and compromise. The selection decision involves a
choice between a finite number of given alternatives, based on a trade-off between a
set of attributes. In the compromise decision the task is to find the value of a set of
design variables that best satisfies some given objective within the system constraints
and bounds. Other kinds of decisions can be represented as a combination of these.
In the conceptual design phase selection is the dominant decision type, in making a
choice between a number of solution principles. In the embodiment the dominant
decision type is compromise, in finding the values of the ship main characteristics in
order to best satisfy mission requirements. This results in a principally different
decision-making process in the conceptual and embodiment design phase, making a
common approach with respect to decision support inappropriate.


"Pending the development of a radically new type
of computer, it is safe to say that which cannot be
formalised in logic cannot be modelled in a
computer system" [Roozenburg 1993]
3
A Review of Engineering Design
It is said that design is in a state of change, and that we see a development towards a
"science of design". The notion of a design science was first put forth by H. A. Simon
in his book “The Sciences of the Artificial” [Simon 1982]. Following this, the design
community has put considerable effort into developing a theoretical fundament on
which such a science can be built, though so far no general consensus has been
reached on the actual content of this fundament.
An excellent survey of the current status of design science is given by [Finger and
Dixon 1989]. Particular research areas comprise the formulation of a consistent design
taxonomy [Dixon, et al. 1988, Ullman 1992], the identification of fundamental design
axioms and invariants [Mistree, et al. 1990, Suh 1990, p 12], the development of
procedures for hypothesis formation and testing in design [Antonsson, 1987, Dixon
1987], and the establishment of a theory for understanding design processes [Mistree,
et al. 1990, Hubka 1982, Hubka and Eder 1987, Coyne, et al. 1990, Rzevski 1980,
Yoshikawa and Koyama 1982].
The pursuit of a theoretical basis for design aimed at linking design method and
scientific method has also been criticised. Cross [Cross 1980] points to the
fundamental difference in the goals of these two activities: While science aims at
describing the nature of what exists, design is concerned with inventing artefacts that
are to be built. As a consequence of this basic difference, a common theoretical
foundation for these two activities is not possible, nor desirable. He further indicates
that the underlying reason for the science approach to design is not based on the
nature of design as such, but rather motivated by the attractiveness of scientific
qualities, like rationality, neutrality, and universality, primarily aimed towards giving
design a higher status both in academia and in society in general [Cross, 1980].
8 Chapter 3 - A Review of Engineering Design
A similar criticism has been put forth by Sargent [Sargent 1994]. He claims that
design requires the integration of techniques from several fundamentally incompatible
views of the world. From this he concludes that we can have no unitary “science of
design” − at best we have a number of partial theories that are useful. Thus, an
essential aspect of design is to reconcile the incommensurate requirements and goals
created by the partial theories.
It is not within the scope of this lecture note to discuss the ontological
1
properties −
the “essence” − of design. Rather, a more utilitarian view is taken, as follows: If we
by "science" understand any methodological activity towards identifying, describing,
investigating, and explaining a certain class of phenomena, then a scientific approach
towards design is both useful and necessary to conduct research and development
work in design.
Box 3-1: On science and design, from [Suh 1990, pp. 5-6]:
"One of the major causes of the dismal state of design is simply a mental block: the
notion that design, unlike the natural sciences, cannot stand on a scientific basis. This basic
hypothesis is both unnecessary and incorrect. (...) Due either to lack of sufficient effort or to
the lack of truly successful paradigms for dealing with creative processes on a systematic
basis based on "principles" and "laws", it has been assumed that these topics cannot be treated
as subject for scientific discourse. (...) In the absence of a scientific basis, human intellectual
endeavours ranging from fine arts to engineering are performed subjectively in the realm of
the "creative" activity. Since the output of such activities cannot be understood rationally in
the absence of commonly accepted criteria, they are treated as such. What this really means is
that we can appreciate the outcome of the intellectual endeavour but do not understand the
process that produces the outcome, and cannot quantify the results. (...) When "know-how"
and knowledge are not codified, each generation must gain similar experience all over, again
and again, and develop its own intuition. These are typical characteristics of a field that has
not yet matured into a "science". A truly scientific discipline is powerful because governing
principles or laws describe the underlying thought process and reduce a seemingly complex
arrays of facts and observations into consistent and explicitly stated knowledge.”
As support of this view, two development trends are of special importance: First, we
have seen design evolve from mainly being a one-man invention process into a multi-
person/multi-team core activity in the industrial organisation. Where before the
designer could to a large extent rely on his/her own skills and experience in
organising and carrying out the design task, it is now common that a large number of
people with different backgrounds, sometimes located at geographically distant
places, work closely together on the same design in parallel. From this follows a
requirement for both a systematisation and a common taxonomy of design and design
processes in order to co-ordinate the activity.

1
ontology The branch of philosophy that deals with being [American Heritage Dictionary, 1991]
Chapter 3 - A Review of Engineering Design 9
Secondly, and most important for this thesis, is the central role that computers have
come to play in design. Until recently, their main function in the ship design process
was to automate the often tedious and complex task of design analysis, and to serve as
an advanced drawing aid in graphical CAD tools. However, in the last few years we
have seen a development towards the computer increasingly acting as a partner to the
human designer. Examples of technologies enabling this are large scale integrated
design systems, knowledge-based systems, and product models. Today, it is no
exaggeration to say that the presence of computers has become a prerequisite for real-
world ship design. As a consequence, there is a need for a systematic and formalised
treatment of all aspects of the design process, in order to satisfy the computer’s
demand for logic and rigour.
Box 3-2: The top-level design task can be described as a mapping between a
functional and a descriptive [Chandrasekaran 1989 p. 77]:
“The design problem is specified by a set of functions to be delivered by an artefact, a set
of constraints to be satisfied by the artefact, a repertoire of components assumed to be
available, and a vocabulary of relations between components. The solution to the design
problem consists of a complete specification of the set of components and their relation which
together describe an instance of the artefact delivering the functions and satisfying the
constraints.”
In the following I will look into the foundation for developing such a formalised
model of the ship design process. The focus will be on both the theoretical aspects of
design science and design methodology, and on new methods and the techniques of
decision support in designing complex, large-scale, engineering systems. In the first
part of the chapter I will briefly discuss elementary design inference processes, since
they represent the building blocks on which more complex design processes will be
based in later chapters. Further, a number of different design paradigms will be
described, and their usefulness for supporting the preliminary ship design process will
be evaluated. In the last part of the chapter, I will survey some relevant new
technologies that is expected to influence the design process in the years to come.
3.1 Inference Processes in Design
At the top level, the design problem is specified by a set of performance functions that
the design artefact is expected to deliver. In addition, a number of constraints and
bounds may be given. The outcome of the process consists of a description of a design
object that both satisfies the given constraints and bounds, and is preferable to other
design objects by some measure.
Thus, we operate mainly on two different representations of the design object, as
illustrated in Figure 3–1: A decision space that consists of descriptions of potential
10 Chapter 3 - A Review of Engineering Design
design solutions, and a performance space specifying the functions to be delivered by
the design object.

Figure 3–1: The top-level design process as a mapping between a decision space and
a performance space
In the ship domain, the decision space might be spanned by a numerical description of
the ship. This description may comprise a set of attribute-value pairs corresponding to
for instance the most important design characteristics, a geometric description of the
hull form using NURBS surfaces, or a topological description of the main ship
system. Most common in a preliminary design setting is a decision space spanned by
a numerical representation of the ship main characteristics, thus forming a n-
dimensional space of real numbers, ℜ
n
.
The performance space specifies the functions delivered by the design object. This
may be both independent performance functions, such as steel weight, production
cost, resistance, etc., or some compound criteria.
Using these representations, the baseline design process may be described as the
mapping of points from the performance space to the corresponding point in the
decision space, thus arriving at a design solution. If this mapping had been ideal it
would bring us directly to the “optimal” design solution. However, for real-world
practical design problems we are forced to take a number of iterative steps in order to
arrive at a satisfying design solution. In the following I will review different types of
such iterative steps, or inference processes. The discussion is to a large extent based
on [Coyne, 1990]. Later in this chapter these basis processes will be used in the
discussion of different design paradigms.
3.1.1 Representational building blocks of the design process
Before we proceed a number of terms on which the description will be based need to
be explained. These terms form the operands of the basic processes, and can be
Chapter 3 - A Review of Engineering Design 11
grouped into vocabulary, descriptions, interpretations, and syntactic and interpretive
knowledge.
The design vocabulary, V:
The vocabulary represent the building
blocks − the “atoms” − of design
descriptions, on which more complex
representational structures will be
based. A parallel in linguistics are
single words in a language.
What vocabulary is appropriate in a
particular design situation is depen-
dent on the chosen representation. For
instance, in a pure numerical repre-
sentation of the design object, the
appropriate vocabulary consists of
design variables represented as a set
of attribute-value pairs. In a geometric
representation of the hull, the vocabulary may be primitives like point, line, surface,
etc., or station-waterline-halfbreadth triplets. The choice of vocabulary affects what
kind of knowledge we are able to represent within the design system. This will be
further discussed in Chapter 4 in the context of the preliminary ship design process.

Figure 3–2: Alternative design vocabularies
Design descriptions, D:
The design description consist of an organised (sub-)set of the vocabulary, where each
vocabulary element is assigned to a particular value following certain rules so as to
represent a valid structure. The description is limited to the “objective” appearance of
the design artefact. This comprises those features of the design objects that can be
obtained by inspection, and exclude those that require interpretation. Again drawing
the parallel to linguistics, the design description corresponds to the sentences of a
language as they are given, without interpreting the meaning content. Typical design
descriptions are a list of the vessel’s main particulars (vocabulary of attribute-value
pairs), a general arrangement drawing (symbolic/geometric vocabulary), or 3-
dimensional hull form representation (geometric vocabulary).
Design interpretation
2
, I:

2
interpretation (…) 2. A representation of the meaning of a work of art as expressed esp. in
representation or performance. [American Heritage Dictionary, 1991]
12 Chapter 3 - A Review of Engineering Design
Design interpretation relates to the meaning content of a particular description, just as
we interpret meaning from a sentence in a language. In design we have two different
types of interpretations: The inferred interpretations which are the functional
performances of a specific artefact determined by design analysis. Typical examples
in the ship domain are resistance, seakeeping behaviour, cost, and required freight
rate. The other type is intended interpretations, denoting the functions and
performances we want the artefact to deliver. This corresponds to goals and
constraints in design, or the design aspiration space [Mistree, et al. 1990].
Syntactic
3
knowledge, K
s
:
Syntactic knowledge comprises knowledge that can be used to form valid structures
of the vocabulary, that is, valid descriptions. The linguistic parallel is knowledge
about how to form correct − but not necessarily meaningful − sentences. An example
of syntactic knowledge may be:
Cb = Cm ⋅ Cp
Hence, if we have a ship described by C
p
= 0.9, C
m
= 0.2, and C
b
= 0.18, it represents
a valid description with respect to the above syntactic knowledge, even if the meaning
content is close to zero.
Interpretive knowledge, K
i
:
To determining the meaning − the semantic content − of a particular design
description we need interpretive knowledge, K
i
. In the context of ship design, this
knowledge is closely related to design analysis. For instance, the knowledge about
how to determine the initial stability of a ship given a description of hull form and
weights represents interpretive knowledge.
3.1.2 Generic inference processes
We have now identified a set of basic objects that are used in design. The next step is
to relate these objects in a set of basic design processes. These processes are founded
on generic inference processes, that can be divided into three main types: deduction,
induction, and abduction. They can briefly be described as follows:

3
syntax 1. GRAMMAR a. The way in which words are put together to form phrases and
sentences (…) 2. COMPUTER SCIENCE The rules governing the construction of a machine
language. [American Heritage Dictionary, 1991]
Chapter 3 - A Review of Engineering Design 13
❏ Deduction is an inference step where the validity of the conclusion is guaranteed,
provided that the premises for the conclusion hold and are non-contradictory.
Deduction can be illustrated by the following sentence pattern
4
(Modus Ponens):
φ → ψ
φ
ψ
❏ In abductive inference, it is the specific instance which is the result. Contrary to
deduction, this is not a logically valid reasoning step. Abduction is given by the
pattern:
φ → ψ
ψ
φ
❏ Induction is the inference process of reasoning from the specific to the general,
also termed “the logic of scientific discovery”. Induction can be represented by
the following reasoning pattern:

1

1
),(φ
2

2
),(…)
φ → ψ
Using these terms, we can now describe a number of basic inference processes that
are part of the total design process Mapping these generic types into the design
domain, the following basic inference steps can be identified [Coyne, et al. 1990]:
3.1.3 Interpreting design descriptions
Traditionally, both in engineering education and in the development of computer-
based design tools there have been a strong focus on the process of interpreting
design descriptions, that is, design analysis. In the ship design domain, this has
typically consisted of the determination of the functional performance of the vessel
based on a set of analysis algorithms or empirical relations using a parametric or
geometric description of the vessel as input. This interpretation step can be expressed
as:
I = τ
1
(K
i
, D) (2.1)
The underlying inference process is that of deduction: given a syntactically valid
description D and the necessary interpretive knowledge K
i
, the interpretation I follows
logically. Following the scheme of Modus Ponens, we may have:

4
The notation follows [Genesereth, 1988], where φ and ψ represent generic sentences. In a design
context, φ represents any design description, ψ stands for any derived property, and φ → ψ stand for an
14 Chapter 3 - A Review of Engineering Design

Ki: ∀x DW(x) ∧ V(x) ⇒ Resistance(x) = f(DW(x), V(x))
D: DW(ShipA) = 200.000 ∧ V(ShipA) = 15
I: Resistance(ShipA) = 1200

The first statement says that if we know the deadweight and speed of any ship (within
the relevant “Universe of Discourse”) we can determine its resistance by using the
function f. Since this is a mapping from a description (DW and V) to an interpretation
(the performance parameter “resistance”), the statement is classified as interpretive
knowledge.
The second statement simply says that we are given a specific instance, ShipA, of
which we actually know the deadweight and the speed. On the basis of these two
premises, the corresponding resistance can be correctly interpreted as 1200, and,
given that the two premises are true, the interpretation is also true by logical
necessity.
The inference step just described is the core process in most existing preliminary ship
design tools. Referring back to Figure 3–1, it represents a mapping from the design
space to the performance space. Thus, it represent a necessary, but not sufficient,
inference step to support the top-level design process. In addition we need to support
the mapping the opposite way, in going from a specification of function to a
specification of form in the design process. For the aforementioned design tools this
has the consequence that the actual design process becomes sequential and iterative,
often described as a “DESIGN-EVALUATE-REDESIGN” cycle. Here, the computer
is primarily responsible for the EVALUATE part based on the interpretation
presented here, while the human designer is responsible both for proposing possible
design solutions in the DESIGN step, and to interpret the outcome of the
EVALUATE step in order to redesign the solution.
3.1.4 Generating design descriptions from interpretations
The generation of design descriptions from interpretations can be represented by the
transformation τ
2,
given as
D = τ
2
(Ki, I) (2.2)

arbitrary generalisation, for instance a rule of thumb, a physical law, or an empirical relation
Chapter 3 - A Review of Engineering Design 15
From a design process perspective, this represents the “ideal” inference step, since it
brings us directly from a functional description in the performance space to the
corresponding description of a design solution in the decision space. As an example,
we may have:

Ki: ∀x DW(x) ∧ V(x) ⇒ Resistance(x) = f(DW(x), V(x))
I: Resistance(ShipA) = 1200
D: DW(ShipA) = 200.000 ∧ V(ShipA) = 15

The example is the same as in the previous section, with the exception that the
interpretation, I, is now one of the premises, and the description, D, is the conclusion.
The inference pattern of the example above corresponds to that of abduction, or
“inference to the best explanation”. The “problem” with abduction is that it does not
represent a valid argumentation in the same way as for deduction, that is, the truth of
the conclusion, D, does not follow logically from the truth of the premises, I and K
i
.
On the contrary, there is most likely an infinite number of possible solutions that are
consistent with the two premises. Still, the abductive inference step represented by the
transformation τ
2
above is both useful and necessary in the production of design
descriptions. In particular, it is useful to reduce the search space by generating
reasonable hypotheses, that later can be validated by deductive interpretations, such
as the transformation τ
1
in Equation 1.1.
3.1.5 Syntactic generation
An alternative to using interpretive knowledge to produce design description, is to
rely solely on syntactic knowledge operating on the vocabulary. This can be
represented by the transformation τ
3,
given by:
D = τ
3
(K
s
,V) (2.3)
Since the intended interpretation (design goals and functions) are not taken into
consideration when the descriptions are produced, a design methodology based on
this is likely to produce a large number of “meaningless” solutions. Consider for
instance the syntactic generation of hull dimensions by random values of length, beam
and depth within a fairly wide range. Most likely this will produce descriptions that
fail to satisfy design goals such as sufficient stability, favourable resistance, etc., thus
having a limited “meaning content”. This will be further discussed in Chapter 5,
relating it to the computational efficiency of concept exploration models. However,
this transformation is still valuable for the production of design descriptions,
16 Chapter 3 - A Review of Engineering Design
particularly from a computer implementation point-of-view. This is mainly because it
represents a simple process compared to the transformation τ
2
. To avoid the
generation of infeasible solutions, we have to anticipate the “meaning content” of a
specific design before the particular design is actually generated and interpreted
(analysed).
3.1.6 Combined interpretation and syntactic generation
In practice, neither of the two aforementioned transformations are normally sufficient
for the efficient production of design description. Rather, a combined approach is
taken, as given by the transformation τ
4
:
D = τ
4
(K
s
, K
i
, V, I) (1.4)
An alternative representation could of course be to express this as a sequence of τ
1
, τ
2

and τ
3
transformations. An example where this is applicable is in a typical “design-
evaluate-redesign” process, where each reasoning step is fairly independent of the
others. However, we will se that often the different inference processes in the
sequence above are tightly integrated, and the compound transformation τ
4
will prove
useful.
3.1.7 Interpretive and syntactic knowledge acquisition
So far the existence of sufficient and relevant design knowledge has been taken for
granted. This is not a reasonable presumption in preliminary ship design − on the
contrary, this process is generally characterised by a lack of knowledge (see Section
1.1). In light of this, the acquisition and maintenance of the knowledge itself becomes
an important task.
The acquisition of interpretive knowledge can be modelled as
K
i
= τ
5
({D
1
, D
2
, ...}, I) (2.5a)
or alternatively as
K
i
= τ
5
({D
1
, I
1
}, {D
2
, I
2
}, ...) (2.5b)
Accordingly, we can model the acquisition of syntactic knowledge as:
K
s
= τ
6
({D
1
, D
2
, ...}, [V]) (2.6)
The inference process in the transformations above are equivalent to induction, where
a general knowledge statement is concluded from a set of observations or test cases.
For example, we may have:
Chapter 3 - A Review of Engineering Design 17

D1, I1: DW(ShipA) = 200.000 ∧ V(ShipA) = 15, Resistance(ShipA) = 1200
D2, I2: DW(ShipB) = 212.000 ∧ V(ShipB) = 14.8, Resistance(ShipB) = 1240
D3, I3: …
Ki: ∀x DW(x) ∧ V(x) ⇒ Resistance(x) = f(DW(x), V(x))

or, in the case of syntactic knowledge generation:

D1: V(ShipA) = 15.0 ∧ IsType(ShipA, TypeX)
D2: V(ShipB) = 14.8 ∧ IsType(ShipB, TypeX)
D3: …
Ks: ∀x IsType(x, TypeX) ⇒ V(x) isTypically around 15 knots

One typical example of the transformations τ
5
and τ
6
is the use of statistical inference
techniques. They can be used to derive empirical relations between the ship main
characteristics and derived performances, such as resistance & propulsion [Holtrop
1984, Holtrop and Mennen 1982], or steel weight [Watson and Gilfillan 1976,
Harvald and Jensen 1992]. They are also used to generate syntactic knowledge, for
instance determine design lanes for parameters and/or parameter combinations [Smith
1992].
In the actual design process models the syntactic and interpretive knowledge is
usually given a priori, as in τ1 to τ
4
, and not obtained as part of the process itself.
However, in recent years there has been an increased focus on the integration of
learning and knowledge acquisition into the design process itself [Aamodt 1991,
Duffy 1993], and it is generally believed that the ability to continually develop and
adapt the knowledge base on which decisions are made will become a key
competitive factor in the future.
3.1.8 Concluding remarks
Though they should not be regarded as an exhaustive set, the different inference
processes presented in this section together form the basis for design problem solving.
They will be used in the discussion later in this chapter on alternative design models,
and I will show that one of the primary differences between the different models lies
in which of the basic inference processes is emphasised.
18 Chapter 3 - A Review of Engineering Design
3.2 Descriptive Design Models
In this section I will discuss descriptive models of design in general, and the model of
the design task environment and problem space proposed by Goel and Pirolli in
particular. The purpose of descriptive models is both to describe how design is
performed within a practical setting, and to identify the general characteristics of
real-world design processes. Often these descriptive models are based on protocol
studies of individual designers or design groups, where data such as sketches,
calculations, verbal communication etc. are systematically gathered and evaluated.
Naturally, it is difficult to validate the design models evolving from such studies,
since design to a large extent is a mental process where there are few visible records.
Still, descriptive models serve as an important input to both the development of
prescriptive models, both as design guidelines for human designers, or to methods to
be implemented in a computer system.
Examples of descriptive models are a study of the design process of a medium-sized
industry project found in [Hales 1987, Hales and Wallace 1987], and a study of the
agreement between theoretical and practical design models in the development of an
offshore structure for the North Sea [Wikstrøm 1989, Wikstrøm and Erichsen 1990].
3.2.1 Invariants of the Design Problem Space and Task Environment
Goel & Pirolli [Goel and Pirolli 1989] have used descriptive protocol studies to
determine invariant characteristics of the generic design problem, based on the
assumption that “a description of design problem-solving must exist that both
captures the similarities in the problem-solving process across the various design
disciplines and recognises the differences between design and non-design problem
solving” [Goel and Pirolli 1989, p. 20]. As a template for this categorisation, they use
the concepts “design task environment” and “design problem space”, the former
denoting relevant features external to the design process, while the latter denotes the
features of design process itself as a result of the task environment.
For the generic design problem, they found eight significant invariants of the task
environment, which can be summarised as:
❏ Many degrees of freedom exists in the problem statement − owing to the fact that
the design problem specification tend to be under-specified
❏ Feedback from the world is limited or delayed during problem solving − much of
the feedback will have to wait for the artefact to be produced or put into regular
use, when a significant of the resources has already been expended
Chapter 3 - A Review of Engineering Design 19
❏ The input to the design process substantially consist of goals and intentions. The
output is a description of a design object
❏ The design object must function independently of the designer − the designer will
not participate in it’s use, and thus not be able to explain and perform its function.
❏ The specification and delivery of the design object are temporally separated. This
enables the designer to model the performance of the design object before it is put
into production, thus reducing the risk of being wrong
❏ Costs are associated with each and every action − no effort towards reducing the
risk of being wrong, by for instance improving the knowledge base or extending
the exploration of the design space, comes for free
❏ Answers are neither right, nor wrong, only better or worse − a parallel to Simon’s
notion of design as a satisficing rather than an optimising activity [Simon 1982].
❏ The problems tend to be large and complex
On the basis of the results from the protocol study, Goel & Pirolli proposed a
structure for the design problem space of the generic design problem, together with an
“explanatory connection” between this structure and the proposed characteristics of
the design task environment. Eight significant invariants were claimed:
❏ Extensive problem structuring
The many degrees of freedom and the lack of information in the problem
statement makes the creation of an efficient problem space difficult. Thus, an
extensive problem structuring is required, comprising among other things the
search for necessary information, the application of legislative, pragmatic,
technical, and self-imposed constraints, and the negotiation of problem space
boundaries. This problem structuring is a continuous activity as new knowledge is
gathered throughout the design process.
❏ Extensive performance modelling
Extensive performance modelling is necessary as a consequence of three of the
invariants of the task environment: The risk involved in being wrong makes
performance modelling a favourable trade-off, the independent existence of the
design object requires the interaction between the design object and its
environment to be anticipated up front, and the delayed feedback loop from the
world makes performance modelling necessary to guide the current problem
solving.
20 Chapter 3 - A Review of Engineering Design
❏ Personalised and institutionalised evaluation functions and stopping rules
Since there are “no right or wrong answers, only better or worse”, it is not
possible to derive a set of rational criteria for when to terminate the design
process. This is in contrast to more well-formulated problem-spaces where
stopping rules may be given by mathematically defined convergence criteria.
❏ A limited commitment mode control strategy with nested evaluation cycles
Ideally, the designer would postpone all evaluation of the design object until it is
completely specified, thus avoiding sub-optimisation. However, given the cost,
time and complexity involved, this is not a feasible strategy. This leads to a
situation where the designer need to negotiate a constant tension between keeping
the problem open and keeping the problem tractable
5
. In the study by Goel and
Pirolli the designers chose a compromise evaluation strategy, where a three-step
process were devised for each decision: First evaluate the component/sub-problem
on its own and decide whether to accept or reject it, then evaluate it in the context
of the design so far, and third, re-evaluate it later in a more complete context. Goel
and Pirolli denoted this strategy as a “limited commitment strategy mode”.
❏ The making and propagation of commitments
This characteristic of the problem space is closely related to the limited
commitment mode strategy, but instead focused on the need to make decisions
concerning the design object along the way in order to end up with a definite and
concrete design description.
❏ Solution decomposition into leaky modules
Because of the size and complexity of the problem, a decomposition into
manageable modules is necessary. According to Goel and Pirolli this
decomposition seems to be discipline specific, and acquired as part of the
designer’s training and practices. One problem is the interdependence between the
modules, giving rise to the term “leaky modules”. These interdependencies were
dealt with in two ways: either negotiated on the spot, or to “plug the leaks by
making functional level assumptions about the interconnecting modules” [Goel
and Pirolli 1989, p. 30] .

5
A similar situation is described in [Jacques, 1980]: “Imagine a momentarily absolutely free
person. Any action which he takes will preclude him from any number of other actions which were
also open to him at the moment of choice. Successive actions will be affected by the first choice. Thus
any action will mean a loss of freedom, but freedom cannot lie in not taking action because one is not
free to act.”
Chapter 3 - A Review of Engineering Design 21
❏ The use of abstractions in the transformation of goals to a description of the
design object
During the design process the designer has to “descend” from functional and
abstract specification of the design goal, to a concrete description of the design
object. In this process several intermediate abstraction levels are applied. Goel and
Pirolli observed that the number of such levels attended to was a function of the
designer’s “experience and familiarity of the task, the availability of relevant
knowledge, and personal preferences” [Goel and Pirolli 1989 p. 30]. The more
experienced, the more quickly the designer get to the low-level details.
They also noted that a common mistake was to descend too soon to the details. By
this, far-reaching commitments are made at a time when the design knowledge is
limited. In the ship design domain, Levander points to the same problem by
describing how naval architects normally begin their work: “They select a set of
main dimensions and start drawing the general arrangement” [Levander 1991, p.
48]. As an alternative he proposes a “system-based design” approach, where the
representation of the design object is kept on a high level of abstraction until late
in the process, thus being able to postpone major commitments until the design
knowledge base is improved.
❏ The use of artificial symbol systems
Artificial symbol systems used in the design process may be for instance natural
language, geometrical sketches, or topology diagrams. These symbol systems are
used both for aiding the design process per se, and for recording and
communicating design decisions.
22 Chapter 3 - A Review of Engineering Design
Size & complexit y of
problem
Input : Goal st at ement s
Out put : Art ifact
specificat ion
Temporal specificat ion
of specificat ion and
delivery
Delayed/limit ed
feedback from t he
world
Independent
funct ioning of art ifact
Cost of act ion
No right or wrong
answers - only bet t er
or worse
Many degrees of
freedom in design
problem st at ement
Solut ion decomposit ion
int o leaky modules
Abst ract ion
hierarchies
LCMCS & Nest ed
evaluat ion loops
Ext ensive performance
modelling
Personalized evaluat ion
funct ion and st opping
rules
Ext ensive problem
st ruct uring
Making and
propagat ion of
commit ment s
Use of art ificial symbol
syst em
Design Task
Environment
Design Problem
Space

Figure 3–3: The design task environment and design problem space for a
general design problem, adopted from [Goel and Pirolli 1989]
Chapter 3 - A Review of Engineering Design 23

Goel & Pirolli’s work is interesting because they show how the characteristics of the
problem space in design can be understood as a consequence of the external factors,
as given by the task environment. This is important to keep in mind in the
development of computer-based design tools, where a de facto problem space is
created by the functionality and interface of the system. Often, this problem space
seems to be as much a consequence of what is possible within the relevant technology
areas, as what is actually needed from the designer’s point of view. Thus, we may find
a mismatch between the designer’s intuitively created problem space (as given by for
instance the invariants of Goel & Pirolli), and the problem space he/she is forced to
work within when using computer-based design tools. Examples of such a mismatch
are:
Problem space created by human
designer
Problem space created by
computer-based design tool
Problem intuitively decomposed into
perceivable sub-problems, limited in
size by the capability of the short
term memory
6

Because of the computer’s ability
to retain large and complex
problems in memory, a
decomposition of the problem is
usually not necessary
Continuous migration between many
different abstraction hierarchies
Often only a single abstraction
level given by a fixed set of
design variables
Opportunistic exploitation of
whatever methods are appropriate
and available (see Section 3.3.7)
Methods to be used usually need
to be anticipated at compilation
time
It is obvious that if the mismatch between the two problem spaces is significant, it
will impede the efficiency and utility of the design tool. Thus, in the course of
devising methods for supporting the design problem-solving process, which is the
goal of this thesis, a thorough understanding of the relevant problem space is
necessary. This will be the main subject of Chapter 3, where I will look into the task
environment and corresponding problem space for ship design, based on the above
presented scheme of Goel & Pirolli. From this, a concept exploration model for

6
This capacity has been estimated to be about seven “chunks” [Simon, 1982, p. 80]. A chunk is a
maximal structure that can be recognized as one single item. E.g. ‘PGH’ consist of three memory
chunks, while ‘LCB’ only one (by a naval architect)
24 Chapter 3 - A Review of Engineering Design
preliminary ship design will be proposed in Chapter 5. The content of this model will
to a large degree inherit from existing, prescriptive design models. Thus, in the
following section I will describe some of the more important of these.
3.3 Prescriptive Design Models
A “model”
7
can be defined as a closed abstraction of a limited part of the world, for
the purpose of explaining and understanding a particular phenomena. Often models
aim at capturing only one specific aspect of this phenomena. Thus, we may operate on
several models concurrently, without having each model competing against the others
with respect to explaining the phenomena as such.
To a large extent, this is the situation in design. Design is a multi-faceted activity,
and, at least for now, the design community has not converged towards one single,
integrating design model capable of explaining all aspect of design. There have been
several design frameworks proposed, aimed at serving an integrating role between the
different design models. However, as will be discussed later in this thesis, there are no
neutral representations − the way we choose to represent both the design object and
the design process will necessarily presuppose a particular model. For instance, if we
choose a representation as rules, it is difficult to use traditional numerical algorithms,
and if we choose a representation consisting of simple attribute-value pairs, the
application of first-order predicate logic is impossible.
For the sake of the discussion here, I have chosen to group the different design models
into five main categories, given as:
1. Design as a systematic decomposition and synthesis
2. Design as a sequential, iterative process
3. Design as optimisation
4. Design as a creative activity
5. Knowledge-based design and artificial intelligence approaches
These five categories should neither be regarded as mutually exclusive, nor should
they be viewed as variants over a single dimension categorisation. The division is

7
model (…) 2. A preliminary pattern serving as the plan from which an item not yet constructed
will be produced. 3. A tentative description of a system or theory that accounts for all of its known
properties. (…) [American Heritage Dictionary, 1991]
Chapter 3 - A Review of Engineering Design 25
chosen mainly because each category to some extent reflect a particular view of
design.
3.3.1 Design as a systematic decomposition and synthesis - the German
VDI model
The VDI model − commonly termed “catalogue design” − is a systematic method for
design that has been developed by the German design community. The method was
originally developed by Pahl and Beitz [Pahl and Beitz 1984], and has later been
adopted as part of the German national standard for the design of technical products
8
.
Funct ion
Energy
Mat erial
Signals
Energy
Mat erial
Signals

Figure 3–4: In the VDI model, the basic function in all technical systems involves the
conversion of energy, material, and/or signals [Pahl and Beitz 1984, p. 23]
The VDI model offers a problem oriented design strategy, where the emphasis is
placed on a detailed problem analysis and a structured procedure to identify a
solution. The first step is to identify the main function of the design object from the
problem description. The main function is then broken down into a hierarchy of sub-
function. All functions are seen as a conversion of energy, material, and/or signal
(information), as illustrated in Figure 3–4. The transformation from a hierarchy of
function to a hierarchy of solution elements is by means of design catalogues, relating
elementary functions with alternative physical effect solutions. These solutions are
then synthesised into a complete design, and further improved in the embodiment
design phase.
What makes the VDI model interesting is the focus on a systematic approach to
design, offering relatively detailed procedures for the design engineer to follow. In
[Miles, 1994] the VDI-model is suggested as an epitome of the general approach to
design in German-speaking countries, as opposed to a focus on design analysis and
numerical techniques in the English-speaking world.

8
Guideline VDI 2222 (‘The design of technical products’)
26 Chapter 3 - A Review of Engineering Design

Figure 3–5: Design catalogue linking elementary functions with alternative solution
principles, from Beitz [Pahl, 1984 , p. 145]
3.3.2 Design as an iterative, sequential process
The most common way to conceptualise the ship design process is by a spiral model,
illustrated in Figure 3–6. It is a descriptive model that captures the sequential and iter-
ative nature of practical ship design, both as the different aspects of the solutions are
calculated and checked, and as the process changes from broad investigation in the
beginning towards detailed design at the centre of the spiral.
Andrews [Andrews 1981] have added time as an extra dimension to the spiral. Here,
the design spirals down the surface of a conical solid, as illustrated in Figure 3–7,
portraying the many constraints on a designer as a fundamental part of the process.
Chapter 3 - A Review of Engineering Design 27

Figure 3–6: The ship design spiral capturing the sequential and iterative nature of
practical ship design
Though the advent of computers have changed the content of the ship design process,
the spiral model still serve as a conceptual model both for the practical work in many
ship design offices, and for many computer-based design tools. Typically, the design
engineer specifies the values of a set of design variables that describes the ship, and in
some cases makes a preliminary selection of a hull form. These values serve as input
for calculation or simulation algorithms that predicts the performance of the ship in
areas such as hydrostatics, resistance & propulsion, weights, seakeeping, and cost.
This performance is then compared with the design requirements, and the design is
either accepted, or the analysis has to be rerun with a revised set of design variables.
A more detailed description of the content of each step in a process following this
scheme can be found in [Hills and Buxton 1988, Hagen 1992, Evans 1959,
Schneekluth 1987]. Examples of computer-based ship design tools that to a large
extent follow this conceptual scheme are Shipshape
9
, Hull-Calc, as part of the Hull-
Tech
10
program suite, and Autoship
11
[Ames and Lynaugh 1988].

9
Shipshape is a ship design program developed by MARINTEK, Norway
10
Hull-Tech is a suite of ship design programs sold by Kockums Computer Systems
11
Autoship is a hull design program develop and sold by CoastDesign, Vancouver, Canada
28 Chapter 3 - A Review of Engineering Design

Figure 3–7: An extension of the spiral, adding time as an extra dimension, from
[Andrews 1981]
The sequential, iterative design process, as captured by the spiral model, can be
captured in a task structure given by “DESIGN-EVALUATE-REDESIGN”, shown in
Figure 3–8. Using the basic inference processes described earlier in this chapter, the
three tasks can briefly be described
as:
DESIGN
EVALUATE
REDESIGN

Figure 3–8: The top-level process elements in a
sequential, iterative design process
DESIGN: Propose a potential
solution to the design
problem, either
based on syntactic
generation, on a
previous solution, or
on general domain
knowledge and
experience
D = τ
4
(K
s
, K
i
, V, I)
EVALUATE: Analyse the proposed solution with respect to the relevant
performances, and compare with the design goals and functional
requirements
I = τ
1
(Ki, D)
REDESIGN: If the proposed solution does not fulfil the design goals and functional
requirements − change the initial solution on the basis of the calculated
performance − iterate.
D’ = τ
2
(K
i
, I)
It is the second step, EVALUATE, that has received most focus with respect to
computer-based decision support. This is mainly because the EVALUATE step to a
large extent is based on traditional design analysis, and thus is well founded on
mathematical and physical concepts. Given the computers ability to store and process
large amounts of numerical data at high speed, a computer implementation of this task
is relatively straightforward.
The other two steps − DESIGN and REDESIGN − have received less attention in the
computer-based design tools based on this task structure. In the REDESIGN step for
Chapter 3 - A Review of Engineering Design 29
instance, if the proposed solution have been found unsatisfactory, there is usually
limited feedback on how (e.g. which variables, what direction, what stepsize) the
design should be changed in order to improve the solution. This relies to a large
extent on the designers expertise and experience.
A drawback that has been pointed out is that this model typically lock the designer to
his/her first assumption [Levander 1991]. This first assumption is often an existing
ship, perhaps slightly modified to account for differences in the functional
requirements, or a starting point within the mainstream of existing designs that is
based on empirical formulas. Since each iteration tend to be relatively time-
consuming, there is a tendency that only a limited part of the potential design space
around the first assumption is explored. This observation is also supported by a
protocol study of mechanical engineers by Ullman and Dietrich, referred in [Finger,
1989], concluding that designers pursue a single design concept, and that they will
patch and repair their original idea rather than generate alternatives
One argument in favour of this "basis ship" approach, based on a (minor)
modification of an existing solution, is that the continuous development into
specialised ship types during the last century has resulted in ship types close to an
"optimum" design. Hence, a single point initial assumption based on an existing ship
will be a good starting point.
While this might be true for a limited time in certain segments of the market, the
statement has not necessarily general validity. Technical progress, e.g. new materials,
new production methods, more efficient propulsion systems, together with an ever
changing environment for shipping activities in terms of stricter regulations, new
markets, and varying market conditions will always call for new solutions. Hence, the
assumption that an “optimal” solution will be found by minor adjustment of an
existing one can prove costly. Rather, it is desirable that the design problem is kept
open in the initial stages, by taking a larger set of possible designs into consideration.
3.3.3 Modelling preliminary ship design as a mathematical optimisation
problem
Generally, design can be defined as the production of a description of an artefact that
is believed to satisfy a given set of functional requirements and constraints − that is, a
feasible design solution. However, feasibility is only a necessary condition for the
final design − sufficient conditions usually include that the design solution is
preferable to other solutions by some means.
Thus, the iterative, sequential process as in the spiral approach represent an
optimisation process in the sense that we continually seek improved solutions through
30 Chapter 3 - A Review of Engineering Design
repeated modification. However, as mentioned in the previous section, the decision on
how to improve the solution relies to large degree on the continuous interaction with
the designer. An alternative approach to optimisation is a formal, mathematical
process where the decision on how to improve is determined internally by the chosen
algorithm. Here, the value of all design variables are determined simultaneously. It is
this type of mathematical optimisation processes which is understood by the term
“optimisation” here.
In the terms of a classical, mathematical optimisation problem, the preliminary design
problem can be stated as:
minimize
subject to
f
n
( ),
( )
( )
x
h x 0
g x 0
x
=

∈ℵ⊆ ℜ

Here, f is an objective function to be minimised, corresponding to the design goals. f
may express the preference structure of a single design goal, or it may be a compound
function representing multiple design goals. h and g are functional constraints, and ℵ
is the set constraint defined over an n-dimensional design space ℜ
n
. In this form, the
design problem is a well-formulated problem, subject to solution by for instance
mathematical programming and operational research techniques.
Expressed in terms of the elementary inference processes discussed in the previous
section, optimisation can be modelled as a single deductive step directly from the
design problem formulation, as given by the transformation τ
2
(Equation 2.2). This
can be illustrated by the following example:
Ki1: ∀x DW(x) ∧ V(x) ⇒ TotalCost(x) = f(DW(x), V(x))
Ki2: ∀x DW(x) ∧ V(x) ⇒ AnnualCargoCapacity(x) = g(DW(x), V(x))

I1: minimise TotalCost(ShipA)
I2: AnnualCargoCapacity(ShipA) > minAnnualCapacity

D: DW(ShipA) = dw ∧ V(ShipA) = v
Here, design knowledge (K
i
) is given in the form of numerical relations between
design variables and the performance variables. Also the intended interpretations −
design goals and constraints − are expressed as numerical relations. In addition,
control knowledge concerning the transformation τ
2
itself is needed. Given that this
can be transformed into a well-behaved problem formulation, satisfying conditions
such as continuity, differentiability, well-boundedness, and unimodality, the
Chapter 3 - A Review of Engineering Design 31
“optimal” design description can be directly derived as a consequence of the intended
interpretation I and interpretive knowledge K
i
.
There are numerous examples of the use of optimisation in ship design. In [Folkers
1973] a case study on the use of geometric programming for determining the ship
main characteristics is presented. In [Nowacki, et al. 1970] a more elaborate study is
performed concerning the preliminary design of tankers. Here, the Hooke & Jeeves
Direct Search technique, and the Sequential Unconstrained Minimisation Technique
(SUMT) are applied. In [Erichsen 1972] both a fleet of containerships and their
terminals are optimised concurrently. In [Ray and Sha 1994] a multi-objective
optimisation of containership main characteristics is presented. Other examples are
[Lyon 1982, Pal 1991, Parsons 1975, Perakis and Jaramillo 1991].
With its ability to make a direct mapping between a representation of the design
problem in the performance space, and a superior solution in the decision space,
mathematical optimisation obviously represents a very powerful design paradigm. In
addition, given a well-formulated and well-behaved problem, the actual problem
solving process is computationally efficient. This is a result of the exploitation of
local information in the design space, using the behaviour of the mapping function at
the current point to direct the process towards an improved solution. By this, the
computationally intensive task of determining the performance associated with a
particular design solution − design analysis − is limited to a minimum. Still, design
tools based on a traditional approach to optimisation have so far had only a limited
impact on the practical design process, and few, if any, commercially available tools
for the shipbuilding industry is based on this design paradigm. What is the reason for
this situation? Part of the explanation might be found in the following points:
1. The overall design problem is not easily transformed into the restricted format
required by most mathematical optimisation algorithms
There are two primary aspects of this transformation problem: One is whether the
real-world characteristics of the preliminary ship design problem are in agreement
with the requirements of the chosen numerical optimisation algorithm, the other is
whether the relatively high level of expertise required to formulate and solve
numerical optimisation problems makes it a viable paradigm for a practical design
tool.
The use of optimisation techniques requires all aspects of the problem to be expressed
in mathematical terms. In addition, there are also specific requirements with respect to
the properties of the problem space. Most algorithms demand that all functional
relations are continuous, others that the functions are differentiable at all points in the
design space. Also, in constrained optimisation, the problem space need to be
properly bounded by the constraint set.
32 Chapter 3 - A Review of Engineering Design
For real-world, complex design problems, the distance to this idealised mathematical
representation is often substantial. A vivid description of this is given in [Goldberg
1989]:
“Theorists interested in optimisation have been too willing to accept
the legacy of the great eighteenth and nineteenth-century mathe-
maticians who painted a clean world of quadratic objective functions,
ideal constraints, and ever present derivatives. The real world of
search is fraught with discontinuities and vast multimodal, noisy
search spaces.”
Is this a valid description for the search space in preliminary ship design too? On the
basis of studies on the use of mathematical optimisation in preliminary ship design
(e.g. [Folkers 1973, Nowacki, et al. 1970, p. 367, Lyon 1982]), the answer seems to
be no. In these studies the design problem is modelled by the ship main
characteristics, a set of empirical relations, and an objective function usually
minimising either the steel weight or required freight rate, giving in most cases a
relatively well-behaved, convex search space.
However, extending this to assume that these search space characteristics can be
found for an arbitrary formulation of the preliminary ship design problem needs
caution. First, the functional relationship f, relating the design vector x to the design
goals, is not well understood in mathematical terms for multi-criteria design
problems. Different methods exist to bring the different criteria together. Examples
are the use of weighted value/utility functions [Keeney, 1976], the use of a ranking of
the design goals in a pre-emptive value function [Smith 1992], or a hierarchical
evaluation process [Sen and Yang 1994]. These methods may cause a non-convex
compound objective function, even if the single goals themselves are convex. One
example is in the design of a frigate using constraint violation as a criteria, showing a
highly multi-modal response function [Smith 1992, p. 168]. It is also a problem when
the optimisation algorithm relies on externally linked procedures, as for instance in
the ship design system NAPA [Priha 1989], or ‘Engineous’ [Ashley 1992]. In these
cases it might be difficult to determine whether the requirements for using a specific
optimisation algorithm is satisfied.
Another problem with using mathematical optimisation is the relatively high level of
expertise that is needed both to formulate a well-behaved problem, and to verify that
the identified solution is in fact a global optimum within the search space.
To some degree the difficulties of using mathematical optimisation algorithms can be
hidden from the practising designer by a proper user interface, letting the designer
only change a limited set of design variables and parameters within a range known to
result in a well-behaved problem. However, this has the draw-back of limiting the
Chapter 3 - A Review of Engineering Design 33
flexibility and possibility to adapt the problem-solving process to the specific
characteristics of the problem. In other words, the possibility of having what is
commonly termed a “meta-design”
12
process will be limited.
2. The creation of design “black boxes”
Another problem with hiding the inner structure of the optimisation algorithm is the
creation of so-called “black-boxes”. A “black-box” is a part of the problem-solving
process in which the designer get little or no insight, and can do nothing more than
put in his/hers good faith in the output. Since the knowledge pertinent to preliminary
ship design is to large degree based on empirical relations and experience where a
personal trust in the calculations are important, such black-boxes are undesirable.
They also leave little room for letting the designer use his/hers experience to improve
the solution. As said by [Folkers 1973]:
"There is actually little success in interesting conventional ship-
builders (in using automated optimisation packages) at this early
stage since they will be sceptical about such undertakings which do not
take into account the various intuitive considerations used in these
complex problems."
From the discussion above, there seems to be a “mismatch” between the actual design
problem, as seen from the practising designers point-of-view, and the idealised repre-
sentation of the problem required by the optimisation-based design tool. In recent
years we have seen some interesting approaches to bridge this mismatch, aiding the
designer to transform a real-world, unstructured problem into the format required by
mathematical optimisation. Two particular approaches are the “Decisions Support
Problem Technique” (DSPT) by Mistree, Smith, et al. [Mistree, et al. 1990, Smith
1992], and a knowledge-based interface to optimisation by Balachandran
[Balachandran 1993].

12
“Meta-design” means the design of the design process, that is, the modeling of the design process
with respect to the characteristics of the problem. The possiblity of explicitly suporting meta-design
will be further discussed in Chapter 5 in the context of concept exploration models
34 Chapter 3 - A Review of Engineering Design
Templat e
Select ion
DSP
Variables
Compromise
DSP
Const raint s

Figure 3–9: Representational scheme in decision-based
design
In Decision-Based Design (DBD) the design process is broken up into a meta-design
phase and a computer-based design phase [Smith, 1992]. In the meta-design phase the
major decisions to be made are identified, and modelled into a hierarchy. In the
following computer-based design phase each of the decisions are transformed into a
corresponding Decision Support Problem, which can be formulated either as a com-
promise or as a selection support problem (or a combination of the two).
The transition to a Decision Support Problem formulation is supported by a set of
keywords that are used to structure each decision problem to a form that is amenable
to solution. For the compromise support problem these keywords are given by
[Mistree, et al. 1991]:
Given information
Find the value of the system variables
Satisfy system constraints, goals, and bounds
Minimise deviation function
13

Given a mathematical formulation of the description above, the decision problem is
solvable by an appropriate numerical algorithm
14
. The critical question becomes: How

13
The deviation function is a function that expresses the relative distance form the design goals in a
multi-objective goal formulation
Chapter 3 - A Review of Engineering Design 35
can a correct and consistent mathematical be ensured? Bras gives an answer to this by
presenting a “Design Guidance System” [Bras 1992]. Here, the transition from a real-
world problem to solvable computer code is achieved by the following steps:
1. The first step is to extract a natural language formulation, called a story, from the
real world problem.
2. This story is analysed using a
parser utility that identifies
relevant problem entities.
These entities are grouped
into a problem statement by
the parser.
3. The problem statements are
grouped with respect to the
keywords of the appropriate
support problem (e.g. given-
find-satisfy-minimise for the
compromise decision)
4. From the keyword
description a process network
is developed which will give
or several possible paths
towards a solution
Box 3-3 - On optimisation and Design"( [Crane,
et al. 1980])
One needs to consider first the primary purpose
in using optimisation methods for real applications.
The most obvious purpose is to find the minimum of
a well defined constrained function accurately and
efficiently. This is appropriate for the designer of an
optimisation subroutine. It is, however, unduly
restrictive where real problems are to be solved. Few
real problems are so simple or so well formulated and
understood that they can be solved simply by
minimising a simple function over n variables, even
when one allows the solution to be constrained. In an
application environment, then, the primary purpose in
using optimisation methods is to enhance one's
understanding of the real problem that is being
modelled, not to compute optimal answers. Viewed in
this context, a mathematical optimisation program is a
sophisticated tool to be used in an application
program for the solution of a real problem. Insight
gained by using optimisation methods with a
particular mathematical model embedded in an
application program will often lead to a revision of
the model that better approximates the real problem
under consideration. Ultimately, the precise minimum
may be of interest."
5. In the last step this process
network is converted into
computer code that can be
directly interpreted by the
numerical solver.
Fundamental to Decision-Based Design is the observation that design problems do not
come into being as well-formulated, numerically solvable problems. As said by
[Coyne, et al. 1990, p. 19]:
"Optimisation has failed to influence the field of design greatly, in part
because it does not address the question of how to arrive at such well
packaged formulations”

14
In the DSPT, the numerical solver is called DSIDES, based on an adaptive linear search
algorithm [Mistree, 1992]
36 Chapter 3 - A Review of Engineering Design
A valuable contribution from Decision-Based Design is how the consequences of this
observation is handled, by providing a framework for assisting the designer in
formulating a solvable problem. With respect to applying mathematical optimisation
techniques in preliminary ship design, this is a critical issue.
What can be concluded from this with respect to the goals set out for this thesis?
First, the fact remains that optimisation is indeed a powerful approach to design.
Given that we are able to formulate our design problem in strict mathematical terms,
and that this formulation is sufficiently well behaved, optimisation provide the most
effective strategy for identifying superior, or “optimal”, solutions within the given
design space. However, taking into consideration the typical characteristics of a pre-
liminary ship design problem, such as incomplete “soft” knowledge and a high degree
of uncertainty, traditional optimisation fails too provide a robust enough base on
which to develop a general framework for decision support in preliminary ship
design. Rather, the strengths of optimisation is better exploited in solving closed sub-
problems of the overall design task − a conclusion that will be further supported in
Chapter 6 concerning the structure of the concept exploration model.
3.3.4 Design as a creative activity: Abductive generation in original
design
In both the previous two generic models of design − the design “spiral” and
optimisation − the basic inference process is based on operations upon knowledge
already existing within the design system. In real-world design situations − and
preliminary ship design in particular − this is not always the case. Often a specific
design problem requires that the designer is able to look beyond the limits of the
existing knowledge base, or to rearrange existing knowledge, in order to find a
satisficing solution. Designers mastering this skill are often described as creative. The
same description may apply to a design system actively supporting such features.
To what degree creativity is required is dependent on the character of the design
problem. Three main types can be identified, termed original, adaptive and variant
design
15
[Pahl, 1977]. Original design applies a new solution principle to a particular
design problem, adaptive design tailor a known system to a different task, keeping the
solution principle intact, while in variant design the size and/or arrangement of
certain aspects of the solution is varied.

15
Other similar classifications are prototype refinement, prototype adaption, and prototype creation
in [Coyne, 1990], and original development, further development, and adaptive design in
[Wogerbauer, 1943]
Chapter 3 - A Review of Engineering Design 37
Preliminary ship design can be classified as either of these three, dependent on the
particular situation. Sometimes the design requirements can be satisfied by a minor
modification of an existing vessel, thus doing variant design. This is perhaps the most
common type of design. In other situations a more fundamental change is needed.
Examples are the development of hatchless containerships, double hull tankers, and
self-unloading bulk carriers. Even though important sub-systems of the baseline
solution are changed, the overall solution principle is kept intact. Thus, these
situations belong to adaptive design. Original design within the ship domain is the
least common type. It requires the designer to be able to look beyond the boundaries
of existing solutions, emphasising skills such as creativity and inventiveness. The
development of the hydrofoil and the air-cushion vehicle are examples from recent
history
16
.
In the case of original design, it is clear that we do not posses the necessary design
knowledge inside the system boundaries. Accordingly, we are not able to arrive at a
design solution using the abductive inference step described on page 15. In that case it
was interpretive knowledge that provided the necessary link between the problem
specification and the design solution, e.g.:

I: “Performance I is required”
Ki: “IF an artefact is described by D (THEN) it delivers performance I”
D: “Hence, an artefact described by D is a possible solution”
In [Roozenburg 1993], Roozenburg discusses the pattern of reasoning in innovative
design. According to him, we may speak about two different types of abductive
reasoning: One is explanatory abduction, following the pattern above. Here, having
put forth the description D as a potential solution to the problem − a design hypothesis
− we may test the hypothesis deductively using the interpretive knowledge, or design
explanation. As mentioned before, this is the typical inference process in both the
“design spiral” approach (K
i
is typically an analysis algorithm) and in the VDI-
method (K
i
is typically a design catalogue) [Hubka 1982, Pahl and Beitz 1984, Roth
1987].
The other type of abductive reasoning is what Roozenburg denotes innovative
abduction. Here, starting from a “non-explainable” design performance, we need to
both develop the necessary design knowledge, and to identify a potential solution. An
example of this inference step is shown below. Both K
i
and D are unknown

16
The existence of original design has been questioned [Coyne, 1990], arguing that this is simply
adaptive design of a sufficient degree to be regarded as a novel idea. E.g. hydrofoils can be said to be
the adaption of an air wing into water, while the air cushion vehicles are based on ordinary
propellers/fans turned horisontally
38 Chapter 3 - A Review of Engineering Design
beforehand, and mutually dependent − you don’t have K
i
without D, and vice versa.
Thus both need to be part of the conclusion, as in the following example:
I: ExcellentSeakeepingAbilities(ShipA)
Ki: ∀x IsType(x, SWATH) ⇒ ExcellentSeakeepingAbilities(x)
D: IsType(ShipA, SWATH)
The mechanism behind innovative abduction is little understood. Typically, it comes
as a flash, a sudden intuitive insight. Borderline situations might exist, where the
necessary knowledge do exist within the closed human-computer design domain but
is too fragmented and unorganised to be explicitly identified and “planned” into the
design process. Such knowledge is often termed “tacit” knowledge, and is believed to
be important in original design. The only way tacit knowledge can play a role in the
design process is by providing a user interface that enables an efficient interplay
between the human and the computer.
Because the reasoning processes behind creativity and innovativeness is not based on
valid, logical inference processes as e.g. in deduction, it is clear that the computers
ability to support such processes in design today is limited, and will remain so at least
until we gain a better understanding of those processes within the human brain. Thus,
the contribution to creativity must be made by the human designer. With respect to
the selection and development of a framework model for preliminary ship design, this
is significant factor, since it indicates the necessity of a complementary role of the
human designer and the computer in the design process. These roles should be
actively supported by the selected design model. This implies features such as
openness, interactive user interfaces, an active role of explanations, and, to the degree
possible, a one-to-one relationship between the computer’s and the human designer’s
internal representation of the problem.
3.3.5 Knowledge-Based design models
A more recently developed group of design methods and models are those that relate
to knowledge-based systems (KBS) and artificial intelligence (AI). There are several
examples of the use of knowledge-based systems in design. General design [Coyne, et
al. 1990, Hees 1992, Kamal, et al. 1987, Miles and Moore 1994, Han, et al. 1994], in
ship design [Nicklaus, et al. 1988, Stearns, et al. 1991]
The common denominator here is the way design knowledge is represented and used.
In most conventional computer programs the knowledge is represented in the form of
procedural algorithms. The problem with this representation is that it holds certain
anticipations on how this knowledge will be used, and that factual knowledge is only
implicitly represented within the procedures of the program.
Chapter 3 - A Review of Engineering Design 39
Contrary to this, the general rule in knowledge-based system is a declarative
representation of knowledge, where all factual knowledge is given a formal and
explicit existence. The representation should, to the extent possible, be independent of
the way this knowledge is applied and processed. The use of KBS in design may have
several advantages, which is summarised in the following points:
❏ The emphasis on a declarative rather than a procedural representation makes the
design knowledge comprehensible both to the human designer and the computer.
This makes it easier to continuously update and extend the knowledge base.
❏ The independence between the design knowledge itself and the methods that
operates upon it make knowledge-based systems robust, in the sense that all
necessary knowledge for solving a particular problem need not to be anticipated
beforehand, but can rely on a more general domain knowledge-base. This makes
knowledge-based systems better at handling ill-defined problems, and problems at
the limits of the intended scope of the system.
According to [Miles and Moore 1994], the ideal knowledge-based system should be
able to
❏ Solve the problem
❏ Explain its reasoning
❏ Learn from completed cases
❏ Restructure its knowledge
❏ Break rules (when and wherever necessary)
❏ Determine the relevance of acquired knowledge
❏ Degrade gracefully upon reaching the limits of the domain
With today’s technology it is impossible to achieve all these goals. Most current
implementation in practical use are able to satisfy only the first two of these features.
However, new technologies are emerging, focusing on the unresolved features of the
above list. Some of these technologies will be further discussed at the end of this
chapter.
3.3.6 DESIGNER: A Focus on the Design Object
One example of the practical use of knowledge-based systems technology is the
DESIGNER program developed by MacCallum et al. [MacCallum 1982, MacCallum
and Martins 1985, MacCallum and Duffy 1987]. The DESIGNER is an expert system,
aimed at exploiting the numerical knowledge embedded in design variables and
relationships. Thus, the emphasis has been on developing an efficient representation
of the design object as a basis for improving the design process. In DESIGNER, the
40 Chapter 3 - A Review of Engineering Design
design process is driven forward by operations upon design variables in a directed
network, as illustrated in Figure 3–10.
The knowledge in DESIGNER is built upon three basic representational concepts:
Design Characteristics, Relations, and Influences. The content of each of these are
illustrated in a frame representation in Figure 3–11. The primary component of the
Characteristic frame is an attribute-value pair as it is found in most numerically based
design tools, but is different in two important respects: First, it has an explicit repre-
sentation independently from the processes that operates upon it, and second, it is not
defined as a part of an assembly of attribute-value pairs as is the case in design
programs requiring a pre-determined input vector of design variables. In addition to
the attribute-value pair, the Characteristic frame also contain slots for an explanation
of the characteristic, the unit of measurement, the accuracy of the given value, and
two collection objects containing relationships and influences, respectively.
Block
coefficient
Lengt h
Machinery
weight
Deadweight
St eelweigt h
Draught
Beam
Dept h
Out fit weight
Power
Speed
Light weight
Displacement

Figure 3–10: A directed network representing the design object in
DESIGNER [MacCallum, 1987]
Chapter 3 - A Review of Engineering Design 41
Accuracy
Name
Explanat ion
Value
Influences
Relat ionships
Unit s
Charact erist ic
St rengt h
Next
Post -condit ions
Expression
Reliabilit y
Pre-condit ions
Next
Charact erist ic frame
Influence frame
Relat ion frame

Figure 3–11: The key representational concepts in DESIGNER: The Characteristic,
containing a collection of relationships and influences on other characteristics
The Relation links a particular characteristic to other by means of a numerical
expression. This expression may represent deep, “first-principle” knowledge (e.g.
DISPL = LPP B T CB), or more shallow knowledge such as numerical heuristics and
empirical relations (e.g. LPP = k DISPL
0.3
V
0.3
). The relation also contains slots for the
reliability, and the pre- and post-conditions that must be fulfilled in order for the
relation to be valid.
The Influence frame contain knowledge about the strength of the numerical
interrelations in the currently active network. These influences will be continuously
updated as the network is processed, thus simulating a kind of learning. By the
Influences, it is possible to both predict the effect of changing the value of one
characteristic on other characteristics not connected directly by a Relation, and predict
the secondary effects of the change propagation in the network.
What makes the numerical network approach to preliminary ship design, represented
by the DESIGNER application, interesting can be summarised as follows:
❏ No particular, fixed model of the design object is assumed, as is the case in design
applications based on procedural algorithms. Thus, the design object may be
modelled so as to fit the parallel mental model of the designer, and new design
aspects (Characteristics) and new knowledge (Relations and Influences) may be
added to the network without destroying the existing structure. By this, the meta-
design process (the planning of the design process) and the design process are
seamlessly integrated.
42 Chapter 3 - A Review of Engineering Design
❏ The representation of design knowledge as single, independent entities (frames,
objects), that can be easily reused in different network structures for various
design problem.
A more detailed evaluation of a numerical network representation will be given in
Chapter 6, both discussing some problems with respect to the practical design
problems, and what particular aspects of this representation that is useful for a ship
design concept exploration model.
As will become evident later in this thesis, I agree with the basic hypothesis about
decision support in design that is implicitly assumed by the DESIGNER: It is the
basic representation of the design domain concepts that lay the foundation for what
kind of knowledge it is possible to bring into the computer-based design process, and
how this knowledge can be operated upon by both the computer and the human
designer. This is different from most other design tools, where the necessary
functionality for a particular design domain is anticipated beforehand, and
implemented as a set of services where the underlying representation is as a set of
algorithmic procedures. The same focus on representation will also be given in this
thesis, when the structure of the concept exploration model is discussed in detail.
3.3.7 Developing a task-structure of design - an integrating approach
The numerical network model in the DESIGNER exemplified a flexible and method-
independent design approach by providing a suitable representation of the design
object. The same features of flexibility and method independence is sought by
Chandrasekaran. But instead of focusing on the representation, these features are
pursued by developing a task-structure of design [Chandrasekaran 1989]. The key
conclusion here is that “design as a general problem solving activity is solved not by
one method or technique but by an opportunistic exploitation of whatever methods are
available. Thus, in principle, very different methods and knowledge can be brought
into play in as flexible a way as possible.”
The task-structure developed by Chandrasekaran is in many respects a parallel to the
German VDI-school. But instead of focusing on the design object by deriving a
hierarchical structure of elementary functions and elementary solutions, the task
structure of Chandrasekaran aims at structuring the overall design task into primitive
subtasks. For each of these subtasks we need to investigate what methods are
available, and the corresponding knowledge and inference requirements the methods
have.
A division is made between design as a task and design as a process. The former
constitutes the act of combining a set of primitive objects into an assembly that
Chapter 3 - A Review of Engineering Design 43
satisfies a specified set of desired properties, while the latter centres on the problem-
solving process itself, i.e. design as search in a state space, design as a mapping from
a performance space to a design space, or design as an “intuitive leap” where the
design solution almost instantaneously comes into the mind of the designer. This is in
compliance with the elementary inference processes discussed earlier in this chapter.
In performing the design task a set of assumptions is made about the domain. First,
the availability of a set of primitive components is assumed. In the ship design domain
this could for instance be design parameters (Lpp, B, Cb, DW), parts (propeller,
machinery components, structural parts) or system descriptions. This corresponds to
the design vocabulary. Second, there exist a set of primitive relations between the
components. Examples are relations between the hull design parameters
(Displacement = Lpp B T Cb) and part assemblies. This corresponds to syntactic
knowledge.
To solve this task, a number of different design
processes are used, dependent on the characteristics of
the specific sub-task, the design domain, and the
preferences of the designer. According to
Chandrasekaran, the reason for this difference is mainly
the availability of knowledge. Hence, a prerequisite for
prescribing design methods for a particular domain (for
instance by developing computer-based design tools) is
a thorough survey of the design knowledge available in
this domain. This is also in compliance with my
previous discussion about different design models: The
appropriateness of a particular model, such as opti-
misation, design-evaluate-redesign, innovative ab-
duction, or knowledge-based systems, is dependent on
the character of the available knowledge.
PROPOSE
CRITIQUE
MODIFY

Figure 3–12: The generic
design process proposed by
[Chandrasekaran 1989]
Chandrasekaran proposes a generic design model
consisting of three basic steps − propose, critique and modify − as illustrated in Figure
3–12. The Propose step generates a potential design solution, for instance by design
decomposition/recomposition, by retrieval and adaptation of previous design cases, or
by constraint satisfaction methods.
The implication for research on tools to support software design will be aided by a
whole range of tools. When a tool will be helpful will depend on the level of the
designers experience with the object being designed and the domain being designed
in. For example, when the designer has designed an object previously he will need
tools that help retrieve the previous designs. When a designer has experience with
44 Chapter 3 - A Review of Engineering Design
elements of the design but not with the design as a whole, he needs tools that will help
to retrieve and assemble the elements in a simulation. When the designer has not had
experience in the domain, he will need tools that help him infer the constraints on the
design.
3.3.8 Concluding remarks on knowledge-based design methods
The common feature in what has been termed knowledge-based design methods here
is the explicit representation of knowledge independent from the methods operating
upon this knowledge. With respect to developing a flexible design tool, and to bring
more knowledge into the preliminary ship design process, I believe this way of
representing knowledge is necessary. Still, there is a fundamental trade-off between
the one extreme of providing for any knowledge and method, and the other extreme of
providing a well-defined set of design procedures. While the former is intuitively
appealing, some of this flexibility may be favourably traded off against the latter in
order to achieve a more structured process. In this thesis this is done by the selection
of a concept exploration model as an integrating process framework.
3.4 New Design Technologies and Emerging Trends
One key requirement for design framework sought in this thesis is that it should
represent an open and extendible design process environment in which new methods
can be easily implemented. Of particular interest in this context is the adaptation of
emerging technologies from the artificial intelligence and knowledge-based systems
domain. In recent years we have seen such methods gradually move from research
environments into practical use, and there is a wide-spread belief that the efficient
exploitation of such technologies will be an important competitive factor in the near
future.
In the following a few such emerging areas will be briefly investigated, and some
promising potential application areas are pointed to. Of particular interest are methods
that are able to support problems that are only given limited support by current design
methods. Some examples are:
❏ the exploitation of knowledge embedded in past design cases. That includes both
the use of individual past designs to aid particular design tasks, and in abstracting
and generalising new design knowledge. Traditionally, the knowledge embedded
in past design cases has been made available either as a single comparison ship
from which a new design solution can be derived, or through the compilation of
empirical formulas relating key design variables and the main performances.
Representative examples are [Watson, 1976, Holtrop and Mennen 1978].
Chapter 3 - A Review of Engineering Design 45
However, we believe there is a potential to better utilise this knowledge by the use
of more “intelligent” techniques. Relevant technologies are artificial neural
networks and case-based reasoning
❏ the identification of optimal solution within complex search spaces corresponding
to the mathematical representation of a real-world ship design problem. This is a
problem shared with for instance the aviation and space industry. Potential
techniques are heuristic optimisation techniques in general, and genetic algorithms
in particular.
❏ the ability to represent and operate upon human expertise and “soft” knowledge.
One of the key characteristics of the ship design process is the important role of
human expertise and experience. This knowledge is often difficult to capture in a
mathematical representation, and thus not easily integrated into a computer-based
design process. Hence, an important challenge is to implement a framework for
efficient representation and operation upon such knowledge. Potential techniques
may be traditional expert systems, fuzzy logic, and rule-based systems.
In the following some of the potential techniques mentioned above will be briefly
described.
3.4.1 Expert Systems
In an expert system, human expertise is usually represented by a set of rules. The
collection of such rules within the system may incorporate heuristics, experience, and
rules of thumb that are accumulated over years of problem solving. In the design
process this knowledge can be operated upon by using an inference engine that is
contained within the program.
In the ship design domain, we have seen the use of expert systems for structural
design [Stearns, et al. 1991, Fleming, et al. 1990] and in concept [Welsh and Hills
1991]. Another interesting application area for expert systems is to aid the designer in
using complex numerical computing tools [Ashley 1992, MacCallum and Duffy 1987,
Duffy and Kerr 1993]. Here, the expert system is used to retain the expertise in the
design process, the programs, and the use of the programs.
3.4.2 Case-Based Reasoning
Case-Based Reasoning (CBR) is, in essence, an AI technology based on efficient
exploitation of the knowledge embedded in previous similar cases. It makes historical
data more accessible by using advanced knowledge representations and inductive
machine learning to structure the information and discover useful knowledge.
46 Chapter 3 - A Review of Engineering Design
To the ship designer these features are intuitively attractive, since a somewhat similar
approach has a long tradition through the use of so-called “reference ship”. Here, a
previous design is used as a starting point, and is then adjusted to fulfil the
requirements of the present task. However, the CBR technique goes some important
steps further, by allowing for qualified, historic design specifications to be stored in a
case base for later reuse. A case is explicitly defined in terms of both functions and
intentions, and the indexing scheme used for retrieving relevant cases is highly
dynamic, as opposed to traditional databases.
3.4.3 Genetic Algorithms
Genetic algorithms have been developed as a parallel to the mechanism of
reproduction and natural selection observed in nature. Genetic algorithms use
historical information to direct the search towards expected increased performance.
This technique preserve the openness of the problem by maintaining a large
population of possible solutions, and continuously produce new solutions partly by
using building blocks from existing high performance solutions, and partly by random
processes similar to mutations in nature. In the design domain, examples of the
application of genetic algorithms are [Braun, et al. 1993, Davis 1991, Gage and Kroo
1993].
Genetic algorithms has been denoted a robust search technique because of its ability
to perform efficiently across a large spectrum of problem characteristics. This is
important for the ship design domain, where a complex search space has made the use
of traditional non-linear optimisation algorithms difficult to use. The main difference
from most other optimisation and search procedures can be captured in the following
four points [Goldberg 1989]:
❏ The search procedure is based on a coding of the parameter set, and not the
parameters themselves.
❏ Genetic algorithms search from and maintain a population of points – not a single
point
❏ Genetic algorithms uses only objective function information to direct the search,
and are thus not relying on derivatives or other auxiliary knowledge
❏ Genetic algorithms use probabilistic, not deterministic transition rules
❏ Genetic algorithms perform exploration and exploitation of the design space
concurrently. In exploration the algorithm tries to avoid convergence in order to
evaluate designs throughout the space in the search for new solutions (or solution
Chapter 3 - A Review of Engineering Design 47
elements). Exploitation focus on a local region, and tries to breed individuals with
high fitness within this region.
The basic genetic algorithm consist of three fundamental processes:
❏ Reproduction, where selected individuals of one generation are copied to the
next generation. The individuals to be reproduced are selected randomly, but with
a bias towards those best fitted, as given by the value of the objective function
("survival of the fittest").
❏ Crossover, where individuals are mated randomly. The mating process produces
individuals with new characteristics (as opposed to the reproduction process,
where the characteristics of the individuals are copied to individuals in the next
generation) involving the exchange of information in the form of building blocks.
❏ Mutation, which plays only a secondary role in the basic genetic algorithm.
Mutation can be useful to produce valuable building blocks which did not exist in
the population from the start, or reproduce valuable building blocks lost in the
reproduction process.
Several general features of genetic algorithms are interesting in the context of
preliminary ship design.
First, by using genetic algorithms the designer will work on a population of possible
design solution. This is the opposite of both typical optimisation-based methods and
the traditional design spiral approach, where the focus is on the improvement of one
solution This will help maintain the openness of the design problem, and reduce the
number of design commitments that needs to be made early when design knowledge
is limited.
Also, with the proper adjustment the genetic algorithm will converge towards several
fitted design solution, thus helping to preserve diversity for design problems with
multi-peaked objective functions. To some extent, this can be compared to
concurrently solving several traditional optimisation problems locating local optima
from different starting points.
Both the crossover and mutation operator support an element of creativity by the
creation of new solutions, either by the combination of features from the parent
solutions as in the crossover process, or by random creation as in the mutation
process.
The genetic algorithms seems to have the ability to support a high degree of man-
computer interaction through the design process, thus allowing for the designer to
apply his/her knowledge and experience in guiding the process towards improved
48 Chapter 3 - A Review of Engineering Design
solutions. In light of the criticism of traditional optimisation tools as "black box"
approaches leaving the designer on the sideline of the process, this is an important
feature.
3.4.4 Artificial Neural Networks
Artificial neural networks have recently received much attention due to their wide
range of applicability and ease with which they can handle complicated problems.
Their main feature is the ability to identify and learn correlated patterns of input data
and target values. They mimic the human learning process, and can handle problems
involving highly non-linear and complex data even if the data are imprecise and
noisy. In the ship design domain a potential application area is to improve the
performance estimating capability of preliminary design tools − an area where we
today are able to provide only limited support. An example of the use of artificial
neural networks for ship design is given in [Sha, et al. 1994].
3.4.5 Design Representation by Product Models
Another emerging technology, which must be seen separately from the
aforementioned AI-based methods, is the application of product models. Product
model focuses on information handling as a core activity in modern engineering
practice. Today many tasks in the design process are automated by means of computer
programs. These programs typically use individual and specialised data, and the
exchange of information between the various processes is difficult. As a response to
these problems product modelling technology has become a whole new field of
research. Such models contain information for all life cycle phases of the product, and
allows this information to be visualised with respect to the specific requirements of
particular disciplines, applications, and abstraction levels. The product model also
serves as a repository for design information with respect to the design object as it is
produced through the process. It is also responsible for the consistency of the model,
and for the digital exchange of product data between different participants in the
process in a heterogeneous system environment.
To serve as a basis for the development and implementation of product models, an
international standard, STEP
17
(ISO 10303), has been proposed. Using STEP more
specific product models for different application areas, such as shipbuilding, can be
built. The first version of STEP that supports the shipbuilding industry is expected to
become a “Draft International Standard” in early 1997 [Mehta and Lehne 1994].

17
Standard for the Exchange of Product Model Data
Chapter 3 - A Review of Engineering Design 49
Such an integrated digital life cycle model is an important perspective on a model for
preliminary ship design. Of particular importance are the results from on-going
research projects aimed at ship relevant implementations. Some examples are:
❏ IMPPACT
18
aimed at developing a reference model for the modelling of
mechanical products and production processes
❏ NEUTRABAS
19
defining STEP-conformant models for shipbuilding, including
ship geometry, ship structures, spatial arrangements, and outfitting systems
❏ MARITIME
20
, a follow-up of the NEUTRABAS project, aimed at contributing to
the ISO standardisation efforts in terms of shipbuilding product models
[Langbecker, et al. 1994]
There is a continuous development going on in order to provide a modelling scheme
as an adequate basis for managing and manipulating engineering/design data.
Flexible data structures are crucial, especially to support early design phases.
In recent years much attention has been given to bringing life-cycle considerations
into the early design stages. This includes aspects such as the producibility,
maintainability, operability, and robustness of a particular design.
3.5 Conclusion
In this chapter, we have looked into the fundamental reasoning processes in design,
such as deduction, abduction, and induction, and related these to practical design
situations. This is required for developing a formalised model of the ship design
process, which again is a prerequisite for understanding different design paradigms,
such as optimisation, simulation, concept exploration, etc.. In the next chapter we
will apply some of these theories and methodologies to the preliminary ship design
problem.

18
ESPRIT Project No. 2165
19
ESPRIT Project No. 2010
20
ESPRIT Project No. 6041

"Preliminary design by its very nature is perhaps
the most subjective aspect of naval architecture,
relying as it does on the accumulated experience
and data of each practitioner" [Watson and
Gilfillan 1976]
4
The Task Environment and Problem Space of
Preliminary Ship Design
The purpose of this chapter is to identify characteristics of the preliminary ship design
problem that distinguish it from both general design and general problems solving
situations. As a scheme I will use the concepts “design task environment” and “design
problem space” that were presented in Chapter 2, denoting the characteristics of the
design problem’s external and internal structure, respectively.
To provide a reference situation for the discussion, imagine for a moment an ideal
world. Here, a preliminary ship design situation might be described as follows:
❏ We have perfect knowledge about all relevant aspects of the external design
environment, both the current state and all future states.
❏ We also have ideal knowledge about ourselves. This implies that we are able to
explicitly state a value function that maps our true preferences between any
(design) alternative.
❏ Third, we have a perfect model of the ship to be designed, that is, we have a
model that expresses all features influencing the value function, and accurately
maps these features into the preference structure in the design performance space.
❏ And fourth, we have available unlimited computer capacity.
Given the situation described above, we can find a true optimal design solution by
brute force − simply by parsing all possible design points, calculating the performance
52 Chapter 4 - The PSD Problem Space and Task Environment
and the corresponding value of each, and at the end select the one with the highest
value.
An alternative to the last point is a situation where the model of the “ship-to-be-
designed” is completely described by a set of mathematical relations that satisfies
requirements such as continuity, differentiability, and convexity within the actual
design space. Here, the design problem can be captured in the terms of a classical,
mathematical optimisation problem, as it was presented in Chapter 2.
The two situations described above are illustrated in Figure 4–1, using the conceptual
scheme of a “design task environment” and a “design problem space”. Given that the
underlying assumptions are true, we are able to locate “optimum designs”
21
.
Perfect knowledge of
preference st ruct ure
Perfect model of t he
ship t o be designed
Exact mapping bet ween
t he ship model and t he
preference st ruct ure
Perfect knowledge
about t he ext ernal
environment
Unlimit ed comput er
capacit y
Perfect model of t he
design problem
Classical mat hemat ical
opt imisat ion
"True" opt imum design
Correct weight ing
bet ween mult iple goals
Design Task Environment
Design Problem Space
Specific propert ies of
t he design space
Search met hods

Figure 4–1: Design problem space and task environment for a ship design situation
with perfect knowledge
However, when it comes to designing complex, real-world systems − like ships − the
“perfect knowledge” assumption is not valid. Design problems in general, and ship
design in particular, are commonly classified as ill-defined problems, where "the
designer attempts to define and evaluate an approximate and unreliable design model,
within a vague but likely solution space, in order to satisfy uncertain design goals"
[Duffy and MacCallum 1989]. It is these “real-world” characteristics of the design
Chapter 4 - The PSD Problem Space and Task Environment 53
problem and the design environment that should be decisive in the choice of a
problem-solving paradigm, and thus is the focus of this chapter.
4.1 Preliminary Ship Design Task Environment
The task environment refers to the external characteristics of the design problem.
From the designer’s perspective, these characteristics represent a set of constraints
that need to be taken into consideration when choosing a problem solving strategy for
a particular design task. For the prototypical preliminary ship design situation,
propose the following invariant characteristics:
❏ Complex mapping between form and function
❏ Multi-dimensional, partly non-monetary performance evaluation
❏ High cost of error
❏ Shallow knowledge structure
❏ Strong domain tradition
❏ Strict time and resource constraints on the design process
❏ Predominantly “one-of-a-kind” and “engineered-to-order” solutions
This is not to say that all ship design problem situations in all details have a task
environment corresponding to the above characteristics. Rather, it represent a
prototypical case − a case which most designers would recognise as typical and to be
common for most ship design situations. In the following, a more detailed discussion
of each characteristic will be given.
4.1.1 Complex mapping between form and function
The input to the design process is a set of functional requirements and goals, for
instance in the form of an outline specification based on the customer’s preferences
and requirements, or compiled from the results of a market research project. The
output from the design process is a description of form, given as a specification of the
ship to be built. Thus, at the top level, the design process may be viewed as a mapping
following the pattern
(function) → (form)

21
A parallel to this “perfect knowledge design situation” is the dream attributed to Leibniz of “a
universal algebra by which all knowledge, including moral and metaphysical truths, can someday be
brought within a single deductive system” [Genesereth, 1988]

54 Chapter 4 - The PSD Problem Space and Task Environment
corresponding to the mapping from a semantic “performance space” to a syntactic
“description space” as was illustrated in Figure 2-1. However, on an operational level
in most computer-based design systems the mapping is the opposite way, by
(deductively) determining the ship performance on the basis of a given description in
the design analysis phase. Here, the mapping follows the pattern
(form) → (function).
This mapping between the two main representations of the ship − traditionally termed
design analysis − may be both complex and computationally intensive. Representative
examples of such mappings are:
(hull form & propeller) → (required SHP)
(hull form) → (seakeeping behaviour)
(hull form, propeller, machinery) → (ship speed)
(all ship systems) → (total cost)
Such a complex mapping between form and function is not unique for ship design,
although this characteristic is more profound here than in most other design domains.
There are several possible
explanations for this, the most
probable being the “nature” of the
ship as a self-contained, highly
integrated structure, the complex
underlying physical phenomena
involved in the movement of a
solid body at the boundary be-
tween two fluids, and the intrinsic
uncertainty with respect to the
present and future state of the
outer environment in which the
ship operates (see Figure 4–2). In
the following, I will discuss each
of these features in more detail.
Complex mapping
bet ween form and
funct ion
Self-cont ained, highly
int egrat ed syst em
Uncert aint y wrt t he
st at e of t he out er
environment
Int eract ion
inner-out er
environment :
Movement of a solid

Figure 4–2: Ship design is characterised by a
complex mapping between form and function
The ship as a self-contained,
highly integrated structure
From an engineering point-of-view, the ship is a complete, self-contained structure.
All functions of the ship is provided by sub-systems within the boundaries of the ship
Chapter 4 - The PSD Problem Space and Task Environment 55
system itself. Examples are power supply, propulsion, fresh water, and cargo support.
This is contrary to many other engineering systems where many of these functions are
provided by external agents.
This results in a tight coupling between ship sub-systems and substantial secondary
and higher order effects on the performance as a consequence of design changes. Such
effects are particularly evident upon changes in weights and volumes, since each
alteration here in most cases affects the ship’s displacement directly
22
. The presence
of secondary and higher order effects contributes significantly to the complexity of
the design process, since it inhibits an effective partitioning of the overall design
problem. This has lead to the expression “leaky modules” describing the partitioning
of the top-level design problem into mutually dependent sub-problems. This will be
further discussed later in this chapter.
A more thorough treatment of the effects of couplings between sub-functions of
engineering systems on the quality of design is given by Nam Suh [Suh 1990]. As one
of two invariant principles of good designs he asserts in his “Independence axiom”
that
“an optimal design always maintain the independence of the functional
requirements”
This is difficult to achieve in ship design. For instance, the functional requirements
(FR’s)
FR
1
: Cargo capacity x metric tonnes
FR
2
: Service speed v knots
are coupled for a weight-constrained monohull, since adjustments in the cargo
capacity will influence on the service speed, and vice versa. It is possible to avoid this
coupling. Choosing instead a design solution consisting of a barge and a tug, the FR’s
are said to be decoupled
23
. Now the design decisions can be taken without secondary
effects, by first dimensioning the barge to satisfy FR
1
, and then design the tug to
satisfy FR
2
. However, it is also quite likely that selecting a conceptual design using
the coupling between the functional requirements as the only criteria will lead to a
sub-optimal solution.

22
The multiplicatory effect of the change of independent weights on the displacement can be
captured in Normand’s Number, after J. A. Normand who published the method in 1885
23
To avoid secondary effects in a decoupled design requires the FR’s to be satisfied in the proper
sequence. A third category is uncoupled designs where the FR’s are completely independent. In
uncoupled designs the sequence of the decisions does not matter.

56 Chapter 4 - The PSD Problem Space and Task Environment
Generally, preliminary ship design problems are coupled, and this coupling is one of
the primary causes for the traditional iterative, sequential design process. As
mentioned in Chapter 2, this process is often depicted by the design spiral, aimed at
outbalancing the conflicting design requirements. In an uncoupled or decoupled
design, no iterations would be necessary. Thus, the consequence of the coupling for
the design process as such is that it makes the prediction of design performance − the
form-function mapping − difficult.
The physical phenomena of moving a solid body at the boundary between two fluids
Some of the most important performance characteristics of the ship relate to the
interaction between the system itself and its environment, that is, the physical
phenomena of moving a solid body in water. Due to the complicated nature of the
flow around the surface of a ship hull, satisfactory analytical methods relating the hull
form to e.g. resistance, powering requirements, and seakeeping behaviour are yet not
developed or, at best, they are immature. Thus, in the preliminary stages of ship
design we still have to rely basically on empirically based methods, and/or predictions
based on similar vessels. Though offering only limited prediction accuracy, these
methods have the advantage of being computationally inexpensive and simple to use.
For more accurate predictions of hydrodynamic performance towing tank test are
used, with a corresponding high cost and delayed feedback. Recent advances in
Computational Fluid Dynamics (CFD) are likely to change this situation. Such
programs are already used in the hydrodynamic design process [Cardena 1992],
leading to the term the numerical towing tank. Due to limited accuracy in predicting
absolute performance levels, CFD tools are especially useful in comparative analyses
of hull forms, determining the marginal influences of the hull parameters
[MacPherson, 1993]. It has also been reported a development of interfaces to CFD
tools from standard design packages such as. NAPA [Marzi and Ye 1994], that
automatically models a suitable mesh for CFD analysis. The possibility of integrating
such tools in the preliminary design process will be further improved by the
development of neutral product data exchange standards, such as STEP. The
drawback of such an integration is the overhead it induces in terms of increased
problem size and additional processing requirements. Thus, the integration of more
advanced design tools into the preliminary stage in the future is believed to increase
the present level of complexity in the form-to-function mapping.
The complexity and stochasticity of the external environment
The physical external environment consist of the boundary between two fluids; water
and air. This environment exhibit a large variation along several dimensions, e.g.
Chapter 4 - The PSD Problem Space and Task Environment 57
waves, wind, and currents. All these variations need to be taken into consideration
when the overall performance of the vessel is determined.
The external environment of the ship also comprises the social and economic factors.
As a consequence of an international and very competitive market for the services
offered by ships, these factors typically show more variation and uncertainty here than
for most other engineering structures. This adds to the difficulty of assessing
important performance characteristics. Areas of uncertainty are e.g. long-term cost
predictions, freight rates, fuel prices, cargo supply/demand, and future transport
capacity, making estimations of life-cycle costs, “optimal” speed, “optimal” cargo
capacity, difficult.
All these three characteristics − the integrated structure, the underlying physical
phenomena, and the external environment − contributes to the complex form-to-
function mapping found in preliminary ship design. There is a continuous
development in ship analysis methods, improving the accuracy in predicting the
performance of the ship. Still, this development is only capable of removing the
apparent complexity of the mapping, by transforming it into a representation that is
solvable by an appropriate algorithm. As said by [Simon 1973 p. 150]:
“In general, the problems presented to problem-solvers by the world
are best regarded as ill-structured problems. They become well-
structured problems only in the process of being prepared for the
problem-solvers. It is not exaggerating much to say that there are no
well-structured problems, only ill-structured ones that are formalised
for problem-solvers”
4.1.2 Multi-dimensional performance evaluation
On a high level of abstraction the evaluation of a merchant ship’s overall performance
can be simplified to calculating the life-cycle economic achievement. However, there
are operational limitations to such a “Maximise profit!” approach. Though factors that
directly influence the profitability of the vessel are important, such as cargo capacity,
building cost, and fuel consumption, there are in most practical design situations other
factors to be taken into consideration that are difficult to transform into monetary
terms. Representative examples are safety issues, environmental impact, and technical
performances such as seakeeping and stability.
The consequence is that the total performance of a specific design need to be
evaluated along several dimensions concurrently, contrary to a single dimension when
for instance only “maximise profit” or “minimise required freight rate” are used.
Though substantial research has been put into developing efficient and rational

58 Chapter 4 - The PSD Problem Space and Task Environment
methods for decision-making in
multi-dimensional situations, the
incorporation of such methods in
commercially available ship design
tools has so far been limited. Later in
the chapter I will discuss how this
influences the design problem space
in terms of a “satisficing” rather than
“optimising” approach to design, and
in terms of relying on personalised
evaluation and stopping rules to
determine when a satisficing solution
has been achieved.
Box 4-1: Example of non-economic design
objective formulation in a design
specification, from [Statoil 1991]:
"On a competitive basis, the Charterer will
give preference to vessels offering the best
design and operational characteristics for
the following high-lighted items:
• Environmental protection
• Minimum cargo retention in cargo tanks
and lines
• Fuel economy in transit and for
discharging
• Efficiency in harbours and at terminals
• Reliability in service”
4.1.3 High cost of error
As mentioned in Chapter 1, the
decisions made in the early stages of the ship design process have a substantial
influence on the total life cycle costs of the ship. Taking into consideration the
magnitude of these life cycle costs, it follows that making the wrong decisions in the
preliminary design stage may have considerable consequences.
The outcome of preliminary design is a contract specification (see Figure 1-2), that
gives a numerical description of the various performances required by the vessel. In
practice, however, the exact fulfilment of the performance requirements is difficult,
and because of this, the contract usually allow certain deviations from the specified
performance. Such allowable deviations are called margins.
Deviations from the specified performances may be grouped into three categories
[Erichsen and Selvig 1991]:
❏ Deviations within the contractually agreed margins. These deviations will be
accepted by the customer, and have thus no serious consequences for the shipyard.
❏ Deviations larger than the agreed margins, but still within limits acceptable
provided the customer is compensated.
❏ Deviations of a magnitude that gives the customer the right to refuse to accept
delivery.
Obviously, it is very important to avoid errors in the design process that result in
deviations of a magnitude corresponding to the latter two of these categories, since it
may lead to severe financial liabilities. As will be discussed later in this chapter, the
Chapter 4 - The PSD Problem Space and Task Environment 59
high cost of error has consequences for the design problem space in terms of
extensive performance modelling and verification of the proposed design, and need to
be taken into consideration when devising a model for supporting decision-making in
preliminary ship design.
4.1.4 Shallow knowledge structure
Preliminary ship design, as with most other real-world engineering problems, is an
open problem in the sense that the problem domain can not be completely described a
single, closed theory, and hence, no unique “optimal” solution can be derived. Rather,
the theory domain of ships is characterised by relying to a large extent on what is
commonly termed “shallow knowledge”, such as empirical relation, rules-of-thumb,
and previously built ships. A parallel characterisation is given by Mistree et al.
[Mistree, et al. 1991], stating that in preliminary design the ratio of soft to hard
information is high. Soft information is information based primarily on the designer’s
judgement and experience, while hard information is essentially based on established
scientific principles.
The character of the domain knowledge has a significant impact on the problem
space. A general rule is that if the ratio of deep knowledge to shallow knowledge is
high, we can rely more on traditional computational/numerical analysis in the design
process. If this ratio is low, other means of analysis is required, such as heuristics,
symbolic computation, rule-based systems, etc. Thus, in order to propose a problem-
solving framework for a specific domain, a thorough understanding of the domain’s
knowledge content is necessary. For preliminary ship design, the character of the
domain knowledge will be further discussed in Chapter 4.
4.1.5 Strong domain tradition
The historical and organisational setting for the ship design activity is also influencing
the design process, and is thus a part of the design task environment. According to
[Johnsen and Ellingsen 1986] the organisational culture in shipping may be
characterised as open, lean, informal, and flexible. The documentation attached to
design and production is limited − for a typical ship this would be about 20-50 kg to
satisfy government and class requirements. A comparable amount for a fixed
installation in the North Sea would be about 30-50 tons. The main reason for this
difference is that ship design builds on a long, historic tradition, where the involved
parties, i.e. the yard, the consultants, the shipowner, the classification societies, have
similar anticipations of the resulting design artefact.
Hence, where nothing else is specified, the designer can to a large extent rely on
design practice. This is contrary to the design of for instance fixed oil platforms where

60 Chapter 4 - The PSD Problem Space and Task Environment
such precedence is far more scarce and thus a more detailed specification is needed.
The impact on the design problem space is that the domain tradition generates a
number of design constraints - constraints that are not necessarily based on the design
specification, but implicitly assumed by all parties involved. Another consequence for
the design problem space is that it makes experience and knowledge embedded in past
design cases particularly important.
4.1.6 Strict time and resource constraints on the preliminary ship design
process
To stay competitive, a design office need to be able to respond quickly to tender
invitations
24
. At the same time, the outcome of the preliminary design process incur
serious obligations for the shipyard, both by deterring the utilisation of the production
resources for a long period of time, and by the committment made to the customer
through the contract (see Section 4.1.3). This require the technical and economical
feasibility of the proposed solution to be well founded. The negotiation of this trade-
off is difficult. As said in [Skipskonsulent 1991]:
"There is a perceived need for new, custom-made competitive design,
but there is far too little time for either of the parties to develop it. The
shipowner has his options badly reduced, and is forced to try to find a
standard design that meets the bill as well as possible, and within the
time limit available."
Because of reduced production times, some activities have been moved earlier relative
to the design time line. Thus, some decisions that earlier were made on the basis of a
detailed design description and/or production plans now need to be made on the basis
of knowledge available after the preliminary design stages. This put further demand
on the quality of design knowledge generated during the early stages.
4.1.7 Predominantly “one-of-a-kind” and “engineered-to-order” solutions
In the first post-war decades many shipyards built large series of a particular ship
type. However, in the last twenty years, when the shipbuilding activity in general has
been low, long series have been far less common [Erichsen 1994]. Though this
situation may again be reversed by the present rise in shipbuilding activities, we may
characterise shipbuilding as predominantly offering “one-of-a-kind” solutions. This
also holds true on a relative scale when comparing with the design and production of
other transport systems, such as cars and aeroplanes.

24
In [Langenberg, 1982], the time allowed for the submission of a tender is estimated to be about
three to five weeks
Chapter 4 - The PSD Problem Space and Task Environment 61
Another characteristic of ship design and production is what is commonly termed
“engineered-to-order” − that is, a significant part of the ship functional requirements
are specified directly by the customer. Again this is somewhat different from other
transportation systems where the product is specified by the manufacturer mainly on
the basis of more general market requirements.
Both these characteristics of the task environment have the consequence that it
becomes very costly, on a relative scale, to develop a particular design, since the
requirements to each design tend to be different, so that the design cost cannot be
divided among a large number of produced units. Thus, there is an important trade-off
between on the one hand tailoring the ship to the specific requirements of the current
design problem, and on the other hand keeping the resources spend on the design on
an acceptable level.
4.2 Preliminary Ship Design Problem Space
As was the case with the Design Task Environment, there seem to be a considerable
variation in the Design Problem Space across different design situations. This
problem space is in part determined by the particular preferences of the designer, and
in part by the impact of the task environment
Assuming that the preceding invariants of the Design Task Environment are
representative for a typical preliminary ship design situation, the next step is to
investigate how they impact the Design Problem Space (DPS). Again, it should be
noted that the elements of the DPS listed here are not based on a descriptive study of
the preliminary ship design process, but derived partly from the study of Goel and
Pirolli, and partly from relevant literature. Still, I believe developing this scheme is
important in terms of explicating the assumptions made about the situation in which
the design methods proposed in Chapter 5 will work.
For the preliminary ship design situation, I assume the following nine invariants to be
important:
❏ Satisficing rather than optimising
❏ Personalised evaluation functions and stopping rules
❏ Decomposition into leaky modules
❏ Sequential, iterative design process
❏ Extensive use of empirical relations and previous cases
❏ Multiple abstraction hierarchies
In the following, each of these will be discussed in more detail.

62 Chapter 4 - The PSD Problem Space and Task Environment
4.2.1 Satisficing rather than optimising
At the beginning of this chapter I described an idealised design situation. Two
scenarios were presented. The first assumed unlimited computer capacity, that
allowed us to use exhaustive search to identify the optimum. The second scenario
assumed that the design space satisfied a particular set of mathematical conditions.
This opened up for the application of mathematical programming/operational research
algorithms to identify a globally optimal solution to the design problem.
For practical ship design problems, neither of these approaches are applicable. One
problem is that it is difficult to completely formalise the design knowledge required to
locate the true optimum. Attempts to formalisation will inevitably discard important
characteristics of the real-world situation, or enforce the quantification of qualitative
aspects, leading to erroneous results. This situation is parallel to every modeling
situation. The purpose of a model is to act as an abstraction, implying that we must
choose a sub-set of aspects of the object or situation to bring into the model. This sub-
set will always tend towards what is easy to formalise.
The situation is captured in the following citation, from [Goldberg 1989]:
“Theorists interested in optimization have been too willing to accept
the legacy of the great eighteenth and nineteenth-century
mathematicians who painted a clean world of quadratic objective
functions, ideal constraints, and ever present derivatives. The real
world of search is fraught with discontinuities and vast multimodal,
noisy search spaces.”
Even if we assume that it is possible to derive a formal model taking into account all
relevant aspects of the design problem, there would still be limitations to identifying
“optimal” solutions. Applying the first solution strategy − that is, mathematical pro-
gramming/operational research − we would need to reformulate the model again to fit
into a scheme of variables, parameters, constraints, and objectives. Recalling the
discussion in Section 4.1.1 about the complexity of the preliminary ship design
problem, this would entail a further abstraction of the problem.
Using instead a simpler search strategy, it may be possible to utilise a fully formalised
model. The real-world limitation in this case would be the dimensionality of the
model with respect to the capacity of the computer. Regardless of the development in
computer technology, there will always be problems which can not be solved by
“brute force” alone within acceptable time. A somewhat exotic restriction is
Bremmermann’s limit, which constrains the number of independent variables in a fac-
torial design to 270 on the basis of the mass of the Earth, the period of atomic
vibration, and Heisenberg’s uncertainty principle [Suh 1990]. A more concrete
Chapter 4 - The PSD Problem Space and Task Environment 63
example: Given 10 design variables, each to be evaluated at ten different values, the
total number of combinations becomes 10
10
. If we assume that each design evaluation
takes 1 millisecond, the total computer time needed will be 10
7
seconds − more than 3
months. This is often referred to as “the curse of dimensionality”. We see the parallel
problem in chess. Even if we here have a complete formalised model − often termed a
strong theory domain [Aamodt 1993] − the deduction of an “optimal” plan leading to
victory is not possible because of the dimensionality of the problem. To compete with
human masters, the chess program must apply “intelligent” search methods in
addition to brute force.
Generalising on these two strategies,
we have a choice between finding an
exact solution to an approximate
representation of the problem, or an
approximate solution to an exact
representation. Neither of these
strategies alone lead to an optimal
designs. This has lead to the term
“satisficing”, first used by Herbert
Simon in “The Sciences of the
Artificial” [Simon 1982]. In Simon’s
words a “satisficer” is “a person who
accepts ‘good enough’ alternatives, not
because he prefers less but because he
has no choice.”
Complex mapping
bet ween formand
funct ion
Mult i-dimensional ,
part ly non-monet ary
performance
l t i
Shallowknowledge
st ruct ure (high
soft / hard info. rat io)
Sat isficing rat her
t han opt imizing
Task Environment Problem Space

Figure 4–3: "Satisficing rather than
optimising" as an invariant of the Design
Problem Space
Concluding this, I claim that “satisficing rather than optimising” is an important in-
variant of the preliminary ship design problem space. It is a consequence of some of
the characteristics of the task environment discussed in the previous section − the
inability to formalise the real-world problem, the complexity and dimensionality of
the problem, and shallow knowledge structure of the domain. This is illustrated in
Figure 4–3.
4.2.2 Personalised evaluation functions and stopping rules
Closely connected to the previous point about ship design as a “satisficing” activity is
the lack of a well defined evaluation function and explicit criteria for terminating the
design process.
In most computer-based preliminary ship design tools the process is oriented towards
calculating the value of the individual functional performances. This may for instance
be steel weight, resistance, seakeeping abilities, or building cost. However, taking into

64 Chapter 4 - The PSD Problem Space and Task Environment
consideration the multi-objective nature of ship design, this knowledge is by itself of
only limited use in determining the overall performance of a particular solution, both
in absolute and relative terms. To do this, a method to synthesise the individual
performances along a single evaluating dimension is needed.
Traditionally, this has been the focus of the field of decision theory, where a
considerable effort has been put into the development of a methodology for making
value trade-offs between different alternatives. The classical text in this field is that of
Keeney & Raiffa [Keeney 1976] where the theoretical foundation for making rational
choices is analysed.
However, such systematic and theoretically stringent methods seem to have had only
limited influence on commercially available ship design tools. Thus, it is safe to say
that in most cases the evaluation of the overall performance of a particular design to a
large degree relies on the individual designers subjective judgement, based on
experience and domain expertise.
This is also the case regarding the decision about when to terminate the design
process. Sometimes this will be determined by external factors such as the time and
resources allocated to the design project. When there are no such external limitations,
this decision will, as was the case with design evaluation, to a large degree be tied to
designers personal judgement, since there is no well-defined criteria for determining
whether the current solution may be improved or not. This is contrary to for instance
the mathematical optimisation design paradigm, where the termination of the design
process is well defined by some optimality criteria
25
.
4.2.3 The decomposition of the design problem into leaky modules
One of the main invariants of the task environment was the complexity of the form-to-
function mapping. The major cognitive strategy to deal with this kind of complexity is
through decomposition [Simon, 1969; Goel, 1989]. The design process is transformed
into a series of independent steps, each performing a closed cycle of description,
evaluation, and decision, but for a reduced number of variables. This aspect of the
design problem space is also captured in the ship design spiral (see Figure 3–6),
where the overall problem is decomposed into modules that are solved serially. The
reduction in the number of problem dimensions to be processed concurrently that is

25
For instance, for the formulation of the optimisation problem as in Section 2.2.3, the necessary
conditions for optimality are the Karush-Kuhn-Tucker (KKT) conditions, given as: 1) h(x*) = 0, g(x*)
≤ 0, 2) ∇f* + λ
T
∇h* + µ
T
∇g* = 0
T
, λ ≠ 0, µ ≥ 0, µ
T
g = 0, where x* corresponds to the optimal design
solution
Chapter 4 - The PSD Problem Space and Task Environment 65
achieved by decomposition help to make the problem tractable for both the computer
and the human designer.
The main difficulty with decomposing the problem is to maintain a sufficient degree
of independence between the individual sub-problems. This is especially so in the
ship design domain, because of the high degree of interaction between the different
ship sub-systems (see Section 4.1.1). This has lead to the description “leaky
modules”.
There are different ways of dealing with these “leakages”. Traditionally, the main
strategy has been what is commonly termed “outbalancing”, as it is captured in the
ship design spiral. In this approach a change in one of the modules initiates the
recalculation of all other modules until a sufficient degree of consistency is re-
established. To what extent this is a viable approach depends to some degree on the
design task under consideration. For instance, the secondary effects of adding an
independent weight in a VLCC design model are far less problematic than for a
semisubmersible design model.
A second strategy is to seek a partitioning of the problem that keep the interactions
between the modules as small as possible. This was the strategy of “axiomatic design”
discussed in Section 4.1.1. A third alternative is to try to couple the different sub-
problems by the explicit modelling of the interaction effects. An example of this is
given in [Smith 1992], where the determination of the main characteristics of the hull
and the propeller for a frigate are modelled as two separate decision problems, but
with the interaction effects taken care of by the solver.
My main point here is that the complexity of the design problem will in most practical
design situations require a decomposition strategy – and the choice of this strategy is
important for the quality of the design result. Hence, when proposing a design model
and a design paradigm, the support for an efficient decomposition strategy need to be
taken into consideration.
4.2.4 Sequential iterative limited commitment mode design strategy
Every decision we take through the course of a design process will limit our design
freedom. Hence, if it was possible, it would be advantageous to postpone all decisions
until every aspects of the design solution can be taken into consideration, thus
avoiding a sub-optimal solution. However, in a practical setting I have argued that the
preliminary ship design process require a decomposition of the problem, with the
subsequent sequential processing of the individual sub-problems. This implies that we
have to take intermediate decisions that are likely to be sub-optimal.

66 Chapter 4 - The PSD Problem Space and Task Environment
But this is not an all-or-none choice; in real-world design situations there is a constant
negotiation between making commitments and keeping the problem open. A possible
strategy towards a favourable trade-off is to keep the solution on a high level of
abstraction as long as possible. An example of this is reported in [Levander 1991]
from the cruise ship design domain. Here, the importance of keeping the solution on a
functional level as long as possible is emphasised, thus maintaining the option to
select different conceptual solutions. On the other hand, if we leave the functional
domain, we easily get locked into exploring the design space along a set of pre-
defined dimensions, even if we keep the problem open in the sense that we postpone
the assignment of numerical values to the design variables.
An alternative to consecutively determining the value of particular design variables is
to make commitments in terms of systematically constraining the search space. This is
intuitively done by experienced designers – for instance when an appropriate range
for the design variables is selected at the outset of the design process. It is obviously a
reasonable trade-off against exploring the whole domain of real numbers. Still, by
every addition of a constraint to the design space the designer faces the risk of
discarding a potentially favourable solution.
For the real-world design of complex systems like ships, the necessity of making
commitments at some level of detail along the design process is an inescapable fact.
The development of more advanced design tool is not likely to change this. Rather,
the focus should rather be on how to provide support for the rational negotiation of
such commitments. Alternative strategies for this will be further discussed in
Chapter 8.
4.2.5 Extensive use of empirical relations and previous cases
Earlier in this chapter, the task environment of ship design was characterised by
having a complex mapping between form and function, thus making it difficult to
establish a strong analytical design model. As a consequence, preliminary ship design
has always relied extensively on empirically based design relations, and the
adaptation of existing designs to new requirements.
The access to performance data, such as steel weight and cost, on existing ships may
be regarded as one of the most important assets for a shipyard or design office. Often,
the work on a new design start by extrapolating from a previous in-house design
26
.
Alternatively, data from existing ships may be used as input to a statistical analysis

26
For instance, this extrapolation may be accomplished by using the the total differential method.
E.g. the change in displacement with respect to a change in an independent weight W
i
may be
Chapter 4 - The PSD Problem Space and Task Environment 67
that produces a set of empirical relations that may be useful for a larger range of ship
sizes and types. Well-known examples are the regression analyses of model and trial
test results at the Netherlands Ship Model Basin, aimed at developing a functional
relationship between the ship main characteristics and ship’s resistance and
propulsion properties [Holtrop 1977], and the work by [Watson and Gilfillan 1976],
developing empirical formulas for a large range of ship characteristics.
The point here is that the extensive reliance on knowledge embedded in existing
design solution is an important characteristic of the design problem space. In Chapter
6 I will discuss further how this can be reflected in the structure of the design model.
4.2.6 Multiple abstraction levels
Earlier in this chapter decomposition was presented as one common strategy to deal
with the complexity of the ship design problem. A complementary strategy is the use
of abstraction mechanisms. In this context, abstraction may be defined as the process
of separating the relevant and irrelevant details from a context [Seltveit 1994]. This
allows information to be represented at different levels of detail, thus being an aid to
focus on the most significant aspects of a problem.
The application of multiple abstraction levels in the ship design can be exemplified by
the increasing level of detail along the design process, starting from a coarse
representation in the early stages to a detailed description in later stages.
In [Oortmerssen and Oossanen 1988] four major abstraction levels are identified, with
different degrees of granularity and accuracy. These levels are defined as:
❏ Level "zero":a top-level description of a potential design based on the ship main
characteristics
❏ Level "one":a more detailed description of the ship. Both level "zero" and "one"
are parameter based descriptions
❏ Level "two": introducing detailed geometry of the ship, including compart-
mentation. The corresponding design analysis is based on the defined geometry
(and not on the design parameters)
❏ Level "three":introducing the geometry of the appendages. Thus, still more exact
calculations are possible in order to determine the corresponding performances

expressed as δ∆ = δW
i
/(1- ∆
-1
ΣW
i
λ
i
), assuming that the individual weights may be calculated by
formulas following the pattern W
i
= k
i

λ
ι


68 Chapter 4 - The PSD Problem Space and Task Environment
In addition, a number of domain specific abstractions have been developed through
the relatively long history of ship design, that in a single concept captures multiple
aspects of the ship’s characteristics or performance. This help to improve the human
designers perceivibility of the model, paying attention to the limited number of
concepts the human mind is capable of processing in parallel. Examples of such
domain specific abstractions are:
❏ Dimensionless parameters, e.g. L/B, B/T, speed-length-ratio (V/√L)
❏ Form coefficients, e.g. C
b
, C
p
, C
m

❏ Graphical abstractions, e.g. section area curves (SAC)
The use of abstraction is crucial to all design in complex domains, since we are not
able to model all aspects of reality in the computer. The reality need to be simplified,
by ignoring those aspects that are of less relevance to the current context.
4.3 Critical Factors for a Design Model
A number of critical factors for the design model can be derived from the invariants
of the problem space. Four such factors are assumed to be of specific importance,
namely flexibility, expressiveness, perceivability, and efficiency. In the following,
each of these critical factors will be discussed in more detail.
Chapter 4 - The PSD Problem Space and Task Environment 69
Complex mapping
bet ween formand
funct ion
High cost of error
Mult i-dimensional ,
part ly non-monet ary
performance
l t i
Shallowknowledge
st ruct ure
St rong domain
t radit ion
Ext ensive use of
empirical relat ions
and previous cases
Decomposit ion
int o leaky modules
Sat isficing rat her
t han opt imising
Personalised
evaluat ion funct ion
and st opping rules
St rict t ime and
resource const raint s
Mult iple abst ract ion
hierarchies
Design Task
Environment
Design Problem
Space
"One-of-a-kind"and
"engineered-t o-order"
solut ions
Delayed/ limit ed
feedback fromt he
world
FLEXIBILITY
EXPRESSIVENESS
PERCEIVABILITY
EFFICIENCY
Crit ical Fact ors

Figure 4–4: The preliminary ship design problem space and task environment, with
corresponding critical factors by which to evaluate the design model

70 Chapter 4 - The PSD Problem Space and Task Environment
Design Task
Environment
Design Problem
Space
Design Model
provide t he
set t ing for
det ermines what
aspect s are of
int erest t o

Figure 4–5: The structure of the design model is determined by the design problem
space, which again is determined by the task environment
4.3.1 Flexibility
By flexibility is understood the freedom the designer has to “meta-design” a design
process that is both in conformance with the characteristics of the design problem
under consideration, and in accordance with his/her personal preferences and level of
expertise.
The focus on flexibility as a critical factor is founded on several of the invariants of
the design problem space. One is the existence of multiple abstractions and
abstraction hierarchies, that was discussed in Section 4.2.6. This requires a flexible
model of the ship that can evolve along the process, starting from a coarse description
in the beginning to a detailed description in the end. Part of the problem of
incorporating this kind of flexibility lies in keeping the model consistent when more
detail is added to the structure, or the focus is changed from a high level abstraction
(e.g. V/√L
pp
-ratio, L
pp
/∇
.33
-ratio, form coefficients) to low level abstractions (e.g. hull
dimensions, detailed hull geometry).
Second, flexibility is needed to add new knowledge to the model as knowledge is
gained through the design process. Only in very few cases the state of knowledge at
the outset of the design process is sufficient to formulate a complete model containing
all aspects required to solve the design problem. Examples are for instance the
addition of new constraints to limit the search space, the reformulation of goals, the
revision of the parameters in empirical relations, or the addition of an ad-hoc rule to
guide the search process.
And third, flexibility is needed in focus the attention of the design problem to those
aspects of the design problem that are most relevant in order to determine the overall
performance of the vessel. This is strongly related to the presence of personalised
evaluation functions and stopping rules as an invariant of the design problem space.
The support for a flexible meta-modelling capability varies substantially among
existing design tools. The most common is a relatively static model that is implicitly
Chapter 4 - The PSD Problem Space and Task Environment 71
defined by the set of analysis procedures on which the application is based, with little
or no possibility for the designer to make changes. However, in Chapter 2 we also
saw an example of the opposite in the DESIGNER application, where the basic
structure of the design model allowed for a very high degree of freedom in the meta-
modelling of a particular design problem. This example also illustrate that the support
for flexibility need to be founded on the low-level representation of the relevant
domain concepts.
However, the support for flexibility is not achieved without a cost. Compared to a
highly structured model with a pre-defined, fixed set of design variables and a given
template of design analysis procedures, a model explicitly supporting meta-design
tend to be considerably more complex, and thus less efficient with respect to the
computational efficiency and size of the computer implementation.
4.3.2 Expressiveness
The expressiveness of a model refers to the ability to capture the relevant knowledge
content of a particular domain. In the context of ship design this comprises all
knowledge useful for generating, analysing, and evaluating potential design solutions,
ranging from “first principles” facts to experience-based and intuition-like rules-of-
thumb. A parallel to expressiveness is the notion of ‘epistemological
27
adequacy’ in
[McCarthy and Hayes 1969], stating that “a representation is called epistemologically
adequate for a person or machine if it can be used practically to express the facts that
one actually has about the (relevant) aspects of the world”.
In practice, epistemologically adequacy need to be weighted against the added
complexity it invokes for the design model. Thus, types of knowledge only marginally
relevant for the domain may be discarded in the interest of simplicity. Knowledge
types may also be discarded because the corresponding inference procedure operating
on this knowledge is either non-existent or difficult to implement.
In most existing, commercially available ship design tools, the only type of
knowledge that is explicitly supported is numerical knowledge. This knowledge is
expressed basically in a procedural form, usually implemented as design analysis
programs operating upon a design object implicitly defined by a collection of
attribute-value pairs. Though this representation is preferable from an operational
point-of-view, and has in most respects been the only realistic alternative
28
, it is also

27
epistemology 1. The division of philosophy that investigates the nature and origin of
knowledge. (…) [American Heritage Dictionary, 1991]
28
It may be argued that for instance a rule-based representation has been a realistic alternative. The
primary argument against this stand is the fact that this representation has not found wide-spread use in
commercially available ship design applications

72 Chapter 4 - The PSD Problem Space and Task Environment
clear this representation lead to important parts of the semantic content of the domain
knowledge being lost. This will be further discussed in the next chapter, in relation to
the knowledge content of the preliminary ship design process.
4.3.3 Perceivability
29

In [Rzevski 1980], “perceivability” is defined as the ability to hold all the important
aspects of a problem and all their interrelationships in mind at one and the same time.
He asserts that:
“People tend to reject, ignore, or undermine the importance of systems
whose purpose, aims, function, or organisation they cannot perceive
If people are forced to interact with an imperceivable system they are
likely to commit an inordinately large number of mistakes”
To what degree a particular design model is regarded as “imperceivable” are strongly
correlated to the complexity of the model. Correspondingly, measures to improve
perceivability are closely connected to complexity reduction techniques in
information systems modelling. Many of these techniques are associated with object-
oriented programming, and comprise for instance methods such as the encapsulation
of information and procedures within objects that have a simple and well-defined
external interface, and the use of inheritance that enable attributes and operations to
be shared among information entities based on a hierarchical relationship.
As was the case with flexibility as a critical factor, there are limits to what measures
should be taken in order to increase the perceivability of a model. This stems from the
dual role of the model in the design process
30
, as illustrated in Figure 4–6. On the one
hand the model serve as a basis for communication and understanding of the real-
world design problem, and on the other hand it serves as a definition of the problem to
be solved by the computer. For the first of these roles, a high degree of abstraction
and simplicity is preferable, while for the latter, a detailed and concrete model is
necessary in order to be computable.

29
perceive (…) 3. To become aware of in one's mind; achieve understanding of [American
Heritage Dicitonary]
30
This is a parallel to the dual role of specifications in information systems modelling, see [Seltveit,
1994]
Chapter 4 - The PSD Problem Space and Task Environment 73
A common concern from ship designers when
faced with a new computer-based design tool
is the creation of so-called “black-boxes”, or
completely encapsulated process modules.
These are processes where the human de-
signer can only control the input and output,
but not the internal structure
31
. Though this
modularisation of the process may decrease
the model’s complexity by abstraction, it may
at the same time inhibit the human
perceivability of the model, since part of the
foundation on which the model’s result is
derived from is hidden from human
inspection. This is serious in a complex
domain such as ship design, where human
expertise, intelligence, and experience play a
key role.
Human designer
cat ion
ment at ion

Figure 4–6 - The dual role of the
design model
Comput er
Design
model
Basis for communi
and underst anding
Basis for imple
and processing
The answer to this problem lies not
necessarily in opening up every one of the
black boxes. An alternative approach is to
systematically provide the human designer
with sufficient explanation of the underlying
process, thus rendering the model’s reasoning
process transparent to the user.
4.3.4 Efficiency
Efficiency may be defined as “the ratio of the
effective or useful output to the total input in any system” [American Heritage
Dictionary]. In the context of ship design, the useful output may for instance be
measured by the number of feasible design solutions that are produced, or the quality
of the best solution. The input to the design process may be measured by the number
of man-hours and computer system resources required to achieve this.
If we take a holistic system view that include both the computer and the human
designer, it is clear that the efficiency of the design system should be evaluated at a
high level of abstraction, since factors such as flexibility and perceivability are

31
This may for instance be a design analysis procedure where the designer has access only to the
compiled version, and not the source code nor a proper documentation or explanation − a rather
common problem in many existing ship design tools

74 Chapter 4 - The PSD Problem Space and Task Environment
primarily directed towards enhancing the human efficiency in the design process.
These factors will usually have a negative effect if we focus on the computational
efficiency of the system alone. For instance, when enabling a high degree of
modelling flexibility, we will at the same time run the risk of sacrificing the efficiency
that can be gained from a simpler knowledge representational formalism and
inference methods. As an example, consider the representation of a simple constraint,
e.g.
LBRATIO: LPP/B < 5.9
as a part of a compiled, procedure-oriented representation. An alternative
representation might be as a binary tree where each node represent a single conceptual
entity (an object), as illustrated in Figure 4–7. While this representation is favourable
from a flexibility point-of-view, it will at the same time induce an overhead in terms
of complexity and multiple evaluation steps that will impede the computational
efficiency of the model.
(OperElem)
value = '<'
(PropElem)
value = 'LPP'
(PropElem)
value = 'B'
(OperElem)
value = '/'
(NumElem)
value = '5.9'
(Constraint)
tag='LBRATIO'
leftP
leftP rightP
rightP
topNode

Figure 4–7: A binary tree representation of a simple constraint
To summarise, it is clear that efficiency is an important factor to consider when
evaluating the appropriateness of a particular design model. This implies that some
compromises need to be made with respect to the other three critical factors when
developing a design model
32
. It is also important to keep in mind that it is the broad
understanding of efficiency that include both the human and the computer that will be
decisive for the quality of the output from the design process.

32
These considerations can be captured in Coggin’s Law of Software Engineering, which states
that “Pragmatics must take precedence over elegance, for Nature cannot be impressed”
Chapter 4 - The PSD Problem Space and Task Environment 75
4.4 Chapter Conclusion
The purpose of this chapter has been to establish a formal description of the
preliminary ship design process, based on design practice and relevant literature. The
characteristics found, expressed in terms of the invariants of the design task
environment and the design problem space, will be used in the next chapters when
discussing the appropriateness of concept exploration models in preliminary ship
design.
An alternative approach could have been to devise a methodology based on a
idealised design situation, such as the one described in the beginning of the chapter,
and thereafter make the necessary adaptations to the real world. This would require
the discrepancies between the real and the idealised world to be relatively small. On
the basis of the preceding description of the ship design task environment and
problem space, this seems not to be the case in the ship design domain. The
differences between the invariants of the design task environment and the four
assumptions stated for the idealised description on page 51 can be summarised as:
❏ Our knowledge about the external conditions of the ship system is limited. The
performance of the ship is a result of its interaction with the surrounding
environment, both physically, economically, and socially. Thus, in order to
evaluate the design solution correctly we need to model all relevant aspects of this
environment. This is difficult both because of the inherent uncertainty involved in
predicting the future, and because it would imply a very large and complex design
model.
❏ Our knowledge about our own preferences and trade-offs is limited. The
consequence of this is that we are usually not able to explicitly formulate goals
that covers all relevant performance aspects completely, which is a necessary
requirement for identifying optimal solutions. The result is that real-world ship
design is a process of finding “satisficing” solutions, where the evaluation of
design alternatives relies to a large degree on human intuition and experience.
❏ Our knowledge about the design object is limited. That is, given a description of a
ship, we are not able to accurately predict all aspects of the corresponding
performance at the design stage, even under idealised conditions.
❏ And even if we were able to derive a perfect model covering all the three
preceding aspects, it would be intractable from a computational point-of-view.
The situation would be like for chess programs: even though we are able to devise
a complete model of the domain, we still are unable to develop a program that is
capable of supporting optimal decisions, as a result of finite computational
capacity.

76 Chapter 4 - The PSD Problem Space and Task Environment
These deviations from an idealised world need to be taken into consideration when
proposing a model for ship design.

“An ideal medium for representing knowledge
about design is one that enable any thought to be
represented but that does not anticipate the
properties of the things described” (Swinson,
1983)
5 References
Ames, R. M. and Lynaugh, K. M. (1988) "A Review of Hullform Design Systems for
the Marine Industry", Marine and Offshore Computer Applications, September 1988
Andrews, D. (1981) "Creative Ship Design", The Naval Architect, November 1981
Andrews, D. (1985) “An Integrated Approach to Ship Synthesis”, The Naval
Architect, April 1986
Antonsson, E. K. (1987) "Developing and Testing Hypothesis in Engineering Design
Research", J. of Mechanisms, Transmissions and Automation in Design, Volume 09,
January 1987
Ashley, S. (1992) "Engineous Explores the Design Space", Mechanical Engineering,
February 1992
Balachandran, M. (1993) "Knowledge-Based Optimum Design", Computational
Mechanics Publication, London
Booch, G. (1994) "Object-Oriented Analysis and Design with Applications",
Benjamin/Cummings, Redwood City, California
Bras, B. A. (1992) "Foundations for Designing Decision-Based Design Processes",
Ph.D. Dissertation, University of Houston, Houston, Texas
Braun, R. D., Kroo, I. and Gage, P. (1993) "Post-Optimality Analysis in Aerospace
Vehicle Design", AIAA Aircraft Design, Systems, and Operations Meeting, August
11-13, 1993, Monterey, California
Cardena, E. M. (1992) "Use of CFD Tools in the Hull Lines Design Process", Design
of Marine and Offshore Structures (CADMO’92)
78 References
Chandrasekaran, B. (1989) "A Framework for Design Problem Solving", Research in
Engineering Design, Volume
Coyne, R. D., Rosenman, M. A., Radford, A. D., Balachandran, M. and Gero, J. S.
(1990) "Knowledge-Based Design Systems", Addison-Wesley Publications, Reading,
Massachusetts
Crane, R. L., Hillstrom, K. E. and Minkoff, M. (1980) Solution of the General
Nonlinear Programming Problem with Subroutine VMCON, Argonne National
Laboratory, Illinois, ANL-80-64
Cross, N. (1980) "Design Method and Scientific Method", Design Research Society
Conference, Portsmouth, Westbury House
Davis, L. (1991) "Handbook of Genetic Algorithms", Van Nostrand Reinhold, New
York
Dierolf, D. A. and Richter, K. J. (1989) Computer-Aided Group Problem Solving for
Unified Life Cycle Engineering (ULCE), Institute for Defense Analyses, Alexandria,
Virginia, IDA Paper P-2149
Dixon, J. R. (1987) "On Research Methodology Towards a Scientific Theory of
Engineering Design", AI EDAM, Number 3
Dixon, J. R., Duffey, M. R., Irani, R. K., Meunier, K. L. and Orelup, M. F. (1988) "A
Proposed Taxonomy of Mechanical Design Problems", Proceedings ASME
Computers in Engineering Conference, San Francisco, California
Drijver, K., Käsper, M., Lehne, M., Oehlmann, R., Mehta, S. and Rimkus, C. (1993)
The MARITIME University of Discourse, D 3111
Duffy, A. H. B. (1993) "Machine Learning in Design", Artificial Intelligence in
Engineering, Volume 8
Duffy, A. H. B. and Kerr, S. M. (1993) "Customised Perspective of Past Designs
From Automated Group Rationalisations", Artificial Intelligence in Engineering,
Duffy, A. H. B. and MacCallum, K. J. (1989) "Computer Representation of
Numerical Expertise for Preliminary Ship Design", Marine Technology, Volume 6,
No. 4, October 1989
Eames, M. C. and Drummond, T. G. (1977) "Concept Exploration — An Approach to
Small Warship Design", Transactions RINA, Volume 19,
Appendix C: [Erikstad, et al. 1995] 79
Engelund, W. C., Stanley, D., Lepsch, R. A. and McMillan, M. M. (1993)
"Aerodynamic Configuration Design Using Response Surface Methodology
Analysis", AIAA Aircraft Design, Systems and Operations Meeting, Monterey,
California
Erichsen, S. (1972) "Optimizing Containerships and their Terminals", SNAME Spring
Meeting, Willimiamsburg, Virginia, May 1972Erichsen, S. (1989) "Management of
Marine Design", Butterworths, London
Erichsen, S. (1994) "The Effect of Learning When Building Ships", Journal of Ship
Production, Volume 0, 3, August 1994
Erichsen, S. and Selvig, E. K. (1991) "Contractual Margins in Relation to Required
Performance", IMSDC'91 - The 4th International Marine Systems Design Conference,
Kobe, Japan, The Society of Naval Architects of Japan
Erikstad, S. O. (1994) "Improving Concept Exploration in the Early Stages of the
Ship Design Process", 5th International Marine Design Conference, Delft, The
Netherlands
Erikstad, S. O., Lautenschlager, U., Bras, B., Allen, J. K. and Mistree, F. (1995)
"Integrating Robustness into Multiobjective Space Vehicle Design Process", Journal
of Guidance, Control, and Dynamics, Volume 8, Number 5
Evans, J. H. (1959) "Basic Design Concepts", Naval Engineers Journal, ASNE,
Volume 1, Number 6
Finger, S. and Dixon, J. R. (1989) "A Review of Research in Mechanical Engineering
Design. Part 1: Descriptive, Prescriptive, and Computer-Based Models of Design
Processes", Research in Engineering Design, Number 1
Finger, S. and Dixon, J. R. (1989) "A Review of Research in Mechanical Engineering
Design. Part II: Representations, Analysis, and Design for the Life Cycle", Research
in Engineering Design, Number 2
Fisher, K. W. (1973) "The Relative Costs of Ship Design Parameters", Transactions
RINA - Royal Institute of Naval Architects, Volume
Fleming, J., Elghadamsi, E. and Tanik, M. (1990) "A Knowledge-Based Approach to
the Preliminary Design of Structures", Journal of Energy Resources Technology,
Volume 12, December 1990
Folkers, J. S. (1973) "Ship Operation and Design", in Optimization and Design,
Prentice-Hall Inc., New York

80 References
Gage, P. and Kroo, I. (1993) "A Role for Genetic Algorithms in a Preliminary Design
Environment", AIAA Aircraft Design, Systems, and Operations Meeting, August 11-
13, 1993, Monterey, California
Gamma, E., Helm, R., Johnson, R, Vlissides, J. (1994) “Design Patterns - Elements of
Reusable Object-Oriented Software”, Addison-Wesley Publ., Reading, Massachusetts
Genesereth, M. R. and Nilsson, N. J. (1988) "Logical Foundations of Artificial
Intelligence", Morgan Kaufmann Publishers Inc.
Georgescu, C., Verbaas, F. and Boonstra, H. (1990) "Concept Exploration Models for
Merchant Ships", CFD and CAD in Ship Design, Wageningen, The Netherlands,
Elsevier Science Publishers B. V.
Goel, V. and Pirolli, P. (1989) "Motivating the Notion of Generic Design within
Information-Processing Theory: The Design Problem Space", Design Studies, Volume
Spring 1989
Goel, V. and Pirolli, P. (1989) "Motivating the Notion of the Generic", AI Magazine,
Spring 1989
Goldberg, D. (1989) "Zen and the Art of Genetic Algorithms", 3rd International
Conference on Genetic Algorithms, George Mason University, Morgan Kaufman
Publishers
Goldberg, D. E. (1989) "Genetic Algorithms in Search, Optimization, and Machine
Learning", Addison-Wesley, Reading, Massachusetts
Grigoropoulos, G. J. and Loukakis, T. A. (1992) "A New Method for Developing Hull
Forms with Superior Seakeeping Qualities", Design of Marine and Offshore
Structures (CADMO’92)
Hagen, A. (1992) Prosedyrer for Prosjektering av Skip (Procedures for the Design of
Ships), Dept. of Marine Systems Design, Norwegian Institute of
Technology/MARINTEK,Report no. 260292
Hagen, A. (1993) "The Framework of a Design Process Language", Ph.D.
Dissertation, Department of Marine System Design, Norwegian Institute of
Technology, Norway
Hales, C. (1987) "Analysis of the Engineering Design Process in an Industrial
Context", PhD Dissertation, Gants Hill Publication
Appendix C: [Erikstad, et al. 1995] 81
Hales, C. and Wallace, K. M. (1987) "Detailed Analysis of an Engineering Design
Project", ICED-87: International Conference on Engineering Design, Boston, The
American Society of Mechanical Engineers
Han, S.-H., Lee, D., Lee, K., Lee, K. and Kim, E.-K. (1994) "Visualization of the
Reasoning Process of a Knowledge-Based Design Support System for the Structural
Design of Ships", ICCAS'94 - 8th International Conference on Computer Applications
in Shipbuilding, Bremen, Germany, Berry Rasmusson Reklam AB
Harvald, S. A. and Jensen, J. J. (1992) "Steel Weight Estimation for Ships",
PRADS'92 - 5th Int. Symposium on Practical Design of Ships and Mobile Units,
Newcastle upon Tyne, UK, Elsevier Science Publishers Ltd.
Hees, M. v. (1992) "QUAESTOR - A Knowledge-Based System for Computations in
Preliminary Ship Design", PRADS'92 - 5th Int. Symposium on Practical Design of
Ships and Mobile Units, Newcastle upon Tyne, UK, Elsevier Science Publishers Ltd.
Hills, W. and Buxton, I. L. (1988) "A Concept Design System for Ships which
Incorporates Production Considerations", 2nd International Conference on
Computers, Design, Manufacturing, and Operations in the Marine and Offshore
Industry, Southampton, UK, Springer Verlag
Holtrop, I. J. (1977) "A Statistical Analysis of Performance Test Results",
International Shipbuilding Progress, Volume 4, Number 270, Feb. 1977
Holtrop, J. (1984) "A Statistical Re-Analysis of Resistance and Propulsion Data",
International Shipbuilding Progress, Volume 1, Number 363
Holtrop, J. and Mennen, G. G. J. (1978) "A Statistical Power Prediction Method",
International Shipbuilding Progress, Volume 5, Number 290
Holtrop, J. and Mennen, G. G. J. (1982) "An Approximate Power Prediction Method",
International Shipbuilding Progress, Volume 9, Number 385
Hubka, V. (1982) "Principles of Engineering Design", Butterworth & Co. (Publishers)
Ltd., London
Hubka, V. and Eder, W. E. (1987) "A Scientific Approach to Engineering Design",
Design Studies, Volume ol 8, No. 3, July 1987
Ingalls, D. H. (1981) "Design Principles Behind Smalltalk", BYTE, 8, Volume
Johnsen, I. and Ellingsen, H. (1986) "Hva kan Oljeindustrien Lære av Skipsfarten",
Petro Magasin, 6-86, Volume Jones, C. J. (1970) "Design Methods", John Wiley &
Sons, New York

82 References
Kamal, S. Z., Karandikar, H. M., Mistree, F. and Muster, D. (1987) "Knowledge
Representation for Discipline-Independent Decision Making", IFIP 1987, Elsevier
Science Publishers B. V.
Keeney, R. L. and Raiffa, H. (1976) "Decisions with Multiple Objectives: Preferences
and Tradeoffs", John Wiley & Sons, New York
Langbecker, U., Nowacki, H., Bühr, W. and Kress, H. (1994) "A Reference
Architecture for Shipbuilding Product Models", ICCAS'94 - 8th International
Conference on Computer Applications in Shipbuilding, Bremen, Germany, Berry
Rasmusson Reklam AB
Lautenschlager, U., Erikstad, S. O., Allen, J. K. and Mistree, F. (1995) "Experimental
Sattelite Trajectory Analysis Using Decision-Based Robust Design", Journal of
Guidance, Control, and Dynamics, Volume 8, Number 5
Levander, K. (1991) "System-Based Passenger Ship Design", IMSDC'91 - The 4th
International Marine Systems Design Conference, Kobe, Japan, The Society of Naval
Architects of Japan
Lyon, T. D. (1982) "A Calculator-Based Preliminary Design Procedure", Marine
Technology, Volume 9, Number 2
MacCallum, K. J. (1982) Creative Ship Design by Computer, North-Holland,
Amsterdam
MacCallum, K. J. (1990) "Does Intelligent CAD Exist?", Artificial Intelligence in
Engineering, No. 2
MacCallum, K. J. and Duffy, A. (1987) "An Expert System for Preliminary
Numerical Design Modeling", Design Studies, Volume ol 8, No. 4, October 1987
MacCallum, K. J. and Martins, P. D. (1985) "Towards a Concept Design Assistant for
Ships", 2nd International Marine Systems Design Conference IMSDC'85, Lyngby,
Denmark
MacPherson, D. M. (1993) “Reliable Performance Prediction: Techniques Using a
Personal Computer”, Marine Technology, Volume 30, Number 4
Marzi, J. and Ye, D. (1994) "On the Integration of CFD in Ship Design", 8th
International Conference on Computer Applications in Shipbuilding, Sept 5-9, 1994,
Bremen, Germany
McCarthy, J. and Hayes, P. (1969) "Some Philosophical Problems from the
Standpoint of Artificial Intelligence", Wiley & Sons (Halsted Press)
Appendix C: [Erikstad, et al. 1995] 83
Mehta, S. and Lehne, M. (1994) "Product Data Technology Benefits - A Perspective
of Yard and Classification Society", ICCAS'94 - 8th International Conference on
Computer Applications in Shipbuilding, Bremen, Germany, Berry Rasmusson Reklam
AB
Miles, J. and Moore, C. (1994) "Practical Knowledge-Based Systems in Conceptual
Design", Springer-Verlag, London
Mistree, F., Smith, W. F., Bras, B., Allen, J. K. and Muster, D. (1990) "Decision-
Based Design: A Contemporary Paradigm for Ship Design", Transactions, SNAME,
Volume 8
Mistree, F., Smith, W. F., Kamal, S. Z. and Bras, B. A. (1991) "Designing Decisions:
Axioms, Models and Marine Applications", Fourth International Marine Systems
Design Conference, Kobe, Japan
Nethercote, W. C. E., Eng, P. and Schmitke, R. T. (1981) "A Concept Exploration
Model for SWATH Ships", The Naval Architect, Volume May 1982
Nicklaus, D. J., Overton, K. S., Tong, S. S. and Russo, C. J. (1988) Knowledge
Representation and Technique for Engineering Design Automation, Elsevier Science
Publishers, B.V.
Nowacki, H., Brusis, F. and Swift, P. M. (1970) "Tanker Preliminary Design - An
Optimization Problem with Constraints", Transactions SNAME, Society of Naval
Architects and Marine Engineers
Oortmerssen, G. v. and Oossanen, P. v. (1988) "A New CAD System for the Design
of Ships", Marine and Offshore Computer Applications, September 1988
Oosterveld, M. W. C. and Oossanen, P. v. (1973) "Representation of Propeller
Characteristics Suitable for Preliminary Ship Design Studies", International
Conference on Computers Applied in the Automationof Shipyard Operation and Ship
Design - ICCAS, Tokyo, Japan
Pahl, G. and Beitz, W. (1984) "Engineering Design", The Design Council/Springer-
Verlag, London/Berlin
Pal, P. K. (1991) "Rationalised Design of Sailing Yachts", PRADS'91 - 4th
International Marine Systems Design Conference, Kobe, Japan
Parsons, M. G. (1975) "Optimization Methods for Use in Computer-Aided Ship
Design", 1st SNAME STAR Symposium

84 References
Perakis, A. N. and Jaramillo, D. I. (1991) "Fleet Deployment Optimization for Liner
Shipping", Maritime Policy and Management, Volume 8, Number 3
Priha, I. (1989) "Integrated Knowledge Systems", Artificial Intelligence in
Engineering, Number 2
Rawson, K. J. (1979) "Maritime System Design Methodology", International
Symposium on Advances in Marine Technology, Trondheim, Norway, Tapir
Ray, T. and Sha, O. P. (1994) "Multicriteria Optimization Model for a Containership
Design", Marine Technology, Volume 1, Number 4, October 1994
Roozenburg, N. F. M. (1993) "On the Pattern of Reasoning in Innovative Design",
Design Studies, Volume 4, Number 1
Roth, K. (1987) "Design Models and Design Catalogs", ICED-87: International
Conference on Engineering Design, Boston, The American Society of Mechanical
Engineers
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. (1991) "Object-
Oriented Modeling and Design", Prentice-Hall, New Jersey
Rzevski, G. (1980) "On the Design of A Design Methodology", Design Research
Society Conference, Portsmouth, Westbury House
Sargent, P. (1994) "Design Science or Nonscience", Design Studies, Volume 5,
Number 4, October 1994
Schneekluth, H. (1987) "Ship Design for Efficiency and Economy", Butterworths,
London
Seltveit, A. H. (1994) "Complexity Reduction in Information Systems Modelling",
PhD Dissertation, Norwegian Institute of Technology
Sen, P. and Yang, J.-B. (1994) "Combining Objective and Subjective Factors in
Multiple Criteria Marine Design", 5th International Marine Design Conference, Delft,
The Netherlands
Sha, O. P., Ray, T. and Gokarn, R. P. (1994) "An Artificial Neural Network Model for
Preliminary Ship Design", ICCAS'94 - 8th International Conference on Computer
Applications in Shipbuilding, Bremen, Germany, Berry Rasmusson Reklam AB
Sha, O. P., Ray, T. and Gokarn, R. P. (1994) "An Artificial Neural Network Model for
Preliminary Ship Design", ICCAS'94 - 8th International Conference on Computer
Applications in Shipbuilding, Bremen, Germany, Berry Rasmusson Reklam AB
Appendix C: [Erikstad, et al. 1995] 85
Simon, H. (1973) "The Structure of Ill-Structured Problems", in Developments in
Design Methodology, John Wiley & Sons, Chichester
Simon, H. A. (1982) "The Sciences of the Artificial", The MIT Press, Cambridge,
Mass.
Skipskonsulent (1991) "Ship Design", Shipping World & Shipbuilder, June 1991,
Volume Smith, W. F. (1992) "The Modeling and Exploration of Ship Systems in the
Early Stages of Decision-Based Design", PhD Dissertation, University of Houston
Smithers, T., Conkie, A., Doheney, J., Logan, B., Millington, K. and Xi Tang, M.
(1990) "Design as Intelligent Behaviour: an AI in Design Research Programme",
Artificial Intelligence in Engineering, No. 2
Statoil (1991) "Document for Statoil's Tender Invitation for Clean Product
Carriers"Statoil (1991) "Tender Document for Statoil's Tender Invitation for Clean
Product Carriers"
Stearns, H., Payne, P. and Smith, G. (1991) "Designing a Knowledge Based Ship
Design System", IMSDC'91 - The 4th International Marine Systems Design
Conference, Kobe, Japan, The Society of Naval Architects of Japan
Suh, N. P. (1990) "The Principles of Design", Oxford University Press, New York
"The American Heritage Dictionary" (1991), Houghton Mifflin Company, Boston
Top, J. and Westen, S. (1992) "Reverse Engineering of QUAESTOR with KADS",
2nd KADS User Meeting, Munich
Ullman, D. G. (1992) "A Taxonomy for Mechanical Design", Research in
Engineering Design, Volume 3
Watson, D. G. M. and Gilfillan, A. W. (1976) "Some Ship Design Methods",
Transactions RINA
Welsh, M. and Hills, W. (1991) "An Expert System for Use in Concept Design",
IMSDC'91 - The 4th International Marine Systems Design Conference, Kobe, Japan,
The Society of Naval Architects of Japan
Wikstrom, K. (1989) "Analys av Prosjekteringen for ett Offshore Projekt", Ph.D
Dissertation, University of Trondheim - Norwegian Institute of Technology
Wikstrom, K. and Erichsen, S. (1990) "Design Models Used in the Development on
North Sea Oil Installations Compared with theorethical Design Models", International
Conference on Engineering Design, Dubrovnik 1990

86 References
Wogerbauer, H. (1943) "Die Technik des Konstruierens", Oldenbourg, Munich
Yoshikawa, H. and Koyama, T. (1982) "Artificial Intelligence and Design",
IMSDC'82 - International Marine Systems Design Concference, LondonAamodt, A.
(1991) "A Knowledge-Intensive, Integrated Approach to Problem Solving and
Sustained Learning", PhD dissertation, University of Trondheim, Department of
Informatics
Aamodt, A. (1993) "A Case-Based Answer to Some Problems of Knowledge-Based
Systems", Scandinavian Conference on Artificial Intelligence