Lecture Note - Intro to Design and Design Modelling

TMR4115 – Design Methods

Lecture Note #1

“Introduction to Marine Systems Design Models and Methods”

Stein Ove Erikstad

August 2003

ii Table of Contents

Table of Contents

1 INTRODUCTION ........................................................................................................................ 1

2 THE PRELIMINARY SHIP DESIGN PROCESS .................................................................... 1 2.1 THE CONTENT OF THE PRELIMINARY SHIP DESIGN PROCESS ................................................. 3

2.1.1 Clarification of task .......................................................................................................... 3 2.1.2 Conceptual design ............................................................................................................ 4 2.1.3 Embodiment Design.......................................................................................................... 5

3 A REVIEW OF ENGINEERING DESIGN ............................................................................... 7 3.1 INFERENCE PROCESSES IN DESIGN ......................................................................................... 9

3.1.1 Representational building blocks of the design process................................................. 10 3.1.2 Generic inference processes ........................................................................................... 12 3.1.3 Interpreting design descriptions ..................................................................................... 13 3.1.4 Generating design descriptions from interpretations..................................................... 14 3.1.5 Syntactic generation ....................................................................................................... 15 3.1.6 Combined interpretation and syntactic generation ........................................................ 16 3.1.7 Interpretive and syntactic knowledge acquisition .......................................................... 16 3.1.8 Concluding remarks ....................................................................................................... 17

3.2 DESCRIPTIVE DESIGN MODELS............................................................................................. 18 3.2.1 Invariants of the Design Problem Space and Task Environment ................................... 18

3.3 PRESCRIPTIVE DESIGN MODELS ........................................................................................... 24 3.3.1 Design as a systematic decomposition and synthesis - the German VDI model ............ 25 3.3.2 Design as an iterative, sequential process ..................................................................... 26 3.3.3 Modelling preliminary ship design as a mathematical optimisation problem ............... 29 3.3.4 Design as a creative activity: Abductive generation in original design......................... 36 3.3.5 Knowledge-Based design models ................................................................................... 38 3.3.6 DESIGNER: A Focus on the Design Object................................................................... 39 3.3.7 Developing a task-structure of design - an integrating approach.................................. 42 3.3.8 Concluding remarks on knowledge-based design methods ............................................ 44

3.4 NEW DESIGN TECHNOLOGIES AND EMERGING TRENDS ....................................................... 44 3.4.1 Expert Systems................................................................................................................ 45 3.4.2 Case-Based Reasoning ................................................................................................... 45 3.4.3 Genetic Algorithms ......................................................................................................... 46 3.4.4 Artificial Neural Networks.............................................................................................. 48 3.4.5 Design Representation by Product Models .................................................................... 48

3.5 CONCLUSION........................................................................................................................ 49 4 THE TASK ENVIRONMENT AND PROBLEM SPACE OF PRELIMINARY SHIP DESIGN................................................................................................................................................. 51

4.1 PRELIMINARY SHIP DESIGN TASK ENVIRONMENT................................................................ 53 4.1.1 Complex mapping between form and function ............................................................... 53 4.1.2 Multi-dimensional performance evaluation ................................................................... 57 4.1.3 High cost of error ........................................................................................................... 58 4.1.4 Shallow knowledge structure.......................................................................................... 59 4.1.5 Strong domain tradition ................................................................................................. 59 4.1.6 Strict time and resource constraints on the preliminary ship design process ................ 60 4.1.7 Predominantly “one-of-a-kind” and “engineered-to-order” solutions ......................... 60

4.2 PRELIMINARY SHIP DESIGN PROBLEM SPACE ...................................................................... 61 4.2.1 Satisficing rather than optimising .................................................................................. 62

Table of Contents iii

4.2.2 Personalised evaluation functions and stopping rules ................................................... 63 4.2.3 The decomposition of the design problem into leaky modules ....................................... 64 4.2.4 Sequential iterative limited commitment mode design strategy...................................... 65 4.2.5 Extensive use of empirical relations and previous cases................................................ 66 4.2.6 Multiple abstraction levels ............................................................................................. 67

4.3 CRITICAL FACTORS FOR A DESIGN MODEL .......................................................................... 68 4.3.1 Flexibility........................................................................................................................ 70 4.3.2 Expressiveness ................................................................................................................ 71 4.3.3 Perceivability.................................................................................................................. 72 4.3.4 Efficiency ........................................................................................................................ 73

4.4 CHAPTER CONCLUSION ........................................................................................................ 75 5 REFERENCES............................................................................................................................ 77

1

Introduction

The focus of this lecture note is the early stages of the design process. The context is the design of marine systems, with special emphasis on merchant ship design.

It will centre on the main characteristics of the design process – not from a design analysis perspective, but rather from the perspective of how a design engineer may understand the design situation at hand in order to select and apply a suitable design model and its corresponding set of methods.

Different design methods can be grouped together into what we call design paradigms. These paradigms differ in their fundamental approach to the design problem. It is important to understand these differences to make proper decisions about when to use – and when not to use – a particular model or method. This require us to take a slight sidestep into basic reasoning processes such as deduction, induction and abduction, and from these derive a formal theory on elemental reasoning processes in design.

I run the risk of leaving some of you at a level of abstraction that seems little relevant to practical design situation. However, we will revisit these elementary processes throughout the semester. Hopefully you will be patient enough to see how they are useful to understand the different design paradigms beyond the step-by-step solution techniques needed to solve text-book problems, but is of little use in most real-world settings.

In addition, this lecture note contains a brief review of engineering design schools. It is not comprehensive and it does not go very deeply into each – if you want to know more you should dig into som of the references. Avoid getting fixed on details – it is most important (and most relevant for your final exam) to get the broad picture.

Trondheim, Agust 2003

Stein Ove Erikstad

2

The Preliminary Ship Design Process

The term early stages refers to the part of the total ship design process in which the main features of the ship is determined, taking high-level technical and economic criteria into consideration. On a task-oriented time-line the early design stages comprise the activities that starts with an identification of a need and a statement of the design problem, and ends with a tender or a contractual specification of the design solution. The features of the vessel to be determined usually include the main dimensions, powering and propulsion arrangements, overall external and internal geometry, and cargo access and handling equipment. Sometimes the selection of ship speed is also covered.

In these early stages some of the most important decisions regarding the vessel are made. Various sources estimate that between 60% and 80% of the total life cycle cost is determined during this part of the design process [Dierolf, 1989]. All later design decisions have to be taken within the frame set by the initial design, with only limited influence on cost and overall performance.

At the same time the situation at this stage is characterised by a high degree of design freedom, as illustrated in Figure 2–1. The design problem is open – no decisions have yet been made that limit the options beyond the bounds given in the problem definitions. All subsequent decisions will put constraints on this freedom. Since not making decisions is hardly a viable alternative, the effort must be put on making these early decisions correct. In [Suh, 1990] the situation is described as:

"Design decisions made at the initial or upstream stage of engineering affect all subsequent outcomes". Fine-tuning of the later stages of engineering operations may often have marginal effects on the total outcome, and certainly cannot rectify the erroneous decisions made at conception; yet we often relegate the design decisions to the least experienced or the least educated of engineering professionals. The reason why this practice has lasted for so long lies in our inability to

2 Chapter 2 –The Preliminary Ship Design Process

reduce design to absolute or scientific principles, rendering the educated and uneducated alike handicapped in this field."

One of the main obstacles to achieving a more rational approach to preliminary design is that the knowledge to support these early decisions is limited. By knowledge is meant all types of facts, methods, heuristics, and experiences, and which at the same time is explicitly available to support decisions regarding the design problem at hand.

The limited availability of knowledge can be attributed to several sources. One is the

inherent uncertainty related to the mapping between the design space and the performance space, that is, the uncertainty in the transformation between the form and the function of the vessel. This uncertainty can be related to the ship system itself, e.g. available volumes, final weights, position of the centre of gravity, material quality, or to the environment in which the ship system operates, e.g. freight rates, cargo inflow, costs, transport demand, weather conditions. Because of this, it is difficult to establish analytical relationships between the design variables and the set of design criteria. To a large extent these relationships have to be modelled on the basis of empirical data and heuristic rules.

Figure 2–1: As the design process proceeds, the knowledge about the design increases, while the freedom to make

changes decreases

Another aspect of the limited availability of knowledge is the relatively high ratio of qualitative to quantitative information. This makes it more difficult to transfer, share and store design knowledge, and also makes the knowledge less available for computer-based design tools which require a high degree of formalism.

Despite the importance of the decisions made in the early stages of the design process, only a minor share of the resources are spend here. In [Levander, 1991] the time and

Chapter 2- The Preliminary Ship Design Process 3

money allocated to the pre-contract phase is estimated to only 1% - 2% of that of the post-contract phase at a typical shipyard. Taking into consideration the complexity of the structure to be built and the financial commitment made in the contract, this effort may seem too limited. However, it needs to be traded off against the risk of not receiving the contract, thus making the allocation of resources for preliminary ship design a difficult decision problem in itself.

On the basis of the preceding description, it is clear that the decisions made in the preliminary design phase are important, yet the provision of support for these decision is made difficult by problem characteristics such as uncertainty, lack of knowledge, and time and resource constraints.

2.1 The Content of the Preliminary Ship Design Process From a temporal point-of-view, preliminary ship design comprises the activities from the design project is initiated to a contract specification is delivered. This corresponds to the three first stages of the design model of Pahl & Beitz [Pahl, 1984]: clarification of task, conceptual design, and embodiment design. Each activity is bounded in time by a set of events, as illustrated in Figure 2–2. Though the content of these activities

and events will vary with respect to both the actual design problem and to differences in design practice, some similarities can be found that together can be used to form a prototypical preliminary ship design process.

Clarif icat ion of t ask

Concept ual design

Embodiment design

Designinit iat ion

Problem descr ipt ion(St at ement of need)

Out line specif icat ion (Tender invit at ion)

Cont ractspecif icat ion

Figure 2–2: Activities and events in the preliminary design process

2.1.1 Clarification of task

The design process initiates with the identification of a need, and the corresponding decision to seek the means for which this need can be satisfied. The first task to be undertaken is the clarification of the design problem. The purpose is to produce an operable problem description − a problem description that is sufficiently defined in


order to start the search for solutions. This includes the identification of promising market segments, forecasting the development of market supply, demand, prices, cost, etc., identification of market characteristics (customers, competitors, conferences, entry and exit barriers, etc.), and the resolution of market constraints and restrictions. Often this activity is performed by the owner or brokers, and not by the shipyard.

Ideally, the result of this activity is a set of pure functional requirements and objectives that the final design solution should meet, that is, the formulation of the design task should not presuppose any particular solution. This is important for maintaining a creative element in the design process, hopefully leading to a new and innovative solution. For instance, formulations like “design a bulker with less than 10 m draft” should be avoided, since important aspects of the solution will be implicitly defined. A better alternative is the formulation: “design a transport system that can unload bulk cargoes in port X where the maximum permissible draught is 10 m” (example from [Erichsen, 1989]). In the latter formulation the emphasis is on the problem, keeping the choice of solution open. However, in practice the openness of the design problem is restricted due to factors such as risk avoidance, the adaptation to existing production technologies and facilities, and sometimes an inherent conservatism in the maritime industry as such.

2.1.2 Conceptual design

Generally, conceptual design involves the development of function structures, the identification of solution principles, and the combination of these into concept variants [Pahl, 1984]. In ship design the content of the conceptual design activity varies substantially. In some cases the concept on which the design is to be based is explicitly given by the potential customer. In other cases there is a number of given alternatives from which the concept is to be chosen. There may also be situations where all existing concepts are considered unsatisfactory, and a new concept has to be developed from scratch.

The result of the conceptual design stage is typically an outline specification, describing the main features of the selected solution, together with the most important design constraints and restrictions. The design specification will serve as a tender document from the purchaser, or as the main governing document for the embodiment design phase for in-house projects.

In order to secure a rational trade-off between different design performances, it is advantageous if the specification explicitly state the design goals of the customer, preferably in operable terms indicating both the relative weight of each goal and how goal satisfaction should be measured. In practice, however, this information is less available, thus relying to a large degree on human expertise for evaluating and

Chapter 2- The Preliminary Ship Design Process 5

selection of the “optimal” solution taking both monetary and non-monetary goals into consideration.

An example illustrating these characteristics for the outline specification is given in Box 2-1. In paragraph (i) the intention of the outline specification of stating the minimum requirements for the vessel to be designed. In (ii) the top-level preferences of the potential customer is given, thus providing the basis for forming an evaluation function that can be used to determine the overall performance of a particular design. Paragraph (iii) in Box 2-1 states the selected conceptual solution, while paragraph (iv) states constraints on the design solution by giving (minimum) performance and operational requirements.

Box 2-1: Excerpts from an outline specification from [Statoil, 1991] illustrating typical characteristics. The outline specification serve as a starting point for the

embodiment design phase

(i) “This outline specification contains design and minimum performance and operational requirements of a tanker for cargoes as listed in DnV Rules (…). “

