design of design guidance system ship 1990

7/27/2019 Design of Design Guidance System Ship 1990

1/23

THE DEVELOPMENT OF A

DESIGN GUIDANCE SYSTEM

FOR THE EARLY STAGES OF DESIGN

BERT BRAS1 WARREN F.SMITH2 FARROKH MISTREE3

1 MARIN, MARITIME RESEARCH INSTITUTE NETHERLANDS, WAGENINGEN, THENETHERLANDS,

Currently RESEARCH ASSOCIATE, OPERATIONS RESEARCH PROGRAM, UNIVERSITY OFHOUSTON, HOUSTON, TEXAS. 77204-4792

2 NAVAL ARCHITECT, DNA, DEPARTMENT OF DEFENCE, CAMPBELL PARK OFFICES,CANBERRA, ACT, AUSTRALIA. 2600

Currently RESEARCH ASSOCIATE, OPERATIONS RESEARCH PROGRAM, UNIVERSITY OFHOUSTON, HOUSTON, TEXAS. 77204-4792

3 PROFESSOR, DEPARTMENT OF MECHANICAL ENGINEERING, UNIVERSITY OFHOUSTON, HOUSTON, TEXAS. 77204-4792

Address all correspondence to Farrokh Mistree

Abstract

The Maritime Research Institute Netherlands (MARIN) is developing a flexible and openship design system called HOSDES. In a triumvirate of collaborative cooperation, theSystem Design Laboratory (University of Houston), MARIN and the Royal Australian

Navy have combined their research and development efforts towards achieving a DesignGuidance System for the HOSDES system. The principal function of this DesignGuidance System is to increase both the efficiency and effectiveness of a human designerwho is designing a ship using HOSDES. In this paper some issues associated with thedevelopment of this Design Guidance System are highlighted.

========Bras, B., Smith, W. F. and Mistree, F., "The Development of a Design Guidance System for the Early

Stages of Design" in CFD and CAD in Ship Design, pp. 221-231, (G. van Oortmerssen, Ed.),

Wageningen, The Netherlands: Elsevier Science Publishers B.V., (1990).


2/23

The Development of a Design Guidance System 2

1. BACKGROUND AND MOTIVATION

The trend in the development of computer systems for the design of complex systems such

as ships is towards providing a designer with greater control (than in the past) over theexecution of individual computer programs (or modules) within the computer system.Invariably, the computer systems for design include individual programs which weredeveloped, in the past, as stand-alone systems. The incorporation of these programs intothe overall system is a major bottleneck requiring an expenditure of large amounts of timeand other resources to transport and convert information from one format to another andto ensure its correct use. Therefore, it is not surprising that naval architects are interestedin the development of application software that can not only be used independently butcan also communicate with each other in the broader context of a computer system forsupporting design. A number of these type of systems for ship design are currently underdevelopment [1-5].

The Maritime Research Institute Netherlands (MARIN) is currently developing HOSDESfor use in the design of ships. The guiding philosophy in HOSDES is to place a designerin a central role in a flexible computer-based design environment [2, 3]. This is achievedthrough:

maximizing the flexibility within HOSDES, placing the onus of using HOSDES effectively completely on a designer, recognizing that a designer is responsible for evaluating, approving, modifying

and eventually recommending the information that are computed by variousprogram modules in HOSDES, and

focusing on providing support for a human designer rather than a black-boxapproach towards design automation.

HOSDES, has at its core a complex interactive information management system thatmakes use of a central relational database as well as a library of program modules. Theseprogram modules embody MARIN's world-renowned experimental experience and theirwealth of knowledge in hydromechanics. The development of HOSDES enables MARINto draw upon the knowledge embodied in these individual program modules in a single,widely accessible design environment. The flexibility and variety of options available inthe fully-developed HOSDES, however, could overwhelm a designer; hence, the need fora Design Guidance System (DGS).

Koops et al. [3] define two major areas for assistance in a flexible (open-ended) shipdesign system like HOSDES, namely,

identifying the most appropriate path through the (HOSDES) system for agiven design problem, and

finding the best possible solution for a design problem in terms of qualitychecks and the presentation of possible ways to improve the design.


3/23


This gives rise to the following question:

How can we increase the efficiency1 and effectiveness2 of human designer(s) whouse HOSDES to design ships?

But first some information on the motivation for developing a Design Guidance System.

2. THE DESIGN GUIDANCE SYSTEM: ITS PRINCIPAL FUNCTION ANDPOTENTIAL BENEFITS

2.1 What are HOSDES, DSIDES and the Design Guidance Systems?

Visualize a camera and assume that this camera symbolizes the computer-based designsystem we wish to create. Why? Let us explain. A camera is used by a human to capturean image (picture) of an object in the real world. Similarly, a computer-based designsystem is to be used by a human designer to create a representation of a real worldengineering system; ideally one that can be manufactured and maintained. Both thecamera and the design system are inanimate; both depend on human direction to realize animage of a system in the real world. The quality of a picture taken with any camera is, inthe ultimate, dependent on the person taking the photograph; so too the design from thecomputer-based design system. system. The quality of the camera affects the quality ofthe picture; so too the quality of the computer-based design system.

HOSDES is our design system - our camera so to say. HOSDES is used by a humandesigner to create a representation (an image) of a ship in its database. Just as a humanexercises control over a camera a human designer exercises control over HOSDES; ahuman in both cases has ultimate control. Light (knowledge and information) reflectedfrom the real world passes through the camera lens and strikes the film thereby imprinting

