THE DEVELOPMENT OF A DESIGN GUIDANCE SYSTEM FOR THE EARLY STAGES OF DESIGN

BERT BRAS1 WARREN F.SMITH2 FARROKH MISTREE3

MARIN, MARITIME RESEARCH INSTITUTE NETHERLANDS, WAGENINGEN, THE NETHERLANDS, Currently RESEARCH ASSOCIATE, OPERATIONS RESEARCH PROGRAM, UNIVERSITY OF HOUSTON, 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 OF HOUSTON, HOUSTON, TEXAS. 77204-4792 3 PROFESSOR, DEPARTMENT OF MECHANICAL ENGINEERING, UNIVERSITY OF HOUSTON, HOUSTON, TEXAS. 77204-4792 Address all correspondence to Farrokh Mistree

Abstract The Maritime Research Institute Netherlands (MARIN) is developing a flexible and open ship design system called HOSDES. In a triumvirate of collaborative cooperation, the System Design Laboratory (University of Houston), MARIN and the Royal Australian Navy have combined their research and development efforts towards achieving a Design Guidance System for the HOSDES system. The principal function of this Design Guidance System is to increase both the efficiency and effectiveness of a human designer who is designing a ship using HOSDES. In this paper some issues associated with the development 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).

The Development of a Design Guidance System

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 the execution of individual computer programs (or modules) within the computer system. Invariably, the computer systems for design include individual programs which were developed, in the past, as stand-alone systems. The incorporation of these programs into the overall system is a major bottleneck requiring an expenditure of large amounts of time and other resources to transport and convert information from one format to another and to ensure its correct use. Therefore, it is not surprising that naval architects are interested in the development of application software that can not only be used independently but can also communicate with each other in the broader context of a computer system for supporting design. A number of these type of systems for ship design are currently under development [1-5]. The Maritime Research Institute Netherlands (MARIN) is currently developing HOSDES for use in the design of ships. The guiding philosophy in HOSDES is to place a designer in a central role in a flexible computer-based design environment [2, 3]. This is achieved through: 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 various program modules in HOSDES, and focusing on providing support for a human designer rather than a black-box approach towards design automation. HOSDES, has at its core a complex interactive information management system that makes use of a central relational database as well as a library of program modules. These program modules embody MARIN's world-renowned experimental experience and their wealth of knowledge in hydromechanics. The development of HOSDES enables MARIN to draw upon the knowledge embodied in these individual program modules in a single, widely accessible design environment. The flexibility and variety of options available in the fully-developed HOSDES, however, could overwhelm a designer; hence, the need for a Design Guidance System (DGS). Koops et al. [3] define two major areas for assistance in a flexible (open-ended) ship design system like HOSDES, namely, identifying the most appropriate path through the (HOSDES) system for a given design problem, and finding the best possible solution for a design problem in terms of quality checks and the presentation of possible ways to improve the design.

The Development of a Design Guidance System This gives rise to the following question: How can we increase the efficiency1 and effectiveness2 of human designer(s) who use HOSDES to design ships? But first some information on the motivation for developing a Design Guidance System. 2. THE DESIGN GUIDANCE SYSTEM: POTENTIAL BENEFITS

ITS PRINCIPAL FUNCTION AND

2.1

What are HOSDES, DSIDES and the Design Guidance Systems?

Visualize a camera and assume that this camera symbolizes the computer-based design system we wish to create. Why? Let us explain. A camera is used by a human to capture an image (picture) of an object in the real world. Similarly, a computer-based design system is to be used by a human designer to create a representation of a real world engineering system; ideally one that can be manufactured and maintained. Both the camera and the design system are inanimate; both depend on human direction to realize an image of a system in the real world. The quality of a picture taken with any camera is, in the ultimate, dependent on the person taking the photograph; so too the design from the computer-based design system. system. The quality of the camera affects the quality of the 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 human designer to create a representation (an image) of a ship in its database. Just as a human exercises control over a camera a human designer exercises control over HOSDES; a human in both cases has ultimate control. Light (knowledge and information) reflected from 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)

Design System (Capturing a Solution)