(ii) “On a competitive basis, the Charterer will give preference to vessels offering the best design and operational characteristics for the following high-lighted items: (…)”

(iii) ”The vessel shall be a single screw fully welded motor tanker with bulb, forecastle, pump room aft, and one semi-spade rudder. The vessel shall be built with double bottom and double skin as ballast tanks, and preferably arranged with centre longitudinal bulkhead in the cargo area. (…)”

(iv) “The vessel shall be constructed and outfitted for world-wide trade. Dimensions for length overall, draft, and extreme beam will be subject for due consideration with respect to limitations at major European and US terminals. Max. draft = 7.5 m. The vessel’s deadweight shall be about 6000-8000 tonnes on design draft in SW. The tank capacity is to be sufficient in order to carry a full deadweight with a cargo of specific gravity 0.8 t/m3. The mean service speed for design loaded/ballast shall not be less than 12.5 knots with main engine running at 90% MCR, and at head wind speed and sea state up to and including Beaufort Number 5. (…)”

2.1.3 Embodiment Design

Using the outline specification as a starting point, the embodiment design phase is concerned with identifying a design solution that is both feasible and preferable to other solutions in terms of performance and cost. In ship design this involves three main activities: determining the main dimensions, selecting a set of preliminary lines for the hull, and developing the main aspects of the general arrangement.


The outcome of the embodiment design phase is a contract specification. This document typically contains the following items [Kanestrøm, 1991; Statoil, 1991]:

❏ Main dimensions and capacities

❏ General arrangement

❏ Preliminary lines

❏ Preliminary weight calculations

❏ Preliminary hydrostatic calculations

❏ Cargo conditions/deadweight estimates

❏ Preliminary tonnage calculations

❏ Preliminary electric load balances

❏ Estimate of production hours

❏ Sketches of important arrangements

❏ Price estimates

❏ Masterplan for the production process

A principal difference between the conceptual and embodiment design phase is the dominant type of decisions made. According to [Mistree, 1991] there are two types of primary decisions: selection and compromise. The selection decision involves a choice between a finite number of given alternatives, based on a trade-off between a set of attributes. In the compromise decision the task is to find the value of a set of design variables that best satisfies some given objective within the system constraints and bounds. Other kinds of decisions can be represented as a combination of these.

In the conceptual design phase selection is the dominant decision type, in making a choice between a number of solution principles. In the embodiment the dominant decision type is compromise, in finding the values of the ship main characteristics in order to best satisfy mission requirements. This results in a principally different decision-making process in the conceptual and embodiment design phase, making a common approach with respect to decision support inappropriate.

"Pending the development of a radically new type of computer, it is safe to say that which cannot be formalised in logic cannot be modelled in a computer system" [Roozenburg 1993]

3

A Review of Engineering Design

It is said that design is in a state of change, and that we see a development towards a "science of design". The notion of a design science was first put forth by H. A. Simon in his book “The Sciences of the Artificial” [Simon 1982]. Following this, the design community has put considerable effort into developing a theoretical fundament on which such a science can be built, though so far no general consensus has been reached on the actual content of this fundament.

An excellent survey of the current status of design science is given by [Finger and Dixon 1989]. Particular research areas comprise the formulation of a consistent design taxonomy [Dixon, et al. 1988, Ullman 1992], the identification of fundamental design axioms and invariants [Mistree, et al. 1990, Suh 1990, p 12], the development of procedures for hypothesis formation and testing in design [Antonsson, 1987, Dixon 1987], and the establishment of a theory for understanding design processes [Mistree, et al. 1990, Hubka 1982, Hubka and Eder 1987, Coyne, et al. 1990, Rzevski 1980, Yoshikawa and Koyama 1982].

The pursuit of a theoretical basis for design aimed at linking design method and scientific method has also been criticised. Cross [Cross 1980] points to the fundamental difference in the goals of these two activities: While science aims at describing the nature of what exists, design is concerned with inventing artefacts that are to be built. As a consequence of this basic difference, a common theoretical foundation for these two activities is not possible, nor desirable. He further indicates that the underlying reason for the science approach to design is not based on the nature of design as such, but rather motivated by the attractiveness of scientific qualities, like rationality, neutrality, and universality, primarily aimed towards giving design a higher status both in academia and in society in general [Cross, 1980].

8 Chapter 3 - A Review of Engineering Design

A similar criticism has been put forth by Sargent [Sargent 1994]. He claims that design requires the integration of techniques from several fundamentally incompatible views of the world. From this he concludes that we can have no unitary “science of design” − at best we have a number of partial theories that are useful. Thus, an essential aspect of design is to reconcile the incommensurate requirements and goals created by the partial theories.

It is not within the scope of this lecture note to discuss the 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 multi-person/multi-team core activity in the industrial organisation. Where before the designer could to a large extent rely on his/her own skills and experience in organising and carrying out the design task, it is now common that a large number of people with different backgrounds, sometimes located at geographically distant places, work closely together on the same design in parallel. From this follows a requirement for both a systematisation and a common taxonomy of design and design processes in order to co-ordinate the activity.

1 ontology The branch of philosophy that deals with being [American Heritage Dictionary, 1991]

Chapter 3 - A Review of Engineering Design 9

Secondly, and most important for this thesis, is the central role that computers have come to play in design. Until recently, their main function in the ship design process was to automate the often tedious and complex task of design analysis, and to serve as an advanced drawing aid in graphical CAD tools. However, in the last few years we have seen a development towards the computer increasingly acting as a partner to the human designer. Examples of technologies enabling this are large scale integrated design systems, knowledge-based systems, and product models. Today, it is no exaggeration to say that the presence of computers has become a prerequisite for real-world ship design. As a consequence, there is a need for a systematic and formalised treatment of all aspects of the design process, in order to satisfy the computer’s demand for logic and rigour.

Box 3-2: The top-level design task can be described as a mapping between a functional and a descriptive [Chandrasekaran 1989 p. 77]:

“The design problem is specified by a set of functions to be delivered by an artefact, a set of constraints to be satisfied by the artefact, a repertoire of components assumed to be available, and a vocabulary of relations between components. The solution to the design problem consists of a complete specification of the set of components and their relation which together describe an instance of the artefact delivering the functions and satisfying the constraints.”

In the following I will look into the foundation for developing such a formalised model of the ship design process. The focus will be on both the theoretical aspects of design science and design methodology, and on new methods and the techniques of decision support in designing complex, large-scale, engineering systems. In the first part of the chapter I will briefly discuss elementary design inference processes, since they represent the building blocks on which more complex design processes will be based in later chapters. Further, a number of different design paradigms will be described, and their usefulness for supporting the preliminary ship design process will be evaluated. In the last part of the chapter, I will survey some relevant new technologies that is expected to influence the design process in the years to come.

3.1 Inference Processes in Design At the top level, the design problem is specified by a set of performance functions that the design artefact is expected to deliver. In addition, a number of constraints and bounds may be given. The outcome of the process consists of a description of a design object that both satisfies the given constraints and bounds, and is preferable to other design objects by some measure.

Thus, we operate mainly on two different representations of the design object, as illustrated in Figure 3–1: A decision space that consists of descriptions of potential


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

Figure 3–1: The top-level design process as a mapping between a decision space and a performance space

In the ship domain, the decision space might be spanned by a numerical description of the ship. This description may comprise a set of attribute-value pairs corresponding to for instance the most important design characteristics, a geometric description of the hull form using NURBS surfaces, or a topological description of the main ship system. Most common in a preliminary design setting is a decision space spanned by a numerical representation of the ship main characteristics, thus forming a n-dimensional space of real numbers, ℜn.

The performance space specifies the functions delivered by the design object. This may be both independent performance functions, such as steel weight, production cost, resistance, etc., or some compound criteria.

Using these representations, the baseline design process may be described as the mapping of points from the performance space to the corresponding point in the decision space, thus arriving at a design solution. If this mapping had been ideal it would bring us directly to the “optimal” design solution. However, for real-world practical design problems we are forced to take a number of iterative steps in order to arrive at a satisfying design solution. In the following I will review different types of such iterative steps, or inference processes. The discussion is to a large extent based on [Coyne, 1990]. Later in this chapter these basis processes will be used in the discussion of different design paradigms.

3.1.1 Representational building blocks of the design process

Before we proceed a number of terms on which the description will be based need to be explained. These terms form the operands of the basic processes, and can be


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

The design vocabulary, V:

The vocabulary represent the building blocks − the “atoms” − of design descriptions, on which more complex representational structures will be based. A parallel in linguistics are single words in a language.

What vocabulary is appropriate in a particular design situation is depen-dent on the chosen representation. For instance, in a pure numerical repre-sentation of the design object, the appropriate vocabulary consists of design variables represented as a set of attribute-value pairs. In a geometric representation of the hull, the vocabulary may be primitives like point, line, surface, etc., or station-waterline-halfbreadth triplets. The choice of vocabulary affects what kind of knowledge we are able to represent within the design system. This will be further discussed in Chapter 4 in the context of the preliminary ship design process.

Figure 3–2: Alternative design vocabularies

Design descriptions, D:

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

Design interpretation2, I:

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

representation or performance. [American Heritage Dictionary, 1991]


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:

3 syntax 1. GRAMMAR a. The way in which words are put together to form phrases and

sentences (…) 2. COMPUTER SCIENCE The rules governing the construction of a machine language. [American Heritage Dictionary, 1991]


❏ 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 computer-based design tools there have been a strong focus on the process of interpreting design descriptions, that is, design analysis. In the ship design domain, this has typically consisted of the determination of the functional performance of the vessel based on a set of analysis algorithms or empirical relations using a parametric or geometric description of the vessel as input. This interpretation step can be expressed as:

I = τ1(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:

4 The notation follows [Genesereth, 1988], where φ and ψ represent generic sentences. In a design

context, φ represents any design description, ψ stands for any derived property, and φ → ψ stand for an


Ki: ∀x DW(x) ∧ V(x) ⇒ Resistance(x) = f(DW(x), V(x))

D: DW(ShipA) = 200.000 ∧ V(ShipA) = 15

I: Resistance(ShipA) = 1200

The first statement says that if we know the deadweight and speed of any ship (within the relevant “Universe of Discourse”) we can determine its resistance by using the function f. Since this is a mapping from a description (DW and V) to an interpretation (the performance parameter “resistance”), the statement is classified as interpretive knowledge.

The second statement simply says that we are given a specific instance, ShipA, of which we actually know the deadweight and the speed. On the basis of these two premises, the corresponding resistance can be correctly interpreted as 1200, and, given that the two premises are true, the interpretation is also true by logical necessity.

The inference step just described is the core process in most existing preliminary ship design tools. Referring back to Figure 3–1, it represents a mapping from the design space to the performance space. Thus, it represent a necessary, but not sufficient, inference step to support the top-level design process. In addition we need to support the mapping the opposite way, in going from a specification of function to a specification of form in the design process. For the aforementioned design tools this has the consequence that the actual design process becomes sequential and iterative, often described as a “DESIGN-EVALUATE-REDESIGN” cycle. Here, the computer is primarily responsible for the EVALUATE part based on the interpretation presented here, while the human designer is responsible both for proposing possible design solutions in the DESIGN step, and to interpret the outcome of the EVALUATE step in order to redesign the solution.

3.1.4 Generating design descriptions from interpretations

The generation of design descriptions from interpretations can be represented by the transformation τ2, given as

D = τ 2(Ki, I) (2.2)

arbitrary generalisation, for instance a rule of thumb, a physical law, or an empirical relation


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:


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,


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 “design-evaluate-redesign” process, where each reasoning step is fairly independent of the others. However, we will se that often the different inference processes in the sequence above are tightly integrated, and the compound transformation τ4 will prove useful.

3.1.7 Interpretive and syntactic knowledge acquisition

So far the existence of sufficient and relevant design knowledge has been taken for granted. This is not a reasonable presumption in preliminary ship design − on the contrary, this process is generally characterised by a lack of knowledge (see Section 1.1). In light of this, the acquisition and maintenance of the knowledge itself becomes an important task.

The acquisition of interpretive knowledge can be modelled as

Ki = τ5({D1, D2, ...}, I) (2.5a)

or alternatively as

Ki = τ5({D1, I1}, {D2, I2}, ...) (2.5b)

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:


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: …


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.


3.2 Descriptive Design Models In this section I will discuss descriptive models of design in general, and the model of the design task environment and problem space proposed by Goel and Pirolli in particular. The purpose of descriptive models is both to describe how design is performed within a practical setting, and to identify the general characteristics of real-world design processes. Often these descriptive models are based on protocol studies of individual designers or design groups, where data such as sketches, calculations, verbal communication etc. are systematically gathered and evaluated. Naturally, it is difficult to validate the design models evolving from such studies, since design to a large extent is a mental process where there are few visible records. Still, descriptive models serve as an important input to both the development of prescriptive models, both as design guidelines for human designers, or to methods to be implemented in a computer system.

Examples of descriptive models are a study of the design process of a medium-sized industry project found in [Hales 1987, Hales and Wallace 1987], and a study of the agreement between theoretical and practical design models in the development of an offshore structure for the North Sea [Wikstrøm 1989, Wikstrøm and Erichsen 1990].

3.2.1 Invariants of the Design Problem Space and Task Environment

Goel & Pirolli [Goel and Pirolli 1989] have used descriptive protocol studies to determine invariant characteristics of the generic design problem, based on the assumption that “a description of design problem-solving must exist that both captures the similarities in the problem-solving process across the various design disciplines and recognises the differences between design and non-design problem solving” [Goel and Pirolli 1989, p. 20]. As a template for this categorisation, they use the concepts “design task environment” and “design problem space”, the former denoting relevant features external to the design process, while the latter denotes the features of design process itself as a result of the task environment.

For the generic design problem, they found eight significant invariants of the task environment, which can be summarised as:

❏ Many degrees of freedom exists in the problem statement − owing to the fact that the design problem specification tend to be under-specified

❏ Feedback from the world is limited or delayed during problem solving − much of the feedback will have to wait for the artefact to be produced or put into regular use, when a significant of the resources has already been expended


❏ The input to the design process substantially consist of goals and intentions. The output is a description of a design object

❏ The design object must function independently of the designer − the designer will not participate in it’s use, and thus not be able to explain and perform its function.

❏ The specification and delivery of the design object are temporally separated. This enables the designer to model the performance of the design object before it is put into production, thus reducing the risk of being wrong

❏ Costs are associated with each and every action − no effort towards reducing the risk of being wrong, by for instance improving the knowledge base or extending the exploration of the design space, comes for free

❏ Answers are neither right, nor wrong, only better or worse − a parallel to Simon’s notion of design as a satisficing rather than an optimising activity [Simon 1982].

❏ The problems tend to be large and complex

On the basis of the results from the protocol study, Goel & Pirolli proposed a structure for the design problem space of the generic design problem, together with an “explanatory connection” between this structure and the proposed characteristics of the design task environment. Eight significant invariants were claimed:

❏ Extensive problem structuring

The many degrees of freedom and the lack of information in the problem statement makes the creation of an efficient problem space difficult. Thus, an extensive problem structuring is required, comprising among other things the search for necessary information, the application of legislative, pragmatic, technical, and self-imposed constraints, and the negotiation of problem space boundaries. This problem structuring is a continuous activity as new knowledge is gathered throughout the design process.

❏ Extensive performance modelling

Extensive performance modelling is necessary as a consequence of three of the invariants of the task environment: The risk involved in being wrong makes performance modelling a favourable trade-off, the independent existence of the design object requires the interaction between the design object and its environment to be anticipated up front, and the delayed feedback loop from the world makes performance modelling necessary to guide the current problem solving.


❏ 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 designer’s training and practices. One problem is the interdependence between the modules, giving rise to the term “leaky modules”. These interdependencies were dealt with in two ways: either negotiated on the spot, or to “plug the leaks by making functional level assumptions about the interconnecting modules” [Goel and Pirolli 1989, p. 30] .

5 A similar situation is described in [Jacques, 1980]: “Imagine a momentarily absolutely free

person. Any action which he takes will preclude him from any number of other actions which were also open to him at the moment of choice. Successive actions will be affected by the first choice. Thus any action will mean a loss of freedom, but freedom cannot lie in not taking action because one is not free to act.”


❏ The use of abstractions in the transformation of goals to a description of the design object

During the design process the designer has to “descend” from functional and abstract specification of the design goal, to a concrete description of the design object. In this process several intermediate abstraction levels are applied. Goel and Pirolli observed that the number of such levels attended to was a function of the designer’s “experience and familiarity of the task, the availability of relevant knowledge, and personal preferences” [Goel and Pirolli 1989 p. 30]. The more experienced, the more quickly the designer get to the low-level details.

They also noted that a common mistake was to descend too soon to the details. By this, far-reaching commitments are made at a time when the design knowledge is limited. In the ship design domain, Levander points to the same problem by describing how naval architects normally begin their work: “They select a set of main dimensions and start drawing the general arrangement” [Levander 1991, p. 48]. As an alternative he proposes a “system-based design” approach, where the representation of the design object is kept on a high level of abstraction until late in the process, thus being able to postpone major commitments until the design knowledge base is improved.

❏ The use of artificial symbol systems

Artificial symbol systems used in the design process may be for instance natural language, geometrical sketches, or topology diagrams. These symbol systems are used both for aiding the design process per se, and for recording and communicating design decisions.


Size & complexit y of problem

Input : Goal st at ement sOutput : Art ifact

specificat ion

Temporal specificat ion of specificat ion and

delivery

Delayed/limit ed feedback from t he

world

Independent funct ioning of art ifact

Cost of act ion

No right or wrong answers - only bet t er

or worse

Many degrees of freedom in design

problem st at ement

Solut ion decomposit ion int o leaky modules

Abst ract ion hierarchies

LCMCS & Nest ed evaluat ion loops

Ext ensive performance modelling

Personalized evaluat ion funct ion and st opping

rules

Ext ensive problem st ruct uring

Making and propagat ion of commit ment s

Use of art ificial symbol syst em

Design TaskEnvironment

Design Problem Space

Figure 3–3: The design task environment and design problem space for a general design problem, adopted from [Goel and Pirolli 1989]


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

Problem space created by human designer

Problem space created by computer-based design tool

Problem intuitively decomposed into perceivable sub-problems, limited in size by the capability of the short term memory6

Because of the computer’s ability to retain large and complex problems in memory, a decomposition of the problem is usually not necessary

Continuous migration between many different abstraction hierarchies

Often only a single abstraction level given by a fixed set of design variables

Opportunistic exploitation of whatever methods are appropriate and available (see Section 3.3.7)

Methods to be used usually need to be anticipated at compilation time

It is obvious that if the mismatch between the two problem spaces is significant, it will impede the efficiency and utility of the design tool. Thus, in the course of devising methods for supporting the design problem-solving process, which is the goal of this thesis, a thorough understanding of the relevant problem space is necessary. This will be the main subject of Chapter 3, where I will look into the task environment and corresponding problem space for ship design, based on the above presented scheme of Goel & Pirolli. From this, a concept exploration model for

6 This capacity has been estimated to be about seven “chunks” [Simon, 1982, p. 80]. A chunk is a

maximal structure that can be recognized as one single item. E.g. ‘PGH’ consist of three memory chunks, while ‘LCB’ only one (by a naval architect)


preliminary ship design will be proposed in Chapter 5. The content of this model will to a large degree inherit from existing, prescriptive design models. Thus, in the following section I will describe some of the more important of these.

3.3 Prescriptive Design Models A “model”7 can be defined as a closed abstraction of a limited part of the world, for the purpose of explaining and understanding a particular phenomena. Often models aim at capturing only one specific aspect of this phenomena. Thus, we may operate on several models concurrently, without having each model competing against the others with respect to explaining the phenomena as such.

To a large extent, this is the situation in design. Design is a multi-faceted activity, and, at least for now, the design community has not converged towards one single, integrating design model capable of explaining all aspect of design. There have been several design frameworks proposed, aimed at serving an integrating role between the different design models. However, as will be discussed later in this thesis, there are no neutral representations − the way we choose to represent both the design object and the design process will necessarily presuppose a particular model. For instance, if we choose a representation as rules, it is difficult to use traditional numerical algorithms, and if we choose a representation consisting of simple attribute-value pairs, the application of first-order predicate logic is impossible.

For the sake of the discussion here, I have chosen to group the different design models into five main categories, given as:

1. Design as a systematic decomposition and synthesis

2. Design as a sequential, iterative process

3. Design as optimisation

4. Design as a creative activity

5. Knowledge-based design and artificial intelligence approaches

These five categories should neither be regarded as mutually exclusive, nor should they be viewed as variants over a single dimension categorisation. The division is

7 model (…) 2. A preliminary pattern serving as the plan from which an item not yet constructed

will be produced. 3. A tentative description of a system or theory that accounts for all of its known properties. (…) [American Heritage Dictionary, 1991]


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.

Funct ionEnergyMaterialSignals

EnergyMaterialSignals

Figure 3–4: In the VDI model, the basic function in all technical systems involves the conversion of energy, material, and/or signals [Pahl and Beitz 1984, p. 23]

The VDI model offers a problem oriented design strategy, where the emphasis is placed on a detailed problem analysis and a structured procedure to identify a solution. The first step is to identify the main function of the design object from the problem description. The main function is then broken down into a hierarchy of sub-function. All functions are seen as a conversion of energy, material, and/or signal (information), as illustrated in Figure 3–4. The transformation from a hierarchy of function to a hierarchy of solution elements is by means of design catalogues, relating elementary functions with alternative physical effect solutions. These solutions are then synthesised into a complete design, and further improved in the embodiment design phase.

What makes the VDI model interesting is the focus on a systematic approach to design, offering relatively detailed procedures for the design engineer to follow. In [Miles, 1994] the VDI-model is suggested as an epitome of the general approach to design in German-speaking countries, as opposed to a focus on design analysis and numerical techniques in the English-speaking world.

8 Guideline VDI 2222 (‘The design of technical products’)


Figure 3–5: Design catalogue linking elementary functions with alternative solution principles, from Beitz [Pahl, 1984 , p. 145]

3.3.2 Design as an iterative, sequential process

The most common way to conceptualise the ship design process is by a spiral model, illustrated in Figure 3–6. It is a descriptive model that captures the sequential and iter-ative nature of practical ship design, both as the different aspects of the solutions are calculated and checked, and as the process changes from broad investigation in the beginning towards detailed design at the centre of the spiral.

Andrews [Andrews 1981] have added time as an extra dimension to the spiral. Here, the design spirals down the surface of a conical solid, as illustrated in Figure 3–7, portraying the many constraints on a designer as a fundamental part of the process.


Figure 3–6: The ship design spiral capturing the sequential and iterative nature of practical ship design

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

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


Figure 3–7: An extension of the spiral, adding time as an extra dimension, from [Andrews 1981]

The sequential, iterative design process, as captured by the spiral model, can be captured in a task structure given by “DESIGN-EVALUATE-REDESIGN”, shown in Figure 3–8. Using the basic inference processes described earlier in this chapter, the

three tasks can briefly be described as:

DESIGN

EVALUATE

REDESIGN

Figure 3–8: The top-level process elements in a

sequential, iterative design process

DESIGN: Propose a potential solution to the design problem, either based on syntactic generation, on a previous solution, or on general domain knowledge and experience

D = τ4(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


instance, if the proposed solution have been found unsatisfactory, there is usually limited feedback on how (e.g. which variables, what direction, what stepsize) the design should be changed in order to improve the solution. This relies to a large extent on the designers expertise and experience.

A drawback that has been pointed out is that this model typically lock the designer to his/her first assumption [Levander 1991]. This first assumption is often an existing ship, perhaps slightly modified to account for differences in the functional requirements, or a starting point within the mainstream of existing designs that is based on empirical formulas. Since each iteration tend to be relatively time-consuming, there is a tendency that only a limited part of the potential design space around the first assumption is explored. This observation is also supported by a protocol study of mechanical engineers by Ullman and Dietrich, referred in [Finger, 1989], concluding that designers pursue a single design concept, and that they will patch and repair their original idea rather than generate alternatives

One argument in favour of this "basis ship" approach, based on a (minor) modification of an existing solution, is that the continuous development into specialised ship types during the last century has resulted in ship types close to an "optimum" design. Hence, a single point initial assumption based on an existing ship will be a good starting point.

While this might be true for a limited time in certain segments of the market, the statement has not necessarily general validity. Technical progress, e.g. new materials, new production methods, more efficient propulsion systems, together with an ever changing environment for shipping activities in terms of stricter regulations, new markets, and varying market conditions will always call for new solutions. Hence, the assumption that an “optimal” solution will be found by minor adjustment of an existing one can prove costly. Rather, it is desirable that the design problem is kept open in the initial stages, by taking a larger set of possible designs into consideration.

3.3.3 Modelling preliminary ship design as a mathematical optimisation problem

Generally, design can be defined as the production of a description of an artefact that is believed to satisfy a given set of functional requirements and constraints − that is, a feasible design solution. However, feasibility is only a necessary condition for the final design − sufficient conditions usually include that the design solution is preferable to other solutions by some means.

Thus, the iterative, sequential process as in the spiral approach represent an optimisation process in the sense that we continually seek improved solutions through


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:

minimizesubject to

f

n

( ),( )( )

xh x 0g x 0

x

=≤

∈ℵ ⊆ ℜ

Here, f is an objective function to be minimised, corresponding to the design goals. f may express the preference structure of a single design goal, or it may be a compound function representing multiple design goals. h and g are functional constraints, and ℵ is the set constraint defined over an n-dimensional design space ℜn. In this form, the design problem is a well-formulated problem, subject to solution by for instance mathematical programming and operational research techniques.

Expressed in terms of the elementary inference processes discussed in the previous section, optimisation can be modelled as a single deductive step directly from the design problem formulation, as given by the transformation τ2 (Equation 2.2). This can be illustrated by the following example:

Ki1: ∀x DW(x) ∧ V(x) ⇒ TotalCost(x) = f(DW(x), V(x)) Ki2: ∀x DW(x) ∧ V(x) ⇒ AnnualCargoCapacity(x) = g(DW(x), V(x)) … I1: minimise TotalCost(ShipA) I2: AnnualCargoCapacity(ShipA) > minAnnualCapacity …

D: DW(ShipA) = dw ∧ V(ShipA) = v

Here, design knowledge (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


“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.


For real-world, complex design problems, the distance to this idealised mathematical representation is often substantial. A vivid description of this is given in [Goldberg 1989]:

“Theorists interested in optimisation have been too willing to accept the legacy of the great eighteenth and nineteenth-century mathe-maticians who painted a clean world of quadratic objective functions, ideal constraints, and ever present derivatives. The real world of search is fraught with discontinuities and vast multimodal, noisy search spaces.”

Is this a valid description for the search space in preliminary ship design too? On the basis of studies on the use of mathematical optimisation in preliminary ship design (e.g. [Folkers 1973, Nowacki, et al. 1970, p. 367, Lyon 1982]), the answer seems to be no. In these studies the design problem is modelled by the ship main characteristics, a set of empirical relations, and an objective function usually minimising either the steel weight or required freight rate, giving in most cases a relatively well-behaved, convex search space.

However, extending this to assume that these search space characteristics can be found for an arbitrary formulation of the preliminary ship design problem needs caution. First, the functional relationship f, relating the design vector x to the design goals, is not well understood in mathematical terms for multi-criteria design problems. Different methods exist to bring the different criteria together. Examples are the use of weighted value/utility functions [Keeney, 1976], the use of a ranking of the design goals in a pre-emptive value function [Smith 1992], or a hierarchical evaluation process [Sen and Yang 1994]. These methods may cause a non-convex compound objective function, even if the single goals themselves are convex. One example is in the design of a frigate using constraint violation as a criteria, showing a highly multi-modal response function [Smith 1992, p. 168]. It is also a problem when the optimisation algorithm relies on externally linked procedures, as for instance in the ship design system NAPA [Priha 1989], or ‘Engineous’ [Ashley 1992]. In these cases it might be difficult to determine whether the requirements for using a specific optimisation algorithm is satisfied.

Another problem with using mathematical optimisation is the relatively high level of expertise that is needed both to formulate a well-behaved problem, and to verify that the identified solution is in fact a global optimum within the search space.

To some degree the difficulties of using mathematical optimisation algorithms can be hidden from the practising designer by a proper user interface, letting the designer only change a limited set of design variables and parameters within a range known to result in a well-behaved problem. However, this has the draw-back of limiting the


flexibility and possibility to adapt the problem-solving process to the specific characteristics of the problem. In other words, the possibility of having what is commonly termed a “meta-design”12 process will be limited.

2. The creation of design “black boxes”

Another problem with hiding the inner structure of the optimisation algorithm is the creation of so-called “black-boxes”. A “black-box” is a part of the problem-solving process in which the designer get little or no insight, and can do nothing more than put in his/hers good faith in the output. Since the knowledge pertinent to preliminary ship design is to large degree based on empirical relations and experience where a personal trust in the calculations are important, such black-boxes are undesirable. They also leave little room for letting the designer use his/hers experience to improve the solution. As said by [Folkers 1973]:

"There is actually little success in interesting conventional ship-builders (in using automated optimisation packages) at this early stage since they will be sceptical about such undertakings which do not take into account the various intuitive considerations used in these complex problems."

From the discussion above, there seems to be a “mismatch” between the actual design problem, as seen from the practising designers point-of-view, and the idealised repre-sentation of the problem required by the optimisation-based design tool. In recent years we have seen some interesting approaches to bridge this mismatch, aiding the designer to transform a real-world, unstructured problem into the format required by mathematical optimisation. Two particular approaches are the “Decisions Support Problem Technique” (DSPT) by Mistree, Smith, et al. [Mistree, et al. 1990, Smith 1992], and a knowledge-based interface to optimisation by Balachandran [Balachandran 1993].

12 “Meta-design” means the design of the design process, that is, the modeling of the design process

with respect to the characteristics of the problem. The possiblity of explicitly suporting meta-design will be further discussed in Chapter 5 in the context of concept exploration models


Template

Select ionDSP

Variables

CompromiseDSP

Constraints

Figure 3–9: Representational scheme in decision-based design

In Decision-Based Design (DBD) the design process is broken up into a meta-design phase and a computer-based design phase [Smith, 1992]. In the meta-design phase the major decisions to be made are identified, and modelled into a hierarchy. In the following computer-based design phase each of the decisions are transformed into a corresponding Decision Support Problem, which can be formulated either as a com-promise or as a selection support problem (or a combination of the two).

The transition to a Decision Support Problem formulation is supported by a set of keywords that are used to structure each decision problem to a form that is amenable to solution. For the compromise support problem these keywords are given by [Mistree, et al. 1991]:

Given information

Find the value of the system variables

Satisfy system constraints, goals, and bounds

Minimise deviation 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


can a correct and consistent mathematical be ensured? Bras gives an answer to this by presenting a “Design Guidance System” [Bras 1992]. Here, the transition from a real-world problem to solvable computer code is achieved by the following steps:

1. The first step is to extract a natural language formulation, called a story, from the real world problem.

2. This story is analysed using a parser utility that identifies relevant problem entities. These entities are grouped into a problem statement by the parser.

3. The problem statements are grouped with respect to the keywords of the appropriate support problem (e.g. given-find-satisfy-minimise for the compromise decision)

4. From the keyword description a process network is developed which will give or several possible paths towards a solution

Box 3-3 - On optimisation and Design"( [Crane, et al. 1980])

One needs to consider first the primary purpose in using optimisation methods for real applications. The most obvious purpose is to find the minimum of a well defined constrained function accurately and efficiently. This is appropriate for the designer of an optimisation subroutine. It is, however, unduly restrictive where real problems are to be solved. Few real problems are so simple or so well formulated and understood that they can be solved simply by minimising a simple function over n variables, even when one allows the solution to be constrained. In an application environment, then, the primary purpose in using optimisation methods is to enhance one's understanding of the real problem that is being modelled, not to compute optimal answers. Viewed in this context, a mathematical optimisation program is a sophisticated tool to be used in an application program for the solution of a real problem. Insight gained by using optimisation methods with a particular mathematical model embedded in an application program will often lead to a revision of the model that better approximates the real problem under consideration. Ultimately, the precise minimum may be of interest."

5. In the last step this process network is converted into computer code that can be directly interpreted by the numerical solver.

Fundamental to Decision-Based Design is the observation that design problems do not come into being as well-formulated, numerically solvable problems. As said by [Coyne, et al. 1990, p. 19]:

"Optimisation has failed to influence the field of design greatly, in part because it does not address the question of how to arrive at such well packaged formulations”

14 In the DSPT, the numerical solver is called DSIDES, based on an adaptive linear search

algorithm [Mistree, 1992]


A valuable contribution from Decision-Based Design is how the consequences of this observation is handled, by providing a framework for assisting the designer in formulating a solvable problem. With respect to applying mathematical optimisation techniques in preliminary ship design, this is a critical issue.

What can be concluded from this with respect to the goals set out for this thesis? First, the fact remains that optimisation is indeed a powerful approach to design. Given that we are able to formulate our design problem in strict mathematical terms, and that this formulation is sufficiently well behaved, optimisation provide the most effective strategy for identifying superior, or “optimal”, solutions within the given design space. However, taking into consideration the typical characteristics of a pre-liminary ship design problem, such as incomplete “soft” knowledge and a high degree of uncertainty, traditional optimisation fails too provide a robust enough base on which to develop a general framework for decision support in preliminary ship design. Rather, the strengths of optimisation is better exploited in solving closed sub-problems of the overall design task − a conclusion that will be further supported in Chapter 6 concerning the structure of the concept exploration model.

3.3.4 Design as a creative activity: Abductive generation in original design

In both the previous two generic models of design − the design “spiral” and optimisation − the basic inference process is based on operations upon knowledge already existing within the design system. In real-world design situations − and preliminary ship design in particular − this is not always the case. Often a specific design problem requires that the designer is able to look beyond the limits of the existing knowledge base, or to rearrange existing knowledge, in order to find a satisficing solution. Designers mastering this skill are often described as creative. The same description may apply to a design system actively supporting such features.

To what degree creativity is required is dependent on the character of the design problem. Three main types can be identified, termed original, adaptive and variant 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]


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 VDI-method (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


beforehand, and mutually dependent − you don’t 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 computer’s and the human designer’s internal representation of the problem.

3.3.5 Knowledge-Based design models

A more recently developed group of design methods and models are those that relate to knowledge-based systems (KBS) and artificial intelligence (AI). There are several examples of the use of knowledge-based systems in design. General design [Coyne, et al. 1990, Hees 1992, Kamal, et al. 1987, Miles and Moore 1994, Han, et al. 1994], in ship design [Nicklaus, et al. 1988, Stearns, et al. 1991]

The common denominator here is the way design knowledge is represented and used. In most conventional computer programs the knowledge is represented in the form of procedural algorithms. The problem with this representation is that it holds certain anticipations on how this knowledge will be used, and that factual knowledge is only implicitly represented within the procedures of the program.


Contrary to this, the general rule in knowledge-based system is a declarative representation of knowledge, where all factual knowledge is given a formal and explicit existence. The representation should, to the extent possible, be independent of the way this knowledge is applied and processed. The use of KBS in design may have several advantages, which is summarised in the following points:

❏ The emphasis on a declarative rather than a procedural representation makes the design knowledge comprehensible both to the human designer and the computer. This makes it easier to continuously update and extend the knowledge base.

❏ The independence between the design knowledge itself and the methods that operates upon it make knowledge-based systems robust, in the sense that all necessary knowledge for solving a particular problem need not to be anticipated beforehand, but can rely on a more general domain knowledge-base. This makes knowledge-based systems better at handling ill-defined problems, and problems at the limits of the intended scope of the system.

According to [Miles and Moore 1994], the ideal knowledge-based system should be able to

❏ Solve the problem ❏ Explain its reasoning ❏ Learn from completed cases ❏ Restructure its knowledge ❏ Break rules (when and wherever necessary) ❏ Determine the relevance of acquired knowledge ❏ Degrade gracefully upon reaching the limits of the domain

With today’s technology it is impossible to achieve all these goals. Most current implementation in practical use are able to satisfy only the first two of these features. However, new technologies are emerging, focusing on the unresolved features of the above list. Some of these technologies will be further discussed at the end of this chapter.

3.3.6 DESIGNER: A Focus on the Design Object

One example of the practical use of knowledge-based systems technology is the DESIGNER program developed by MacCallum et al. [MacCallum 1982, MacCallum and Martins 1985, MacCallum and Duffy 1987]. The DESIGNER is an expert system, aimed at exploiting the numerical knowledge embedded in design variables and relationships. Thus, the emphasis has been on developing an efficient representation of the design object as a basis for improving the design process. In DESIGNER, the


design process is driven forward by operations upon design variables in a directed network, as illustrated in Figure 3–10.

The knowledge in DESIGNER is built upon three basic representational concepts: Design Characteristics, Relations, and Influences. The content of each of these are illustrated in a frame representation in Figure 3–11. The primary component of the Characteristic frame is an attribute-value pair as it is found in most numerically based design tools, but is different in two important respects: First, it has an explicit repre-sentation independently from the processes that operates upon it, and second, it is not defined as a part of an assembly of attribute-value pairs as is the case in design programs requiring a pre-determined input vector of design variables. In addition to the attribute-value pair, the Characteristic frame also contain slots for an explanation of the characteristic, the unit of measurement, the accuracy of the given value, and two collection objects containing relationships and influences, respectively.

Block coefficient Lengt h

Machineryweight

Deadweight

St eelweigt h

Draught

Beam

Dept h

Out fit weight

Power

Speed

Light weight

Displacement

Figure 3–10: A directed network representing the design object in DESIGNER [MacCallum, 1987]


Accuracy

Name

Explanat ion

Value

Influences

Relat ionships

Unit s

Charact erist ic

St rengt h

NextPost -condit ions

Expression

Reliabilit y

Pre-condit ions

Next

Charact erist ic frame

Influence frame

Relat ion frame

Figure 3–11: The key representational concepts in DESIGNER: The Characteristic, containing a collection of relationships and influences on other characteristics

The Relation links a particular characteristic to other by means of a numerical expression. This expression may represent deep, “first-principle” knowledge (e.g. DISPL = LPP B T CB), or more shallow knowledge such as numerical heuristics and empirical relations (e.g. LPP = k 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 meta-design process (the planning of the design process) and the design process are seamlessly integrated.


❏ The representation of design knowledge as single, independent entities (frames, objects), that can be easily reused in different network structures for various design problem.

A more detailed evaluation of a numerical network representation will be given in Chapter 6, both discussing some problems with respect to the practical design problems, and what particular aspects of this representation that is useful for a ship design concept exploration model.

As will become evident later in this thesis, I agree with the basic hypothesis about decision support in design that is implicitly assumed by the DESIGNER: It is the basic representation of the design domain concepts that lay the foundation for what kind of knowledge it is possible to bring into the computer-based design process, and how this knowledge can be operated upon by both the computer and the human designer. This is different from most other design tools, where the necessary functionality for a particular design domain is anticipated beforehand, and implemented as a set of services where the underlying representation is as a set of algorithmic procedures. The same focus on representation will also be given in this thesis, when the structure of the concept exploration model is discussed in detail.

3.3.7 Developing a task-structure of design - an integrating approach

The numerical network model in the DESIGNER exemplified a flexible and method-independent design approach by providing a suitable representation of the design object. The same features of flexibility and method independence is sought by Chandrasekaran. But instead of focusing on the representation, these features are pursued by developing a task-structure of design [Chandrasekaran 1989]. The key conclusion here is that “design as a general problem solving activity is solved not by one method or technique but by an opportunistic exploitation of whatever methods are available. Thus, in principle, very different methods and knowledge can be brought into play in as flexible a way as possible.”

The task-structure developed by Chandrasekaran is in many respects a parallel to the German VDI-school. But instead of focusing on the design object by deriving a hierarchical structure of elementary functions and elementary solutions, the task structure of Chandrasekaran aims at structuring the overall design task into primitive subtasks. For each of these subtasks we need to investigate what methods are available, and the corresponding knowledge and inference requirements the methods have.

A division is made between design as a task and design as a process. The former constitutes the act of combining a set of primitive objects into an assembly that


satisfies a specified set of desired properties, while the latter centres on the problem-solving process itself, i.e. design as search in a state space, design as a mapping from a performance space to a design space, or design as an “intuitive leap” where the design solution almost instantaneously comes into the mind of the designer. This is in compliance with the elementary inference processes discussed earlier in this chapter.

In performing the design task a set of assumptions is made about the domain. First, the availability of a set of primitive components is assumed. In the ship design domain this could for instance be design parameters (Lpp, B, Cb, DW), parts (propeller, machinery components, structural parts) or system descriptions. This corresponds to the design vocabulary. Second, there exist a set of primitive relations between the components. Examples are relations between the hull design parameters (Displacement = Lpp B T Cb) and part assemblies. This corresponds to syntactic knowledge.

To solve this task, a number of different design processes are used, dependent on the characteristics of the specific sub-task, the design domain, and the preferences of the designer. According to Chandrasekaran, the reason for this difference is mainly the availability of knowledge. Hence, a prerequisite for prescribing design methods for a particular domain (for instance by developing computer-based design tools) is a thorough survey of the design knowledge available in this domain. This is also in compliance with my previous discussion about different design models: The appropriateness of a particular model, such as opti-misation, design-evaluate-redesign, innovative ab-duction, or knowledge-based systems, is dependent on the character of the available knowledge.

PROPOSE

CRITIQUE

MODIFY

Figure 3–12: The generic

design process proposed by [Chandrasekaran 1989]

Chandrasekaran proposes a generic design model consisting of three basic steps − propose, critique and modify − as illustrated in Figure 3–12. The Propose step generates a potential design solution, for instance by design decomposition/recomposition, by retrieval and adaptation of previous design cases, or by constraint satisfaction methods.

The implication for research on tools to support software design will be aided by a whole range of tools. When a tool will be helpful will depend on the level of the designers experience with the object being designed and the domain being designed in. For example, when the designer has designed an object previously he will need tools that help retrieve the previous designs. When a designer has experience with


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].


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.


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


elements). Exploitation focus on a local region, and tries to breed individuals with high fitness within this region.

The basic genetic algorithm consist of three fundamental processes:

❏ Reproduction, where selected individuals of one generation are copied to the next generation. The individuals to be reproduced are selected randomly, but with a bias towards those best fitted, as given by the value of the objective function ("survival of the fittest").

❏ Crossover, where individuals are mated randomly. The mating process produces individuals with new characteristics (as opposed to the reproduction process, where the characteristics of the individuals are copied to individuals in the next generation) involving the exchange of information in the form of building blocks.

❏ Mutation, which plays only a secondary role in the basic genetic algorithm. Mutation can be useful to produce valuable building blocks which did not exist in the population from the start, or reproduce valuable building blocks lost in the reproduction process.

Several general features of genetic algorithms are interesting in the context of preliminary ship design.

First, by using genetic algorithms the designer will work on a population of possible design solution. This is the opposite of both typical optimisation-based methods and the traditional design spiral approach, where the focus is on the improvement of one solution This will help maintain the openness of the design problem, and reduce the number of design commitments that needs to be made early when design knowledge is limited.

Also, with the proper adjustment the genetic algorithm will converge towards several fitted design solution, thus helping to preserve diversity for design problems with multi-peaked objective functions. To some extent, this can be compared to concurrently solving several traditional optimisation problems locating local optima from different starting points.

Both the crossover and mutation operator support an element of creativity by the creation of new solutions, either by the combination of features from the parent solutions as in the crossover process, or by random creation as in the mutation process.

The genetic algorithms seems to have the ability to support a high degree of man-computer interaction through the design process, thus allowing for the designer to apply his/her knowledge and experience in guiding the process towards improved


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


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 19 ESPRIT Project No. 2010 20 ESPRIT Project No. 6041

"Preliminary design by its very nature is perhaps the most subjective aspect of naval architecture, relying as it does on the accumulated experience and data of each practitioner" [Watson and Gilfillan 1976]

4

The Task Environment and Problem Space of

Preliminary Ship Design

The purpose of this chapter is to identify characteristics of the preliminary ship design problem that distinguish it from both general design and general problems solving situations. As a scheme I will use the concepts “design task environment” and “design problem space” that were presented in Chapter 2, denoting the characteristics of the design problem’s external and internal structure, respectively.

To provide a reference situation for the discussion, imagine for a moment an ideal world. Here, a preliminary ship design situation might be described as follows:

❏ We have perfect knowledge about all relevant aspects of the external design environment, both the current state and all future states.

❏ We also have ideal knowledge about ourselves. This implies that we are able to explicitly state a value function that maps our true preferences between any (design) alternative.

❏ Third, we have a perfect model of the ship to be designed, that is, we have a model that expresses all features influencing the value function, and accurately maps these features into the preference structure in the design performance space.

❏ And fourth, we have available unlimited computer capacity.

Given the situation described above, we can find a true optimal design solution by brute force − simply by parsing all possible design points, calculating the performance

52 Chapter 4 - The PSD Problem Space and Task Environment

and the corresponding value of each, and at the end select the one with the highest value.

An alternative to the last point is a situation where the model of the “ship-to-be-designed” is completely described by a set of mathematical relations that satisfies requirements such as continuity, differentiability, and convexity within the actual design space. Here, the design problem can be captured in the terms of a classical, mathematical optimisation problem, as it was presented in Chapter 2.

The two situations described above are illustrated in Figure 4–1, using the conceptual scheme of a “design task environment” and a “design problem space”. Given that the underlying assumptions are true, we are able to locate “optimum designs”21.

Perfect knowledge of preference st ruct ure

Perfect model of t he ship t o be designed

Exact mapping bet ween t he ship model and t he preference st ruct ure

Perfect knowledge about t he ext ernal

environment

Unlimit ed comput er capacit y Perfect model of t he

design problem

Classical mat hemat ical opt imisat ion

"True" opt imum design

Correct weight ing bet ween mult iple goals

Design Task Environment

Design Problem Space

Specific propert ies of t he design space

Search met hods

Figure 4–1: Design problem space and task environment for a ship design situation

with perfect knowledge

However, when it comes to designing complex, real-world systems − like ships − the “perfect knowledge” assumption is not valid. Design problems in general, and ship design in particular, are commonly classified as ill-defined problems, where "the designer attempts to define and evaluate an approximate and unreliable design model, within a vague but likely solution space, in order to satisfy uncertain design goals" [Duffy and MacCallum 1989]. It is these “real-world” characteristics of the design

Chapter 4 - The PSD Problem Space and Task Environment 53

problem and the design environment that should be decisive in the choice of a problem-solving paradigm, and thus is the focus of this chapter.

4.1 Preliminary Ship Design Task Environment The task environment refers to the external characteristics of the design problem. From the designer’s perspective, these characteristics represent a set of constraints that need to be taken into consideration when choosing a problem solving strategy for a particular design task. For the prototypical preliminary ship design situation, propose the following invariant characteristics:

❏ Complex mapping between form and function ❏ Multi-dimensional, partly non-monetary performance evaluation ❏ High cost of error ❏ Shallow knowledge structure ❏ Strong domain tradition ❏ Strict time and resource constraints on the design process ❏ Predominantly “one-of-a-kind” and “engineered-to-order” solutions

This is not to say that all ship design problem situations in all details have a task environment corresponding to the above characteristics. Rather, it represent a prototypical case − a case which most designers would recognise as typical and to be common for most ship design situations. In the following, a more detailed discussion of each characteristic will be given.

4.1.1 Complex mapping between form and function

The input to the design process is a set of functional requirements and goals, for instance in the form of an outline specification based on the customer’s preferences and requirements, or compiled from the results of a market research project. The output from the design process is a description of form, given as a specification of the ship to be built. Thus, at the top level, the design process may be viewed as a mapping following the pattern

(function) → (form)

21 A parallel to this “perfect knowledge design situation” is the dream attributed to Leibniz of “a

universal algebra by which all knowledge, including moral and metaphysical truths, can someday be brought within a single deductive system” [Genesereth, 1988]


corresponding to the mapping from a semantic “performance space” to a syntactic “description space” as was illustrated in Figure 2-1. However, on an operational level in most computer-based design systems the mapping is the opposite way, by (deductively) determining the ship performance on the basis of a given description in the design analysis phase. Here, the mapping follows the pattern

(form) → (function).

This mapping between the two main representations of the ship − traditionally termed design analysis − may be both complex and computationally intensive. Representative examples of such mappings are:

(hull form & propeller) → (required SHP)

(hull form) → (seakeeping behaviour)

(hull form, propeller, machinery) → (ship speed)

(all ship systems) → (total cost)

Such a complex mapping between form and function is not unique for ship design, although this characteristic is more profound here than in most other design domains. There are several possible explanations for this, the most probable being the “nature” of the ship as a self-contained, highly integrated structure, the complex underlying physical phenomena involved in the movement of a solid body at the boundary be-tween two fluids, and the intrinsic uncertainty with respect to the present and future state of the outer environment in which the ship operates (see Figure 4–2). In the following, I will discuss each of these features in more detail.

Complex mapping between form and

funct ion

Self-contained, highly integrated system

Uncertainty wrt the state of the outer

environment

Interact ion inner-outer

environment: Movement of a solid

Figure 4–2: Ship design is characterised by a complex mapping between form and function

The ship as a self-contained, highly integrated structure

From an engineering point-of-view, the ship is a complete, self-contained structure. All functions of the ship is provided by sub-systems within the boundaries of the ship


system itself. Examples are power supply, propulsion, fresh water, and cargo support. This is contrary to many other engineering systems where many of these functions are provided by external agents.

This results in a tight coupling between ship sub-systems and substantial secondary and higher order effects on the performance as a consequence of design changes. Such effects are particularly evident upon changes in weights and volumes, since each alteration here in most cases affects the ship’s displacement 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 (FR’s)

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 FR’s 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 Normand’s Number, after J. A. Normand who published the method in 1885 23 To avoid secondary effects in a decoupled design requires the FR’s to be satisfied in the proper

sequence. A third category is uncoupled designs where the FR’s are completely independent. In uncoupled designs the sequence of the decisions does not matter.


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.


waves, wind, and currents. All these variations need to be taken into consideration when the overall performance of the vessel is determined.

The external environment of the ship also comprises the social and economic factors. As a consequence of an international and very competitive market for the services offered by ships, these factors typically show more variation and uncertainty here than for most other engineering structures. This adds to the difficulty of assessing important performance characteristics. Areas of uncertainty are e.g. long-term cost predictions, freight rates, fuel prices, cargo supply/demand, and future transport capacity, making estimations of life-cycle costs, “optimal” speed, “optimal” cargo capacity, difficult.

All these three characteristics − the integrated structure, the underlying physical phenomena, and the external environment − contributes to the complex form-to-function mapping found in preliminary ship design. There is a continuous development in ship analysis methods, improving the accuracy in predicting the performance of the ship. Still, this development is only capable of removing the apparent complexity of the mapping, by transforming it into a representation that is solvable by an appropriate algorithm. As said by [Simon 1973 p. 150]:

“In general, the problems presented to problem-solvers by the world are best regarded as ill-structured problems. They become well-structured problems only in the process of being prepared for the problem-solvers. It is not exaggerating much to say that there are no well-structured problems, only ill-structured ones that are formalised for problem-solvers”

4.1.2 Multi-dimensional performance evaluation

On a high level of abstraction the evaluation of a merchant ship’s overall performance can be simplified to calculating the life-cycle economic achievement. However, there are operational limitations to such a “Maximise profit!” approach. Though factors that directly influence the profitability of the vessel are important, such as cargo capacity, building cost, and fuel consumption, there are in most practical design situations other factors to be taken into consideration that are difficult to transform into monetary terms. Representative examples are safety issues, environmental impact, and technical performances such as seakeeping and stability.

The consequence is that the total performance of a specific design need to be evaluated along several dimensions concurrently, contrary to a single dimension when for instance only “maximise profit” or “minimise required freight rate” are used. Though substantial research has been put into developing efficient and rational


methods for decision-making in multi-dimensional situations, the incorporation of such methods in commercially available ship design tools has so far been limited. Later in the chapter I will discuss how this influences the design problem space in terms of a “satisficing” rather than “optimising” approach to design, and in terms of relying on personalised evaluation and stopping rules to determine when a satisficing solution has been achieved.

Box 4-1: Example of non-economic design objective formulation in a design specification, from [Statoil 1991]:

"On a competitive basis, the Charterer will give preference to vessels offering the best design and operational characteristics for the following high-lighted items:

• Environmental protection

• Minimum cargo retention in cargo tanks and lines

• Fuel economy in transit and for discharging

• Efficiency in harbours and at terminals

• Reliability in service” 4.1.3 High cost of error

As mentioned in Chapter 1, the decisions made in the early stages of the ship design process have a substantial influence on the total life cycle costs of the ship. Taking into consideration the magnitude of these life cycle costs, it follows that making the wrong decisions in the preliminary design stage may have considerable consequences.

The outcome of preliminary design is a contract specification (see Figure 1-2), that gives a numerical description of the various performances required by the vessel. In practice, however, the exact fulfilment of the performance requirements is difficult, and because of this, the contract usually allow certain deviations from the specified performance. Such allowable deviations are called margins.

Deviations from the specified performances may be grouped into three categories [Erichsen and Selvig 1991]:

❏ Deviations within the contractually agreed margins. These deviations will be accepted by the customer, and have thus no serious consequences for the shipyard.

❏ Deviations larger than the agreed margins, but still within limits acceptable provided the customer is compensated.

❏ Deviations of a magnitude that gives the customer the right to refuse to accept delivery.

Obviously, it is very important to avoid errors in the design process that result in deviations of a magnitude corresponding to the latter two of these categories, since it may lead to severe financial liabilities. As will be discussed later in this chapter, the


high cost of error has consequences for the design problem space in terms of extensive performance modelling and verification of the proposed design, and need to be taken into consideration when devising a model for supporting decision-making in preliminary ship design.

4.1.4 Shallow knowledge structure

Preliminary ship design, as with most other real-world engineering problems, is an open problem in the sense that the problem domain can not be completely described a single, closed theory, and hence, no unique “optimal” solution can be derived. Rather, the theory domain of ships is characterised by relying to a large extent on what is commonly termed “shallow knowledge”, such as empirical relation, rules-of-thumb, and previously built ships. A parallel characterisation is given by Mistree et al. [Mistree, et al. 1991], stating that in preliminary design the ratio of soft to hard information is high. Soft information is information based primarily on the designer’s judgement and experience, while hard information is essentially based on established scientific principles.

The character of the domain knowledge has a significant impact on the problem space. A general rule is that if the ratio of deep knowledge to shallow knowledge is high, we can rely more on traditional computational/numerical analysis in the design process. If this ratio is low, other means of analysis is required, such as heuristics, symbolic computation, rule-based systems, etc. Thus, in order to propose a problem-solving framework for a specific domain, a thorough understanding of the domain’s knowledge content is necessary. For preliminary ship design, the character of the domain knowledge will be further discussed in Chapter 4.

4.1.5 Strong domain tradition

The historical and organisational setting for the ship design activity is also influencing the design process, and is thus a part of the design task environment. According to [Johnsen and Ellingsen 1986] the organisational culture in shipping may be characterised as open, lean, informal, and flexible. The documentation attached to design and production is limited − for a typical ship this would be about 20-50 kg to satisfy government and class requirements. A comparable amount for a fixed installation in the North Sea would be about 30-50 tons. The main reason for this difference is that ship design builds on a long, historic tradition, where the involved parties, i.e. the yard, the consultants, the shipowner, the classification societies, have similar anticipations of the resulting design artefact.

Hence, where nothing else is specified, the designer can to a large extent rely on design practice. This is contrary to the design of for instance fixed oil platforms where


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 trade-off is difficult. As said in [Skipskonsulent 1991]:

"There is a perceived need for new, custom-made competitive design, but there is far too little time for either of the parties to develop it. The shipowner has his options badly reduced, and is forced to try to find a standard design that meets the bill as well as possible, and within the time limit available."

Because of reduced production times, some activities have been moved earlier relative to the design time line. Thus, some decisions that earlier were made on the basis of a detailed design description and/or production plans now need to be made on the basis of knowledge available after the preliminary design stages. This put further demand on the quality of design knowledge generated during the early stages.

4.1.7 Predominantly “one-of-a-kind” and “engineered-to-order” solutions

In the first post-war decades many shipyards built large series of a particular ship type. However, in the last twenty years, when the shipbuilding activity in general has been low, long series have been far less common [Erichsen 1994]. Though this situation may again be reversed by the present rise in shipbuilding activities, we may characterise shipbuilding as predominantly offering “one-of-a-kind” solutions. This also holds true on a relative scale when comparing with the design and production of other transport systems, such as cars and aeroplanes.

24 In [Langenberg, 1982], the time allowed for the submission of a tender is estimated to be about

three to five weeks


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.


4.2.1 Satisficing rather than optimising

At the beginning of this chapter I described an idealised design situation. Two scenarios were presented. The first assumed unlimited computer capacity, that allowed us to use exhaustive search to identify the optimum. The second scenario assumed that the design space satisfied a particular set of mathematical conditions. This opened up for the application of mathematical programming/operational research algorithms to identify a globally optimal solution to the design problem.

For practical ship design problems, neither of these approaches are applicable. One problem is that it is difficult to completely formalise the design knowledge required to locate the true optimum. Attempts to formalisation will inevitably discard important characteristics of the real-world situation, or enforce the quantification of qualitative aspects, leading to erroneous results. This situation is parallel to every modeling situation. The purpose of a model is to act as an abstraction, implying that we must choose a sub-set of aspects of the object or situation to bring into the model. This sub-set will always tend towards what is easy to formalise.

The situation is captured in the following citation, from [Goldberg 1989]:

“Theorists interested in optimization have been too willing to accept the legacy of the great eighteenth and nineteenth-century mathematicians who painted a clean world of quadratic objective functions, ideal constraints, and ever present derivatives. The real world of search is fraught with discontinuities and vast multimodal, noisy search spaces.”

Even if we assume that it is possible to derive a formal model taking into account all relevant aspects of the design problem, there would still be limitations to identifying “optimal” solutions. Applying the first solution strategy − that is, mathematical pro-gramming/operational research − we would need to reformulate the model again to fit into a scheme of variables, parameters, constraints, and objectives. Recalling the discussion in Section 4.1.1 about the complexity of the preliminary ship design problem, this would entail a further abstraction of the problem.

Using instead a simpler search strategy, it may be possible to utilise a fully formalised model. The real-world limitation in this case would be the dimensionality of the model with respect to the capacity of the computer. Regardless of the development in computer technology, there will always be problems which can not be solved by “brute force” alone within acceptable time. A somewhat exotic restriction is Bremmermann’s limit, which constrains the number of independent variables in a fac-torial design to 270 on the basis of the mass of the Earth, the period of atomic vibration, and Heisenberg’s uncertainty principle [Suh 1990]. A more concrete


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.

Generalising on these two strategies, we have a choice between finding an exact solution to an approximate representation of the problem, or an approximate solution to an exact representation. Neither of these strategies alone lead to an optimal designs. This has lead to the term “satisficing”, first used by Herbert Simon in “The Sciences of the Artificial” [Simon 1982]. In Simon’s words a “satisficer” is “a person who accepts ‘good enough’ alternatives, not because he prefers less but because he has no choice.”


funct ion

Mult i-dimensional , part ly non-monetary

performance l t i

Shallow knowledge st ructure (high

soft /hard info. rat io)

Sat isficing rather than opt imizing

Task Environment Problem Space

Figure 4–3: "Satisficing rather than optimising" as an invariant of the Design

Problem Space

Concluding this, I claim that “satisficing rather than optimising” is an important in-variant of the preliminary ship design problem space. It is a consequence of some of the characteristics of the task environment discussed in the previous section − the inability to formalise the real-world problem, the complexity and dimensionality of the problem, and shallow knowledge structure of the domain. This is illustrated in Figure 4–3.

4.2.2 Personalised evaluation functions and stopping rules

Closely connected to the previous point about ship design as a “satisficing” activity is the lack of a well defined evaluation function and explicit criteria for terminating the design process.

In most computer-based preliminary ship design tools the process is oriented towards calculating the value of the individual functional performances. This may for instance be steel weight, resistance, seakeeping abilities, or building cost. However, taking into


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-to-function mapping. The major cognitive strategy to deal with this kind of complexity is through decomposition [Simon, 1969; Goel, 1989]. The design process is transformed into a series of independent steps, each performing a closed cycle of description, evaluation, and decision, but for a reduced number of variables. This aspect of the design problem space is also captured in the ship design spiral (see Figure 3–6), where the overall problem is decomposed into modules that are solved serially. The reduction in the number of problem dimensions to be processed concurrently that is

25 For instance, for the formulation of the optimisation problem as in Section 2.2.3, the necessary

conditions for optimality are the Karush-Kuhn-Tucker (KKT) conditions, given as: 1) h(x*) = 0, g(x*) ≤ 0, 2) ∇f* + λT∇h* + µT∇g* = 0T, λ ≠ 0, µ ≥ 0, µTg = 0, where x* corresponds to the optimal design solution