an image - which is usually slightly distorted and fuzzy. This is also true of HOSDES.The analogy is in Figure 1.

Real World Solution(Ideal)

Computer-Based Solution(An Image)

Design System(Capturing a Solution)

1 We consider efficiency to be a measure of the swiftness with which information, that can be used by

a designer to make a decision, is generated.2 We consider effectiveness to be a measure of quality of a decision (correctness, completeness,

comprehensiveness) that is made by a designer.


4/23


Figure 1 -- The Analogy between a Camera and a Design System

What can we do to create a better image/computer-based solution? Two actions can betaken, namely,

improve the equipment , and improve the interactions between the human and the camera (design system

and designer).

Both the camera and design systems have improved significantly over time; just comparethe first cameras and computer-aided design systems with those that are available today.Both cameras and computers (the conerstone of computer-based design) continue to beimproved so let us focus on the second action.

How can we improve the interaction between a human operating a camera or a designsystem? A photographer using one of the earlier cameras had to do everything based onexperience and insight. He/she would look at the sky, judge the amount of light, judge thedistance and adjust the diaphragm and focus accordingly. Newer cameras included lightmeters and a means to judge whether the camera was focussed was embedded in the viewfinder. The photographer used these aids set the aperture and timing and was still requiredto focus the camera. The DSIDES system3 is to HOSDES what the light meter and thefocusing aid are to the camera.

As we all know, a photographer can always ignore the aids and operate the cameramanually. In some cases there is no other way. Anybody who has taken pictures at night(e.g., the moon, a citys skyline) knows that the semi-automatic features are useless and aswitch to manual mode is imperative for obtaining any semblance of a good picture.

Similarly in the HOSDES system a designer may choose not to activate the DSIDESsystem - maybe simply because the DSIDES system is not equipped to handle suchsituations.

Has evolution of cameras stopped? The answer is an emphatic no. Nowadays, camerasthat have the capability to automatically focus and adjust timing and diaphragm, are notonly available but are relatively inexpensive. The control unit of this camera attuned to theenvironment; it is embodied with some intelligence. This intelligence is used to takeinformation from the environment, process it, adjust the controls, and advise aphotographer that it is ready to take a picture. The DGS is to HOSDES what theintelligent control unit is to a modern camera. The DGS is attuned to perceive what a

designer is trying to capture and provide him/her with information and advice that couldbe used to arrive at a good representation of the object of design in a knowledge base. In

3 The Decision Support Problem Technique, a decision-based approach for the design of engineering

systems, is being developed by the Systems Design Laboratory at the University of Houston. The

DSPT Workbook is a Apple Macintosh based environment that is being created for the

implementation of the Decision Support Problem Technique. Support for human designers is

provided through the formulation and solution of Decision Support Problems. DSIDES is the

computer system for solving Decision Support Problems.


5/23


both cases a human can ignore the assistance proffered by the control unit and negate itsactions. In other words, a human has ultimate control and is responsible for the quality ofthe image.

Where are we now? We view the HOSDES system as a semi-automatic camera with

DSIDES providing support for human decision making and the DGS the control unit thathelps a designer use HOSDES as efficiently and effectively as possible. And what aboutthe DSPT Workbook? Well, the DSPT Workbook is akin to the camera body; a body towhich to which various lenses can be attached. The camera body will embody theintelligent control unit (DGS) and the means for decision support (DSIDES). Changingthe lens of the camera from, say, a wide angle to a telephoto is akin to focussing ondifferent domains. In this analogy, the camera body represents the domain independentinformation, whereas the lens contains the domain dependent information. However, thereis a tradeoff. The lens must be suitable to fit to the body. In other words, the domaindependent information (lens) must be in a form suitable to be handled by the domainindependent information (camera body). This is a limitation - but just contemplate theadvantages!

2.2 What is the Principal Function of a Design Guidance System?

We believe that the principal function of a Design Guidance System is to increase theefficiency and effectiveness of a designer as he/she designs a ship in general and negotiatesa solution to a design problem in particular. We believe that, in the ultimate, support for ahuman designer can be provided via a design guidance system only if a model of theprocess of design is known and modeled on a computer.

Why? Design deals with the creation of a real world system, i.e., an artifact. The artifactis the valuable end result of this creation. But how was this artifact designed? What were

the activities performed? What has been learned during the design process? As importantas the artifact is, understanding the process is equally, if not more, important. Once theprocess is understood, the knowledge gained can be used to increase the efficiency andeffectiveness of another designer. Therefore, we believe developing an understanding ofthe process of design itself is important.

One could compare designing without any information about the process with crossing acountry in, say, Europe with only streetmaps of various cities in it but with no countrymap showing major roads. With some luck the country can be crossed. If a country mapthat included roads was available and used the amount of effort and time spent could besignificantly reduced. Similarly, in our opinion, the DGS must not only provide advice on

obtaining knowledge about the artifact ( la the cities and their streetmaps) but alsoinformation on theprocess of obtaining this knowledge ( la the country map).

Of course the utility of a particular map to, say, a trucker and a tourist will be different;since their individual needs and perspectives are different. Similarly, the needs ofdesigners working in different design environments would be different. In this paper, wedescribe some issues associated with the development of a DGS in general but with thefocus clearly on a Design Guidance System for HOSDES. Consequently our perspective


6/23


is clearly rooted in Decision-Based Design [6], the Decision Support Problem Technique[7], and the DSIDES [8] and HOSDES computer systems. Hence, the followingstatement:

The principal function of our Design Guidance System is to support human

designers in increasing their efficiency and effectiveness in designing ships usingHOSDES