Computer-Based Solution (An Image)

1 2

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. We consider effectiveness to be a measure of quality of a decision (correctness, completeness, comprehensiveness) that is made by a designer.

The Development of a Design Guidance System

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 be taken, 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 compare the 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 be improved so let us focus on the second action. How can we improve the interaction between a human operating a camera or a design system? A photographer using one of the earlier cameras had to do everything based on experience and insight. He/she would look at the sky, judge the amount of light, judge the distance and adjust the diaphragm and focus accordingly. Newer cameras included light meters and a means to judge whether the camera was focussed was embedded in the view finder. The photographer used these aids set the aperture and timing and was still required to focus the camera. The DSIDES system3 is to HOSDES what the light meter and the focusing aid are to the camera. As we all know, a photographer can always ignore the aids and operate the camera manually. In some cases there is no other way. Anybody who has taken pictures at night (e.g., the moon, a city s skyline) knows that the semi-automatic features are useless and a switch 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 DSIDES system - maybe simply because the DSIDES system is not equipped to handle such situations. Has evolution of cameras stopped? The answer is an emphatic no. Nowadays, cameras that have the capability to automatically focus and adjust timing and diaphragm, are not only available but are relatively inexpensive. The control unit of this camera attuned to the environment; it is embodied with some intelligence. This intelligence is used to take information from the environment, process it, adjust the controls, and advise a photographer that it is ready to take a picture. The DGS is to HOSDES what the intelligent 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 could be 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.

The Development of a Design Guidance System

both cases a human can ignore the assistance proffered by the control unit and negate its actions. In other words, a human has ultimate control and is responsible for the quality of the 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 that helps a designer use HOSDES as efficiently and effectively as possible. And what about the DSPT Workbook? Well, the DSPT Workbook is akin to the camera body; a body to which to which various lenses can be attached. The camera body will embody the intelligent control unit (DGS) and the means for decision support (DSIDES). Changing the lens of the camera from, say, a wide angle to a telephoto is akin to focussing on different domains. In this analogy, the camera body represents the domain independent information, whereas the lens contains the domain dependent information. However, there is a tradeoff. The lens must be suitable to fit to the body. In other words, the domain dependent information (lens) must be in a form suitable to be handled by the domain independent information (camera body). This is a limitation - but just contemplate the advantages! 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 the efficiency and effectiveness of a designer as he/she designs a ship in general and negotiates a solution to a design problem in particular. We believe that, in the ultimate, support for a human designer can be provided via a design guidance system only if a model of the process 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 artifact is 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 important as the artifact is, understanding the process is equally, if not more, important. Once the process is understood, the knowledge gained can be used to increase the efficiency and effectiveness of another designer. Therefore, we believe developing an understanding of the process of design itself is important. One could compare designing without any information about the process with crossing a country in, say, Europe with only streetmaps of various cities in it but with no country map showing major roads. With some luck the country can be crossed. If a country map that included roads was available and used the amount of effort and time spent could be significantly 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 also information on the process 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 of designers working in different design environments would be different. In this paper, we describe some issues associated with the development of a DGS in general but with the focus clearly on a Design Guidance System for HOSDES. Consequently our perspective

The Development of a Design Guidance System

is clearly rooted in Decision-Based Design [6], the Decision Support Problem Technique [7], and the DSIDES [8] and HOSDES computer systems. Hence, the following statement: The principal function of our Design Guidance System is to support human designers in increasing their efficiency and effectiveness in designing ships using HOSDES 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 of frigates. Our interest, therefore, is in developing a Design Guidance System to support a human designer in the early stages of project initiation in general and the HOSDES system in 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 the Institute of Defence Analysis [9]: The importance of early design decisions is widely recognized. It is often stated that roughly 70 percent of the total life cycle cost of the system is determined during the conceptual phase. Due to the lack of hard data, very few traditional CAD tools are available to support the early stages of design. Considering the high 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 a designer in the early stages of design is clear from the preceding quote. If this problem is so significant then what is available? In their comprehensive review of the research in mechanical engineering design Finger and Dixon state [10, 11]: An important area that has received little attention to date is the creation of design environments that integrate available tools into a consistent system to support the designer. Therefore, we focus our research and development efforts on developing a DGS that is geared towards increasing the efficiency and effectiveness of a designer in the early stages of 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.