achieved by decomposition help to make the problem tractable for both the computer and the human designer.

The main difficulty with decomposing the problem is to maintain a sufficient degree of independence between the individual sub-problems. This is especially so in the ship design domain, because of the high degree of interaction between the different ship sub-systems (see Section 4.1.1). This has lead to the description “leaky modules”.

There are different ways of dealing with these “leakages”. Traditionally, the main strategy has been what is commonly termed “outbalancing”, as it is captured in the ship design spiral. In this approach a change in one of the modules initiates the recalculation of all other modules until a sufficient degree of consistency is re-established. To what extent this is a viable approach depends to some degree on the design task under consideration. For instance, the secondary effects of adding an independent weight in a VLCC design model are far less problematic than for a semisubmersible design model.

A second strategy is to seek a partitioning of the problem that keep the interactions between the modules as small as possible. This was the strategy of “axiomatic design” discussed in Section 4.1.1. A third alternative is to try to couple the different sub-problems by the explicit modelling of the interaction effects. An example of this is given in [Smith 1992], where the determination of the main characteristics of the hull and the propeller for a frigate are modelled as two separate decision problems, but with the interaction effects taken care of by the solver.

My main point here is that the complexity of the design problem will in most practical design situations require a decomposition strategy – and the choice of this strategy is important for the quality of the design result. Hence, when proposing a design model and a design paradigm, the support for an efficient decomposition strategy need to be taken into consideration.