The preceding provides the driving motivation for the development.

2.3 What are the Potential Benefits of Developing a Design Guidance System?

The current development of the HOSDES system is focused on the conceptual design offrigates. Our interest, therefore, is in developing a Design Guidance System to support ahuman designer in the early stages of project initiation in general and the HOSDES systemin particular. Two questions arise:

How important is design guidance in the early stages of project initiation?How important are decisions made in the early stages on the final artifact?

We find the answers to the preceding questions in the conclusion of a recent study for theInstitute of Defence Analysis [9]:

The importance of early design decisions is widely recognized. It is often statedthat roughly 70 percent of the total life cycle cost of the system is determinedduring the conceptual phase. Due to the lack of hard data, very few traditionalCAD tools are available to support the early stages of design. Considering thehigh leverage of the decisions made during these stages, this is an undesirable

situation.

The significance of the need for a computer-based DGS to support the activities of adesigner in the early stages of design is clear from the preceding quote. If this problem isso significant then what is available? In their comprehensive review of the research inmechanical engineering design Finger and Dixon state [10, 11]:

An important area that has received little attention to date is the creation ofdesign environments that integrate available tools into a consistent system tosupport the designer.

Therefore, we focus our research and development efforts on developing a DGS that isgeared towards increasing the efficiency and effectiveness of a designer in the early stagesof project initiation. The two questions that need to be answered are:

How can this be accomplished?What is needed?

These questions are addressed in the next section.


7/23


3. ON INCREASING THE EFFICIENCY AND EFFECTIVENESS OF HUMANDESIGNERS

3.1 How?

How can the efficiency and effectiveness of a designer be increased through the use of aDesign Guidance System? We assert that the efficiency and effectiveness of a designercan be increased by:

increasing the speed with which the design iteration is accomplished, and reducing of the number of iterations.

An increase in speed of iteration (increasing efficiency) has traditionally been the focus ofdesign automation. A reduction in the number of iterations is profitable especially wheniterations are very costly; this issue is yet to be resolved. Often flaws in the solution tothe design problem are detected during manufacturing and even maintenance. Thecorrective redesign effort is usually extremely expensive and ideally should be have beendesigned out prior to manufacture. The effort to reduce such costly iterations hasprovided the stimulus for developing approaches to design that include life cycleconsiderations (that is, design, manufacture and support). Approaches to design thatincorporate life cycle considerations include concurrent engineering [12-14], simultaneousengineering, Unified Life Cycle Engineering (ULCE) [9, 15-17], producibility engineering[18]. Companies which have made use of some of these approaches have reportedimpressive benefits [14].

3.2 What is Needed?

An increment in iteration speed can be achieved if at least some parts of a design processare known and can be modelled. To achieve a reduction in the number of iterations notonly a model of the process but also information that can be used to determine how theprocess can be improved is needed. By creating a model of a process of design andimplementing it on a computer we obtain a structure we can use to determine what advice,if any, the DGS can provide a designer. As with any other model we would like to be ableto analyze it, debug it, find redundancies, inconsistencies, store it for future reference orusage. Also we would like to be able to detect (sub)processes which are independent ofeach other and could therefore be solved concurrently, thus saving time. The basic notionis that as long as a model of the process to be used for designing can be obtained andanalyzed then computer based tools can be developed to improve it. Without a model of

the process that can be represented and manipulated on a computer this, we believe, willbe impossible. Given the preceding, two fundamental questions need to be answered. Thequestions:

How can a computer-based model of a design process be obtained? How can the various types of information involved in a design process be

represented and manipulated ?


8/23


These questions are addressed in the following sections.

4. ON DEVELOPING A DESIGN GUIDANCE SYSTEM - OUR APPROACH

4.1 Models of Design Processes and Information

Two different classes of models of the design process have been proposed, namely,prescriptive and descriptive models [6, 19]. The principle underlying prescriptive modelsis to persuade or encourage designers to adopt a particular way of doing design. Manyprescriptive models have been developed and proposed over the years. Descriptivemodels embody sequences of activities that typically occur in a design process. Thesemodels exemplify how design is done and not what should be done to arrive at a solutionHowever, there is no generally accepted unique model of the engineering design process.Andreasen [20] reflects on some of the problems of applying such models in practice. DeBoer [21] also alerts us to the reluctance of designers in industry to accept (prescriptive)models of design processes.

Whether or not a generally acceptable model of the design process exists it is questionablewhether a complex process like ship design can be described in one single informationform, e.g., rules or optimization models. Numerous efforts have (unfortunately) beenundertaken to fit the process of design into a particular mode of representing information,for example, production rules. However, the information needed by a designer within anydesign process is almost always provided in different forms, for example, a computerprogram, knowledge base, rule, neural network, mathematical programming formulation, asimple formula, raw data, program output, etc. Hence, we contend that any informationmanagement system developed for design must be capable of supporting the storage andprocessing of various types of information.

The preceding observation is reinforced by Fox and Safier [22] and Forbus [23]. Further,Finger and Dixon [10, 11] state:

The models and methods for parametric design are highly domain dependent.Research on a unifying parametric design paradigm, which must include bothnumeric and non-numeric methods, is needed.

Fulton et al. [24] provide an extensive discussion on managing engineering designinformation. They conclude that conventional Database Management Systems developedfor business and administration oriented environments cannot fulfill the functional

requirements for engineering design. These deficiencies have led to the development ofmany data/process modeling methodologies (e.g., IDEF0, Entity Relationship Models,

Object Oriented Data Models, etc.). Fulton et al. studied seven of those methodologiesfor engineering design using an aircraft design case study. Their conclusion with respectto this is as follows:

