Lecture Note - Intro To Design and Design Modelling PDF

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
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
A REVIEW OF ENGINEERING DESIGN ............................................................................... 7

3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.2
3.2.1
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.3.8
3.4
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.5
INFERENCE PROCESSES IN DESIGN ......................................................................................... 9

Representational building blocks of the design process................................................. 10
Generic inference processes ........................................................................................... 12
Interpreting design descriptions ..................................................................................... 13
Generating design descriptions from interpretations..................................................... 14
Syntactic generation ....................................................................................................... 15
Combined interpretation and syntactic generation ........................................................ 16
Interpretive and syntactic knowledge acquisition .......................................................... 16
Concluding remarks ....................................................................................................... 17
DESCRIPTIVE DESIGN MODELS............................................................................................. 18
Invariants of the Design Problem Space and Task Environment ................................... 18
PRESCRIPTIVE DESIGN MODELS ........................................................................................... 24
Design as a systematic decomposition and synthesis - the German VDI model ............ 25
Design as an iterative, sequential process ..................................................................... 26
Modelling preliminary ship design as a mathematical optimisation problem ............... 29
Design as a creative activity: Abductive generation in original design ......................... 36
Knowledge-Based design models ................................................................................... 38
DESIGNER: A Focus on the Design Object................................................................... 39
Developing a task-structure of design - an integrating approach.................................. 42
Concluding remarks on knowledge-based design methods ............................................ 44
NEW DESIGN TECHNOLOGIES AND EMERGING TRENDS ....................................................... 44
Expert Systems................................................................................................................ 45
Case-Based Reasoning ................................................................................................... 45
Genetic Algorithms ......................................................................................................... 46
Artificial Neural Networks.............................................................................................. 48
Design Representation by Product Models .................................................................... 48
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 21. 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
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
Figure 21: As the design process proceeds, the knowledge

about the design increases, while the freedom to make
changes decreases
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.
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
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 22. Though the content of these activities
Clarificat ion of
t ask
Design
init iat ion
Concept ual
design
Pr oblem descr ipt ion

(St at ement of need)
Embodiment
design
Out line specificat ion

(Tender invit at ion)
Cont r act
specificat ion
Figure 22: Activities and events in the preliminary design process
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.
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
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
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
vessels 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.
The outcome of the embodiment design phase is a contract specification. This

document typically contains the following items [Kanestrm, 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].
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 ontological1 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 multiperson/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.
ontology The branch of philosophy that deals with being [American Heritage Dictionary, 1991]
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 realworld 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 computers
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 31: A decision space that consists of descriptions of potential
10
design solutions, and a performance space specifying the functions to be delivered by

the design object.
Figure 31: 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 ndimensional 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
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 dependent on the chosen representation. For
instance, in a pure numerical representation of the design object, the
appropriate vocabulary consists of
design variables represented as a set Figure 32: Alternative design vocabularies
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.
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 vessels main particulars (vocabulary of attribute-value
pairs), a general arrangement drawing (symbolic/geometric vocabulary), or 3dimensional hull form representation (geometric vocabulary).
Design interpretation2, I:
interpretation () 2. A representation of the meaning of a work of art as expressed esp. in