4.2.4 Sequential iterative limited commitment mode design strategy

Every decision we take through the course of a design process will limit our design freedom. Hence, if it was possible, it would be advantageous to postpone all decisions until every aspects of the design solution can be taken into consideration, thus avoiding a sub-optimal solution. However, in a practical setting I have argued that the preliminary ship design process require a decomposition of the problem, with the subsequent sequential processing of the individual sub-problems. This implies that we have to take intermediate decisions that are likely to be sub-optimal.


But this is not an all-or-none choice; in real-world design situations there is a constant negotiation between making commitments and keeping the problem open. A possible strategy towards a favourable trade-off is to keep the solution on a high level of abstraction as long as possible. An example of this is reported in [Levander 1991] from the cruise ship design domain. Here, the importance of keeping the solution on a functional level as long as possible is emphasised, thus maintaining the option to select different conceptual solutions. On the other hand, if we leave the functional domain, we easily get locked into exploring the design space along a set of pre-defined dimensions, even if we keep the problem open in the sense that we postpone the assignment of numerical values to the design variables.

An alternative to consecutively determining the value of particular design variables is to make commitments in terms of systematically constraining the search space. This is intuitively done by experienced designers – for instance when an appropriate range for the design variables is selected at the outset of the design process. It is obviously a reasonable trade-off against exploring the whole domain of real numbers. Still, by every addition of a constraint to the design space the designer faces the risk of discarding a potentially favourable solution.