The study indicated that none of the existing modeling techniques is adequatefor supporting the overall aerospace vehicle design process. The OODM (Object


9/23


Oriented Data Model) seems to possess many of the features required for theideal design decision support system for modeling the aerospace vehicle designprocess. Some of the features that the OODM lacks are embodied in othermethodologies. It is felt that research toward an extended information modelingmethodology, formed by combining the OODM model with a process model (such

as IDEF0 or SAMM), may provide the optimal decision support environment.

The preceding reinforces our earlier observation (see Section 3.2) that the modeling ofdesign processes and their implementation on a computer bear further investigation. Theemphasis by Fulton and co-workers on the need for providing decision support is alsonoted. With this as background we summarize our approach in developing a DesignGuidance System for HOSDES in the next section.

4.2 Decision-Based Design and the Decision Support Problem Technique

Decision-Based Design is a term coined to emphasize a different perspective from which

to develop methods for design, [25, 26]. In Decision Based Design it is asserted that theprincipal function of a designer is making decisions associated with the design of anartifact [12, 27]. This assertion is in keeping with the philosophy underlying HOSDES(see Section 1). The implementation of Decision-Based Design can take many forms.One implementation of Decision-Based Design is the Decision Support Problem (DSP)Technique which is under development at the Systems Design Laboratory of theUniversity of Houston. Support for human designers is provided through the solution ofDecision Support Problems. The process of design is modeled using entities, for example,phases, events, decisions, tasks and the like. A designer working within the DSPTechnique has the freedom to use submodels of a design process (prescriptive models)created and stored by others and also to create models (descriptive models) of theirintended plan of action using the aforementioned entities. By using the aforementionedentities to model a plan of action descriptions of processes in a common "language" forteams from various disciplines is possible and can be stored for further use. The softwarefor implementing the DSP Technique is called the DSIDES system (Decision Support inthe Design of Engineering Systems) [8] and the DSPT Workbook [28]. The RoyalAustralian Navy has incorporated DSIDES within AUSEVAL [4, 5]. AUSEVAL is aproto-typical system for the preliminary design of naval and commercial ships usingDecision Support Problems.

4.3 Modeling Processes in Design

What are some of the basic entities for modeling design processes? Some of the basic

entities used to model design processes in the Decision Support Problem Technique areshown in Figure 2. The entities are discussed in more detail in [6].


10/23


E

T

?

i

P Phase

Event

Task

Decision

Information

?

?

?

?

CompromiseDSP

PreliminarySelection DSP

SelectionDSP

i

System

SystemVariable

Goals / BoundsConstraints

AnalyticalRelationship

Figure 2 -- Basic Entities for Modeling Design Processes

In general, these entities are relationships with one input and one output. Amodel/network of a process is created by connecting entities in a systematic fashion. Anexample of a model of preliminary ship synthesis using some of the basic entities is givenin Figure 3. Further information is provided in [6].


11/23


E

Preliminary

Design i

i

Top

Level

Specification

Ship

Characteristics

?

?

Ti

Goals and

Constraints

i

Basic

Concept

Refine Goals and

Constraints

iGoals and

Constraints

i

i

Top

Level

Specification

Ship

Characteristics

i T

i

General Design

Knowledge

?

Model

Solution

i

i

i

Hull

Analysis

Propeller

Analysis

Propeller

Concepts &

Attributes

T

Ei

Prepare

Documents

Experimental

Validation

Experimental

Information

Order

Information

Preliminary

Ship

Synthesis

Figure 3 -- A Model of Preliminary Ship Synthesis [6]

How will the process models be obtained from a designer? One possibility is, that adesigner will explicitly enter a model of his/her design plan (akin to creating a macro on acomputer) and then follow it. In this case the plan will be used in a like manner to aprescriptive model of the design process. On the other hand, suppose a designer wants to

reach an objective for which no process model is stored in the computer. In this case, adesigner would examine the available models (look at available macros in the macrolibrary), experiment with some of them (try some of the macros) and then create a process(a meta-macro so to speak) that is a composite of the ones that have been stored. In bothcases, the DGS, will be called on to assist a designer in accessing information albeit ofdifferent types.


12/23


13/23


Given that it is possible to obtain process representations suitable for implementation ona computer system what would be the main tasks for a DGS?

We define designing as [12]:

the process of converting information that characterizes the needs andrequirements for a product into knowledge about a product.

In keeping with our definition we state our perception of knowledge, information anddata. It seems, that a preferred order has been developed among these three terms.Knowledge is the most complex form. By reasoning, discussion and other mind-involvingprocesses, knowledge is derived by human beings from information. If knowledge isstored it becomes information. Data is the simplest form and is characterized by a sense ofhardness. Data and facts are often considered to be equal. Data is information, but not allinformation is data. Since the perception of knowledge and information may vary we willonly use the term information in the following, but one is free to interpret this term asknowledge when appropriate.

In order to support the change of information into knowledge about an artifact, theinformation in a DGS should also be able to change. Since it is impossible to know inadvance what changes may occur we need to incorporate a means for the autonomousacquisition of information. As stated, this acquisition is necessary to support the advicegiven by the DGS to its user. Advice is also necessary to support the acquisition of theinformation itself (e.g., an answer to the question whether the information is relevant).With this in mind we identify two tasks for the DGS:

advising based on the available information, and

acquiring new information.

There are two types of users from which a Design Guidance System can acquireinformation and give advice to, namely,