representation or performance. [American Heritage Dictionary, 1991]
12
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].
Syntactic3 knowledge, Ks:
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 Cp = 0.9, Cm = 0.2, and Cb = 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, Ki:
To determining the meaning the semantic content of a particular design
description we need interpretive knowledge, Ki. 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:
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]
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 pattern4 (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 computerbased 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(Ki, D)
(2.1)
The underlying inference process is that of deduction: given a syntactically valid

description D and the necessary interpretive knowledge Ki, the interpretation I follows
logically. Following the scheme of Modus Ponens, we may have:
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
4
14
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 31, 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
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:
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 Ki.
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(Ks,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
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(Ks, Ki, 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 designevaluate-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
Ki = 5({D1, D2, ...}, I)
(2.5a)
Ki = 5({D1, I1}, {D2, I2}, ...)
(2.5b)
or alternatively as
Accordingly, we can model the acquisition of syntactic knowledge as:

Ks = 6({D1, D2, ...}, [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:
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:
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
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 [Wikstrm 1989, Wikstrm 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
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 its 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 Simons
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
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 tractable5. 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
designers 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] .
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.
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
designers 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
Design Task
Environment
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
Design Problem
Space
Solut ion decomposit ion
int o leaky modules
Use of art ificial symbol

syst em
Abst ract ion

hierarchies
Making and
propagat ion of
commit ment s
LCMCS & Nest ed

evaluat ion loops
Ext ensive performance

modelling
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
Personalized evaluat ion

funct ion and st opping
rules
Ext ensive problem

st ruct uring
Figure 33: The design task environment and design problem space for a
general design problem, adopted from [Goel and Pirolli 1989]
23
Goel & Pirollis 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 designers point of view. Thus, we may find
a mismatch between the designers 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 memory6
Because of the computers 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
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 model7 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
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]
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 products8.
Energy
Mat erial
Energy
Funct ion
Signals
Mat erial
Signals
Figure 34: 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 subfunction. All functions are seen as a conversion of energy, material, and/or signal
(information), as illustrated in Figure 34. 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.
Guideline VDI 2222 (The design of technical products)
26
Figure 35: 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 36. It is a descriptive model that captures the sequential and iterative 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 37,
portraying the many constraints on a designer as a fundamental part of the process.
27
Figure 36: 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 Shipshape9, Hull-Calc, as part of the HullTech10 program suite, and Autoship11 [Ames and Lynaugh 1988].
Shipshape is a ship design program developed by MARINTEK, Norway

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
10
28
Figure 37: 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 38. Using the basic inference processes described earlier in this chapter, the
three tasks can briefly be described
as:
DESIGN:
DESIGN
EVALUATE
REDESIGN
Figure 38: The top-level process elements in a

sequential, iterative design process
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(Ks, Ki, 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(Ki, 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
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 timeconsuming, 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
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 f ( x ),
subject to h( x ) = 0
g( x ) 0
x n
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:
I1:
I2:
x DW(x) V(x) AnnualCargoCapacity(x) = g(DW(x), V(x))
D:
DW(ShipA) = dw V(ShipA) = v
minimise TotalCost(ShipA)
AnnualCargoCapacity(ShipA) > minAnnualCapacity
Here, design knowledge (Ki) 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
31
optimal design description can be directly derived as a consequence of the intended

interpretation I and interpretive knowledge Ki.
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
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 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.
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
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-design12 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 shipbuilders (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 representation 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
Templat e
Select ion
DSP
Compromise
DSP
Variables
Const raint s
Figure 39: 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 compromise 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 function13
Given a mathematical formulation of the description above, the decision problem is

solvable by an appropriate numerical algorithm14. 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
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 realworld 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. givenfind-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
5. In the last step this process
network is converted into
computer code that can be
directly interpreted by the
numerical solver.
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."
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
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 preliminary 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 subproblems 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
design15 [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]
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
history16.
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 (Ki is typically an analysis algorithm) and in the VDImethod (Ki 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 Ki 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
beforehand, and mutually dependent you dont have Ki 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 computers and the human designers
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.
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 todays 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
design process is driven forward by operations upon design variables in a directed

network, as illustrated in Figure 310.
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 311. 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 representation 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.
Speed
Displacement
Beam
Block
coefficient
Lengt h
Power
Draught
Dept h
St eelweigt h
Machinery
weight
Light weight
Out fit weight
Deadweight
Figure 310: A directed network representing the design object in

DESIGNER [MacCallum, 1987]
41
Charact erist ic frame

Name
Explanat ion
Value
Accuracy
Relat ion frame
Unit s
Influence frame
Charact erist ic
Relat ionships
Influences
Expression
Reliabilit y
Pre-condit ions
St rengt h
Post -condit ions
Next
Next
Figure 311: 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 DISPL0.3 V0.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 metadesign process (the planning of the design process) and the design process are
seamlessly integrated.
42
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 methodindependent 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
43
satisfies a specified set of desired properties, while the latter centres on the problemsolving 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 optimisation, design-evaluate-redesign, innovative abduction, or knowledge-based systems, is dependent on
the character of the available knowledge.
PROPOSE
CRITIQUE
MODIFY
Figure 312: 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
312. 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
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].
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
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
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 mancomputer interaction through the design process, thus allowing for the designer to
apply his/her knowledge and experience in guiding the process towards improved
48
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, STEP17 (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
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:
IMPPACT18 aimed at developing a reference model for the modelling of

mechanical products and production processes
NEUTRABAS19 defining STEP-conformant models for shipbuilding, including
ship geometry, ship structures, spatial arrangements, and outfitting systems
MARITIME20, 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

20
19
"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 problems 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-bedesigned 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 41, 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 designs21.
Design Task Environment

Perfect knowledge of
preference st ruct ure
Unlimit ed comput er
capacit y
Perfect knowledge
about t he ext ernal
environment
Correct weight ing

bet ween mult iple goals
Exact mapping bet ween

t he ship model and t he
preference st ruct ure
Perfect model of t he
ship t o be designed
Perfect model of t he
design problem
Specific propert ies of

t he design space
Classical mat hemat ical

opt imisat ion
Search met hods

"True" opt imum design
Design Problem Space

Figure 41: 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
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 designers 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 customers 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
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
Self-cont ained, highly
int egrat ed syst em
ship as a self-contained, highly
integrated structure, the complex
Complex mapping
underlying physical phenomena
Uncert aint y wrt t he
bet
ween form and
st at e of t he out er
involved in the movement of a
funct ion
environment
solid body at the boundary between two fluids, and the intrinsic
Int eract ion
inner-out er
uncertainty with respect to the
environment :
present and future state of the
Movement of a solid
outer environment in which the
ship operates (see Figure 42). In
Figure 42: Ship design is characterised by a
the following, I will discuss each
complex mapping between form and function
of these features in more detail.
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
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 ships displacement directly22. 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
(FRs)
FR1:
Cargo capacity x metric tonnes
FR2:
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 FRs
are said to be decoupled23. Now the design decisions can be taken without secondary
effects, by first dimensioning the barge to satisfy FR1, and then design the tug to
satisfy FR2. 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 Normands Number, after J. A. Normand who published the method in 1885
23
To avoid secondary effects in a decoupled design requires the FRs to be satisfied in the proper
sequence. A third category is uncoupled designs where the FRs are completely independent. In
uncoupled designs the sequence of the decisions does not matter.
56
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.
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-tofunction 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 wellstructured 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 ships 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
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.
4.1.3 High cost of error
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
discharging
Efficiency in harbours and at terminals
Reliability in service
in
transit
and
for
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
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 designers
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 problemsolving framework for a specific domain, a thorough understanding of the domains
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
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
invitations24. 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 tradeoff 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
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
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 subset 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 programming/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
Bremmermanns limit, which constrains the number of independent variables in a factorial design to 270 on the basis of the mass of the Earth, the period of atomic
vibration, and Heisenbergs uncertainty principle [Suh 1990]. A more concrete
63
example: Given 10 design variables, each to be evaluated at ten different values, the
total number of combinations becomes 1010. If we assume that each design evaluation
takes 1 millisecond, the total computer time needed will be 107 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.
Task Environment
Problem Space
Mult i-dimensional ,
part ly non-monet ary
performance
l ti
Complex mapping
bet ween form and
funct ion
Sat isficing rat her

t han opt imizing
Shallow knowledge
st ruct ure (high
soft /hard info. rat io)
Figure 43: "Satisficing rather than

optimising" as an invariant of the Design
Problem Space
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 Simons
words a satisficer is a person who
accepts good enough alternatives, not
because he prefers less but because he
has no choice.
Concluding this, I claim that satisficing rather than optimising is an important invariant 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 43.
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
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 criteria25.
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-tofunction 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 36),
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* + Th* + Tg* = 0T, 0, 0, Tg = 0, where x* corresponds to the optimal design
solution
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 reestablished. 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 subproblems 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
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 predefined 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 design26.
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 Wi may be
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 ships 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 compartmentation. 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 = Wi/(1- -1Wii), assuming that the individual weights may be calculated by
formulas following the pattern Wi = ki
68
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 ships 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. Cb, Cp, Cm
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.
Design Task
Environment
Design Problem
Space
69
Crit ical Fact ors
Mult i-dimensional ,
part ly non-monet ary
performance
l ti
Complex mapping
bet ween form and
funct ion
St rict t ime and

resource const raint s
Personalised
evaluat ion funct ion
and st opping rules
FLEXIBILITY
Sat isficing rat her
t han opt imising
High cost of error
Shallow knowledge
st ruct ure
St rong domain
t radit ion
"One-of-a-kind" and
"engineered-t o-order"
solut ions
EXPRESSIVENESS
Decomposit ion
int o leaky modules
PERCEIVABILITY
Ext ensive use of
empirical relat ions
and previous cases
EFFICIENCY
Mult iple abst ract ion
hierarchies
Delayed/limit ed
feedback from t he
world
Figure 44: The preliminary ship design problem space and task environment, with
corresponding critical factors by which to evaluate the design model
70
Design Task
Environment
provide t he
set t ing for
det ermines what

aspect s are of
int erest t o
Design Problem
Space
Design Model
Figure 45: 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/Lpp-ratio, Lpp/.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
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 metamodelling 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-ofthumb. A parallel to expressiveness is the notion of epistemological27 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 alternative28, 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
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 Perceivability29
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 objectoriented 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 process30, as illustrated in Figure 46. On the one
hand the model serve as a basis for communication and understanding of the realworld 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]
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 designer can only control the input and output,
but not the internal structure31. Though this
modularisation of the process may decrease
the models complexity by abstraction, it may
at the same time inhibit the human
perceivability of the model, since part of the
foundation on which the models 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.
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 models reasoning
process transparent to the user.
4.3.4 Efficiency
73
Human designer
Basis for communicat ion

and underst anding
Design
model
Basis for implement at ion
and processing
Comput er
Figure 46 - The dual role of the

design model
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
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 47. 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.
topNode
(OperElem)
value = '<'
(Constraint)
tag='LBRATIO'
leftP
rightP
(NumElem)
value = '5.9'
(OperElem)
value = '/'
leftP
(PropElem)
value = 'LPP'
rightP
(PropElem)
value = 'B'
Figure 47: 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 model32. 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 Coggins Law of Software Engineering, which states
that Pragmatics must take precedence over elegance, for Nature cannot be impressed
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
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 (CADMO92)
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., Ksper, 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 1113, 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 (CADMO92)
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
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",
Holtrop, J. and Mennen, G. G. J. (1982) "An Approximate Power Prediction Method",
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 Lre 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., Bhr, 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)
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) "DecisionBased 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/SpringerVerlag, 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) "ObjectOriented 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
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

Lecture Note - Intro To Design and Design Modelling PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture Note - Intro To Design and Design Modelling PDF

Uploaded by

Copyright:

Available Formats

TMR4115 Design Methods

Introduction to Marine Systems Design Models and

Stein Ove Erikstad

THE PRELIMINARY SHIP DESIGN PROCESS .................................................................... 1

A REVIEW OF ENGINEERING DESIGN ............................................................................... 7

INFERENCE PROCESSES IN DESIGN ......................................................................................... 9

Trondheim, Agust 2003

Chapter 2 The Preliminary Ship Design Process

reduce design to absolute or scientific principles, rendering the

Figure 21: As the design process proceeds, the knowledge

Chapter 2- The Preliminary Ship Design Process

money allocated to the pre-contract phase is estimated to only 1% - 2% of that of the

2.1 The Content of the Preliminary Ship Design Process

Pr oblem descr ipt ion

Out line specificat ion

Figure 22: Activities and events in the preliminary design process

2.1.1 Clarification of task

Chapter 2 The Preliminary Ship Design Process

2.1.2 Conceptual design

Chapter 2- The Preliminary Ship Design Process

2.1.3 Embodiment Design

Chapter 2 The Preliminary Ship Design Process

The outcome of the embodiment design phase is a contract specification. This

Main dimensions and capacities

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

Masterplan for the production process

"Pending the development of a radically new type

Chapter 3 - A Review of Engineering Design

Chapter 3 - A Review of Engineering Design

3.1 Inference Processes in Design

Chapter 3 - A Review of Engineering Design

design solutions, and a performance space specifying the functions to be delivered by

3.1.1 Representational building blocks of the design process

Chapter 3 - A Review of Engineering Design

grouped into vocabulary, descriptions, interpretations, and syntactic and interpretive

interpretation () 2. A representation of the meaning of a work of art as expressed esp. in

Chapter 3 - A Review of Engineering Design

Design interpretation relates to the meaning content of a particular description, just as

Hence, if we have a ship described by Cp = 0.9, Cm = 0.2, and Cb = 0.18, it represents

3.1.2 Generic inference processes

Chapter 3 - A Review of Engineering Design

Deduction is an inference step where the validity of the conclusion is guaranteed,

In abductive inference, it is the specific instance which is the result. Contrary to

3.1.3 Interpreting design descriptions

The underlying inference process is that of deduction: given a syntactically valid

Chapter 3 - A Review of Engineering Design

x DW(x) V(x) Resistance(x) = f(DW(x), V(x))

DW(ShipA) = 200.000 V(ShipA) = 15

3.1.4 Generating design descriptions from interpretations

Chapter 3 - A Review of Engineering Design

x DW(x) V(x) Resistance(x) = f(DW(x), V(x))

DW(ShipA) = 200.000 V(ShipA) = 15

3.1.5 Syntactic generation

Chapter 3 - A Review of Engineering Design

particularly from a computer implementation point-of-view. This is mainly because it

3.1.6 Combined interpretation and syntactic generation

An alternative representation could of course be to express this as a sequence of 1, 2