For the real-world design of complex systems like ships, the necessity of making commitments at some level of detail along the design process is an inescapable fact. The development of more advanced design tool is not likely to change this. Rather, the focus should rather be on how to provide support for the rational negotiation of such commitments. Alternative strategies for this will be further discussed in Chapter 8.

4.2.5 Extensive use of empirical relations and previous cases

Earlier in this chapter, the task environment of ship design was characterised by having a complex mapping between form and function, thus making it difficult to establish a strong analytical design model. As a consequence, preliminary ship design has always relied extensively on empirically based design relations, and the adaptation of existing designs to new requirements.

The access to performance data, such as steel weight and cost, on existing ships may be regarded as one of the most important assets for a shipyard or design office. Often, the work on a new design start by extrapolating from a previous in-house 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


that produces a set of empirical relations that may be useful for a larger range of ship sizes and types. Well-known examples are the regression analyses of model and trial test results at the Netherlands Ship Model Basin, aimed at developing a functional relationship between the ship main characteristics and ship’s resistance and propulsion properties [Holtrop 1977], and the work by [Watson and Gilfillan 1976], developing empirical formulas for a large range of ship characteristics.

The point here is that the extensive reliance on knowledge embedded in existing design solution is an important characteristic of the design problem space. In Chapter 6 I will discuss further how this can be reflected in the structure of the design model.