humans (designers), and technical systems (e.g., databases, computers, experimental setups, monitoring

systems).

The advising and acquisition tasks can be performed by the DGS on request of the user orautonomously. In the first case we consider the DGS to be passive and in the second case

active; designer(s) are always be able to overrule the system. In a ideal scenario a DGSwill support human judgment not replace it.

5.1 Advising a Designer

Ideally the Design Guidance System should provide advice on all aspects of a designprocess. However, in this paper we focus on some important examples by posing anumber of questions which are likely to occur in a Decision-Based Design process.


14/23


What is known about the object of design?It is necessary for a designer to be able to query the system at any time and be advisedabout what is known about the object of design. This information is important for designreview, in planning the next step and also in preventing redundant computations.

What is the path to effect a solution?Given the information stored about the object of design and design processes, the DGSshould be able to advise a designer about how to go about obtaining a solution to theproblem at hand.

What are the dependencies in a design ?A designer may want to make a change in the design at some time during the process.How will this change affect the rest of the design? For example, a change in the type ofengine may have far reaching consequences on the overall design; it will affect the weightwhich in turn may affect stability, etc. Two designers can work concurrently without anyproblems on some aspects of a ship only if there are no information dependencies betweenthe information they are using. We would like the DGS to be able to identify thesedependencies and inform the designers accordingly.

What should be offered as advice?The DGS may be faced with a choice. For instance, consider the issue of which resistanceprediction formula should be recommended for use to a designer. The choice of whichresistance formula to use is dependent not only on the type of vessel being used, the unitsin which it is being designed but also on the stage of design for which the advice is sought.As the design progresses the amount and quality of information changes and the ratio hardto soft information increases. Further, while designing a designer may invoke, at varioustimes, activities which can be classified as diverging, systemizing and converging. A

designer may generate concepts (a diverging activity), evaluate these concepts(systemizing) and then focus on one for further development (a converging activity).These three activities are sometimes called the basic cycle [21]. When diverging, adesigner needs a large amount of shallow information that covers a wide range. Whensystemizing and converging, a designer needs more applied, accurate and deepinformation. Quite clearly the types of programs to be used are quite different for theseactivities.

5.1 The Acquisition of New Information

New information can be acquired from two primary sources, namely, human designers and

technical systems. With this in mind, we pose and answer some of the more interestingquestions.

What can be acquired from a technical system ?Information which can be acquired from a technical system has, in general, a lowcomplexity level. In fact a technical system can only provide data which needs to beprocessed to obtain information having a higher order of complexity. For example, anexperimental setup, such as a towing tank, in a maritime research institute returns usually


15/23


only values for specific system variables. In order to be useful in designing the data needsto be converted into a more useful representation. Typical ways to convert raw data intouseful and general representations which can be used in design are regression analysis,induction, etc.

What can be acquired from the Design Guidance System itself ?Since the Design Guidance System is itself a technical system it can also acquire newinformation from knowledge bases. It could take elements of information and combinethese elements into a new more complex element of information. Thus new information(and also knowledge) can be acquired by means of synthesizing existing information. Forinstance, when asked by a designer as to how the resistance of a ship can be calculated, asubsystem of the DGS (the ASSIST-utility [3, 31]) can generate a path of relationshipswhich will conclude with a value of the resistance. This path which is the result of anadvising activity can be stored as a new relationship, that is, a new information element.Guided by a designer, the DGS can learn from its own knowledge base.

How does new information contribute to existing information ?The creation of a new information element may be driven by the need for a generalizationor specialization of existing information. Generalization will increase the applicability ofinformation and therefore may provide some sense of "creativity". For instance, someprinciples from the design process of aeroplanes have been successfully applied in shipdesign as well. The design of the well-known winged keels, e.g., as used by the twelvemeter sailing yacht Australia II which won the America's Cup in 1984, is based onprinciples used in the design of aeroplane wings. This is an example of generalization ofdomain dependent information. It was recognized, that the only major difference wasthe medium (gas or fluid) surrounding the wing. If all relationships between the mediumand the other design variables are known we could simply introduce or generalize themedium, in principle. Another example of generalization is the synthesis of a relationship

from data by means of regression analysis. Automation of such kinds of generalizations ishighly desirable and its development will involve considerable effort.

Specialization increases the accuracy and certainty of information. Specialization willgenerally increase the domain dependency of the information. Especially in the laterstages of design more accurate information is needed and thus the need for generalizationdecreases whereas the need for specialization increases. Specialization is easier toaccomplish than generalization. Most of the information entered by a designer will bespecial for his/her design.

What can be acquired from humans ?

Information with a high level of complexity has to be acquired from humans. Models ofcomplex processes can only be acquired form humans. A human is especially valuable inproviding soft information. A human designer embodies experience, creativity andcommon sense. For instance, when developing a regression model a designer may bebetter informed than a computer whether a particular model makes sense in the real world.Capturing such insight is very important for developing an effective DGS over time.


16/23


6. TOOLS TO SUPPORT ACQUISITION AND ADVISING

Acquisition of information and advising are the main tasks for the DGS. To support thesetasks various tools are necessary. Most of these tools can be used both in the context ofinformation acquisition as well as advising. In Figure 4 a framework of the tools and

activities is shown. Acquisition and advising are shown as the two poles of the DGSactivities. They are diametrical opposite around a center of tools available in the DGS tosupport these two prime activities.

Basic Tasks of DGS:

Environment for DGS:

Acquisition of (new) information

Advice based on the embeddedinformation

Humans(users)

Technical Systems(computer systems, experimentalsetups, monitoring systems, etc.)