The Development of a Design Guidance System

3.

ON INCREASING THE EFFICIENCY AND EFFECTIVENESS OF HUMAN DESIGNERS How?

3.1

How can the efficiency and effectiveness of a designer be increased through the use of a Design Guidance System? We assert that the efficiency and effectiveness of a designer can 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 of design automation. A reduction in the number of iterations is profitable especially when iterations are very costly; this issue is yet to be resolved. Often flaws in the solution to the design problem are detected during manufacturing and even maintenance. The corrective redesign effort is usually extremely expensive and ideally should be have been designed out prior to manufacture. The effort to reduce such costly iterations has provided the stimulus for developing approaches to design that include life cycle considerations (that is, design, manufacture and support). Approaches to design that incorporate life cycle considerations include concurrent engineering [12-14], simultaneous engineering, Unified Life Cycle Engineering (ULCE) [9, 15-17], producibility engineering [18]. Companies which have made use of some of these approaches have reported impressive benefits [14]. 3.2 What is Needed?

An increment in iteration speed can be achieved if at least some parts of a design process are known and can be modelled. To achieve a reduction in the number of iterations not only a model of the process but also information that can be used to determine how the process can be improved is needed. By creating a model of a process of design and implementing 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 able to analyze it, debug it, find redundancies, inconsistencies, store it for future reference or usage. Also we would like to be able to detect (sub)processes which are independent of each other and could therefore be solved concurrently, thus saving time. The basic notion is that as long as a model of the process to be used for designing can be obtained and analyzed 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, will be impossible. Given the preceding, two fundamental questions need to be answered. The questions: 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 ?

The Development of a Design Guidance System These questions are addressed in the following sections.

4. 4.1