4.2.6 Multiple abstraction levels

Earlier in this chapter decomposition was presented as one common strategy to deal with the complexity of the ship design problem. A complementary strategy is the use of abstraction mechanisms. In this context, abstraction may be defined as the process of separating the relevant and irrelevant details from a context [Seltveit 1994]. This allows information to be represented at different levels of detail, thus being an aid to focus on the most significant aspects of a problem.

The application of multiple abstraction levels in the ship design can be exemplified by the increasing level of detail along the design process, starting from a coarse representation in the early stages to a detailed description in later stages.

In [Oortmerssen and Oossanen 1988] four major abstraction levels are identified, with different degrees of granularity and accuracy. These levels are defined as:

❏ Level "zero":a top-level description of a potential design based on the ship main characteristics

❏ Level "one":a more detailed description of the ship. Both level "zero" and "one" are parameter based descriptions

❏ Level "two": introducing detailed geometry of the ship, including compart-mentation. The corresponding design analysis is based on the defined geometry (and not on the design parameters)

❏ Level "three":introducing the geometry of the appendages. Thus, still more exact calculations are possible in order to determine the corresponding performances

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

ι


In addition, a number of domain specific abstractions have been developed through the relatively long history of ship design, that in a single concept captures multiple aspects of the ship’s characteristics or performance. This help to improve the human designers perceivibility of the model, paying attention to the limited number of concepts the human mind is capable of processing in parallel. Examples of such domain specific abstractions are:

❏ Dimensionless parameters, e.g. L/B, B/T, speed-length-ratio (V/√L) ❏ Form coefficients, e.g. 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.



funct ion

High cost of error

Mult i-dimensional , part ly non-monetary

performance l t i

Shallow knowledge structure

St rong domain t radit ion

Extensive use of empirical relat ions and previous cases

Decomposit ion into leaky modules

Sat isficing rather than opt imising

Personalised evaluat ion funct ion and stopping rulesStrict t ime and

resource constraints

Mult iple abstract ion hierarchies

Design TaskEnvironment

Design ProblemSpace

"One-of-a-kind" and "engineered-to-order"

solut ions

Delayed/limited feedback from the

world

FLEXIBILITY

EXPRESSIVENESS

PERCEIVABILITY

EFFICIENCY

Crit ical Fact ors

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


Design Task Environment

Design Problem Space Design Model

provide theset t ing for

determines whataspects are of interest to

Figure 4–5: The structure of the design model is determined by the design problem space, which again is determined by the task environment

4.3.1 Flexibility

By flexibility is understood the freedom the designer has to “meta-design” a design process that is both in conformance with the characteristics of the design problem under consideration, and in accordance with his/her personal preferences and level of expertise.

The focus on flexibility as a critical factor is founded on several of the invariants of the design problem space. One is the existence of multiple abstractions and abstraction hierarchies, that was discussed in Section 4.2.6. This requires a flexible model of the ship that can evolve along the process, starting from a coarse description in the beginning to a detailed description in the end. Part of the problem of incorporating this kind of flexibility lies in keeping the model consistent when more detail is added to the structure, or the focus is changed from a high level abstraction (e.g. V/√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


defined by the set of analysis procedures on which the application is based, with little or no possibility for the designer to make changes. However, in Chapter 2 we also saw an example of the opposite in the DESIGNER application, where the basic structure of the design model allowed for a very high degree of freedom in the meta-modelling of a particular design problem. This example also illustrate that the support for flexibility need to be founded on the low-level representation of the relevant domain concepts.

However, the support for flexibility is not achieved without a cost. Compared to a highly structured model with a pre-defined, fixed set of design variables and a given template of design analysis procedures, a model explicitly supporting meta-design tend to be considerably more complex, and thus less efficient with respect to the computational efficiency and size of the computer implementation.

4.3.2 Expressiveness

The expressiveness of a model refers to the ability to capture the relevant knowledge content of a particular domain. In the context of ship design this comprises all knowledge useful for generating, analysing, and evaluating potential design solutions, ranging from “first principles” facts to experience-based and intuition-like rules-of-thumb. A parallel to expressiveness is the notion of ‘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


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 object-oriented programming, and comprise for instance methods such as the encapsulation of information and procedures within objects that have a simple and well-defined external interface, and the use of inheritance that enable attributes and operations to be shared among information entities based on a hierarchical relationship.

As was the case with flexibility as a critical factor, there are limits to what measures should be taken in order to increase the perceivability of a model. This stems from the dual role of the model in the design process30, as illustrated in Figure 4–6. On the one hand the model serve as a basis for communication and understanding of the real-world design problem, and on the other hand it serves as a definition of the problem to be solved by the computer. For the first of these roles, a high degree of abstraction and simplicity is preferable, while for the latter, a detailed and concrete model is necessary in order to be computable.

29 perceive (…) 3. To become aware of in one's mind; achieve understanding of [American

Heritage Dicitonary] 30 This is a parallel to the dual role of specifications in information systems modelling, see [Seltveit,

1994]


A common concern from ship designers when faced with a new computer-based design tool is the creation of so-called “black-boxes”, or completely encapsulated process modules. These are processes where the human de-signer can only control the input and output, but not the internal structure31. Though this modularisation of the process may decrease the model’s complexity by abstraction, it may at the same time inhibit the human perceivability of the model, since part of the foundation on which the model’s result is derived from is hidden from human inspection. This is serious in a complex domain such as ship design, where human expertise, intelligence, and experience play a key role.

Human designer

cat ion

ment at ion

Figure 4–6 - The dual role of the design model

Comput er

Design model

Basis for communiand underst anding

Basis for impleand processing

The answer to this problem lies not necessarily in opening up every one of the black boxes. An alternative approach is to systematically provide the human designer with sufficient explanation of the underlying process, thus rendering the model’s reasoning process transparent to the user.

4.3.4 Efficiency

Efficiency may be defined as “the ratio of the effective or useful output to the total input in any system” [American Heritage Dictionary]. In the context of ship design, the useful output may for instance be measured by the number of feasible design solutions that are produced, or the quality of the best solution. The input to the design process may be measured by the number of man-hours and computer system resources required to achieve this.

If we take a holistic system view that include both the computer and the human designer, it is clear that the efficiency of the design system should be evaluated at a high level of abstraction, since factors such as flexibility and perceivability are

31 This may for instance be a design analysis procedure where the designer has access only to the

compiled version, and not the source code nor a proper documentation or explanation − a rather common problem in many existing ship design tools


primarily directed towards enhancing the human efficiency in the design process. These factors will usually have a negative effect if we focus on the computational efficiency of the system alone. For instance, when enabling a high degree of modelling flexibility, we will at the same time run the risk of sacrificing the efficiency that can be gained from a simpler knowledge representational formalism and inference methods. As an example, consider the representation of a simple constraint, e.g.

LBRATIO: LPP/B < 5.9

as a part of a compiled, procedure-oriented representation. An alternative representation might be as a binary tree where each node represent a single conceptual entity (an object), as illustrated in Figure 4–7. While this representation is favourable from a flexibility point-of-view, it will at the same time induce an overhead in terms of complexity and multiple evaluation steps that will impede the computational efficiency of the model.

(OperElem)value = '<'

(PropElem)value = 'LPP'

(PropElem)value = 'B'

(OperElem)value = '/'

(NumElem)value = '5.9'

(Constraint)tag='LBRATIO'

leftP

leftP rightP

rightP

topNode

Figure 4–7: A binary tree representation of a simple constraint

To summarise, it is clear that efficiency is an important factor to consider when evaluating the appropriateness of a particular design model. This implies that some compromises need to be made with respect to the other three critical factors when developing a design 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 Coggin’s Law of Software Engineering, which states

that “Pragmatics must take precedence over elegance, for Nature cannot be impressed”


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.


These deviations from an idealised world need to be taken into consideration when proposing a model for ship design.

“An ideal medium for representing knowledge about design is one that enable any thought to be represented but that does not anticipate the properties of the things described” (Swinson, 1983)

5 References

Ames, R. M. and Lynaugh, K. M. (1988) "A Review of Hullform Design Systems for the Marine Industry", Marine and Offshore Computer Applications, September 1988

Andrews, D. (1981) "Creative Ship Design", The Naval Architect, November 1981

Andrews, D. (1985) “An Integrated Approach to Ship Synthesis”, The Naval Architect, April 1986

Antonsson, E. K. (1987) "Developing and Testing Hypothesis in Engineering Design Research", J. of Mechanisms, Transmissions and Automation in Design, Volume 09, January 1987

Ashley, S. (1992) "Engineous Explores the Design Space", Mechanical Engineering, February 1992

Balachandran, M. (1993) "Knowledge-Based Optimum Design", Computational Mechanics Publication, London

Booch, G. (1994) "Object-Oriented Analysis and Design with Applications", Benjamin/Cummings, Redwood City, California

Bras, B. A. (1992) "Foundations for Designing Decision-Based Design Processes", Ph.D. Dissertation, University of Houston, Houston, Texas

Braun, R. D., Kroo, I. and Gage, P. (1993) "Post-Optimality Analysis in Aerospace Vehicle Design", AIAA Aircraft Design, Systems, and Operations Meeting, August 11-13, 1993, Monterey, California

Cardena, E. M. (1992) "Use of CFD Tools in the Hull Lines Design Process", Design of Marine and Offshore Structures (CADMO’92)

78 References

Chandrasekaran, B. (1989) "A Framework for Design Problem Solving", Research in Engineering Design, Volume

Coyne, R. D., Rosenman, M. A., Radford, A. D., Balachandran, M. and Gero, J. S. (1990) "Knowledge-Based Design Systems", Addison-Wesley Publications, Reading, Massachusetts

Crane, R. L., Hillstrom, K. E. and Minkoff, M. (1980) Solution of the General Nonlinear Programming Problem with Subroutine VMCON, Argonne National Laboratory, Illinois, ANL-80-64

Cross, N. (1980) "Design Method and Scientific Method", Design Research Society Conference, Portsmouth, Westbury House

Davis, L. (1991) "Handbook of Genetic Algorithms", Van Nostrand Reinhold, New York

Dierolf, D. A. and Richter, K. J. (1989) Computer-Aided Group Problem Solving for Unified Life Cycle Engineering (ULCE), Institute for Defense Analyses, Alexandria, Virginia, IDA Paper P-2149

Dixon, J. R. (1987) "On Research Methodology Towards a Scientific Theory of Engineering Design", AI EDAM, Number 3

Dixon, J. R., Duffey, M. R., Irani, R. K., Meunier, K. L. and Orelup, M. F. (1988) "A Proposed Taxonomy of Mechanical Design Problems", Proceedings ASME Computers in Engineering Conference, San Francisco, California

Drijver, K., Käsper, M., Lehne, M., Oehlmann, R., Mehta, S. and Rimkus, C. (1993) The MARITIME University of Discourse, D 3111

Duffy, A. H. B. (1993) "Machine Learning in Design", Artificial Intelligence in Engineering, Volume 8

Duffy, A. H. B. and Kerr, S. M. (1993) "Customised Perspective of Past Designs From Automated Group Rationalisations", Artificial Intelligence in Engineering,

Duffy, A. H. B. and MacCallum, K. J. (1989) "Computer Representation of Numerical Expertise for Preliminary Ship Design", Marine Technology, Volume 6, No. 4, October 1989

Eames, M. C. and Drummond, T. G. (1977) "Concept Exploration — An Approach to Small Warship Design", Transactions RINA, Volume 19,

Appendix C: [Erikstad, et al. 1995] 79

Engelund, W. C., Stanley, D., Lepsch, R. A. and McMillan, M. M. (1993) "Aerodynamic Configuration Design Using Response Surface Methodology Analysis", AIAA Aircraft Design, Systems and Operations Meeting, Monterey, California

Erichsen, S. (1972) "Optimizing Containerships and their Terminals", SNAME Spring Meeting, Willimiamsburg, Virginia, May 1972Erichsen, S. (1989) "Management of Marine Design", Butterworths, London

Erichsen, S. (1994) "The Effect of Learning When Building Ships", Journal of Ship Production, Volume 0, 3, August 1994