REALWORLD

ENVIRONMENT

TECHNICAL SYSTEMSHUMANS

TOOLSACQUISITION ADVICE

KNOWLEDGEBASE

DGS

Figure 4 -- Framework of Tools and Activities of a DGS

The knowledge base is portrayed as a reflection or an image of the environment in whichthe DGS operates. The aim of course is to make this image as accurate as possible. Thiscan be achieved by improving the tools in the DGS continuously. The set of tools in theDGS is portrayed as a lens between the DGS knowledge base and the environment. Thelight, i.e., information, can pass through the lens from both sides. The direction dependson whether the DGS is in the advising or acquisition mode. As in the case of light passingthrough a lens information passing through the tools may be altered. For instance, it maybe analyzed like light in a spectrum by a prism. By reversing the prism, differentinformation entities may be combined and synthesized into a new, more useful, entity.


17/23


D

GS

TOOLS

KNOWLEDGE AND

INFORMATION

ACQUISITION

ADVICE

REAL WORLDENVIRONMENT

COMPUTERENVIRONMENT

DGS TOOL SET:

an Optical Instrument

between the

Real World

and the

Computer

Figure 5 -- Design Guidance System: A Lens for Knowledge and Information

In some ways we see some similarities between our efforts in developing a DGS and in thebuilding of an optical lens (see Figure 5). A set of tools (for example, the DPSTWorkbook, DSIDES, HOSDES) have already been developed. These tools constitute thelens through which information passes. However, we hasten to add that our lens is stillcrude and our efforts are focused on improving it. We propose to do this by adding theDGS to this tool-kit; a DGS that is itself open-ended and designed to accommodatechanges in the tool-kit. We classify the tools required to support the tasks of the DGSinto four categories:

Information Analysis Tools. Information Synthesis Tools. Information Evaluation Tools. General Support Tools.

The discussion that follows is not comprehensive. In it we highlight, through example, thecharacteristics of tools in each of the preceding categories.

6.1 Information Analysis Tools

These are tools with which to decompose a complex information entity (e.g., amathematical function) into its elements (e.g., variables, numbers and mathematicaloperators) and to analyze these elements. Two examples follow.

As indicated in Section 4.2, it is necessary to be able to monitor a designersactivities to obtain a model of the process being followed. To provide advice itis necessary to decompose the model into its entities (see Figure 2) and then


18/23


analyze these entities. In other words obtain a higher level of information thanwhat is obtained through monitoring.

Consider a mathematical representation of a constraint. Various systemvariables and mathematical functions may have been used in this constraint. Inorder to determine whether the constraint is satisfied or not these system

variables and mathematical functions need to be detected in the constraint bythe DGS. If their current values are known, the degree of feasibility of theconstraint can be determined and thus new information is obtained.

In both cases a designer may be prompted for assistance.

6.2 Information Synthesis Tools

These are tools with which to compose a complex information entity using other entitieselements (e.g., an inference network from production rules). Tools for building models ofprocesses fall into this category. Low level information can be combined and promotedinto a higher order (this is an example where the distinction between knowledge andinformation becomes small). For instance, data can be synthesized into analyticalrelationships by regression analysis or curve fitting. Induction algorithms like ID3 [32]combine data into rules. Other data can be synthesized into this model to generalize orspecialize it. Relationships can be combined into higher order relationships by inferencetools. Programming is also an example of synthesizing information. Model building ordefining a Decision Support Problem is another example. Tools to support, or evenperform these tasks autonomously, fall into this category. Again, in all cases a designermay be prompted for assistance since he/she is an essential part of the acquisition andadvising loop.

6.3 Information Evaluation Tools

These are tools with which to determine the value associated with a certain informationentity (e.g., the value of a mathematical function). Synthesis and analysis of informationprovide new information. But what is the value of information? For instance, a rule canbe true or false. We need to know whether a constraint is satisfied. Currently a syntaxparser, that functions as an interpreter, is available to analyze and evaluate mathematicaland logical expressions. This parser needs to be rewritten (so that it can be compiled) forit to be useful in evaluating complex, higher level relationships like the compromise DSPs.

6.4 General Support Tools

These are tools which do not fit within the previous categories. Some important examplesare:

interface tools for the environment, which include tools for internal informationstorage,

information recognition tools, which detect different information entities whichseem to be independent, but in fact are highly correlated (e.g., boat and ship),and


19/23


consistency control tools, which passively/actively maintain the consistency ofthe information

Interface to the environment: Information needs to be visible for the environment of theDGS. The interface to the real world environment can be divided into a machine and user

interface for communicating with technical systems and humans. The user interface needsto be very user-friendly. The interface for the DGS is being developed using the publicdomain X Windows software which allows portability to various computer systemswithout modification.

Recognition of information: For storing and retrieving items in a knowledge base oneneeds key-words. This may appear to be a simple task but difficulties arise when differentpieces of informationhave to be stored which at first glance seem to have no correlation,but in fact are just different descriptions of the same object, for example, the words carand automobile. This is known as a semantic variation.

The problem of semantic variation involves pattern recognition. One approach to solvingthis problem is to establish attributes which can then be mapped using techniques such asdiscriminant analysis, cluster analysis and neural networks [33-35]. This approach, atpresent, is more in the realm of research than practice. Another approach, to tackling theproblem of semantic variation is to define a synonym list (like in modern word-processors)and/or define SHIP = BOAT kind of relationships. For the moment, we are contemplatingusing the second approach in the proto-typical development of the DGS. We recognizethat this approach may result in a combinatorial explosion.