ON DEVELOPING A DESIGN GUIDANCE SYSTEM - OUR APPROACH 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 models is to persuade or encourage designers to adopt a particular way of doing design. Many prescriptive models have been developed and proposed over the years. Descriptive models embody sequences of activities that typically occur in a design process. These models exemplify how design is done and not what should be done to arrive at a solution However, 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. De Boer [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 questionable whether a complex process like ship design can be described in one single information form, e.g., rules or optimization models. Numerous efforts have (unfortunately) been undertaken 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 any design process is almost always provided in different forms, for example, a computer program, knowledge base, rule, neural network, mathematical programming formulation, a simple formula, raw data, program output, etc. Hence, we contend that any information management system developed for design must be capable of supporting the storage and processing 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 both numeric and non-numeric methods, is needed. Fulton et al. [24] provide an extensive discussion on managing engineering design information. They conclude that conventional Database Management Systems developed for business and administration oriented environments cannot fulfill the functional requirements for engineering design. These deficiencies have led to the development of many data/process modeling methodologies (e.g., IDEF0, Entity Relationship Models, Object Oriented Data Models, etc.). Fulton et al. studied seven of those methodologies for engineering design using an aircraft design case study. Their conclusion with respect to this is as follows: The study indicated that none of the existing modeling techniques is adequate for supporting the overall aerospace vehicle design process. The OODM (Object

The Development of a Design Guidance System Oriented Data Model) seems to possess many of the features required for the ideal design decision support system for modeling the aerospace vehicle design process. Some of the features that the OODM lacks are embodied in other methodologies. It is felt that research toward an extended information modeling methodology, 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 of design processes and their implementation on a computer bear further investigation. The emphasis by Fulton and co-workers on the need for providing decision support is also noted. With this as background we summarize our approach in developing a Design Guidance 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 the principal function of a designer is making decisions associated with the design of an artifact [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 the University of Houston. Support for human designers is provided through the solution of Decision Support Problems. The process of design is modeled using entities, for example, phases, events, decisions, tasks and the like. A designer working within the DSP Technique 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 their intended plan of action using the aforementioned entities. By using the aforementioned entities to model a plan of action descriptions of processes in a common "language" for teams from various disciplines is possible and can be stored for further use. The software for implementing the DSP Technique is called the DSIDES system (Decision Support in the Design of Engineering Systems) [8] and the DSPT Workbook [28]. The Royal Australian Navy has incorporated DSIDES within AUSEVAL [4, 5]. AUSEVAL is a proto-typical system for the preliminary design of naval and commercial ships using Decision 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 are shown in Figure 2. The entities are discussed in more detail in [6].

The Development of a Design Guidance System

10

P E T ? i ? ? ? ?

Phase

Event

Task

Decision

Information

Compromise DSP Preliminary Selection DSP Selection DSP

i
System

System Variable Goals / Bounds Constraints Analytical Relationship

Figure 2 -- Basic Entities for Modeling Design Processes In general, these entities are relationships with one input and one output. A model/network of a process is created by connecting entities in a systematic fashion. An example of a model of preliminary ship synthesis using some of the basic entities is given in Figure 3. Further information is provided in [6].

The Development of a Design Guidance System

Preliminary Design E i

11

Top Level Specification Ship Characteristics

Goals and Constraints

Refine Goals and Constraints

Hull Analysis Basic Concept

Goals and Constraints

i
Order Information Propeller Concepts & Attributes Model Solution Prepare Documents

Top Level Specification

i i

T i
General Design Knowledge

i
Propeller Analysis

?
? Preliminary Ship Synthesis

Ship Characteristics

Experimental Validation

i
Experimental Information

Figure 3 -- A Model of Preliminary Ship Synthesis [6] How will the process models be obtained from a designer? One possibility is, that a designer will explicitly enter a model of his/her design plan (akin to creating a macro on a computer) and then follow it. In this case the plan will be used in a like manner to a prescriptive 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, a designer would examine the available models (look at available macros in the macro library), 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 both cases, the DGS, will be called on to assist a designer in accessing information albeit of different types.

The Development of a Design Guidance System

12

Can we always depend a designer to provide an explicit model of the design process for implementation on a computer? The answer is no. It is possible for a designer to have a mental construct of a plan of action but not in a form that can be explicitly entered into a computer. In this case, we would resort to monitoring (with permission of course) to obtain a descriptive model of the process just completed. Two examples of support that could be provided by the DGS follow: As a designer is designing and being monitored the DGS could recognize that what the designer is attempting to do has been done before and advise the designer accordingly (something akin to using a spell checker in a word processor with the suggest option active). Suppose a designer specifies a constraint on the diameter of a propeller. The DGS could autonomously search the knowledge base(s) to find a relationship or procedure which would determine the numerical value of the propeller diameter. What is the basis of an information representation scheme? It is clear from the preceding that a uniform information representation scheme is necessary. It can be created by recognizing that all forms of information are relationships with an input and an output. In this way relationships of different types can be combined into models, that is, hierarchies. These hierarchies represent information at a higher level of complexity. An example of this is the combination of subroutines into a Fortran program module. In this case, several relationships are being combined into a larger, more complex relationship. Extensive work in the use of relationships in a ship design environment is being performed by MacCallum et al. [29, 30]. What is the essence of our approach? In summary our approach to solving the two fundamental problems identified in Section 3.2 is as follows: Let a designer specify a model of his/her design process explicitly (by entering) and/or implicitly (by allowing a computer to monitor). Classify all information into certain basic entities (e.g., phases, events, decisions, tasks, systems, goals) and consider all information as relationships with an input and an output. Use the entities to build networks which model design processes and are represented in a form suitable for manipulation. This approach will allow us to obtain computer-based descriptive models of a design process. These descriptive models can subsequently be manipulated and improved in a computer environment to form the basis of prescriptive models (which could be offered as advice) for a designer in a new situation. The manipulation for improvement could be done by a designer, by a designer in collaboration with the DGS or autonomously by the DGS itself. The development of this capability to analyze and improve the design process, we believe, will contribute to increases in the efficiency and effectiveness of a designer using the HOSDES system. Further information about our approach is given in [6].

5.

MAIN TASKS FOR A DESIGN GUIDANCE SYSTEM

The Development of a Design Guidance System

13

Given that it is possible to obtain process representations suitable for implementation on a 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 and requirements for a product into knowledge about a product. In keeping with our definition we state our perception of knowledge, information and data. 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-involving processes, knowledge is derived by human beings from information. If knowledge is stored it becomes information. Data is the simplest form and is characterized by a sense of hardness. Data and facts are often considered to be equal. Data is information, but not all information is data. Since the perception of knowledge and information may vary we will only use the term information in the following, but one is free to interpret this term as knowledge when appropriate. In order to support the change of information into knowledge about an artifact, the information in a DGS should also be able to change. Since it is impossible to know in advance what changes may occur we need to incorporate a means for the autonomous acquisition of information. As stated, this acquisition is necessary to support the advice given by the DGS to its user. Advice is also necessary to support the acquisition of the information 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 acquire information 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 or autonomously. 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 DGS will support human judgment not replace it. 5.1 Advising a Designer

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

The Development of a Design Guidance System

14

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 advised about what is known about the object of design. This information is important for design review, 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 DGS should be able to advise a designer about how to go about obtaining a solution to the problem 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 of engine may have far reaching consequences on the overall design; it will affect the weight which in turn may affect stability, etc. Two designers can work concurrently without any problems on some aspects of a ship only if there are no information dependencies between the information they are using. We would like the DGS to be able to identify these dependencies 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 resistance prediction formula should be recommended for use to a designer. The choice of which resistance formula to use is dependent not only on the type of vessel being used, the units in 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 hard to soft information increases. Further, while designing a designer may invoke, at various times, 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, a designer needs a large amount of shallow information that covers a wide range. When systemizing and converging, a designer needs more applied, accurate and deep information. Quite clearly the types of programs to be used are quite different for these activities. 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 interesting questions. What can be acquired from a technical system ? Information which can be acquired from a technical system has, in general, a low complexity level. In fact a technical system can only provide data which needs to be processed to obtain information having a higher order of complexity. For example, an experimental setup, such as a towing tank, in a maritime research institute returns usually

The Development of a Design Guidance System

15

only values for specific system variables. In order to be useful in designing the data needs to be converted into a more useful representation. Typical ways to convert raw data into useful 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 new information from knowledge bases. It could take elements of information and combine these elements into a new more complex element of information. Thus new information (and also knowledge) can be acquired by means of synthesizing existing information. For instance, when asked by a designer as to how the resistance of a ship can be calculated, a subsystem of the DGS (the ASSIST-utility [3, 31]) can generate a path of relationships which will conclude with a value of the resistance. This path which is the result of an advising 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 generalization or specialization of existing information. Generalization will increase the applicability of information and therefore may provide some sense of "creativity". For instance, some principles from the design process of aeroplanes have been successfully applied in ship design as well. The design of the well-known winged keels, e.g., as used by the twelve meter sailing yacht Australia II which won the America's Cup in 1984, is based on principles used in the design of aeroplane wings. This is an example of generalization of domain dependent information. It was recognized, that the only major difference was the medium (gas or fluid) surrounding the wing. If all relationships between the medium and the other design variables are known we could simply introduce or generalize the medium, 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 is highly desirable and its development will involve considerable effort. Specialization increases the accuracy and certainty of information. Specialization will generally increase the domain dependency of the information. Especially in the later stages of design more accurate information is needed and thus the need for generalization decreases whereas the need for specialization increases. Specialization is easier to accomplish than generalization. Most of the information entered by a designer will be special for his/her design. What can be acquired from humans ? Information with a high level of complexity has to be acquired from humans. Models of complex processes can only be acquired form humans. A human is especially valuable in providing soft information. A human designer embodies experience, creativity and common sense. For instance, when developing a regression model a designer may be better 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.

The Development of a Design Guidance System 6. TOOLS TO SUPPORT ACQUISITION AND ADVISING

16

Acquisition of information and advising are the main tasks for the DGS. To support these tasks various tools are necessary. Most of these tools can be used both in the context of information 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 DGS activities. They are diametrical opposite around a center of tools available in the DGS to support these two prime activities.

Basic Tasks of DGS: Acquisition of (new) information Advice based on the embedded information

REAL WORLD ENVIRONMENT TECHNICAL SYSTEMS HUMANS

ACQUISITION

TOOLS

ADVICE

Environment for DGS: Humans (users) Technical Systems (computer systems, experimental setups, monitoring systems, etc.)
KNOWLEDGE BASE

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 which the DGS operates. The aim of course is to make this image as accurate as possible. This can be achieved by improving the tools in the DGS continuously. The set of tools in the DGS is portrayed as a lens between the DGS knowledge base and the environment. The light, i.e., information, can pass through the lens from both sides. The direction depends on whether the DGS is in the advising or acquisition mode. As in the case of light passing through a lens information passing through the tools may be altered. For instance, it may be analyzed like light in a spectrum by a prism. By reversing the prism, different information entities may be combined and synthesized into a new, more useful, entity.

The Development of a Design Guidance System

17

REAL WORLD ENVIRONMENT

COMPUTER ENVIRONMENT

DGS TOOL SET: an Optical Instrument between the Real World and the Computer T O O L S D G S

KNOWLEDGE AND INFORMATION

ACQUISITION ADVICE

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 the building of an optical lens (see Figure 5). A set of tools (for example, the DPST Workbook, DSIDES, HOSDES) have already been developed. These tools constitute the lens through which information passes. However, we hasten to add that our lens is still crude and our efforts are focused on improving it. We propose to do this by adding the DGS to this tool-kit; a DGS that is itself open-ended and designed to accommodate changes in the tool-kit. We classify the tools required to support the tasks of the DGS into 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, the characteristics 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., a mathematical function) into its elements (e.g., variables, numbers and mathematical operators) and to analyze these elements. Two examples follow. As indicated in Section 4.2, it is necessary to be able to monitor a designer s activities to obtain a model of the process being followed. To provide advice it is necessary to decompose the model into its entities (see Figure 2) and then

The Development of a Design Guidance System analyze these entities. In other words obtain a higher level of information than what is obtained through monitoring. Consider a mathematical representation of a constraint. Various system variables and mathematical functions may have been used in this constraint. In order to determine whether the constraint is satisfied or not these system variables and mathematical functions need to be detected in the constraint by the DGS. If their current values are known, the degree of feasibility of the constraint can be determined and thus new information is obtained. In both cases a designer may be prompted for assistance. 6.2 Information Synthesis Tools

18

These are tools with which to compose a complex information entity using other entities elements (e.g., an inference network from production rules). Tools for building models of processes fall into this category. Low level information can be combined and promoted into a higher order (this is an example where the distinction between knowledge and information becomes small). For instance, data can be synthesized into analytical relationships 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 or specialize it. Relationships can be combined into higher order relationships by inference tools. Programming is also an example of synthesizing information. Model building or defining a Decision Support Problem is another example. Tools to support, or even perform these tasks autonomously, fall into this category. Again, in all cases a designer may be prompted for assistance since he/she is an essential part of the acquisition and advising loop. 6.3 Information Evaluation Tools

These are tools with which to determine the value associated with a certain information entity (e.g., the value of a mathematical function). Synthesis and analysis of information provide new information. But what is the value of information? For instance, a rule can be true or false. We need to know whether a constraint is satisfied. Currently a syntax parser, that functions as an interpreter, is available to analyze and evaluate mathematical and logical expressions. This parser needs to be rewritten (so that it can be compiled) for it 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 examples are: interface tools for the environment, which include tools for internal information storage, information recognition tools, which detect different information entities which seem to be independent, but in fact are highly correlated (e.g., boat and ship), and

The Development of a Design Guidance System consistency control tools, which passively/actively maintain the consistency of the information

19

Interface to the environment: Information needs to be visible for the environment of the DGS. 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 needs to be very user-friendly. The interface for the DGS is being developed using the public domain X Windows software which allows portability to various computer systems without modification. Recognition of information: For storing and retrieving items in a knowledge base one needs key-words. This may appear to be a simple task but difficulties arise when different pieces of information have 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 car and automobile. This is known as a semantic variation. The problem of semantic variation involves pattern recognition. One approach to solving this problem is to establish attributes which can then be mapped using techniques such as discriminant analysis, cluster analysis and neural networks [33-35]. This approach, at present, is more in the realm of research than practice. Another approach, to tackling the problem 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 contemplating using the second approach in the proto-typical development of the DGS. We recognize that this approach may result in a combinatorial explosion. Consistency control: Tools for consistency control are essential. Ignizio [32] describes five types of inconsistency to be identified in rule-based expert systems. If we use relationships 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 inconsistencies should be developed. Also hidden inconsistencies caused by using a different identification 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. Further developments will be added to this shell. The following has been completed: A structure for a domain independent information representation has been developed. At present a hierarchical knowledge base for the aforementioned

The Development of a Design Guidance System representation is simulated using a file structure. Corresponding storage and retrieval tools have been developed, as well as a simple user interface, including print and list routines. These tools will be replaced, at some other time, 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/inference networks from relationships is available. A submodule of ASSIST which can be used to identify all possible calculation paths in a network with multiple alternative calculation methods at one node is available. The efforts within the Systems Design Laboratory are being directed in four areas: Development of the capability to analyze, synthesize and evaluate complex calculation paths/networks. This work is necessary to define complex relationships and will be used to formulate compromise DSPs. The DSIDES system is available for solving Decision Support Problems. Development of the capability to maintain consistency within the knowledge base. 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 major amount 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 ships have been implemented in AUSEVAL [4]. We propose to use AUSEVAL and its templates to test various features of the DGS.

20

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

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

The Development of a Design Guidance System

21

and Warren Smith to work at the University of Houston. Peter van Oossanen and Bert Koops 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 work with us in Houston. The financial contribution of our corporate sponsor the BF Goodrich Company to further develop the Decision Support Problem Technique is gratefully acknowledged. The development of an X Windows interface for DSIDES is being funded in 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 Ship Technology and Research (STAR) Symposium/3rd International Marine Systems Design Conference (IMSDC), Pittsburgh, Pennsylvania, 1988, 279-306. A. Koops, A. C. W. J. O. Oomen and P. Van Oossanen,"HOSDES: A New Computer-Aided System for the Conceptual Design of Ships", Proceedings Bicentennial Maritime Symposium, Sydney, Australia, 1988, 17-29. A. Koops, A. C. J. W. Oomen and B. A. Bras,"Computer Aided Design Assistance and Decision Support", Proceedings ICCAS, Shanghai, China, 1988, W. F. Smith, T. Lyon and B. Robson,"AUSEVAL - A Systems Approach for the Preliminary Design of Naval Ships", Proceedings Bicentennial Maritime Symposium, Sydney, Australia, 1988, 1-16. W. F. Smith,"AUSEVAL - The Application of the Decision Support Problem Technique to Ship Design", Proceedings International Workshop on Engineering Design and Manufacturing Management, Melbourne, Australia, 1988, 127-147. F. Mistree, W. F. Smith, B. Bras, J. K. Allen and D. Muster,"Decision-Based Design: A New Paradigm for Ship Design", Transactions Society of Naval Architects and Marine Engineers, San Francisco, California, 1990. D. Muster and F. Mistree, "The Decision Support Problem Technique in Engineering Design", The International Journal of Applied Engineering Education, 4(1), 1988, 23-33. F. Mistree, S. Z. Kamal and B. A. Bras, "DSIDES: Decision Support in the Design of Engineering Systems", Systems Design Laboratory Report, University of Houston, Houston, Texas, 1989. D. A. Dierolf and K. J. Richter, "Computer-Aided Group Problem Solving for Unified Life Cycle Engineering (ULCE)", IDA Paper P-2149, Institute for Defense Analyses, Alexandria, Virginia, 1989. S. Finger and J. R. Dixon, "A Review of Research in Mechanical Engineering Design. Part 1: Descriptive, Prescriptive, and Computer-Based Models of Design Processes", Research in Engineering Design, 1, 1989, 51-67. 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. F. Mistree and D. Muster,"Conceptual Models for Decision-Based Concurrent Engineering Design for the Life Cycle", Proceedings of the Second National Symposium on Concurrent Engineering, Morgantown, West Virginia, 1990,

2.

3. 4.

5.

6.

7.

8.

9.

10.

11.

12.

The Development of a Design Guidance System 13.

22

14.

15.

16.

17.

18.

19. 20. 21. 22.

23. 24.

25.

26.

27.

28.

29.

J. P. Pennell and M. M. G. Slusarczuk, "An Annotated Reading List for Concurrent Engineering", IDA Document D-571, Institute for Defense Analyses, Alexandria, Virginia, 1989. R. I. Winner, J. P. Pennell, H. E. Bertrand and M. M. G. Slusarczuk, "The Role of Concurrent Engineering in Weapons System Acquisition", IDA Report R-338, Institute for Defense Analyses, Alexandria, Virginia, 1988. 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. 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. U. D. W. Group, "Decision Support Requirements in a Unified Life Cycle Engineering (ULCE) Environment", IDA Paper P-2064, Institute for Defense Analyses, Alexandria, Virginia, 1988. D. E. Calkins, R. S. Gaevert, F. J. Michel and K. J. Richter, "Aerospace System Unified Life Cycle Engineering: Producibility Measurement Issues", IDA Paper P2151, Institute for Defense Analyses, Alexandria, Virginia, 1989. N. Cross, Engineering Design Methods , John Wiley & Sons, Chichester, 1989. M. M. Andreasen,"Design Strategy", Proceedings 1987 International Conference on Engineering Design, Boston, 1987, 171-178. S. J. De Boer, Decision Methods and Techniques in Methodical Engineering Design , Academisch Boeken Centrum, De Lier, The Netherlands, 1989. M. S. Fox and S. Safier,"Problem Solving Architectures for Computer-Assisted Design", Proceedings of the Second National Symposium on Concurrent Engineering, Morgantown, West Virginia, 1990. K. D. Forbus, "Intelligent Computer-Aided Engineering", AI Magazine, (Fall), 1988. R. E. Fulton, C. Pin-Yeh and K. J. Richter, "Managing Engineering Design Information", IDA Paper P-2154, Institute for Defense Analyses, Alexandria, Virginia, 1989. F. Mistree, D. Muster, J. A. Shupe and J. K. Allen, "A Decision-Based Perspective for the Design of Methods for Systems Design, Recent Experiences in Multidisciplinary Analysis and Optimization", NASA CP 3031, NASA, 1989. J. A. Shupe, "Decision-Based Design: Taxonomy and Implementation", Ph.D. Dissertation, Department of Mechanical Engineering, University of Houston, Houston, Texas, 1988. J. A. Shupe, D. Muster, J. K. Allen and F. Mistree, "Decision-Based Design: Some Concepts and Research Issues", Expert Systems, Strategies and Solutions in Manufacturing Design and Planning, A. Kusiak ed., Society of Manufacturing Engineers, Dearborn, Michigan, 1988. J. K. Allen, J. Hong, S. Adyanthaya and F. Mistree, "The Decision Support Technique Workbook for Life Cycle Engineering", Systems Design Laboratory Report, University of Houston, Houston, Texas, 1989. K. J. MacCallum and D. K.J. H.B.,"Approximate Calculations in Preliminary Design", Computer Application in the Automation of Shipyard Operation and Ship Design 5 (ICCAS), Trieste, Italy, 1985.

The Development of a Design Guidance System 30.

23

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 and Other Multivariable Methods, The Duxbury Series in Statistics and Decision Sciences, PWS-KENT Publishing Company, Boston, 1988. 34. J. L. McClelland and D. E. Rumelhart, Explorations in Parallel Distributed Processing - 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: A Database System for Concurrent Engineering Applications", Report Number 89062, Rensselaer Design Research Center, Rensselaer Polytechnic Institute, Troy, New York, 1990.