Erichsen, S. and Selvig, E. K. (1991) "Contractual Margins in Relation to Required Performance", IMSDC'91 - The 4th International Marine Systems Design Conference, Kobe, Japan, The Society of Naval Architects of Japan

Erikstad, S. O. (1994) "Improving Concept Exploration in the Early Stages of the Ship Design Process", 5th International Marine Design Conference, Delft, The Netherlands

Erikstad, S. O., Lautenschlager, U., Bras, B., Allen, J. K. and Mistree, F. (1995) "Integrating Robustness into Multiobjective Space Vehicle Design Process", Journal of Guidance, Control, and Dynamics, Volume 8, Number 5

Evans, J. H. (1959) "Basic Design Concepts", Naval Engineers Journal, ASNE, Volume 1, Number 6

Finger, S. and Dixon, J. R. (1989) "A Review of Research in Mechanical Engineering Design. Part 1: Descriptive, Prescriptive, and Computer-Based Models of Design Processes", Research in Engineering Design, Number 1

Finger, S. and Dixon, J. R. (1989) "A Review of Research in Mechanical Engineering Design. Part II: Representations, Analysis, and Design for the Life Cycle", Research in Engineering Design, Number 2

Fisher, K. W. (1973) "The Relative Costs of Ship Design Parameters", Transactions RINA - Royal Institute of Naval Architects, Volume

Fleming, J., Elghadamsi, E. and Tanik, M. (1990) "A Knowledge-Based Approach to the Preliminary Design of Structures", Journal of Energy Resources Technology, Volume 12, December 1990

Folkers, J. S. (1973) "Ship Operation and Design", in Optimization and Design, Prentice-Hall Inc., New York

80 References

Gage, P. and Kroo, I. (1993) "A Role for Genetic Algorithms in a Preliminary Design Environment", AIAA Aircraft Design, Systems, and Operations Meeting, August 11-13, 1993, Monterey, California

Gamma, E., Helm, R., Johnson, R, Vlissides, J. (1994) “Design Patterns - Elements of Reusable Object-Oriented Software”, Addison-Wesley Publ., Reading, Massachusetts

Genesereth, M. R. and Nilsson, N. J. (1988) "Logical Foundations of Artificial Intelligence", Morgan Kaufmann Publishers Inc.

Georgescu, C., Verbaas, F. and Boonstra, H. (1990) "Concept Exploration Models for Merchant Ships", CFD and CAD in Ship Design, Wageningen, The Netherlands, Elsevier Science Publishers B. V.

Goel, V. and Pirolli, P. (1989) "Motivating the Notion of Generic Design within Information-Processing Theory: The Design Problem Space", Design Studies, Volume Spring 1989

Goel, V. and Pirolli, P. (1989) "Motivating the Notion of the Generic", AI Magazine, Spring 1989

Goldberg, D. (1989) "Zen and the Art of Genetic Algorithms", 3rd International Conference on Genetic Algorithms, George Mason University, Morgan Kaufman Publishers

Goldberg, D. E. (1989) "Genetic Algorithms in Search, Optimization, and Machine Learning", Addison-Wesley, Reading, Massachusetts

Grigoropoulos, G. J. and Loukakis, T. A. (1992) "A New Method for Developing Hull Forms with Superior Seakeeping Qualities", Design of Marine and Offshore Structures (CADMO’92)

Hagen, A. (1992) Prosedyrer for Prosjektering av Skip (Procedures for the Design of Ships), Dept. of Marine Systems Design, Norwegian Institute of Technology/MARINTEK,Report no. 260292

Hagen, A. (1993) "The Framework of a Design Process Language", Ph.D. Dissertation, Department of Marine System Design, Norwegian Institute of Technology, Norway

Hales, C. (1987) "Analysis of the Engineering Design Process in an Industrial Context", PhD Dissertation, Gants Hill Publication


Hales, C. and Wallace, K. M. (1987) "Detailed Analysis of an Engineering Design Project", ICED-87: International Conference on Engineering Design, Boston, The American Society of Mechanical Engineers

Han, S.-H., Lee, D., Lee, K., Lee, K. and Kim, E.-K. (1994) "Visualization of the Reasoning Process of a Knowledge-Based Design Support System for the Structural Design of Ships", ICCAS'94 - 8th International Conference on Computer Applications in Shipbuilding, Bremen, Germany, Berry Rasmusson Reklam AB

Harvald, S. A. and Jensen, J. J. (1992) "Steel Weight Estimation for Ships", PRADS'92 - 5th Int. Symposium on Practical Design of Ships and Mobile Units, Newcastle upon Tyne, UK, Elsevier Science Publishers Ltd.

Hees, M. v. (1992) "QUAESTOR - A Knowledge-Based System for Computations in Preliminary Ship Design", PRADS'92 - 5th Int. Symposium on Practical Design of Ships and Mobile Units, Newcastle upon Tyne, UK, Elsevier Science Publishers Ltd.

Hills, W. and Buxton, I. L. (1988) "A Concept Design System for Ships which Incorporates Production Considerations", 2nd International Conference on Computers, Design, Manufacturing, and Operations in the Marine and Offshore Industry, Southampton, UK, Springer Verlag

Holtrop, I. J. (1977) "A Statistical Analysis of Performance Test Results", International Shipbuilding Progress, Volume 4, Number 270, Feb. 1977

Holtrop, J. (1984) "A Statistical Re-Analysis of Resistance and Propulsion Data", International Shipbuilding Progress, Volume 1, Number 363

Holtrop, J. and Mennen, G. G. J. (1978) "A Statistical Power Prediction Method", International Shipbuilding Progress, Volume 5, Number 290

Holtrop, J. and Mennen, G. G. J. (1982) "An Approximate Power Prediction Method", International Shipbuilding Progress, Volume 9, Number 385

Hubka, V. (1982) "Principles of Engineering Design", Butterworth & Co. (Publishers) Ltd., London

Hubka, V. and Eder, W. E. (1987) "A Scientific Approach to Engineering Design", Design Studies, Volume ol 8, No. 3, July 1987

Ingalls, D. H. (1981) "Design Principles Behind Smalltalk", BYTE, 8, Volume

Johnsen, I. and Ellingsen, H. (1986) "Hva kan Oljeindustrien Lære av Skipsfarten", Petro Magasin, 6-86, Volume Jones, C. J. (1970) "Design Methods", John Wiley & Sons, New York

82 References

Kamal, S. Z., Karandikar, H. M., Mistree, F. and Muster, D. (1987) "Knowledge Representation for Discipline-Independent Decision Making", IFIP 1987, Elsevier Science Publishers B. V.

Keeney, R. L. and Raiffa, H. (1976) "Decisions with Multiple Objectives: Preferences and Tradeoffs", John Wiley & Sons, New York

Langbecker, U., Nowacki, H., Bühr, W. and Kress, H. (1994) "A Reference Architecture for Shipbuilding Product Models", ICCAS'94 - 8th International Conference on Computer Applications in Shipbuilding, Bremen, Germany, Berry Rasmusson Reklam AB

Lautenschlager, U., Erikstad, S. O., Allen, J. K. and Mistree, F. (1995) "Experimental Sattelite Trajectory Analysis Using Decision-Based Robust Design", Journal of Guidance, Control, and Dynamics, Volume 8, Number 5

Levander, K. (1991) "System-Based Passenger Ship Design", IMSDC'91 - The 4th International Marine Systems Design Conference, Kobe, Japan, The Society of Naval Architects of Japan

Lyon, T. D. (1982) "A Calculator-Based Preliminary Design Procedure", Marine Technology, Volume 9, Number 2

MacCallum, K. J. (1982) Creative Ship Design by Computer, North-Holland, Amsterdam

MacCallum, K. J. (1990) "Does Intelligent CAD Exist?", Artificial Intelligence in Engineering, No. 2

MacCallum, K. J. and Duffy, A. (1987) "An Expert System for Preliminary Numerical Design Modeling", Design Studies, Volume ol 8, No. 4, October 1987

MacCallum, K. J. and Martins, P. D. (1985) "Towards a Concept Design Assistant for Ships", 2nd International Marine Systems Design Conference IMSDC'85, Lyngby, Denmark

MacPherson, D. M. (1993) “Reliable Performance Prediction: Techniques Using a Personal Computer”, Marine Technology, Volume 30, Number 4

Marzi, J. and Ye, D. (1994) "On the Integration of CFD in Ship Design", 8th International Conference on Computer Applications in Shipbuilding, Sept 5-9, 1994, Bremen, Germany

McCarthy, J. and Hayes, P. (1969) "Some Philosophical Problems from the Standpoint of Artificial Intelligence", Wiley & Sons (Halsted Press)


Mehta, S. and Lehne, M. (1994) "Product Data Technology Benefits - A Perspective of Yard and Classification Society", ICCAS'94 - 8th International Conference on Computer Applications in Shipbuilding, Bremen, Germany, Berry Rasmusson Reklam AB

Miles, J. and Moore, C. (1994) "Practical Knowledge-Based Systems in Conceptual Design", Springer-Verlag, London

Mistree, F., Smith, W. F., Bras, B., Allen, J. K. and Muster, D. (1990) "Decision-Based Design: A Contemporary Paradigm for Ship Design", Transactions, SNAME, Volume 8

Mistree, F., Smith, W. F., Kamal, S. Z. and Bras, B. A. (1991) "Designing Decisions: Axioms, Models and Marine Applications", Fourth International Marine Systems Design Conference, Kobe, Japan

Nethercote, W. C. E., Eng, P. and Schmitke, R. T. (1981) "A Concept Exploration Model for SWATH Ships", The Naval Architect, Volume May 1982

Nicklaus, D. J., Overton, K. S., Tong, S. S. and Russo, C. J. (1988) Knowledge Representation and Technique for Engineering Design Automation, Elsevier Science Publishers, B.V.

Nowacki, H., Brusis, F. and Swift, P. M. (1970) "Tanker Preliminary Design - An Optimization Problem with Constraints", Transactions SNAME, Society of Naval Architects and Marine Engineers

Oortmerssen, G. v. and Oossanen, P. v. (1988) "A New CAD System for the Design of Ships", Marine and Offshore Computer Applications, September 1988

Oosterveld, M. W. C. and Oossanen, P. v. (1973) "Representation of Propeller Characteristics Suitable for Preliminary Ship Design Studies", International Conference on Computers Applied in the Automationof Shipyard Operation and Ship Design - ICCAS, Tokyo, Japan

Pahl, G. and Beitz, W. (1984) "Engineering Design", The Design Council/Springer-Verlag, London/Berlin

Pal, P. K. (1991) "Rationalised Design of Sailing Yachts", PRADS'91 - 4th International Marine Systems Design Conference, Kobe, Japan

Parsons, M. G. (1975) "Optimization Methods for Use in Computer-Aided Ship Design", 1st SNAME STAR Symposium

84 References

Perakis, A. N. and Jaramillo, D. I. (1991) "Fleet Deployment Optimization for Liner Shipping", Maritime Policy and Management, Volume 8, Number 3

Priha, I. (1989) "Integrated Knowledge Systems", Artificial Intelligence in Engineering, Number 2

Rawson, K. J. (1979) "Maritime System Design Methodology", International Symposium on Advances in Marine Technology, Trondheim, Norway, Tapir

Ray, T. and Sha, O. P. (1994) "Multicriteria Optimization Model for a Containership Design", Marine Technology, Volume 1, Number 4, October 1994

Roozenburg, N. F. M. (1993) "On the Pattern of Reasoning in Innovative Design", Design Studies, Volume 4, Number 1

Roth, K. (1987) "Design Models and Design Catalogs", ICED-87: International Conference on Engineering Design, Boston, The American Society of Mechanical Engineers

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. (1991) "Object-Oriented Modeling and Design", Prentice-Hall, New Jersey

Rzevski, G. (1980) "On the Design of A Design Methodology", Design Research Society Conference, Portsmouth, Westbury House

Sargent, P. (1994) "Design Science or Nonscience", Design Studies, Volume 5, Number 4, October 1994

Schneekluth, H. (1987) "Ship Design for Efficiency and Economy", Butterworths, London

Seltveit, A. H. (1994) "Complexity Reduction in Information Systems Modelling", PhD Dissertation, Norwegian Institute of Technology

Sen, P. and Yang, J.-B. (1994) "Combining Objective and Subjective Factors in Multiple Criteria Marine Design", 5th International Marine Design Conference, Delft, The Netherlands

Sha, O. P., Ray, T. and Gokarn, R. P. (1994) "An Artificial Neural Network Model for Preliminary Ship Design", ICCAS'94 - 8th International Conference on Computer Applications in Shipbuilding, Bremen, Germany, Berry Rasmusson Reklam AB

Sha, O. P., Ray, T. and Gokarn, R. P. (1994) "An Artificial Neural Network Model for Preliminary Ship Design", ICCAS'94 - 8th International Conference on Computer Applications in Shipbuilding, Bremen, Germany, Berry Rasmusson Reklam AB


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

Documents

Transcript of Lecture Note - Intro to Design and Design Modelling