Consistency control: Tools for consistency control are essential. Ignizio [32] describesfive types of inconsistency to be identified in rule-based expert systems. If we userelationships instead of rules, the same types inconsistencies occur, namely,

redundant relationships, conflicting relationships, subsumed relationships, unnecessary parameters in the relationship, and circular relationship chains, i.e., loops.

A tool for consistency control which can take care of the above-mentioned inconsistenciesshould be developed. Also hidden inconsistencies caused by using a differentidentification for the same information item should ideally be detected.

7. SOME RESEARCH AND DEVELOPMENT ISSUES

A working prototype shell of the Design Guidance System has been developed. Furtherdevelopments will be added to this shell. The following has been completed:

A structure for a domain independent information representation has beendeveloped. At present a hierarchical knowledge base for the aforementioned


20/23


representation is simulated using a file structure. Corresponding storage andretrieval tools have been developed, as well as a simple user interface,including print and list routines. These tools will be replaced, at some othertime, by more sophisticated developments.

A syntax parser for the analysis, synthesis and evaluation of certain types of

information is available. A submodule of the ASSIST utility which can generate calculation/inferencenetworks from relationships is available.

A submodule of ASSIST which can be used to identify all possible calculationpaths in a network with multiple alternative calculation methods at one node isavailable.

The efforts within the Systems Design Laboratory are being directed in four areas:

Development of the capability to analyze, synthesize and evaluate complexcalculation paths/networks. This work is necessary to define complexrelationships and will be used to formulate compromise DSPs. The DSIDESsystem is available for solving Decision Support Problems.

Development of the capability to maintain consistency within the knowledgebase.

Development of a user-interface using X-windows software. Development of the capability to analyze, synthesize and evaluate design

processes. We recognize that this development is important and a majoramount of our effort is being directed to this activity.

Three projects that will be undertaken shortly are as follows:

Integration of DSIDES with a data base that supports concurrent engineering

such as ROSE [36]. Development of a simplified information recognition system as described in the

preceding section. The development of cases with which to test various features of the DGS.

Decision Support Problem templates for use in the conceptual design of shipshave been implemented in AUSEVAL [4]. We propose to use AUSEVAL andits templates to test various features of the DGS.

Much remains to be done and as we have learned to say, since we came to Texas, y'allcome! There is so much to do.

ACKNOWLEDGEMENTS

Over the years support for the development of the Decision Support Problem Techniquefor ship design has come from two sources. We gratefully acknowledge the following:Brian Robson of the Department of Defence (Navy), Canberra, Australia in 1983 initiatedthe work reported in this paper with a grant (for developing AUSEVAL: A ShipEvaluation System) and is responsible for sending two of his naval architects, Tim D. Lyon


21/23


and Warren Smith to work at the University of Houston. Peter van Oossanen and BertKoops of MARIN: The Netherlands Ship Model Basin, Wageningen, Holland, in 1988,joined the Canberra-Houston team by funding our work and sending Bert Bras to workwith us in Houston. The financial contribution of our corporate sponsor the BF GoodrichCompany to further develop the Decision Support Problem Technique is gratefully

acknowledged. The development of an X Windows interface for DSIDES is being fundedin part by a grant from the Texas Advanced Technology Program (Grant No. 3652-227).

REFERENCES

1. D. E. Calkins,"Ship Synthesis Model Morphology", Proceedings 13th ShipTechnology and Research (STAR) Symposium/3rd International Marine SystemsDesign Conference (IMSDC), Pittsburgh, Pennsylvania, 1988, 279-306.

2. A. Koops, A. C. W. J. O. Oomen and P. Van Oossanen,"HOSDES: A NewComputer-Aided System for the Conceptual Design of Ships", ProceedingsBicentennial Maritime Symposium, Sydney, Australia, 1988, 17-29.

3. A. Koops, A. C. J. W. Oomen and B. A. Bras,"Computer Aided Design Assistanceand Decision Support", Proceedings ICCAS, Shanghai, China, 1988,

4. W. F. Smith, T. Lyon and B. Robson,"AUSEVAL - A Systems Approach for thePreliminary Design of Naval Ships", Proceedings Bicentennial Maritime Symposium,Sydney, Australia, 1988, 1-16.

5. W. F. Smith,"AUSEVAL - The Application of the Decision Support ProblemTechnique to Ship Design", Proceedings International Workshop on EngineeringDesign and Manufacturing Management, Melbourne, Australia, 1988, 127-147.

6. F. Mistree, W. F. Smith, B. Bras, J. K. Allen and D. Muster,"Decision-BasedDesign: A New Paradigm for Ship Design", Transactions Society of NavalArchitects and Marine Engineers, San Francisco, California, 1990.

7. D. Muster and F. Mistree, "The Decision Support Problem Technique in EngineeringDesign", The International Journal of Applied Engineering Education, 4(1), 1988,23-33.

8. F. Mistree, S. Z. Kamal and B. A. Bras, "DSIDES: Decision Support in the Designof Engineering Systems", Systems Design Laboratory Report, University ofHouston, Houston, Texas, 1989.

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

10. S. Finger and J. R. Dixon, "A Review of Research in Mechanical EngineeringDesign. Part 1: Descriptive, Prescriptive, and Computer-Based Models of Design

Processes",Research in Engineering Design, 1, 1989, 51-67.11. S. Finger and J. R. Dixon, "A Review of Research in Mechanical Engineering

Design. Part 2: Representations, Analysis, and Design for the Life Cycle", Research

in Engineering Design, 1, 1989, 121-137.12. F. Mistree and D. Muster,"Conceptual Models for Decision-Based Concurrent

Engineering Design for the Life Cycle", Proceedings of the Second NationalSymposium on Concurrent Engineering, Morgantown, West Virginia, 1990,


22/23


13. J. P. Pennell and M. M. G. Slusarczuk, "An Annotated Reading List for ConcurrentEngineering", IDA Document D-571, Institute for Defense Analyses, Alexandria,Virginia, 1989.

14. R. I. Winner, J. P. Pennell, H. E. Bertrand and M. M. G. Slusarczuk, "The Role ofConcurrent Engineering in Weapons System Acquisition", IDA Report R-338,

Institute for Defense Analyses, Alexandria, Virginia, 1988.15. S. Azarm, D. A. Dierolf, J. Naft, M. Pecht, K. J. Richter and B. T. Sawyer,"Decision Support Requirements in a Unified Life Cycle Engineering (ULCE)Environment", IDA Paper P-2064, Institute for Defense Analyses, Alexandria,Virginia, 1988.

16. M. Brei, W. E. Cralley, D. A. Dierolf, D. J. Owen, K. J. Richter and E. Rogan,"Architecture and Integration Requirements for an ULCE Design Environment",IDA Paper P-2063, Institute for Defense Analyses, Alexandria, Virginia, 1988.

17. U. D. W. Group, "Decision Support Requirements in a Unified Life CycleEngineering (ULCE) Environment", IDA Paper P-2064, Institute for DefenseAnalyses, Alexandria, Virginia, 1988.

18. D. E. Calkins, R. S. Gaevert, F. J. Michel and K. J. Richter, "Aerospace SystemUnified Life Cycle Engineering: Producibility Measurement Issues", IDA Paper P-2151, Institute for Defense Analyses, Alexandria, Virginia, 1989.

19. N. Cross,Engineering Design Methods , John Wiley & Sons, Chichester, 1989.20. M. M. Andreasen,"Design Strategy", Proceedings 1987 International Conference on

Engineering Design, Boston, 1987, 171-178.21. S. J. De Boer, Decision Methods and Techniques in Methodical Engineering

Design , Academisch Boeken Centrum, De Lier, The Netherlands, 1989.22. M. S. Fox and S. Safier,"Problem Solving Architectures for Computer-Assisted

Design", Proceedings of the Second National Symposium on ConcurrentEngineering, Morgantown, West Virginia, 1990.

23. K. D. Forbus, "Intelligent Computer-Aided Engineering",AI Magazine, (Fall), 1988.

24. R. E. Fulton, C. Pin-Yeh and K. J. Richter, "Managing Engineering DesignInformation", IDA Paper P-2154, Institute for Defense Analyses, Alexandria,Virginia, 1989.

25. F. Mistree, D. Muster, J. A. Shupe and J. K. Allen, "A Decision-Based Perspectivefor the Design of Methods for Systems Design, Recent Experiences inMultidisciplinary Analysis and Optimization", NASA CP 3031, NASA, 1989.

26. J. A. Shupe, "Decision-Based Design: Taxonomy and Implementation", Ph.D.Dissertation, Department of Mechanical Engineering, University of Houston,Houston, Texas, 1988.

27. J. A. Shupe, D. Muster, J. K. Allen and F. Mistree, "Decision-Based Design: SomeConcepts and Research Issues", Expert Systems, Strategies and Solutions in

Manufacturing Design and Planning, A. Kusiak ed., Society of ManufacturingEngineers, Dearborn, Michigan, 1988.

28. J. K. Allen, J. Hong, S. Adyanthaya and F. Mistree, "The Decision SupportTechnique Workbook for Life Cycle Engineering", Systems Design LaboratoryReport, University of Houston, Houston, Texas, 1989.

29. K. J. MacCallum and D. K.J. H.B.,"Approximate Calculations in PreliminaryDesign", Computer Application in the Automation of Shipyard Operation and ShipDesign 5 (ICCAS), Trieste, Italy, 1985.


23/23


30. H. B. Duffy and K. J. MacCallum, "Computer Representation of Numerical

Expertise for Preliminary Ship Design",Marine Technology, 26(4), 1989, 289-302.31. J. C. Stoop, "Assist Utility", HOSDES Project Report 47621-5-RD, Maritime

Research Institute Netherlands, Wageningen,The Netherlands, 1986.32. J. P. Ignizio, An Introduction to Expert Systems: The Methodology and its

Implementation , McGraw-Hill, New York, 1990.33. D. G. Kleinbaum, L. L. Kupper and K. E. Muller, Applied Regression Analysis andOther Multivariable Methods, The Duxbury Series in Statistics and DecisionSciences, PWS-KENT Publishing Company, Boston, 1988.

34. J. L. McClelland and D. E. Rumelhart, Explorations in Parallel DistributedProcessing - A Handbook of Models, Programs and Exercises, The MIT Press,Boston, 1988.

35. J. L. McClelland and D. E. Rumelhart, Psychological and Biological Models ,Parallel Distributed Processing - Explorations in the Microstructure of Cognition,The MIT Press, Boston, 1988.

36. M. Hardwick, D. Spooner, E. Hvannberg, B. Downie, A. Faulstich, D. Loffredo, A.Mehta, D. Sanderson, R. Harris, G. Abou-Ezzi, J. Gong and J. Young, "ROSE: ADatabase System for Concurrent Engineering Applications", Report Number 89062,Rensselaer Design Research Center, Rensselaer Polytechnic Institute, Troy, NewYork, 1990.