THE SOCIETY OF NAVAL ARCHITECTS AND MARINE ENGINEERS 601 Pavonia Avenue, Jersey City, New Jersey 07306

Presented at the Annual Meeting, San Francisco, California, October31-November 3, 1990.

Decision-Based Design: A Contemporary Paradigm for Ship Design
F. Mistree, Member, University of Houston, Texas, W. F. Smith, Associate Member, Dept. of Defence, Canberra, ACT, Australia, B. A. Bras, Visitor, Maritime Research Institute Netherlands, Wageningen, The Netherlands, J. K. Allen, Visitor, Janco Research, Inc., Houston, Texas, D. Muster, Visitor, University of Houston, Texas Abstract
For decades ships have been designed using the well-known “basis ship approach” together with the equally well-known Evans-Buxton-Andrews spiral. The two principal limitations of the spiral are that the process of design is assumed to be sequential and the opportunity to include life cycle considerations is limited. It is our contention that in order to increase both the efficiency and effectiveness of the process of ship design a new paradigm for the process of design is needed. In this paper, we review recent developments in the field of design and offer a contemporary paradigm, Decision-Based Design, for the design of ships; one that encompasses systems thinking and embodies the concept of concurrent engineering design for the life cycle. equilibrium isolated from their environments. However, in the past half century, there has been a virtual revolution in the way engineers view many of their problems and, even more recently, at some schools of engineering, in the way design is being taught. The fundamental reason for these changes can be attributed to two singular events; a new emphasis on systems thinking and the pervasive presence of electronic computers. In their synergistic coupling, they have irreversibly changed the world view of engineering and engineering education and provided the foundation for developing systematic methods for planning approaches to the design of large-scale, complex, fuzzily defined transdisciplinary systems open to their environments. Systems thinking 1 , when applied to the design of a system, emphasizes both the emergent properties of the system as a single entity and the separate and collective properties of the systems and its subsystems in their intrinsic environments [1]. This is the antithesis
Checkland [1] defines systems thinking as "an epistemology which, when applied to human activity is based upon the four basic ideas: emergence, hierarchy, communication, and control as characteristics of systems." 1

Engineering Design: A Review
Design, particularly engineering design, is in a period of ferment. For more than three centuries, the world view of engineering design has been based in the Newtonian concepts of reductionism and mechanism, and closed systems in

of an approach to design that requires the harmonious coupling of a designer's experience-based intuition and skills in performing analyses which emphasize both reductionism and mechanism and the design of the components of a system in isolation from the influences of their environments. Systems thinking and computer technology exist in an overlapping world of synergistic action. The broadening influence of systems thinking encourages engineers to

approach a design problem that spans several traditional disciplines in terms of which they define their design problem. Simultaneously and consciously, they define the laws and relationships that characterize the transdisciplinary body of knowledge in which the problem is embedded. A corollary effect of the advent of systems design is the blurring of the lines that have separated the traditional disciplines in academic institutions and industry. We are beginning to discover that the neat, dichotomous packaging that separates, say, mechanical engineering, electrical engineering and naval architecture is more political than technical. It may be a traditional and convenient means for organizing administrative entities and budgets but it is not necessarily useful for organizing technical, problem-solving teams. In the decades since computers became the universal tool of engineers and scientists we have observed dramatic changes in the computers themselves, our manner of using them, and in the opening of new related fields of research in science and technology. We now have computers that can process symbols in the broadest sense, words, graphs, and numbers, and they are imbued with the ability to reason. New software and hardware allow us to do things that, even a few years ago, we could contemplate only wishfully. Designers are on the threshold of being able to use a computer not just as a tool, but as an advisor, a critic and, ultimately, as a partner in the process of design. The function of processing symbols in any design method, we believe, is to provide a means for a designer to identify and formulate a problem so that it can be modeled as realistically as possible and to allow the formulation so generated to be translated into a structured form amenable to solution. Most futurists (Naisbitt, Toffler, Bell, and Dennison, among others) agree that we are at the beginning of the Information Age. In this new age, information will be available to designers almost instantly in quantity and quality

heretofore not considered possible. Designers will negotiate the solutions to open problems in conjunction with computers, data-bases and expert systems. They will be involved primarily with the unstructured or partially structured parts of problems (that is, with establishing system goals, partitioning the system in terms of its functional subsystems and planning the design process itself) rather than with the structured part (that is, the design of components) which will be automated. Independent of the approaches or methods used to plan, establish goals and model systems, designers are and will continue to be involved in two primary activities, namely, processing symbols and making decisions -- two activities that are central to increasing the efficiency 2 and effectiveness 3 of designers and the processes they use. The Recent Evolution of Design from an Art towards a Science Design as an organized discipline is of relatively recent origin, compared to engineering which can trace its beginnings to the proto-engineers who built Hammurabi's war engines. The earliest design approaches were introduced soon after the start of the Industrial Revolution. Their principal elements were the iterative, sequential application of analyses based in the Newtonian principles of reductionism and mechanism and syntheses utilizing the intuitive skills of a designer. Recent work by members of a relatively broadbased community of researchers suggests that the development of a body of knowledge which supports the science of design can be and is being realized. However, it is probably a realistic assessment of the situation to state that, at
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. 3 We consider effectiveness to be a measure of quality of a decision (correctness, completeness, comprehensiveness) that is made by a designer.

this time, the science of design is in a pre-theory stage [2]. The body of work developed thus far has been largely uncoordinated. However, there is a small group within this community attempting to identify and organize the commonalties that exist in the design approaches, techniques and methods of Simon's “designers”, that is, those who devise courses of action aimed at changing existing situations into preferred ones. The long-term goal of this group is to establish the philosophical underpinning and structure of a discipline-independent science of design of which the science of engineering design would be a principal part. There have been several reviews of the relatively recent design literature. These include those by Pahl and Beitz [3] (who give a comprehensive review of the evolution of design in Germany), Hubka and Schregenberger [4] (who provide a short review of trends in both Europe and in the United States), Andreasen [5] (who gives an overview of the state of the art in Europe), Cross [6] (who has written an easy to read review of design methods), De Boer [7] (who has reviewed a number of design and general problem solving methods) and Finger and Dixon [8, 9] (who provide a two-part review of the state of the art in mechanical engineering design). An interesting survey on research methods to study design plus an extensive bibliography has been made by Brei et al. [10]. Stauffer et al. [11], Waldron et al. [12] and Wallace and Hales [13] approach design science by examining how designers design; a descriptive approach. Hubka [14] and Pahl and Beitz [3] are well known for their prescriptive approach to design. Suh [15], Tomiyama and Yoshikawa [16], and Takala [17] have attempted to define design using axioms. Ostrofsky [18], Suh [19], Mistree et al. [20], De Boer [7] have been major proponents of approaching design from the standpoint of decisions made by engineers in the process of design. Others have approached design from the standpoint of

optimization. Azarm et al. [21] provide a survey of the use of optimization methods in design. Some examples of using optimization in design are given by Vanderplaats [22] and Hughes [23]. Sobieszczanski-Sobieski is a leading authority on decomposition and multidisciplinary optimization [24, 25]. Currently, the use of artificial intelligence (AI) in design is one of the most active areas of research and development. A major contribution of ideas and prototypical systems for designing engineering systems using AI principles have been made by Brown and Chandrasekaran [26], Brown [27], and Dixon et al. [28, 29]. Gero et al. [30], use artificial intelligence to focus on computational models of design as a process. Basically, these proposed systems and ideas focus on capturing expertise to solve design problems, and/or providing alternative problem solving methods for ill-structured problems. Recently the application of neural networks, in design, has created a wave of interest [31, 32, 33]. Currently, two major streams of development in design are evident, namely, the pursuit of a definitive theory of design and the development and application of computer-based tools in design. Further, two different model types for the design process have been proposed, namely, prescriptive models and descriptive models. Both models are offered as means for increasing the efficiency and effectiveness of designers and the processes they use. Both models are applicable to ship design (as they are for any engineering design discipline). Prescriptive Models of Design Prescriptive models embrace a systematic, algorithmic-based approach that has at its core a general design methodology which includes three basic activities, namely, analysis, synthesis and evaluation. It is beyond the scope of this review to discuss all of the prescriptive models of design that have been proposed and developed over the years. Two prescriptive models of the

design process, which a consensus of engineers consider important, have been developed by Pahl and Beitz [3] and Hubka [14]. The model proposed by Pahl and Beitz has been further developed and published by the Verein Deutscher Ingenieure in Guideline VDI 2221 “Systematic Approach to the Design of Technical Systems and Products”. Commentaries on the development and implementation of this guideline have been made by Beitz [34] and Cross [6]. Both models cited are in harmony with systems thinking and, although they vary in form, they share at least three basic activities in common: Analysis: A process of partitioning or decomposing any system into its subsystems and component parts to determine their separate and collective nature, proportion, functions, relationships, etc. Synthesis: A process of integrating a collection of subsystems so as to create a system with emergent properties. Evaluation: A process of assessing the degree to which a solution satisfies the goals that were originally stated. De Boer [7] opines that a basic threestep pattern (diverging, systemizing and converging) can generally be recognized in each phase and subphase of a prescriptive model. The first step in design or general problem solving is usually divergent in nature; a designer is called on to generate a (large) number of ideas, alternatives or possible solutions. These ideas are then analyzed and synthesized into forms that may represent acceptable solutions to the problem. This is the systemizing activity. Finally the refined ideas obtained by systemizing are further synthesized, analyzed and evaluated leading in general to a single satisficing4 design. As the number of acceptable ideas or solutions is decreased, the activity is characterized by convergence.
Satisficing - not the “best” but “good enough” (use of this term, in the context of optimization, is first attributed to Herbert Simon [35])

These prescriptive models of design rely on decomposition, assimilation and iteration and closely resemble the traditional approach to ship design as espoused in many texts and as discussed in detail later. For example, in determining ship structural characteristics, transitions are made from a representative hull box-girder analysis, to a midship module/section analysis, to the specification of detailed local structure. The Classification Societies with their rules encourage designers to follow a prescriptive model, at least, in commercial ship design. Descriptive Models of Design In contrast to prescriptive models, descriptive models exemplify how design is done by a designer and not necessarily what should be done to arrive at a solution in accordance with an “expert” or theorist. Pahl and Beitz [3] and Cross [6] identify four activities that may be basic to descriptive models of design: Problem analysis a problem statement is developed. Conceptual design - the statement of the problem is used to generate a collection of broad solutions. Embodiment design - the solutions in the collection are refined for the purpose of eliminating those that are least satisfactory until only the final design remains. Detail design - all the details of the final design are specified and the manufacturing drawings and documentation are produced. Validation of descriptive models of design is difficult and, given the highly personalized contributions of designers to the process, models are usually offered as no more than guidelines, not as inviolate protocols. However, in general, most engineers do not have the requisite skills or long-term interest for process validation. Nevertheless, Wallace and Hales [13, 36] have documented in explicit detail an actual design process in industry and Stauffer et al. [11] have attempted to determine just how designers, in fact, do perform

design. They concluded, that the designers they monitored: • developed the functional aspects of the design in stages throughout the problem solving effort rather than during an initial functional development stage called for by many design theories; • used functional considerations that remained qualitative while often the form considerations became quantitative during the problem solving effort; • made decisions based on qualitative, subjective reasoning during all phases of design; • used their knowledge to influence the generation of ideas for problem solutions (i.e., they did not use a domain independent procedure); • used their knowledge to influence how ideas were evaluated, hence they did not evaluate ideas in a consistent manner; • used their knowledge to influence their problem solving method, that is, when the subjects had little knowledge in a domain of application they did not go into the details, but simply picked what was available; • performed mental, visual and physical simulations as an aid to understanding problems and evaluating solutions; • attempted to find a satisfactory rather than optimal solution. Stauffer and his coauthors, in their paper, speculate that these human actions, most of them deviations from prescribed practice, may have been the result of poor training, cognitive limitations or other factors. Juster [37] and Andreasen [5] highlight some of the problems of using some of the methods and guidelines (which are a product of design science) in practice. Andreasen, however, is optimistic: “… there is no doubt that the basic patterns in design science are right.” His optimism appears to be justified in the light of the success reported by those utilizing an approach called “concurrent engineering”.

Concurrent Engineering for the Life Cycle


Concurrent engineering represents a common sense approach to product development in which all elements of the product's life cycle from conception through disposal are integrated into a single continuous feedback-driven design process. It has also been called “simultaneous engineering”, “Unified Life Cycle Engineering (ULCE)”, “producibility engineering”, etc. Recently, in this country, the principal supporter of concurrent engineering has been the United States Department of Defense which has found too often that designers have formulated new and elegant systems which cannot be produced and deployed economically [38]. The primary goal of concurrent engineering is the minimization of costs over the complete life cycle of a system while maximizing its quality and performance. A formal definition for concurrent engineering is given by Winner [39]: CONCURRENT ENGINEERING Concurrent engineering is a systematic approach to the integrated, concurrent design of products and their related processes, including manufacturing and support. This approach is intended to cause the developers, from the outset, to consider all elements of the product life cycle from conception through disposal, including quality, cost, schedule, and user requirements. Concurrent engineering is characterized by a “focus on the customer's requirements and priorities, a conviction that quality is the result of improving a process, and a philosophy that improvement of the processes of design, production and support are never-ending responsibilities of the entire enterprise” [39]. In concurrent engineering, the early stages of project initiation are especially significant because major design decisions are made, usually based on a

predominance of soft5 information, which can have far-reaching effects on the system being designed. Portions of a sequential and a concurrent process of design are illustrated in Fig. 1. As illustrated, the information flow in concurrent engineering is bidirectional and decisions are based on both upstream and downstream considerations. In contrast, in a sequential approach information flows in one direction only. Conceptually, it is evident from any perspective that as a design process progresses and decisions are made, the freedom to make changes as one proceeds is reduced and the knowledge about the object of design increases. This is illustrated in Fig. 2. At the same time, there is a progression from soft to hard information. A product of and a clear motivation for concurrent engineering is to “drag” the knowledge curve to the left, thereby increasing the ratio of hard to soft information that is available in the early stages of design. This relative improvement in the quality of information should lead to designs that are completed in less time and at less cost than those designed using a traditional sequential process. Some of the benefits resulting from a concurrent engineering design approach, as reported by six

Some of the information used in the making of a decision may be soft, that is, based on the designer's judgment and experience and some information may be hard, that is, derived from scientific principles.


Requirement Product Development Process Development Prototype

Requirement Product Development Process Development Prototype • • • •

major companies, are presented in Table 1. In• general, the reported benefits of the • • • approach are [39]: • The quality of designs was improved which resulted in dramatic reductions of engineering change orders (greater than 50%) in early production. • Product development-cycle times were reduced by 40-60% when concurrent, rather than sequential, design processes were used. • Manufacturing costs were reduced by 30-40% when multifunction teams integrated product and process designs. • The costs of scrap and rework were reduced by 75% through product and process design optimization. Table 1 Reported cost, schedule, quality benefits of concurrent engineering [39]

Fig. 1 A comparison of sequential and concurrent engineering (adapted from [39])
Potential Time Savings 100%


Knowledge About Design

Design Freedom 0

Development of Requirements Conceptual Design Preliminary Design Contract Design Detail Design Construction

Fig. 2 Increasing the amount of knowledge about a product at an early stage

Although concurrent engineering can be implemented in many ways the generic elements of it are as follows [39]: McDonald Douglas 60% savings Significant savings Scrap reduced 58%, on bid for reactor and (reduction from 45 weeks rework cost reduced Reliance on multifunction teams to • missile projects. to 8 hours) in one phase of 29%, and nonconformances integrate the design, manufacturing high-speed vehicle reduced 38%; weld defects preliminary design; per unit decreased 70%;and support processes of a product. 18 month saving on 68% fewer changes on • Use of computer-aided design, TVA-8B design. reactor; 68% fewer drawing changes on engineering and manufacturing TVA-8B. methods to support design ___________________________________________________________________________ integration through shared product Boeing Ballistic Reduced labor rates by Part and materials lead- Floor inspection ratio Systems Division $28/hour; savings 30% time reduced by 30%; one decreased by over 2/3; and process models and data bases. below bid. part of design analysis material shortages • Use reduced of a variety of analytical reduced by over 90%. from 12% to 0; 99% defect-free operation. methods to optimize a product's ___________________________________________________________________________ design, manufacturing and support AT & T Cost of repair for new Total process time reduced Defects reduced by 30% processes. circuit pack production to 46% of baseline for to 87%. Compared to traditional engineering cut at least 40%. 5ESS.™ ___________________________________________________________________________ in which synthesis of the product design plays the central role, the synthesis of the Deere & Company 30% actual savings in 60% savings in Number of inspectors developmental cost for developmental time. reduced by 2/3.process (which includes design, construction equipment. manufacture and support aspects) is the ___________________________________________________________________________ dominant feature in concurrent Hewlett-Packard Manufacturing costs Reduced development cycle Product field failure rate engineering. With the synthesis of the Co. Instrument reduced 42%. time 35%. reduced 60%. Scrap and Division rework reduced process at this higher level, the synthesis 75%. ___________________________________________________________________________ of the product follows naturally.
Case Study Cost Schedule Quality


Product direct assembly labor hours reduced 45%.

Significant reduction in length of PMT design cycle. 40% reduction in electronic design cycle.

Fewer engineering changes. Guaranteed productibility and testability.

Our Frame of Reference Quite clearly, any discussion of designing practical engineering systems of tomorrow, using approaches based on systems thinking and computers, must include concurrent engineering design for the life cycle. Further, while the aims and objectives of concurrent engineering are clear, there is no generally accepted model of a design process that can be used to include concurrency and design for the life cycle. We believe that it is unlikely that one model will emerge as the ultimate model of design for all products and processes. Therefore, in the next two sections, our approach is to evaluate critically the well-known ship design spiral and introduce a paradigm we call Decision-Based Design. Further, because of their importance, we focus on the early stages of ship design.

Ship Design: Its Evolution
What is the impact of the preceding general discussion on ship design? We

believe that it is significant. Hubka and Schregenberger [4] point out that the seeds of design science first sprouted in individual fields of engineering, such as naval architecture. So what do we have in ship design to build on? Let us begin with a review of the ship design spiral that is the underlying model for much of the current state of practice in ship design. The Ship Design Spiral: A Model of the Ship Design Process In 1959, Evans [40] made a significant contribution to visualizing and modeling the process of ship design. His “general design diagram” is reproduced as Fig. 3. Now known as the “ship design spiral” it captured the basic tenets of a widely accepted approach to ship design. A major characteristic of the spiral approach is that the design process is sequential and iterative rather than concurrent. It is also laborious and expensive. While some refinements have been made over time, these characteristics remain unchanged. Buxton introduced economic issues into the spiral [41] and time was added as a third dimension by Andrews [42]. In so doing, Andrews attempted to account for the open nature of the design process. Andrews' representation of the ship design process as a helical “corkscrew” is shown in Fig. 4 and he states that the advantage of this image is that many dialogues and constraints on a designer can be shown as fundamental to the process. However, this representation still relies on sequential activity and iteration. It is widely recognized that the spiral represents an important historical model of the ship design process. We therefore put on record two salient observations. Firstly, while the spiral is characteristically drawn by Evans and others as converging towards a product, the process is

















Fig. 3

Evan's general design diagram [40]

divergent with respect to information and the increasing detail of definition. This divergent aspect is reflected in Buxton's representation. The convergent/divergent perspectives of Evans and Buxton are complementary to each other; more on this point later. Secondly, it is recognized that when the spiral was first formalized and in the years following, it represented a descriptive model that portrayed how design was done; it represented both the state-of-art (state-ofresearch) and the state-of-industry (stateof-practice). The then available design algorithms and tools mandated a sequential and iterative design approach with computers being used as high speed calculators to increase the efficiency of a designer traversing the spiral. However, the spiral is still viewed, by many today, as a valid prescriptive model, that is, a representation of how design should be done and hence is still a portrayal of the state-of-art! While the spiral approach may result in satisfactory designs it does not promote the identification of superior solutions. As Lyon and Mistree [43]




periods when the ship building industry is doing well and the volume of ship building is high, the traditional laborious approach may be effective since, • the effort expended is worthwhile because almost all designs are built, • designs can be improved through small improvements from ship to ship and class to class, and • a large amount of data is available on similar ships. However, when the market is depressed, with low ship construction activity, and in view of the specialized, single vessel designs encountered, the traditional approach is ineffective since an adequate design is no longer competitive in the open market, and a costly protracted approach to design is uneconomical. Alternatives to the Evans-BuxtonAndrews spiral have been proposed in the past but they have failed to gain wide support. For completeness, a brief discussion of these follows. Towards a Concurrent Model for Ship Design The design spiral is a conceptual model of a process for effecting ship design. The major units of the spiral (conceptual design, preliminary design, detail design, etc.) are central to implementing any ship design process and there are numerous ways of implementing these units. However, most formal, algorithmic and mathematical approaches that have been reported in the open literature are for preliminary ship design. One approach for implementing preliminary ship design is design through “enumeration”. This method is based on the assumption that all design variables can be expressed in terms of the vessel's length and it employs a procedure in which the length is increased sequentially until a feasible design is found. A computer is used in the “search” for a feasible solution. No particular insight is required from the designer, since any number of lengths can be evaluated and the final design is selected by inspection.

The limitation of this method is its capability to handle only a single objective. It is also highly dependent upon the functional relationships that are developed between length and the other design variables. An example of this

technique is the design of bulk cargo carriers by Gilfillan [44]. Another approach is to formulate preliminary ship design as an optimization problem. There have been a number of


Select Empirical Formulae Life Cycle


Balance Coefficients


Initial Checks




Based on Ship Type Upper Deck Maj. Spaces Based on Ship Type Area/Wt Balance






OVERALL PICTURE The design spirals down the surface of the model

SECTION THROUGH MODEL Showing typical steps in spiral

Fig. 4 Andrew's overall model of the ship design process [42] applications of this technique and each and Mistree [43] introduced a generic has had a varying degree of success. multiobjective formulation for the Different aspects of the preliminary ship preliminary design of ships in 1985. design problem have been formulated and Traditionally, the major thrust of solved as single-objective, optimization research in ship design has been focused problems by Murphy et al. [45], narrowly on specific analytical aspects. Nowacki et al. [46], and Smith and Only recently has more interest and effort Woodhead [47]. The advantages of being devoted to synthesis and decision formulating a design problem as an support (for example, [43, 48, 49, 50, optimization problem are that 51, 52]). Mistree et al. [53] have computations are reduced, the computer presented one of the the first successful code can generally be modified to algorithms for solving large, practical accommodate the required number of design problems using sequential linear design variables and constraints, and the programming. This algorithm is not “best” solution as defined by the limited by the problems associated with objective function is found automatically. the earlier (SLP) algorithms (for In the preceding formulations the design example, see [47]) and it is one of the is driven by a single objective; an core elements of MAESTRO, a ship unlikely event in the real world. Lyon structural synthesis program [23].

Hughes and Mistree established the need for concurrency in analysis, evaluation and synthesis while designing major structural systems [49]. This notion of concurrency has been developed further by Lyon and Mistree [43] in a multiobjective formulation (the compromise Decision Support Problem) for the preliminary design of ships. This work has since been embodied in the AUSEVAL system that is being used by the Directorate of Naval Architecture in Australia and is being incorporated by the Maritime Research Institute Netherlands (MARIN) into their design system, HOSDES. The issue of concurrency associated with solving hierarchical problems in the preliminary design of ships is addressed by Smith [50]. In our opinion, the spiral paradigm for ship design is still useful. We contend that the elements of the spiral be made part of a new process that accommodates concurrency, facilitates the inclusion of life cycle considerations and provides a means for designing and managing the design process itself. Acknowledging these needs, how should our outlook be altered or enhanced? A Change of Perspective: Frustum of a Cone The

the modeled design considerations are to pass on answers in a sequence of forward-chained steps and the resultant need for iteration is high as one strives to satisfy constraints. Alternatively, if the design process is viewed as taking place on the inside, the ordering of calculation and progress is not strictly defined. Analogous to lineof-sight, all considerations can be sighted at any point in the process. Thus, the missing notion of concurrence in the spiral may be accommodated by working on the inside. Further, it follows that working on the inside represents, at present, the state-of-research in design: a concurrent approach.


Fig. 5

Design on the outside: state-of-practice

In order to change the basic design representation fundamentally from a sequential spiral to an integrated and concurrent scheme, the perspective from which design is viewed needs to change. For illustrative purposes, imagine the process of design to be represented by a funnel or the frustum of a cone (see Fig. 5). Further, consider a surface generator of this conical frustum to represent the locus of one of the design activities (as depicted in the traditional spiral) such as stability, lines generation or structural definition. As the design process advances in the traditional sense, one works around the outside of the frustum as depicted by the arrows in Fig. 5. This is similar to the notion proposed by Andrews [42] and highlighted in Fig. 4. Typically, the only interactions between

Fundamentally, the barriers for modeling interactions do not exist when a designer's orientation is an internal one. As depicted in Fig. 6, each interplay between design considerations could be modeled effectively with information flowing through a “ring of interaction”. Iteration, as such, would then only be necessary as the amount and quality of information or the requirements changed significantly. Concurrency would replace iteration in processes in which a balance between conflicting requirements and conflicting objectives is sought. In this sense, each phase of design (e.g., the conceptual design phase, the preliminary design phase) is portrayed as disc-like, but of irregular shape. By further refining this illustration, in the limit, as more becomes known of the object of design, the representative disc

becomes geometrically complete and circular. The scale, however, on each radial connector is unique. As an aside, we note that iteration will always be necessary but, in a concurrent








approach, is minimized. The process of formulating a mathematical model of a ring of interaction (later to be defined as a “template”) for each design phase is procedural with the interaction between rings represented by a transfer of knowledge and information. Our choice of a frustum of a cone (see Figs. 5 and 6) is based on Evans’ spiral; one in which a design process eventually converges upon a design. We recognize that this convergence will result in an increase (as indicated by Buxton) in some of the other outcomes of the process. For example, as the design process converges knowledge about a design increases, the qualitative ratio between hard and soft information increases, the degree of partitioning and planning needed to proceed with the design increases, the costs increase and STABILITY the personnel involved increases, just to state just a few. And other outcomes, such as design freedom, diminish. STRUCTURE We have used a frustum of a cone and a designer's perspective of the frustum to clarify the difference we LINES perceive between state-of-practice and the state-of-research in ship design. Some additional fundamental issues can also be addressed using the same imagery (see Fig. 7). At the onset of the design process, a number of alternatives/options may exist, but, as design progresses, some of these ideas and concepts may be STABILITY discarded and others coalesce. In some way, strands of thought are severed and joined as illustrated in Fig. 7. At the STRUCTURE same time, while the global design process is converging, subprocesses are LINES both converging and diverging. Characterization of the Spiral and Systems Approaches Design in progress, in the spiral approach, is characterized by a blending of knowledge and information. This notion is illustrated in Fig. 8. While the requirements of a design are initially stated conjunctively the tools necessary to fashion a solution are generally developed and used as independent entities. Metaphorically, the tools sit as


Fig. 6

Design on the inside: state-of-research

independent packages (see Fig. 8) on a shelf with a minimal capability for interfacing in a holistic design sense. There are some integrated packages but they remain an exception rather than the rule. When a task is defined, the tools deemed necessary to perform the task are selected and their outputs are blended together iteratively. In a computer













Fig. 8 Fig. 7 Characteristics within the design process

The spiral approach characterized

environment this is typified by a series of batch processed jobs; a stability assessment may be followed by a strength calculation which is preceded by a weight estimate. This process requires the application of significant resources (illustrated as energy in Fig. 8) and testing. With sufficient iteration, the elements of the design become so aligned that a satisficing solution is produced (see lower part of Fig. 8). In this approach to obtaining a satisficing solution the role played by the computer is that of a high speed calculator. In contrast, by adopting a systems approach and working on the inside of

the conical frustum in a concurrent manner, to accommodate the complexity of the required information processing and to ensure that a rational decision can be made, a partnership between the human designer and the computer must be forged. As illustrated conceptually in Fig. 9, this union may be represented in the form of a hybrid shifter or wrench. If the wrench's fixed or moveable jaw is too weak or missing altogether, the tool is worthless. So it is in a systems-based design environment, a satisfactory contribution by each part -- human and computer -- must be achieved. In so doing, both strength and flexibility are generated. But to what is the wrench applied? Obviously to nuts and bolts; which figuratively idealize the decisions, the flow of information and knowledge, and the subsystem relationships and their interactions in a systems approach to design. The bolt of Fig. 9 is one, perhaps from a preliminary ship design model, which ties together algorithms for resistance, economics, strength etc. It enables the interaction or force of one algorithm to be transferred and applied concurrently to the others as in the “ring of interaction” of Fig. 6. Many bolts may be manually and loosely applied to join components in creating an abstract model of a design process, but the harmony between a human designer and computer (i.e., the wrench) is mandatory to effectively and tightly bind the abstract mathematical models of physical subsystems together as a total system.


Fig. 9

A systems approach characterized

On Designing Ships in the Future Given the preceding perspective of design, why bother about transforming design science into design practice? There are several practical reasons for transforming one of the tangible outcomes of design science, namely, design methods into practice. Cross [6] identifies four practical reasons: the increasing complexity of systems, the need of a well-managed team approach, the need for increasing the efficiency of the process to decrease the lead-time, and the increasing costs and risks associated with modern design. An example of the influence of design and manufacturing on maintenance is given in [54]. While physical size, as opposed to diversified function, is not the issue of the '90's, the essence of Buxton's comment in 1972 [41] is still valid: “The scope for making the wrong decisions in ship design has increased greatly with the expansion of ship sizes and types. Until recently, the decision was much more whether to build rather than what to build, as each succeeding ship was usually a modification of

an earlier one. Now one design of an ocean-going ship can easily be 100 times larger than another and the scope for poor investment multiplies accordingly.” Tibbits and Gale [55] argue along similar lines to Cross. They stress the need for closer cooperation between the Naval Sea Systems Command (NAVSEA) and the ship yards serving the U.S. Navy. They describe the NAVSEA design environment and the diminishing available resources and identify two main reasons for the increased interest in the design production interface. The first is that productivity improvements and ship cost reductions are highly dependent on decisions made during conceptual and preliminary design as well as the detailed design phases. The second is the increased need for ships to be operable, reliable, maintainable and survivable while meeting the desired mission capability. Two of the interesting conclusions they draw are: • Navy and industry must collaborate in developing computerized approaches to ship design, construction, life cycle support and management, including data transfer techniques. • Means must be developed to incorporate production considerations in the preliminary and contract design phases. An effort towards the development of a computerized approach to ship design, construction, life cycle support and management is described by Billingsley and Ryan [56]. They describe the history of the Navy’s Computer Supported Design (CSD) system. The primary goal of the CSD system is to develop computer tools for performing ship design from the earliest stages through the Contract

Design phase and integrate them by exchanging data through a common database. A secondary goal is to facilitate data transfer between and among the various organizations involved in designrelated activities. The data transfer is focused around the product model which is the collection of geometric and nongeometric information necessary to fully describe the completed ship. Having identified some significant reasons to pursue a systematic, cost effective and efficient approach to design in general and ship design in particular, how can this be achieved? We believe a concurrent engineering approach is what is needed. Industrial success has been reported in this realm as shown in Table 1 while Andreasen [5] identifies failures in attempts to apply other methods in industry. Given that improvements in ship design can be made by applying concurrent engineering, what is needed for this to occur? Firstly, a design philosophy and, secondly, design tools for implementing it are needed. The tools for effecting design will differ in the different phases of design. On the other hand, the philosophy of design can remain constant throughout the design process, if this philosophy is rooted in a domainindependent and time-independent construct, namely, a decision. Recognizing the need to move towards a new concurrent and decision-based design model that facilitates design for the life cycle, how should our outlook be altered or enhanced? Our response: Decision-Based Design.

Decision-Based Design: A Contemporary Paradigm for Design
Decision-Based Design is a term coined to emphasize a different perspective from which to develop methods for design [20, 57]. The principal role of a designer, in DecisionBased Design, is to make decisions.

This seemingly limited role is useful in providing a starting point for developing design methods based on paradigms that spring from the perspective of decisions made by designers (who may use computers) as opposed to design that is assisted by the use of computers, optimization methods (computer-aided design optimization) or methods that evolve from specific analysis tools such as finite element analysis. Decisions help bridge the gap between an idea and reality. In general, decisions are characterized by information from many sources (and disciplines) and may have wide ranging repercussions. In Decision-Based Design, decisions serve as markers to identify the progression of a design from initiation to implementation to termination. In Decision-Based Design they represent a unit of communication; one that has both domain-dependent and domainindependent features. Some principal observations and beliefs from a Decision-Based Design perspective are as follows: • The principal role of an engineer or designer is to make decisions. • Design involves a series of decisions some of which may be made sequentially and others that must be made concurrently. • Design involves hierarchical decision making and the interaction between these decisions must be taken into account. • Design productivity can be increased through the use of analysis, visualization and synthesis in complimentary roles, and by augmenting the recognized capability of computers in processing numerical information to include the processing of symbols (for example, graphs, pictures, drawings, words) and reasoning (for example, list processing in artificial intelligence). • Life-cycle considerations that affect design can be modeled in upstream design decisions.

• Symbols are processed to support human decisions, for example, analog/signals, numeric information, graphic information, and textual information. • A technique that supports human decision making, ideally, • must be process-based and discipline-independent, • must be suitable for solving open problems that are characteristic of a fuzzy environment, and • must facilitate self-learning. The characteristics of decisions are governed by the characteristics associated with the design of real-life engineering systems. These characteristics are summarized by the following descriptive sentences: • Decisions in design are invariably multileveled and multidimensional in nature. • Decisions involve information that comes from different sources and disciplines. • Decisions are governed by multiple measures of merit and performance. • All the information required to arrive at a decision may not be available. • Some of the information used in arriving at a decision may be hard, that is, based on scientific principles and some information may be soft, that is, based in the designer's judgment and experience. • The problem for which a decision is being made is invariably loosely defined and open. Virtually none of the decisions are characterized by a singular, unique solution. The decisions are less than optimal and are called satisficing solutions. • Design is the process of converting information that characterizes the needs and requirements of a system into knowledge about the system itself. In Decision-Based Design it is the making of decisions that brings about the transformation of information into knowledge. By focusing upon decisions, we have a description of the processes written in a

common “language” for teams from the various disciplines -- a language that can be used in the process of designing. Our formal definition of the term designing is as follows [20, 58]: DESIGNING Designing is a process of converting information that characterizes the needs and requirements for a product into knowledge about a product. In this definition, we use the term product in its most general sense; it may include processes as well. This definition of design follows from Simon's [35] definition of a designer as anyone who affects or changes the state of things. Three different types of design, namely, original, adaptive and variant have been identified. The distinction between them is based on the amount of originality required. • Original Design - an original solution principle is determined for a desired system and used to create the design of a product. In naval architecture, we believe, original design occurs when only the mission requirements are known and the well-known “basis ship” design procedure cannot be employed. • Adaptive Design - an existing design is adapted to different conditions or tasks; thus, the solution principle remains the same but the product will be sufficiently different so that it can meet the changed tasks that have been specified. Using the “basis ship” approach in ship design is an example of adaptive design. • Variant Design - the size and/or arrangement of parts or subsystems of the chosen system are varied. The desired tasks and solution principle are not changed. A good example of variant design is when a ship series is being designed and changes between subsequent flights are effected. Whether the design process is classified as original, adaptive or variant depends greatly on the perspective chosen. The

application of steam power to shipping which occurred during the Industrial Revolution generated original design principles for providing waterborne transportation. Clearly, this represented a step-function in the development of design solutions for naval and commercial vessels. Since then, the steam ship concept has been improved vastly by adaptive and variant design. Considering only the hull form, it is difficult to argue that any mono-hulled displacement surface ship represents anything other than variant design. However, if the design procedure is classified based on the functional requirements of the completed ship, design in all three categories are possible. For example, the fitting of a standard cargo ship with a novel cargo handling system could be viewed as original design. In original, adaptive and variant design, the major issues facing a designer are different because the amount and type of design knowledge and information available at the start of the design process is different. In original design, solution principles are of paramount importance, for adaptive design, specified tasks assume major importance, and for variant design, size and/or general arrangement issues occupy the designer. In adaptive design, the new tasks specified are the major focus, the solution principle remains the same and therefore, is of no concern. The size and/or arrangement remain to be determined and are open issues. How can the efficiency and effectiveness of a designer be increased in Decision-Based Design? We assert that the efficiency and effectiveness of a designer can be increased: • by increasing the speed with which design iteration is accomplished, and • by reducing 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. 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. Without a model of a design process that can be represented and manipulated on a computer, it is impossible to provide guidance that is suitable for improving the efficiency and effectiveness of a human designer. By focusing upon decisions, we provide a means for creating models of decision-based processes (including design, manufacture and maintenance) that can be used to advantage by a computer-based Design Guidance S ystem (DGS) [59]. Issues relevant to the development of a Design Guidance System are described near the end of this paper. The starting point for representing a designer's perception of the real world and design environment is a heterarchical6 set of constructs7 arranged without discernable pattern and with no construct being dominant. Typically, the heterarchical set associated with a product's life-cycle includes the product's market, the product, its manufacture, its maintenance and its subsequent retirement8 . The starting point for representing a designer's perception of the process of design is also a heterarchical set of constructs (see Figure 13). In Decision-Based Design this heterarchical set embodies decisions or sets of decisions that characterize a designer's judgment of the decisions involved in effecting a design. A hierarchical set of constructs, on the other hand, characterizes the process or sequence involved in effecting these
Heterarchy - A formal organization of nodes without any single permanent uppermost node, a non-hierarchical organization. 7 Construct - a complex idea resulting from a synthesis of simpler ideas. 8 In Decision-Based Design, the terms manufacture and maintenance take on specific meanings (see [58, 60]). 19

decisions, and hence, the design. We call the

problem at the right level and postulate a process for ensuring an outcome; so too for a child. Imagine, a child playing with Decisions (DSPs and Decision Blocks) “Tinker Toys™” (see Fig. 11). The child Information and knowledge Parentis looking at some “disks” and “sticks” or Dominant DSP a contiguous pile on the floor. lying in There is an order in the apparent chaos on the floor but its form cannot be perceived by Mom or Dad; but the child may have a mental construct of what is to be built. Certain disks support others. Some pairs of disks are joined by sticks from past times at play. But then, gradually, the pieces from the floor are transformed into a sail boat. So when did the child start the process of building the sail boat? Was it with the keel, the hull, the mast, the sail … ? If we can identify this first HETERARCHICAL HIERARCHICAL step (i.e., the dominant node within a REPRESENTATION REPRESENTATION process) we know when the child started The relationships between The relationships between the process. We assert that the process decision blocks are not ordered decision blocks are ordered and hence not directed. and hence are directed. this case building) was initiated when (in the child first identified one of the disks and sticks as a component of the sail Fig. 10 Heterarchical and boat; the rest followed. Similarly, design starts when the first step is taken hierarchical representations in to extract a hierarchy from a heterarchy, Decision-Based Design that is, when the dominant node (in our case a decision entity) is chosen. The implementation of DecisionBased Design can take different forms. decisions, or sets of decisions, In mechanical engineering there is an decision entities. increasing awareness that decisions made Knowledge and information entities link by designers could be the key element in these decision entities in both the development of design methods that heterarchical and hierarchical facilitate design for the life cycle and representations as shown in Fig. 10. In a foster concurrency in the process, for heterarchy there are connections between example, Suh [19], Whitney et al. [61] nodes; there is a pattern or structure but and Finger et al. [62]. In naval the structure is re-entrant or recursive -architecture, Hills and Buxton [63] have without a permanent uppermost node or recently alluded to this notion as well. starting point. In practice, the challenge in transforming a decision heterarchy to a decision hierarchy (or plan of action) is to identify a correct starting point; one that leads to a plan of action that is both viable and cost-effective. As will be shown later, our ability to model processes using a set of basic entities is one of the principal features of Decision-Based Design. Modeling processes (for example, design, manufacture, maintenance, and the like) helps a designer identify the right
Decision and Information Entities





Fig. 11 Heterarchies and hierarchies: a Tinker Toy™ illustration

formulating Decision Support Problems (DSPs), and the software. The DSP Technique is being developed to effect the different types of design previously discussed, namely, original, adaptive and variant. The DSP Technique requires that a designer implement two phases, namely, a meta-design phase and a computer-based design phase. Metadesign is accomplished through partitioning a problem into its elemental DSPs and then devising a plan of action. Decision Support Problems provide a means for modeling decisions encountered in design and the domain specific mathematical models so built are called templates. Multiple objectives, quantified using analysis-based “hard” and insight-based “soft” information, can be modeled in the DSPs. For real-world, practical systems, all of the information for modeling systems comprehensively and accurately in the early stages of the project, may not be available. Therefore, the solution to the problem, even if one is obtained using optimization techniques, cannot be optimum with respect to the real world due to the inherent approximations in the model. However, this solution can be used to support a designer's quest for a superior solution. In a computer-assisted environment this support is provided in the form of optimal solutions for DSPs. Formulation and solution of DSPs provide a means for making the following types of decisions:

Our approach is called the Decision S upport Problem (DSP) Technique [64, 65]. It is being developed and implemented, at the University of Houston, to provide support for human judgment in designing systems which can be manufactured and maintained. The Decision Support Problem Technique and Decision Support Problems The DSP Technique consists of three principal components: a design philosophy rooted in systems thinking, an approach for identifying and

• Selection - the indication of a preference, based on multiple attributes, for one among several alternatives [66, 67]. • Compromise - the improvement of an alternative through modification [43, 67]. • Coupled or hierarchical - decisions that are linked together; selection/selection, compromise/compromise and selection/compromise decisions may be coupled [68, 69, 70, 71]. • Conditional - decisions in which the risk and uncertainty of the outcome are taken into account [72, 73, 74, 75]. • Heuristic - decisions made on the basis of a knowledge base of facts and rules of thumb; DSPs that are solved using reasoning and logic only [76]. Applications of DSPs include the design of ships, damage tolerant structural and mechanical systems, the design of aircraft, mechanisms, thermal energy systems, design using composite materials and data compression. A detailed set of references to these applications is presented in [77]. DSPs have been developed for hierarchical design; coupled selection-compromise, compromise-compromise and selectionselection. These constructs have been used to study interaction between design and manufacture [70] and between various events in the conceptual phase of the design process [68]. The software for implementing the DSP Technique is called the DSIDES system (Decision Support in the Design of Engineering Systems) [78] and the DSPT Workbook [79]. Support for human judgment in a computer-assisted environment is provided in the form of a Partitioner, a Scheduler, a Reporting utility and other utilities by means of which a designer can formulate and solve Decision Support Problems [80]. The Royal Australian Navy has incorporated DSIDES within AUSEVAL [81, 82]. AUSEVAL is a proto-typical system for the preliminary design of naval and commercial ships using Decision Support Problems and is

to be incorporated into MARIN’s HOSDES system [83, 84]. The processes of design, manufacture, maintenance are modeled in the DSP Technique using entities, for example, phases, events, tasks, decisions, and information. 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. Modeling a Time-Line for Design The life cycle of a large system such as a ship is delimited by the decision to create a ship design to conform to a specific problem statement and the ship's disposal. Thus a ship's life cycle has a beginning and an end with certain characteristic events occurring at approximately predictable points during this life cycle, for example, launching, refitting, etc. One way of assessing the passage of time is in terms of these events. For example, the passage of time could be related to the number of voyages taken, the extent of corrosion of the hull, or the obsolescence of the fittings. This is defined as event-based time. On the other hand, physical time is measured in years, days and hours. While eventbased time bears some relationship to physical time, it need not be linearly related. Time in a design process may be modeled using event-based time rather than physical time. As we indicated earlier, the principal role of the design process is to convert information that characterizes the needs and requirements for a product into knowledge about the product itself. For an engineering system, this conversion of information into knowledge is invariably accomplished in stages. In the traditional design process names have been given to the stages. In naval architecture these stages are frequently called feasibility, conceptual, preliminary and detail design. From the standpoint of the information

necessary for making decisions in each of the stages their name and number are not important. What is important is that: • the types of decisions being made (e.g., selection and compromise) are the same in all stages, and • the quantity of hard information (relative to soft information) increases as the knowledge about the product increases. In the DSP Technique, see Fig. 12, the qualitative ratio of hard-to-soft information available at any time in the process is a key factor in determining the nature of the support that a human designer needs as he/she negotiates a satisficing solution to a design problem. We assert that it is possible, based on this qualitative relationship to define any of the processes in design in terms of phases (e.g., designing for concept and designing for manufacture) and identifiable milestones or events (e.g., economic viability, preliminary synthesis, detailed analysis). We also believe that by using the qualitative relationship it is intuitively possible to categorize computer-based aids for design into categories, for example, tools that can be used to provide support for the decision making activities of a human designer form one category while tools that facilitate design automation form another category, (see Fig. 12). By way of example, a simplified time-line for original design is illustrated in Fig. 12. In the designing for concept phase we seek to cast as wide a net as practicable in order to generate as many concepts as possible and then to home in systematically on a concept which satisfies the functional specifications and which also can be produced and maintained. In other words, in designing for concept we are involved in the process of converting information that characterizes the needs and requirements for a product into specific knowledge that can be used in designing for manufacture and maintenance. In the designing for manufacture phase we seek to ensure that the product can be manufactured costeffectively. We recognize that in practice iteration between events (and phases) will

occur; however, such an eventuality is not explicitly shown in Fig. 12. One of the many scenarios that could be postulated by a designer to accomplish Conceptual Design through Detailed Analysis is shown in Fig. 13. Let us assume that we wish to execute an original design and that this process is underway. Further, let us assume that the economic viability of the project has been established and that the “go” signal for the next event (Conceptual Design) has been received in




Ideation, Artist's conception, Selection, Compromise, Rapid prototyping.
Designing for Concept

AUTOMATION CAD, Solid modelling, Tolerances, Manufacturing processes, Costing.

Designing for Manufacture

Economic Viability Conceptual

Detailed Detailed Processes Analysis Drawings for Serial (costing, Manufacture manufacturability, Prototype etc.) Testing Dimensional Synthesis (includes tolerancing)

Preliminary Synthesis

Fig. 12 A typical design timeline: an example incorporating designing for concept and designing for manufacture

the form of a problem statement. Now, we are ready to start the Conceptual Design phase. The first task in this example is ideation, that is, the generation of alternative ways (concepts) of achieving the objectives embodied in the problem statement. Ideally, a large number of concepts should be generated. Techniques that foster ideation include brainstorming, attribute listing, check listing and synectics. The end-product of ideation is a group of concepts. At this stage information on these concepts will be limited and most of it will be soft. How can we identify the best concept? This is a three-step process: • In the first step we use the available soft information to identify the more promising “most-likely-to-succeed” concepts. This is accomplished by formulating and solving a preliminary selection DSP. • Next, we establish the functional feasibility, in the context of essential requirements, of these most-likelyto-succeed concepts and develop them into candidate alternatives. The development process includes engineering analysis and design; it is aimed at increasing the amount of hard information that can be used to characterize the suitability of the alternative for selection. At the end of this step the ratio of hard to soft information should be significantly greater than it was at the start of this step. • In the third step we select one (or at most two) candidate alternative for further development. This is accomplished by formulating and solving a selection DSP which has been designed to utilize both the hard and the soft information available. Of course, as needed, we can, and should, repeat any of the preceding steps.

MACHINERY AND RELATED SPACES Event: Conceptual Design Ideation Generate many concepts. (CODOG, CODAD, COGOG, CODAG, Electric, Steam, Sail, ER aft, ER midships, Direct drive, Indirect drive … ) Decision via Preliminary Selection DSP Select the Most-Likely-To-Succeed concepts. → CODOG, CODAD, COGOG … Engineering Establish Functional Feasibility of Most-Likely-To Succeed concepts given Essential Requirements. (Convert concepts to candidate alternatives) Decision via Selection DSP Select one candidate alternative for development. → CODOG, ER midships, Direct Drive Engineering Establish the Cost-effectiveness and Manufacturability of the chosen alternative. (Critically evaluate the selection)

Event: Preliminary Synthesis
Decision via Compromise DSP Improve the Functional Effectiveness of selected alternative through modification. (Establish and accept a satisficing design)

Event: Detailed Analysis
Engineering Based on information provided in Preliminary Synthesis test the Functional Feasibility of the selected alternative in the context of a Comprehensive set of Requirements, and develop information on costs and manufacturing. Decision via refined Compromise DSP Improve, through modification, the Functional and Cost-effectiveness of the design. (Refine the Compromise DSP by including information on costs and manufacturability - Establish and accept an improved design)

Event: Dimensional Synthesis …

Fig. 13

Designing for concept: an idealization


Let us assume that we are satisfied with the alternative we have selected for further development. We develop this alternative into a feasible alternative (thereby increasing the value of the qualitative ratio between hard and soft information). This development results in a feasible alternative; one that satisfies the functional requirements, is probably cost-effective and can be manufactured. At this stage, we have a visceral feel for the overall dimensions and character of the system but are unable to state with confidence its precise dimensions. However, let us assume that we are satisfied with the feasibility of the alternative and are ready to proceed to the next phase, namely, Preliminary Synthesis. In Preliminary Synthesis the alternative is improved through the modification of its dimensions. This is achieved by formulating and solving a compromise DSP. In this event our earlier feel for the dimensions and general character of the design's descriptors is transformed from the imprecision of unquantifiable parameters to precisely defined, numerically stated measures of the design's properties. We are ready now to undertake the next phase, namely, Detailed Analysis. There is sufficient information about the vessel at the start of the Detailed Analysis phase to ensure functional feasibility in the context of a comprehensive set of requirements and -in terms of the first-order information used in the just-performed Preliminary Synthesis -- its cost-effectiveness and manufacturability. In Detailed Analysis we may perform a relatively complete stress analysis of the design using a finite element program, a relatively complete simulation of the system, and the like. We are now in a position to ensure the functional feasibility of a design that is cost-effective and manufacturable. This is accomplished by augmenting the formulation of the compromise DSP used for Preliminary Synthesis with economic and manufacturability considerations. The end-product of Preliminary Synthesis is the preliminary design. Of

course, the value of the qualitative ratio between hard and soft information has increased and upon analysis we are ready for the next phase, namely, Designing for Manufacture. As previously identified, the act of designing always involves some iterating. Iterating is costly and should ideally be avoided and if it is necessary it should be accomplished as rapidly as possible. In the DSP Technique rapid iteration is possible by modifying and resolving the DSPs. Iteration costs can also be reduced by evaluating the need for iteration at clearly defined points in the design time-line. In the DSP Technique these points are the clearly defined phases and events (see Fig. 13). Now, how can a time-line of a process be modeled using phases and events? The answer: Meta-design. Meta-Design: A Paradigm for Partitioning and Planning in Engineering Design The development of methods for dividing system design problems into subproblems, solving these subproblems and then synthesizing these solutions into a design for the entire system is important. We define the term system [85] as follows: SYSTEM A system is a grouping of associated entities which is characterized by a mental construct; one of the associated entities is the boundary. The preceding definition is applicable to both concrete and conceptual systems. A concrete system, for example, a ship, or a tension-leg platform for drilling, exists in space and time and is composed of matter and energy organized by information. A conceptual system exists in the mind only and, hence, conceptualizations of presumably the same system may differ from observer to observer. Some of the constructs or parts of conceptual systems may correspond to real-world systems. For example, the American Bureau of

Shipping, considered as a whole is a conceptual system which is synthesized from two constructs, one representing its concrete subsystems such as its employees, computers, etc. and the other a conceptual subsystem representing its organization and structure. Note, our definition of system is applicable to both the object being designed and the design process itself; the object maybe a concrete or conceptual system and the design process itself is a conceptual system. In order to facilitate a holistic representation of a system in the early stages of project initiation, we need tools that allow us to represent the desired functions of a system by constructing a model of it using representations of subsystems or clusters of subsystems with assigned functions. These representations can be specific or generic. The latter are of greater value initially in that each generic representation specifies the function which a group of components (a subsystem) is required to perform, for example, storage of information, matter or energy. In this form, the representation need not indicate the physical characteristics of the subsystem, its cost or other pertinent information, only its function. We need tools to model the processes we use to design these systems. At this early stage in the design of a system, within the bounds of reasonable connectivities, a designer can arrange and rearrange its essential functional components without regard for, say, physical or economic considerations. This offers a designer the means to explore the feasibility of different system configurations and to pose and answer “what-if” kinds of questions before the design has been frozen and changes in it can be made only with great difficulty. Similarly, we need tools that allow us to represent, in the early stages of project initiation, the processes that we use to design these systems; tools that allow us to arrange and rearrange essential procedures or activities without regard for, say, the available resources and this leads to metadesign [60, 85].

META-DESIGN: a metalevel process of designing systems that includes partitioning the system for function, partitioning the design process into a set of decisions and planning the sequence in which these decisions will be made. Meta-design is particularly useful in the design of systems in which concurrency among disciplines is required or in which some degree of concurrency in analysis and synthesis is sought. The specific activities performed by a designer change as the design evolves. So do the specific activities that constitute meta-design. Rogan and Cralley [86] describe some of the issues involved in using meta-design in designing a design process for a realworld engineering system. A design problem may be divided into subproblems either by decomposition or partitioning. In the early stages of project initiation these terms are not synonyms. The processes are different. In the context of design, and particularly in the context of the DSP Technique, the differences in the meanings of the two terms are essential to distinguish between two modes of approach to design problems. Decomposition is the process of dividing the system into its smallest, coherent, self-contained elements. A designer using decomposition is guided by the inherent structure of the system and the Newtonian principles of reductionism and mechanism and is motivated by the knowledge that (although it may not be clearly revealed to a designer) the solution being sought exists. This knowledge follows from the fact that either explicitly or implicitly the problem statement specifies a closed system. If followed to completion, decomposition always results in the same subsystems, regardless of who performs the decomposition. Decomposition is appropriate especially when design synthesis is based on the principle of repeated analysis. In decomposition, analysis progresses from the level of parent system to subsystems to subsubsystems to … and finally to

components. The reverse process, synthesis, progresses from the component to system level. In adaptive and variant design involving closed systems, decomposition is important and the reversibility of the decomposition/synthesis process is exploited. However, in original design, decomposition must play a subordinate role to partitioning and planning since the subsystems cannot be defined a priori. Expressed differently, if the problem statement implies an open system, one that is incompletely specified, a designer is precluded from using decomposition. Partitioning and planning is required. Partitioning is the process of dividing the functions, processes, and structures that comprise the system into subsystems, subsubsystems, etc. In partitioning a designer is guided by knowledge of the system's environment, by considerations of the human needs the system must satisfy and the tasks that must be performed by the fully functional system. Partitioning a design problem yields a grouping of interrelated decisions and also provides knowledge and information that can be used for planning. In the Decision Support Problem Technique we partition the system being designed into its subsystems and the process of design into decisions using generic, disciplineindependent models which have their origins in the taxonomy of general living systems theory [65, 85, 87]. In planning, information about organizational resources and time constraints are added to the decisions identified in the partitioning phase and these decisions are organized into a decision plan, that is, a plan of action for implementing the decision-based design process. In the Decision Support Problem Technique planning provides the structure within which we organize the decisions we expect to make in the course of designing a product. Central to partitioning, decomposition and planning is our ability to model the processes associated with design. The modeling and the design of the design

process itself are discussed in the following section.

Modeling Design Processes in the Decision Support Problem Technique
As indicated earlier, we believe it is unlikely that one model will emerge as the ultimate model of design. We subscribe to the notion that the principal function of an engineer in general and a design engineer in particular is to make decisions. In this context, in the earlier sections, we have provided a description of our understanding of the nature of the design environment and a categorization of the process of design (from a decisionbased perspective) in terms of phases, events, tasks, knowledge and information, and decisions. We expect our decision-based model to take on different forms to accommodate design of systems in general -- designs that are characterized by information from multiple disciplines, different types of designs, and different perspectives within the life cycle. In effect, our model, considered as a system, is open to its environment and we expect it to evolve with time. To facilitate this, our thrust is to make available tools (analogous to the palette of a painter) that a human designer can use to describe a design time-line. Of course, in time, these descriptions along a time-line could result in prescriptions for parts of the overall process. By giving designers the lead role in model development, we believe, it will ensure continuous feedback which can be used to improve the tools themselves. Entities for Modeling Design Processes within the DSP Technique The basic entities for modeling a process in the DSP Technique, in an ascending hierarchical order are: Knowledge and Information, Tasks and Decisions, Events and Phases. These basic entities are used to build

hierarchies and model design processes independent of the domain of application. In Fig. 12 two phases, namely, Designing for Concept and Designing for Manufacture, are indicated. Each of these phases consists of Events, for example, Economic Viability, Conceptual Design, etc. Tasks and Decisions are used to model Events (see Fig. 13). The role of Tasks and Decisions is to use what is known about a product to learn more and to augment the already known data with the new. Both Tasks and Decisions require knowledge and information as input and they produce knowledge and information as output. In the DSP Technique a Decision entity is modeled as a DSP. Communication between entities is maintained by using the Knowledge and Information entity. Thus, while Phases, Events, Tasks and Decision entities embody knowledge and information, they do so at different levels of abstraction. In keeping with our definition of a system presented earlier, a system can be modeled by a grouping of associated subsystems. Accordingly, a process is a system as are, potentially, the higherlevel entities used to model the process. A system may have subsystems. Similarly, entities may embody other entities. Thus, a hierarchy of processes can be modeled using the basic entities we have just introduced. A system has certain properties. These properties are characterized by system descriptors, namely, system variables and their relationships. Relationships between the system variables exist and can be modeled as analytical relationships (for example, force = mass * acceleration), or as goals, constraints and bounds. The goals, constraints and bounds represent the aspirations, requirements and limits imposed on a system respectively. Constraints and bounds describe the feasible design space (the space representing all feasible solutions) and the goals define the aspiration space. All entities embody relationships but all relationships are not restricted to being mathematical in nature. Relationships in

a process can occur in different forms, for example, as a computer program, knowledge base, rule, neural network, mathematical programming formulation, a simple formula, etc. However, a uniform representation scheme can be developed by recognizing that all relationships require some form of input and generate an appropriate output. This view facilitates the combination of different types of relationships into networks and paths, that is, into hierarchies. These hierarchies represent the knowledge and information held and generated at different levels of complexity. An example of this is the combination of subroutines into a FORTRAN program. In a computer program several relationships are combined into a larger, more complex relationship. Extensive work in the use of relationships in ship design is being performed by Duffy and MacCullum [51]. At the meta-design level, the actual formulation of the relationship is in most cases not needed. For planning purposes, in evaluating what should be done next or when creating a model or hierarchy, it is sufficient to know whether one or more relationships can be found in order to progress. However, at the design level where one is actually formulating, solving and debugging relationships, specific information about the form of the relationship is required. This brings us to the context in which the entities are used. Design requires more detailed information about the entities than meta-design. Therefore we distinguish between knowledge and information used by the entities and knowledge and information about the entities. We call the former design knowledge and the latter metaknowledge. Introducing the DSPT Palette In this section we introduce the Decision Support Problem Technique Palette which is used to model a process. This palette, shown in Fig. 14, contains symbols or icons for the basic entities described in the preceding section.

P E T ? i ? ? ? ?




Decision …

Information …

Compromise Preliminary Selection Selection

System System Variable Goals / Bounds Constraints Analytical Relationship

Fig. 14 The DSPT palette for modeling processes The Phase icon is identified by a “P” and can be used to partition a process into smaller more manageable pieces. Events occur within a phase and the Event icon is identified by an “E”. Tasks and Decisions occur within Events. A task is an activity to be accomplished. The design process itself is a task for the design team, namely, “convert information into knowledge about the product”. The task itself may contain other tasks and decisions -- as in the design task. However, simple tasks like “run computer program A” do not involve decisions. In our palette a task is identified by a “T”. A Decision icon is defined by a rectangle having a question mark within it. This choice was natural as a question

mark often connotates a call for a decision. Currently we have only included specifically the preliminary selection, selection and compromise decisions in the palette. The corresponding icons are a combination of the basic decision icon with some further symbolism. Selection is a converging activity since the number of alternatives is reduced. The icons for both selection DSPs characterize this in our palette. The selection DSP icon has a single point, indicating that on solving a selection DSP a single alternative is identified for further development. The preliminary selection icon is similar but it does not end with a point indicating that on solving a preliminary selection DSP a number of most-likely-to-succeed concepts are identified for further development. The icon for a compromise DSP ends in a “C”. A compromise represents a tradeoff between conflicting goals. When there is no conflict between the goals the solution could be represented by the upper or lower extremes of the C in the rectangle. However, when there is a conflict, which invariably is the case, the result emerges from the middle representative of a compromise between two extremes. Knowledge and information are required to model any process. In the palette, knowledge and information about the process and product are classified as systems. A system is identified by a circle with a smaller circle in the middle. This is illustrative of the central nature of a system in the

process and also the fact that other systems and their associated knowledge and information are embedded in the system. This embodiment is symbolized by the small circle. System variables (e.g., principal dimensions, length of an event, number of people involved in a task) are embedded in systems. The icon for a system variable is a small circle showing its atom-like character and that no lower hierarchical level is possible. Relationships are often considered as “black boxes”. Hence, our representation of analytical relationships as plain rectangles. All icons having a rectangular shape are in fact relationships. Phases, Events, Tasks and Decisions are relationships. An icon consisting of a nozzle embedded within a rectangle is representative of a goal/constraint/bound type relationship. The nozzle is symbolic of the restrictive nature of these relationships. As shown, all icons embody deterministic/hard knowledge and information. Soft knowledge and information are to be represented using the same icons but with different grey scales applied. The darker the icon appears, the more one is looking in the dark and the softer the knowledge and information available. As the icon becomes lighter, the knowledge and information becomes clearer and harder. Using the icons in this palette we are able to describe processes. Design knowledge and information flows from left to right through the icons. Metaknowledge and

information is connected to the design information by lines of a different type. In a computer environment the metainformation can be stored in a different layer which can be projected onto the layer with the primary design process description. Needless to say the same icons are used to model both meta- and design- knowledge and information. Using the DSPT Palette for the Design of a Frigate In this section we illustrate the use of the DSPT Palette using the design of a frigate as an example. The partitioning, of this example, follows the same general pattern illustrated earlier (see Fig. 13) -but it is markedly different in respect to the details of implementation. In Fig. 15 a portion of the time-line of the life cycle of a frigate is shown. From left to right, the qualitative relationship between hard and soft information increases. The design Phases, Events and product specific information are included. The graphics on the bottom line represent the strategic need, the various concepts, the selected basic concept, the preliminary design, the contract negotiations, the manufacturing, the finished ship, the ship after the half-life refit and the decommissioned ship. As shown in Fig. 15, the design is partitioned into four major design phases for this example. Typically, the end of each phase is not abrupt and it is often difficult to see when a



DESIGNING FOR CONCEPT DESIGNING FOR MANUFACTURE DESIGNING FOR MAINTENANCE DESIGNING FOR IMPROVEMENT Development of Naval Staff Requirements (NSR) Conceptual Design Preliminary Design Contract Design Tender Evaluation Contract Negotiations Detail Design Construction Launching Trials Commissioning Post Design Intermediate Dockings Half Life Refit Decommissioning Disposal


Strategic Need / Foreign Policy Statement of Requirements Basic Concept (product of Conceptual Design) Top Level Specification (product of Preliminary Design) PRODUCT Ship Characteristics (product of Preliminary Design) SPECIFIC Detailed Ship Design and Construction Specification (product of Contract Design) INFORMATION Contract Guidance Drawings (products of Contract Design) Construction Work Packages (products of Detail Design) Maintenance Documentation Operational Documentation Test and Trial Reports Service Life History







Fig. 15 Time-line for designing a frigate new phase starts. Therefore, the phases Macintosh™) a designer could click on in Fig. 15 overlap each other. Within and “open” an icon. By this action, the these phases we identify a number of lower level models would be displayed. Events. Events are not restricted to one By way of example we have opened the phase. For instance the preliminary Phase icon for Designing for Concept in design event is found in designing for Fig. 16. Now the events that constitute concept, manufacture and maintenance. this phase are visible. The horizontal bars in Fig. 15 provide an The first event is the development of indication of the duration, in physical the Naval Staff Requirements which time, of phases and events. Input to the results in a document. This document design process is a strategic need or plus general design information forms the foreign policy and during the life of the input for the conceptual design event frigate more and more hard information which feeds forward a basic concept (e.g., drawings, documentation) while initiating a feedback loop to the becomes available. Thus, the ratio of development of the naval staff hard to soft information is seen to requirement event. The basic concept increase as the time-line is traversed from and the general design knowledge left to right. provide the necessary information for the The icons from the DSPT Palette are preliminary and contract design events. now used to model the time-line shown Note that again an overlap between these in Fig. 15. In Fig. 16 the top level model two events occurs. The preliminary is given. This model consists of four design event provides the top level overlapping phases (Designing for specification and the ship characteristics, Concept, Designing for Manufacture, whereas the contract design event Designing for Maintenance and provides the general specification and the Designing for Improvement) and the guidance drawings. For a closer look we input and output information (the open the conceptual and preliminary strategic need and the total life cycle design events. design knowledge). On a computer A model of the conceptual design desk-top (like that provided by an Apple event is given in Fig. 17. The primary

goal of this event is to establish the basic concept. Therefore concepts have to be generated from general design knowledge. Our model reveals that a preliminary selection DSP is to be solved to identify the most suitable concepts for further development. This is to be followed by solving a compromise DSP to improve these concepts through modification. Finally a selection DSP is to be solved to identify the basic concept. Attributes are modeled in both the preliminary selection and the selection
Strategic Need/ Foreign Policy i

Conceptual Design
E i

Basic Concept


Extract Goals and Constraints

Determine Influencing Attributes T Concepts


i Goals and


Suitable Concepts
? i ? i ?


Improved Concepts
P P P i

Total Life Cycle Design Information (Knowledge)

Generate T Concepts

i Improvement

Measures of (variables)

DESIGNING FOR CONCEPT Concept(s) Information



General Design Knowledge Top Level i Specification
Preliminary Design
E i E i Ship

Determine Areas for Potential Improvement

Strategic Need/ Foreign Policy
i E


Fig. 17 A model of the conceptual design event Characteristics

Development of NSR

Conceptual Basic Design Concept

E i Specification i

Contract Design


General Design Knowledge

Fig. 16 A model of the designing for concept phase

DSPs. Therefore, a task is introduced in the Contractmodel for determining the most influential attributes from the naval staff Guidance Drawings requirements. For the compromise DSP we need to know the areas to be improved and what the goals and constraints are. The goals and constraints are extracted from the naval staff requirements. The task of finding the areas of possible improvement depend on the concept to be improved and the general design knowledge. After having improved the concepts the basic concept is selected. In the model, concurrency can be detected easily. The tasks of determining the influencing attributes, extracting the goals and constraints from the naval staff requirements and the generation of concepts can be performed simultaneously. Also, the task of extracting goals and constraints and the task of determining the areas for potential


improvement can be performed concurrently. Once the basic concept is known from the conceptual design event we can start the preliminary design event. A model of the preliminary design event is given in Fig. 18. The results of the preliminary design event are the ship characteristics and the top level specification. For this the basic concept needs to be refined. The subsystems and their associated information have to be determined. This ordering of information is a task. Using this information a preliminary ship synthesis needs to be performed. A propeller selection needs to be made and the propeller and hull dimensions have to be determined. We use compromise DSPs for the dimensioning and a selection DSP for the propeller selection. The goals and constraints obtained from the naval staff requirements may need to be refined prior to solving the DSPs. In Fig. 18 we have only shown the hull and propeller subsystems, but DSPs for the machinery selection, compartment arrangement etc. can be added. This is implied by the dotted line below the DSPs and the analysis information icons. The DSPs are not independent of each other. A change in the hull dimensions affects the propeller choice and dimensioning in general. Therefore, the DSPs are modeled as being coupled and should be solved concurrently. The model solution obtained from the preliminary ship synthesis is validated next in an experimental validation event. In this event towing tank tests, data interpretation, etc., are performed. The experimental validation is then fed back and is ordered with the other available information. Preliminary ship synthesis may need to be performed again. If a satisfactory model is

Preliminary Design

i Specification i Ship

Top Level


Goals and Constraints

Refine Goals and Constraints

Hull Analysis Basic Concept
i i


Goals and Constraints Specification Model Prepare Solution Documents
i T

Propeller Concepts & Order Information Attributes
T i




General Design Knowledge

Propeller Analysis

Preliminary Ship Synthesis Experimental Validation




Experimental Information

Fig. 18 A model of the preliminary design event obtained the corresponding documents, the top level specification and the ship characteristics, need to be prepared. Preliminary ship synthesis is a key element shown in Fig. 18. Therefore we have focused on this element again in Fig. 19. The information blocks consist of various systems (in this case propeller types), system variables, analytical relationships and goal/constraint relationships. Note the use and amount of grey shading in the resistance calculation and seakeeping calculation relationships. Both are empirical relationships. Assuming an available set of algorithms, the seakeeping calculation is shown darker, implying that it is more vague than the resistance calculation. As we have stated, the DSPs forming the preliminary ship synthesis model should be solved concurrently. We are able to solve such problems using the coupled mathematical formulations of the DSPs

shown in the lower part of Fig. 19. A more detailed discussion of the “Compromise DSP” in general follows, as do some sample DSPs relating to the design of a light-patrol frigate. In Fig. 20 we illustrate, using icons from the DSPT Palette, the Evans/Buxton design spiral using as a basis the representation provided by Buxton [41, 88]. The model is sequential with a refinement loop and the available information increments after each task is completed. Whereas the DSPT Palette was developed for use in the DSP Technique it can be used to model the ship design spiral and extrapolating, all manner of design models, both descriptive and prescriptive. In both the frigate and the design spiral examples detailed above, the metaknowledge and information has not been depicted in order to simplify the figures. The Compromise Decision Support Problem: Some Details

Length Beam Draft Depth ...... Resistance Calculation Seakeeping Calculation Space Calculation ......

Volume greater than Required Volume Achieve desired Seakeeping Performance Depth to Propeller Shaft within specified bounds ......

Hull Analysis
i i Goals and

Constraints Model Solution

Propeller Concepts & Attributes
i Wageningen B-series Controllable Pitch ......



Propeller Analysis

Preliminary Ship Synthesis

Selection DSP Compromise DSP 1 Compromise DSP 2 (Propeller) (Hull) (Propeller ) _____________________________________________________________ Find Y, e- , e+ X, d-, d+ S, h -, h+ Satisfy ∑Y=1 g1(S,X,Y) ≥ 0 g 2(S,X,Y) ≥ 0 MF(X,S) . Y + e- - e+ = 1 A1(S,X,Y) + d- - d+ = G1 A2(S,X,Y) + h - - h+ = G e- * e+ = 0 # d- * d+ = 0 # h - * h+ = 0 # 0 ≤ Y≤ 1 Xmin ≤ X ≤ Xmax S min ≤ S ≤ Smax e- , e+≥ 0 d- , d+≥ 0 h - , h +≥ 0 _____________________________________________________________ Minimize (Lexicographically) Z = { f1(e -, d- , d+ , h- , h+), ..., fk(e -, d-, d+, h- , h+) } X, Y, S - system variables h- , h+, d-, d+, e-, e+ - deviation variables g - constraint functions A - goal functions G - goal target values MFi - merit function of alternative i Z - deviation function (Preemptive form, k priority levels) # can be omitted if a vertex-solution algorithm is used

The difference between the compromise DSP and the traditional single objective formulation for a two dimensional problem is illustrated in Fig. 21. In the case of the single objective formulation, shown in Fig. 21a, the objective is a function of the system variables. The space representing all feasible solutions (the feasible design space) is surrounded by the system constraints and bounds of the problem. The objective is to maximize the value of Z and hence, as shown in the figure, the solution will be at vertex A.

Fig. 19 An example of modeling preliminary ship synthesis


Determine Trading Pattern
i T i i

Determine Speed
T i i i

Determine Dimensions


Incremental Information

Fig. 20 A model of the Buxton/Evans design spiral using i the palette
i i i

Incremental Information

Incremental Information

(OTHER TASKS) Determine Trim and Stability
T i i i i i i i i i i i i i i i

Determine Lightweight Deadweight
T i i i i i i i i i i i i i i i i

Determine Economics
T i i i i i i i i i i i i i i i i i

Incremental Information Objective Function X2

Incremental Information

Incremental Information

A2(X) + d 2- - d2+ = G2

Z = W 1 A1(X) + W2 A2(X) + W3 A3(X)




A1(X) + d1 - - d1+ = G 1 Aspiration Space

Direction of increasing Z A Feasible Design Space Feasible Design Space A

Deviation Function

A3(X) + d3- - d3 + = G

Z = W 3 (d1- + d1+) + W3 (d 2-+ d 2+) + W3 (d3 -+ d

Bounds System constraints


Bounds System constraints System goals




Fig. 21

A single objective optimization problem and the multigoal compromise decision support problem solution to this problem represents a trade-off between that which is desired (as modeled by the aspiration space) and that which can be achieved (as modeled by the design space). For illustrative purposes assume that there is no point of overlap between the design space and the aspiration space. Further, the Archimedean form (see Fig. 22) has been

In the compromise formulation, the set of system constraints and bounds again define the feasible design space, whereas the set of system goals define the aspiration space (see Fig. 21b and Fig. 22). For feasibility the system constraints and bounds must again be satisfied whereas the system goals are to be achieved to the extent possible. The

used and it is assumed that the goals are equally important. Can the standard single objective form provide a solution to a problem posed in this way? The answer is no. In the standard form there is no provision to model “soft” constraints; the goals of the compromise DSP are akin to soft constraints. Further, no information is available, when the standard form is used, as to what a designer should do to alter the model to obtain a feasible solution. The solution for the compromise DSP shown in Fig. 21b is at vertex A. This is the same solution as that obtained for the problem illustrated in Fig. 21a. The difference is that in the compromise case with the aspiration space modeled, the best possible solution can be identified. Given a solution, it is left to a designer to accept this solution or to explore the problem further by modifying the aspirations and/or the feasible design space and re-solving. The values of the deviation variables provide a measure in assessing the degree by which each of the goals have not been achieved and are a source of some very useful information. One of the first and most widely used multiobjective mathematical programming techniques is Goal Programming (GP) [89]. In our opinion, the compromise DSP is a subset of goal programming; a subset that is particularly suitable for use in engineering. The term “goal programming” is used, by its developers [90], to indicate the search for an “optimal” program (i.e., set of policies to be implemented), for a mathematical model that is composed solely of goals. This does not represent a limitation, in fact any mathematical programming model (e.g., linear programming), may find an alternate representation via GP. Further, not only does GP provide an alternative representation, it often provides a representation that is more effective than other techniques in capturing the nature of real world problems. From our perspective, the terms “Compromise Decision Support Problem” and “Goal Programming” are synonymous to the extent that they refer

to multiobjective optimization models; they both share the concept of deviation variables which provide a measure of the “goodness” of the solution with respect to the target values of goals. They both share the concept of problem variables



A1 (X)/G1 + d 1 - - d + = T 1 1

A2(X)/G2 + d2 - - d + = T 2 2 Aspiration Space

Feasible Design Space

Deviation Function

+ A3 (X)/G 3 + d 3 - - d 3 = T 3

X Bounds System constraints System goals


Given An Alternative to be improved through modification, Assumptions used to model the domain of interest, The system parameters, The goals for the design, and n number of system variables p+q number of system constraints p equality constraints q inequality constraints m number of system goals Gi value that is desirable to achieve Ai(X) that which can be achieved Ti target value, nondimensional ratio g i (X) system constraint function fk (di ) Wi Capability ≥ Demand g i (X) = Ci (X) - D i (X) function of deviation variables to be minimized at priority level k for Preemptive case weight for Archimedean case

Find The values of the independent system variables: Xj j = 1,..., n The values of the deviation variables: di -, d + i i = 1,..., m Satisfy The system constraints (linear, nonlinear): g i (X) = 0; i = 1,..., p g i (X) ≥ 0; i = p+1,...,p+q + di -* di = 0; i = 1,..., m The system goals (linear, nonlinear): + Ai(X)/G i + di - - di = T i ; i = 1,..., m The lower and upper bounds on the system variables: Xj min ≤ Xj ≤ X max ; j = 1,..., n j The lower bounds on the deviation variables: d i - , di ≥ 0 Minimize The deviation function: Case a: Preemptive (lexicographic minimum) Z = [ f 1 d i -, d i +), . . ,f ( d i -, d +) ] ( k i Case b: Archimedean m m + Z = ∑ Wi d i - + d i ) ; ( ∑ Wi = 1; Wi≥ 0 i=1 i=1

Fig. 22 The compromise decision support problem

and hard and soft goals (called system variables, system constraints and system goals in the compromise DSP formulation). What distinguishes the compromise DSP formulation is the fact that it is tailored to handle common engineering design situations in which physical limitations manifest themselves as system constraints (mostly inequalities) and bounds. These constraints and bounds are handled separately from the system goals, contrary to the goal programming formulation in which everything is converted into goals. The system descriptors, namely, system and deviation variables, system constraints, system goals, bounds and the deviation function are described in detail elsewhere (for example, [43, 67]) and will not be repeated here. The mathematical form of the compromise DSP is summarized in Fig. 22. The selection DSP can be formulated and solved as a compromise DSP [69] (this is important for facilitating concurrency in synthesis). This makes it possible to formulate and solve coupled selectionselection DSPs and coupled selectioncompromise DSPs [50, 68, 70]. In effect the mathematical form of the coupled DSPs are akin to compromise DSPs. The compromise DSP is solved using an extension of the SLIPML algorithm [53] that is part of the DSIDES System [78]. For coupled DSPs the SLIPML algorithm calls on the MULTIPLEX algorithm to effect solution [91]. As indicated in Fig. 22 the system and deviation variables in a compromise DSP are always nonnegative. Further, to effect solution one of the following three conditions must hold, namely, di- = 0 and di+ = 0 or di- = 0 and di+ > 0 or di- > 0 and di+ = 0 . This requirement is modeled by: di- . d i+ = 0. The preceding constraint must be satisfied to obtain a solution of the compromise DSP. The satisfaction of

this constraint poses a problem for gradient-based nonlinear programming algorithms. If we are willing to accept a vertex solution then this constraint is satisfied as a matter of course. Since SLIPML and its extension, the ALP algorithm, are based on the notion of sequential linear programming that results in solutions at the vertex, this constraint can be omitted from the formal mathematical model.

elsewhere [81, 82] and the specific problems were developed and solved using AUSEVAL. Design Requirements For a LightPatrol Frigate A new frigate is required for undertaking general, long-distance patrol duties off the east coast of Australia. This frigate must have high-speed pursuit capability together with an extensive range and endurance. Weapons and sensors include a large anti-submarine helicopter with an appropriate handling system, a medium-calibre gun, a surveillance radar, a point-defence weapon system, a hull-mounted sonar system and a close-in weapon system. The frigate is also required to be fully operable, including helicopter operations, in seastate 5, have a maximum sustained speed of no less than 30 knots and have an endurance speed of at least 18 knots. The range is to be at least 5000 NM at the endurance speed of 18 knots. The technical requirements for the ship include a combined diesel or gas (CODOG) machinery system located amidships, two propeller shafts, a steel hull and steel superstructure and a 2.55 meters target height between decks. Hull Synthesis: Template The Frigate

Designing a Light-Patrol Frigate
We use a practical example, namely, the design of a light-patrol frigate to illustrate some of the points made earlier in this paper: • By using a practical example we provide a flavor of the mechanics of applying the Decision-Based Design paradigm to a design problem. In particular, this frigate example is used to highlight some facets of the preliminary ship synthesis module of Fig. 19. • In practice, ship design involves a number of trade-offs (or compromises) between economic and technical efficiency. The efficacy of using the compromise DSP in such cases is illustrated through example. The example involves the determination of that set of principal dimensions that satisfy a multitude of constraints and is also representative of the best trade-off between technical and economic efficiency. • A DSP template can evolve with time, be used to explore the solution space and/or quantify rapidly the effect of changing requirements on the solution. This too is illustrated in this section. A reduced set of design requirements for a light-patrol frigate are listed in the following section. Additional information pertaining to the conceptual design of this vessel is reported

In considering machinery, in many cases, the requirement of naval ships to operate over a range of speeds requires a hybrid system. For instance, with a CODOG arrangement the diesels are adequate to deliver power at the endurance speed while gas turbines are utilized to achieve maximum speed. Another alternative is diesel and diesel (CODAD) where in the sprint condition, all engines are on line. Similarly, configurations such as CODAG and COGAG are possibilities. The primary template detailed herein offers machinery arrangement specification in the form of a select one-from-many menu. Later

discussion relates to exploring the effect of alternate machinery arrangements via rapid redesign and augmentation of the frigate template with a machinery system selection template. Returning to the model of Fig. 19 and continuing on from the preceding general discussion, the hull synthesis model for this frigate is detailed in the form of a compromise DSP. In light of the design requirements quoted, and given that the ship is required to remain at sea for extensive periods, the goals for the design are identified (in order of priority) as: • Achieve the desired capital cost. • Achieve the desired seakeeping quality. • Achieve the desired endurance speed powering. • Achieve the desired maximum sustained speed powering. • Achieve the desired displacement. • Achieve the desired height between decks. It is recognized that while the template described accommodates and synthesizes most aspects of naval ship design, some items such as through life costs and the choice of structural arrangement, either longitudinal or transverse framing, are not currently included in the model. The frigate template is formulated as follows: Given Naval Operational Requirements • Ship Type (frigate) • Speed maximum sustained in knots endurance in knots • Range at endurance speed in nautical miles • Endurance - days at sea • Seakeeping maximum seastate for normal ship and helicopter operation.

• Payload number and type of weapons, aircraft, command, control and surveillance equipment Desirable Characteristics • Machinery Type (CODOG or CODAD or COGAG or Steam Turbine) • Location of machinery space (aft or midships) • Number of propeller shafts • Hull and superstructure material (steel and/or aluminium) Find The principal ship dimensions LPP - length between perpendiculars in meters B - ship design beam in meters T - ship design draft in meters D - ship design depth in meters The form coefficients Cb - block coefficient Cp - prismatic coefficient Cw - waterplane coefficient Cm - midship section coefficient and LCB - longitudinal center of buoyancy in meters forward of midships LCF - longitudinal center of floatation in meters forward of midships SDKHT- standard height between decks in meters Satisfy The following system constraints: Space • Displacement is equal to or greater than the estimated weight • Internal volume is equal to or greater than the required internal volume


• Total deck area is equal to or greater than the required deck area • Length must exceed aerial, weapon and ship system separation requirements • The double bottom height is between 0 and 1.5 meters Stability • The intact stability in the minimum operating condition exceeds the minimum requirement determined in accordance with RAN Stability Criteria Seakeeping • The seakeeping rank is greater than that required for the specified sea state for normal ship operations and for helicopter operations • The natural period of roll is greater than the period of encounter • The natural period of heave is greater than 120% of the period of encounter relevant to heave, i.e. ship operates in supercritical region • The natural period of pitch is greater than 120% of the period of encounter relevant to pitch, i.e. ship operates in supercritical region • Freeboard is greater than the required freeboard at midships Form • The prismatic coefficient is within limits defined by the speed-length ratio • The LCF is at least a given percentage aft of the LCB • The form coefficient relationship, Cb=Cp*Cm • Minimum and maximum values for : L/B L/D L/T B/D B/T T/D Cb/Cw Cb/Cp Cw/Cp SDKHT

The following system bounds: • All variables, except LCB and LCF, must be positive • The block coefficient, Cb, lies between 0.4 and 0.9 • The waterplane coefficient, Cw, lies between 0.65 and 0.9 • The prismatic coefficient, Cp, lies between 0.55 and 0.85 • The midship section coefficient, Cm, lies between 0.7 and 0.995 The following system goals: • The capital cost is equal to or smaller than the target value • The seakeeping quality is equal to or greater than the target value • The endurance speed powering is equal to or smaller than the target value • The maximum sustained speed powering is equal to or smaller than the target value • The displacement is equal to or smaller than the target value • The height between decks is equal to or greater than the target value Minimize • The deviation function. The preceding word problem has been transformed into a mathematical form (a compromise DSP) and solved. Some comments on the mathematical model, its solution and partial results follow. Some Comments on Formulation and Solution the

The general mathematical form of a compromise DSP is shown in Fig. 19 and in greater detail in Fig. 22. For the frigate DSP, the bounds on the system variables (e.g., 100 m ≤ LPP ≤ 200 m) and the linear constraints which represent the hull geometry “design lanes” (e.g., 1.220 ≤ 1.0942*Cb + 1.0*C w ≤ 1.260) are easily represented in the template implemented on a computer. However, the nonlinear constraints and goals cannot be so easily represented in

the computer template. Each of them has been encoded in a subroutine or set of subroutines and it is sufficient to identify here a subject list of the library modules utilized to effect solution: A/C LOADS COSTS COMPLEMENT DECK AREAS ELECTRICAL LOADS FREEBOARD HYDROSTATICS POWERING PROPELLERS RANGE SEAKEEPING STABILITY STRENGTH VOLUME WEIGHTS Further details are provided in [81, 82]. As identified earlier, the frigate hull synthesis template has six independent goals which collectively represent a measure of performance for the design. In this problem, economic efficiency is modeled directly by the capital cost goal and technical efficiency by the remaining goals. All goals are assigned priorities and treated preemptively [90, 91]. That is, improvements in the design are made based on the priority assigned to a particular goal; lower priority goals affect the solution only after the higher priority goals have had their chance at improving the design. Thus, for example, if the cost goal is assigned a higher priority than the seakeeping goal, a minimum cost design will be found first followed by a design that represents the best, feasible trade-off while keeping cost effectively constant and improving seakeeping, and so on. In this way a socalled lexicograhic minimum is found. In the frigate DSP, the priorities can be varied to suit the Naval Staff Requirements

or a designer's current preferences and the effects of such changes are shown in [81, 82]. One difficulty in developing a compromise DSP for computer implementation is that of modeling algorithmically the drafting functions associated with traditional design work. That is, the representation of the “lines plan” and the general arrangement. Ship geometry, and in particular the area and location of decks, significantly affects the calculation of internal volume, total deck area and system separation and to a lesser extent all other areas of the design. Weapon and system location affects vertical, longitudinal and transverse centers of gravity but also influences weight, internal volume and various system interactions. This difficulty has been overcome by using a standard layout or profile and allowing a designer to select the location of certain weapons and systems. The Standard Frigate Profile, as shown in Fig. 23, defines the ship geometry in terms of the principal dimensions and is based on both the policy and design practices of a designer. In general, it establishes ship features such as the length of decks, location and height of masts and funnels, location and dimensions of the flight deck and location of machinery spaces. The frigate template created allows a designer to modify this standard profile by choosing the number of propeller shafts, the location of the machinery spaces and the location of some weapons and systems. It is intended that the standard profile be continually updated to include and mirror both trends in design and accepted design practice. To this end and so as not to bias the designs generated, the use of a representative general profile which also incorporates the designer’s philosophy is recommended, in contrast to using the profile of an existing vessel. However, in some circumstances, using an existing vessel may be justified. Further, alternate profiles could also be proposed and examined. The Baseline Solution

The baseline Light-Patrol Frigate design that follows, with a range of 5000 nautical miles, is for the case where the cost goal had the highest priority. This implies a “minimum cost ship”. While all other goals identified are not at the same priority level, they are technical in nature. Therefore, the solution could be stated in terms of a trade-off between economic and technical efficiency. It is assumed that the weapon and sensor requirements incorporate the following major payload items: • Weapons - 76 mm OTO-MELARA gun, 20 mm VULCAN-PHALANX CIWS, vertical launch SEASPARROW (16 cell), HARPOON (2x4-cell canisters), Mk 32 torpedo tubes (2 triple tubes), and a Seahawk helicopter (SH-60) • Sensors - SPS 49 air-search radar, SPS 55 surface-search radar, Mk 92 FCS (2 channel with STIR), Mulloka sonar, SLQ-32V(2) ECM, NIXIE torpedo decoy, SRBOC chaff launcher, and Data LINK 11.

The output is extensive and information provided includes: • Technical Information Proportions and principal dimensions, hydrostatic information, propulsive characteristics, preliminary powering and propeller design, electrical loads, complement, stability assessment and minimum KG curve, seakeeping performance, areas and volumes required and available including margins, weight estimation including margins, and strength calculations • Economic Information Shipbuilders cost estimate, equipment costs, first outfit of stores costs, other project costs, and total capital cost estimate for ship. Selected output for this design showing principal characteristics, costs, areas, volumes and weights is presented in Fig. 24 and Fig. 25. Of significant interest, while adding validity to the model, is the fact that the ship is shown to be volume limited as one would expect for a warship. While not directly evident from the results, the use of a lexicographic A deviation function to model the multiple and conflicting goals (technical and A. Gun System economic) ensured that the solution B. Missile System C. Box/ process continued until the best solution Cannister Missile Launcher in accordance with all goals was found. D. Torpedo Tubes & Within the optimization process, the Magazine intermediate solutions indicated that a minimum length/displacement ship was A found relatively quickly. From an economic perspective, this is understandable since a “minimum cost ship” would generally equate with a minimum length/displacement ship. However, the process continued beyond this point, not converging and terminating until all possible improvements in technical efficiencies were made. Extending the above, the results of a study for determining the effect of installing CODOG, CODAD or COGAG machinery plants, is presented. These results reflect a consistent requirement for



Fig. 23

The standard frigate profile

the minimum cost ship with all priority levels identical to those in the baseline solution above. Only the machinery type specification has been varied. In Fig. 26 we illustrate the effect of selecting each of the three different machinery installations. A histogram identifying relative values of power installed, seakeeping rank and capital cost for each is given. The COGAG power plant with its high space and fuel requirements results in a ship with a lower seakeeping, higher installed power and increased cost. The CODAD and CODOG installations result in similar designs with the reduced weight of the CODOG plant providing a greater benefit than the reduced volume of the CODAD plant. Therefore, the CODOG ship has slightly lower cost and installed power and a small advantage in seakeeping performance.

CODAD Power Installed Seakeeping Rank Capital Cost 0 1 2 3 UNIT VALUE 4 5 6


Fig. 26



The effect of machinery selection


FINAL DESIGN DATA ----------------LBP BEAM DRAFT DEPTH DECK HEIGHT CB CP = 0.4698 = 0.5694 = 117.80 METERS = 11.98 METERS = 3.90 METERS = 7.50 METERS = 2.47 METERS CW CM = 0.7186 = 0.8182

TOTAL COST ESTIMATE FOR ONE SHIP -------------------------------(- COST $A MILLION -) SHIPBUILDERS COSTS (INCL SERVICES & FACILITIES) LABOUR MATERIALS TOTAL EQUIPMENT (AGFE & CFE) FIRST OUTFIT OF STORES ETC OTHER PROJECT COSTS = = 30. KNOTS 18. KNOTS 21997. KW = 14 = 18 = 24 = 108 = 164 TOTALS 389.862 89.557 24.528 114.086 150.412 26.988 98.375


2648.55 TONNES







2401. KW 406.25 KW 268.91 TONNES


Fig. 24

The baseline solution: principal characteristics and costs


REQUIRED DECK AREAS AND VOLUMES FOR GROUP 1 T0 7 SYSTEMS -------------------------------------------------------GROUP REQUIRED REQUIRED DECK AREA VOLUME M**2 M**3 -----------------------------------------------STRUCTURE PROPULSION PLANT ELECTRICAL PLANT COMMAND AND CONTROL AUXILIARY SYSTEMS OUTFIT ARMAMENT LOAD VARIABLES 853.50 58.30 25.02 482.00 80.97 696.00 273.10 425.00 2424.86 1357.37 465.95 1192.30 421.16 1721.67 675.56 1080.93

WEIGHT SUMMARY -------------TSC WEIGHT VCG TONNES M-ABL ----------------------------------------------------100 200 300 400 500 600 700 STRUCTURE PROPULSION PLANT ELECTRICAL PLANT COMMAND & CONTROL AUXILIARY SYSTEMS OUTFIT & FURNISHINGS ARMAMENT DESIGN MARGIN * 762.02 263.77 154.30 97.63 303.70 204.27 36.26 218.63 5.17 3.00 5.12 8.73 5.62 6.41 9.71 6.59 DESCRIPTION

-----------------------------------------------MARGIN (TOTAL) 111.93 284.28

----------------------------------------------------LIGHTSHIP WEIGHT 800 LOAD VARIABLE SERVICE LIFE MARGIN # 2040.58 445.71 124.31 6.01 2.62 8.12

-----------------------------------------------TOTAL 3005.83 9624.08

-----------------------------------------------TOTAL AVAILABLE DECK AREA = TOTAL AVAILABLE VOLUME = 3868.32 SQ METERS 9823.33 CU METERS

----------------------------------------------------FULL LOAD WEIGHT 2610.60 5.12

----------------------------------------------------MARGINS * DESIGN - WEIGHT = 12.0 % OF LIGHTSHIP - VCG = 2.5 % OF LIGHTSHIP KG SERVICE LIFE - WEIGHT = 5.0 % OF FULL LOAD - VCG = 0.15 M ADDITION TO FULL LOAD KG



Fig. 25 The baseline solution: areas, volumes and weights A Machinery System Selection • Range - at endurance DSP speed • Operational profile As an extension of this approach for • Total hours-at-sea per year choosing a propulsion system, a DSP • Required reliability (as template for machinery arrangement percentage availability) selection could be created and included in Ship Parameters the total Preliminary Ship Synthesis • Principal dimensions model. This DSP may be stated as • Propulsion factors follows: • Propulsor specification Given • Volume of machinery spaces Naval Operational Requirements • Electrical loads • Speed - maximum Possible Alternatives sustained • Machinery arrangements - endurance - CODOG (1xGT,2xDE or - minimum 2xGT,2xDE) sustained - CODAD (4xDE)

- COGAG (2xGT or 4xGT) Preferred power plants - GE LM2500 - RR SPEY SM1A - Stork Werkspoor 8SW280 - Stork Werkspoor 12SW280 - Stork Werkspoor 16SW280 - MTU 12 V1163 TB83 - MTU 16 V1163 TB93

Find The most appropriate machinery arrangement, and the optimal power plants. Satisfy The following system constraints: Performance • The range is equal to or greater than the required range • The main propulsion engines power is equal to or greater than the power required to achieve maximum sustained speed • The cruise propulsion engines power is equal to or greater than the power required to achieve maximum endurance speed • The minimum continuous power is equal to or less than the power required to achieve minimum sustained speed Space • The volume of the machinery spaces is equal to or greater than the required volume for the machinery Operational • the percentage availability is equal to or greater than the required percentage availability The following system goals: • The capital cost is equal to or smaller than the target value • The machinery weight is equal to or smaller than the target value • The volume of machinery spaces is equal to or smaller than the target value • The range is equal to or greater than the target value • The reliability is equal to or greater than the target value Minimize • The deviation function.

While the hull synthesis and the machinery selection templates presented herein are independent in themselves it is clear that they are dependent subsystems of a ship system. The attribute ratings for the machinery selection are influenced by the geometric system variables of the ship's length, beam, depth, etc. Similarly, the values of the frigate template goals are dependent upon the machinery selected. This form of interdependency and hierarchy of decisions is typical of real-world design problems and has been addressed in [50]. The DSPs highlighted in this section represent small elements in the overall design process but they are significantly complex and non-trivial to develop. It is estimated that the frigate template including the required library modules took six man months to develop. The complexity of these elemental templates, the number that are needed to effect a “total” design of a ship, and their interconnectivity gives rise to problems associated with information management that could easily overwhelm a designer who is attempting to use them. Hence, some sort of computer-based guidance is warranted.

Design Guidance in a Decision-Based, Design Environment
Given that concurrent engineering design for the life cycle can and should be implemented using a method that is rooted in Decision-Based Design, what is needed to bring this about ? As we have already indicated we believe that firstly, a design philosophy and secondly, design tools for implementation, are needed. In keeping with the Decision-Based Design philosophy, a proposed utility to increase a designer’s efficiency and effectiveness has been identified as the Design Guidance System (DGS). A more detailed explanation of the Design Guidance System is given in [59] and in the following we provide only an overview.

A Camera and a Design System: An Analogy Visualize a camera and assume that this camera symbolizes the computerbased design system we wish to create. Why a camera? 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 ultimately dependent on the person taking the photograph; so too the design from the computer-based design system. The quality of the camera affects the quality of the picture; so too the quality of the computer-based design system the design. 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. The analogy is shown in Fig. 27. 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 equipment. Both the camera and design systems have improved significantly over time; just compare the first cameras and computeraided design systems with those that are available today. Both cameras and computers continue to be improved so let us focus on the second action. 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.

Real World Solution (Ideal)

Design System (Capturing a Solution)

Computer-Based Solution (An Image)

Fig. 27 An analogy between a camera and a design system

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 to set the aperture and timing and was still required to focus 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. Nowadays, cameras that have the capability to focus automatically and adjust timing and diaphragm, are not only available, but are relatively inexpensive. The control unit of this camera is attuned to the environment and is endowed with some intelligence. This intelligence is used to take information from the environment, process it, adjust the controls, and advise a photographer that the camera is ready to take a picture. We view the HOSDES system as a semiautomatic camera with DSIDES providing support for human decision making and the DGS as 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 various lenses can be attached. The camera body will surround the intelligent control unit

(DGS) and the means for decision support (DSIDES). Changing the lens of the camera from, say, a wide angle lens to a telephoto lens is akin to focussing on different domains. In this analogy, the camera body represents the domainindependent 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 domaindependent information (lens) must be in a form suitable to be handled by the domain-independent information (camera body). This is a restriction but it is not without advantage. On Designing a Design Guidance System Let us start with an example from the real world of ship design in order to provide a conceptual exposition of the tasks of a DGS in the future. Suppose the conceptual design of a ship has been completed and the design has progressed to the Preliminary Design event as shown in Fig. 18. Consider the following scenario (see Fig. 28). A design team has retrieved the basic concept, created and solved the DSP for Preliminary Synthesis (see Fig. 19). Next, to validate the design a model of the ship is built and tested in a towing tank. Over a period of time, several experimental “runs” are made with this model in the towing tank and the results are used to evaluate the design. The experimental results are fed back to the design team who detect a difference between the predicted and observed resistance. Thus the prediction formula must be improved by an expert hydrodynamicist. Then the design team must update its preliminary synthesis model and re-solve it.



DESIGN (A Team Effort)








New Design Design and Manufacture Information Model Model and Statistical Information New Prediction Formula Hydrodynamic Information and Design

Fig. 28 An example of a DGS in a ship design/research environment In the near future, the efficiency and effectiveness of a designer can be enhanced by increasing the speed with which the design iteration is accomplished, and by reducing of the number of iterations. An increment in iteration speed can be achieved if at least some parts of a design process are known and can be modelled. A means for modeling processes, namely, the basic entities and the DSPT Palette were introduced earlier in this paper. 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 and 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, computer

based tools can be developed to improve it. Given the preceding, two fundamental questions need to be answered: • 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? 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 manner similar 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 that is a composite of the ones that have been stored with perhaps some additional information. In both cases, the DGS, will be called on to assist a designer in accessing information, albeit of different types. Can we always depend on 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 entered into a computer explicitly. In this case, we would resort to monitoring the actions of a human designer (with permission of course) to obtain a descriptive model of the process just completed. In summary, the essence of our approach is as follows:

• Let a designer specify a model of his/her design process explicitly (by entering it directly) and/or implicitly (by allowing a computer to monitor the design activity). • 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 be manipulated and subsequently 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 a computer-based design system. Further information about the desirable characteristics of a DGS is given in [59].

We believe that there is a spring-like sense of change in the air as an increasing number of scientists and technologists come to appreciate the inadequacies of the single-cause-single-effect paradigm that is based in Newtonian science. This appreciation itself reflects an insight induced by systems thinking. This is not to say that the single-cause-single-effect paradigm inherent in traditional science, and in traditional approaches to design, is to be supplanted soon by a new everything-is-related-to-everything-else paradigm. Rather, systems thinking

serves to emphasize the wide-ranging and complex interdependencies inherent in any design problem and to highlight the ever more apparent inadequacy of the traditional, sequential design methods. For decades ships have been designed using the well-known “basis ship approach” together with the equally well-known Evans-Buxton-Andrews spiral. The two principal limitations of the spiral are that the process of design is assumed to be sequential and the opportunity to include life cycle considerations is limited. In this paper, we propose a paradigm shift; to Decision-Based Design, a paradigm that encompasses systems thinking and embodies the concept of concurrent engineering design for the life cycle. In proposing this shift, we recognize the need to be sensitive, especially in the transition period, to the comfortable mindset offered by traditional approaches to design, such as the ship design spiral, and the anxiety associated with a new paradigm, namely, Decision-Based Design. According to Kuhn [92], a new paradigm, such as is offered here, does not evolve through a cumulative extension of an old one. Instead, there is a reconstruction of the field, in this case design, using the contemporary perspectives of concurrency of decision making in the context of systems thinking and designing for the life cycle. Kuhn intimates that changes are made to the field's most elementary theoretical considerations as well as to many of its applications and methods that were rooted in the traditional paradigm, in this case, the design spiral. The changes, brought about by a paradigm shift, are not cumulative but small-scale, step-like revolutionary transformations. They replace an old paradigm, in whole or in part, with a new one, in this case, Decision-Based Design. The new paradigm may not destroy previous knowledge or conflict with its predecessors. However, it provides a new cognitive mapping, a new vision of the world. In the early nineteenth century, Schopenhauer [93] noted that

“Every man takes the limits of his own vision for the limits of the world.” In a sense, we are asking our readers to take the new paradigm explicated here, within the limits of our vision of the world of design, into the limits of theirs.

Over the years support for the development of the Decision Support Problem Technique has come from many sources. We gratefully acknowledge the following people and organizations. 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 he has been responsible for sending two of his naval architects, Tim D. Lyon and Warren Smith to work at the University of Houston. Peter van Oossanen and Bert Koops of MARIN, Wageningen, Holland, in 1988 joined the Canberra-Houston team by funding our work and sending Bert Bras to work with us in Houston. In the early 80's, John Fontenot, through the NL Foundation, made several grants to support the development of the Decision Support Problem Technique. In 1985, Jaric Sobieszczanski-Sobieski supported the development of the DSP Technique with a contract from NASA Langley. Since 1987, David C. Bonner, through the B.F. Goodrich R&D Center, Brecksville, Ohio, has contributed to our laboratory and the development of the DSP Technique. In 1989, Steven LeClair supported our work with a SBIR Phase I contract. Geoff Uttmark of TransTech Marine Co., New York, has also supported us with a financial contribution and encouragement. Finally, the cost of computer time has been underwritten by the University of Houston. Over the years many people have contributed to work reported in this paper. We gratefully acknowledge them. Jon A. Shupe coined the phrase

Decision-Based Design and developed this notion further in his Ph.D. dissertation. Tim D. Lyon, Roger Ramsey and Kim Williams of the Department of Defence (Navy) Canberra, Australia, contributed to the development of AUSEVAL and the frigate template. Eduardo Bascaran, Saiyid Kamal, Harshavardhan Karandikar, Nagesh Kuppuraju and Q-J Zhou have contributed in developing the decision constructs that we have reported. Lori Smith is thanked for donating her time and helping us with the graphics. A thankyou is also extended to David Andrews, Frank G. Bartlett, Ian L. Buxton, Dale Calkins, Ken J. MacCallum, Michael J. Parsons and Jon A. Shupe for their specific comments that helped us in developing our manuscript.

1. Checkland, P., Systems Thinking, Systems Practice, John Wiley & Sons, New York, 1981. 2. Dixon, J. R., "On Research Methodology Towards a Scientific Theory of Engineering Design," Artificial Intelligence for Engineering Design, Analysis and Manufacturing, Vol. 1, No. 3, 1987, pp. 145-157. 3. Pahl, G. and Beitz, W., Engineering Design, K. Wallace Ed., A. Pomerans Trans., The Design Council/Springer-Verlag, London/Berlin, 1984. 4. Hubka, V. and Schregenberger, J., "Paths Towards Design Science" in Proceedings, 1987 International Conference on Engineering Design, Vol. 1, Boston, The American Society of Mechanical Engineers, 1987, pp. 3-14. 5. Andreasen, M. M., "Design Strategy" in Proceedings, 1987 International Conference on Engineering Design, Vol. 1, Boston, The American Society of Mechanical Engineers, 1987, pp. 171-178.

6. Cross, N., Engineering Design Methods, John Wiley & Sons, Chichester, 1989. 7. De Boer, S. J., Decision Methods and Techniques in Methodical Engineering Design, Academisch Boeken Centrum, De Lier, The Netherlands, 1989. 8. Finger, S. and Dixon, J. R., "A Review of Research in Mechanical Engineering Design. Part 1: Descriptive, Prescriptive, and Computer-Based Models of Design Processes," Research in Engineering Design, Vol. 1, 1989, pp. 51-67. 9. Finger, S. and Dixon, J. R., "A Review of Research in Mechanical Engineering Design. Part 2: Representations, Analysis, and Design for the Life Cycle," Research in Engineering Design, Vol. 1, 1989, pp. 121-137. 10.Brei, M. L., Dierolf, D. A. and Richter, K. J., "A Survey of Research Methods to Study Design," IDA Paper P2155, Institute for Defense Analyses, Alexandria, Virginia, 1989. 11.Stauffer, L. A., Ullman, D. G. and Dietterich, T. G., "Protocol Analysis of Mechanical Engineering Design" in Proceedings, 1987 International Conference on Engineering Design, Vol. 1, Boston, The American Society of Mechanical Engineers, 1987, pp. 74-85. 12.Waldron, M. B., Jelinek, W., Ownes, D. and Waldron, K. J., "A Study of Visual Recall Differences Between Expert and Naive Mechanical Engineers" in Proceedings, 1987 International Conference on Engineering Design, Vol. 1, Boston, The American Society of Mechanical Engineers, 1987, pp. 86-93. 13.Wallace, K. M. and Hales, C., "Detailed Analysis of an Engineering Design Project" in Proceedings, 1987 International Conference on Engineering Design, Vol. 1, Boston, The American Society of Mechanical Engineers, 1987, pp. 94-101. 14.Hubka, V., Principles of Engineering Design, W. E. Eder Ed., W.E. Eder Trans., Butterworth, London, 1982.

15.Suh, N. P., Principles of Design, Oxford University Press, Oxford, U.K., 1988. 16.Tomiyama, T. and Yoshikawa, H., "Extended General Design Theory" in Design Theory in Computer Aided Design, H. Yoshikawa and E. Warman Ed., North-Holland, Amsterdam, 1987, pp. 95-130. 17.Takala, T., "Theoretical Framework for Computer Aided Innovative Design" in Design Theory for CAD, H. Yoshikawa and E. Warman Ed., North-Holland, Amsterdam, 1987, pp. 323-338. 18.Ostrofsky, B., Design, Planning and Development Methodology, PrenticeHall, 1977. 19.Suh, N. P., "Development of the Science Base for the Manufacturing Field through the Axiomatic Approach," Robotics and Computer-Integrated Manufacturing, Vol. 1, No. 3/4, 1984, pp. 397-415. 20.Mistree, F., Muster, D., Shupe, J. A. and Allen, J. K., "A Decision-Based Perspective for the Design of Methods for Systems Design," Recent Experiences in Multidisciplinary Analysis and Optimization, NASA CP 3031, Hampton, Virginia, NASA, 1989, . 21.Azarm, S., Dierolf, D. A., Naft, J., Pecht, M., Richter, K. J. and Sawyer, B. T., "Decision Support Requirements in a Unified Life Cycle Engineering (ULCE) Environment," IDA Paper P-2064, Institute for Defense Analyses, Alexandria, Virginia, 1988. 22.Vanderplaats, G. N., Numerical Optimization Techniques for Engineering Design: With Applications, McGrawHill, New York, 1984. 23.Hughes, O. F., Ship Structural Design: A Rationally-Based, Computer Aided Optimization Approach, SNAME, Jersey City, NJ, 1988. 24.Sobieszczanski-Sobieski, J., "Multi-Disciplinary Optimization for Engineering Systems: Achievements and Potential," Report No.101566, NASA, 1989. 25.Sobieszczanski-Sobieski, J., "A Linear Decomposition Method for Large Optimization Problems - Blueprint for

Development," NASA TM 83248, NASA Langley, 1982. 26.Brown, D. C. and Chandrasekaran, B., "Expert Systems for a Class of Mechanical Design Activity" in Knowledge Engineering in Computer-Aided Design, J. Gero Ed., North-Holland, 1986, pp. 259-283. 27.Brown, D. C., "Capturing Mechanical Design Knowledge," ASME Computers in Mechanical Engineering, Vol. 2, 1985, pp. 121-129. 28.Dixon, J. R., Duffey, M. R., Irani, R. K., Meunier, K. L. and Orelup, M. F., "A Proposed Taxonomy of Mechanical Design Problems" in Proceedings, ASME Computers in Engineering Conference, Vol. 1, San Francisco, California, The American Society of Mechanical Engineers, 1988, pp. 41-46. 29.Dixon, J. R., Libardi, E. C. and Nielsen, E. H., "Unresolved Research Issues in Development of Design-WithFeatures-Systems," MDA Technical Report 2-89, Mechanical Design Automation Laboratory, University of Massachusetts, Amherst, Massachusetts, 1989. 30.Gero, J. S. and Rosenman, M. A., "A Conceptual Framework for Knowledge-Based Design Research at Sydney University's Design Computing Unit" in Artificial Intelligence in Design, J. S. Gero Ed., Springer-Verlag, Berlin, 1989, pp. 363-382. 31.McClelland, J. L. and Rumelhart, D. E., Explorations in Parallel Distributed Processing - A Handbook of Models, Programs and Exercises, The MIT Press, Cambridge, Massachusetts, 1988. 32.McClelland, J. L. and Rumelhart, D. E., Psychological and Biological Models, Parallel Distributed Processing Explorations in the Microstructure of Cognition, The MIT Press, Cambridge, Massachusetts, 1988. 33.Rumelhart, D. E. and McClelland, J. L., Foundations, Parallel Distributed Processing - Explorations in the Microstructure of Cognition, The MIT Press, Cambridge, Massachusetts, 1988.

34.Beitz, W., "General Approach of Systematic Design - Application of VDIGuideline 2221" in Proceedings, 1987 International Conference on Engineering Design, Vol. 1, Boston, The American Society of Mechanical Engineers, 1987, pp. 15-20. 35.Simon, H. A., The Sciences of the Artificial, The MIT Press, Cambridge, Massachusetts, 1982. 36.Hales, C., "Analysis of the Engineering Design Process in an Industrial Context," Ph.D. Dissertation, Gants Hill Publications, University of Cambridge, UK, 1987. 37.Juster, N. P., "The Design Process and and Design Methodologies," Technical Report, University of Leeds, 1985. 38.Calkins, D. E., Gaevert, R. S., Michel, F. J. and Richter, K. J., "Aerospace System Unified Life Cycle Engineering: Producibility Measurement Issues," IDA Paper P-2151, Institute for Defense Analyses, Alexandria, Virginia, 1989. 39.Winner, R. I., Pennell, J. P., Bertrand, H. E. and Slusarczuk, M. M. G., "The Role of Concurrent Engineering in Weapons System Acquisition," IDA Report R-338, Institute for Defense Analyses, Alexandria, Virginia, 1988. 40.Evans, J. H., "Basic Design Concepts," Naval Engineers Journal, Nov., 1959, pp. 671-678. 41.Buxton, I. L., "Engineering Economics Applied to Ship Design," TRANS. RINA, Vol. 114, Royal Institution of Naval Architects, 1972, pp. 409-428. 42.Andrews, D., "Creative Ship Design,” TRANS. RINA, Vol. 123, Royal Institution of Naval Architects, 1981, pp. 447-471. 43.Lyon, T. D. and Mistree, F., "A Computer-based Method for the Preliminary Design of Ships," Journal of Ship Research, Vol. 29, No. 4, 1985, pp. 251-269.

44.Gilfillan, A. W., "The Economic Design of Bulk Cargo Carriers,” TRANS. RINA, Vol. 111, Royal Institution of Naval Architects, 1969, pp. 113-140. 45.Murphy, R., Sabat, D. J. and Taylor, R. J., "Least Cost Ship Characteristics by Computer Techniques," Marine Technology, Vol. 2, No. 2, 1965, pp. 174-202. 46.Nowacki, H., Brusis, F. and Swift, P. M., "Tanker Preliminary Design - An Optimization Problem with Constraints,” TRANS. SNAME, Vol. 78, Society of Naval Architects and Marine Engineers, 1970, pp. 357-390. 47.Smith, G. K. and Woodhead, R. G., "A Design Scheme for Structures,” TRANS. RINA, Vol. 116, Royal Institution of Naval Architects, 1974, pp. 47-66. 48.Calkins, D. E., "Ship Synthesis Model Morphology" in Proceedings, 13th Ship Technology and Research (STAR) Symposium/3rd International Marine Systems Design Conference (IMSDC), Pittsburgh, Pennsylvania, Society of Naval Architects and Marine Engineers, 1988, pp. 279-306. 49.Hughes, O. F., Mistree, F. and Zanic, V., "A Practical Method for the Rational Design of Ship Structures," Journal of Ship Research, Vol. 24, No. 2, 1980, pp. 101-113. 50.Smith, W. F., Kamal, S. Z. and Mistree, F., "The Influence of Hierarchical Decisions on Ship Design," Marine Technology, Vol. 24, No. 2, 1987, pp. 131-142. 51.Duffy, H. B. and MacCallum, K. J., "Computer Representation of Numerical Expertise for Preliminary Ship Design," Marine Technology, Vol. 26, No. 4, 1989, pp. 289-302. 52.Welsh, M., Hills, W. and Buxton, I. L., "The Application of an Expert System at the Concept Stage of Container Ship Design" in Proceedings, Fourth International Symposium on Practical Design of Ships and Mobile Units, Vol. 1, Varna, Bulgaria, Bulgarian Ship Hydrodynamics Centre, 1989, pp. 41.141.8.

53.Mistree, F., Hughes, O. F. and Phuoc, H. B., "An Optimization Method for the Design of Large, Highly Constrained, Complex Systems," Engineering Optimization, Vol. 5, No. 3, 1981, pp. 141-144. 54.McCord, R. S., "Influence of Ship Design and Fabrication on Underwater Maintenance and Repair," Marine Technology, Vol. 20, No. 2, 1983, pp. 177-183. 55.Tibbits, B. F. and Gale, P. A., "The Naval Ship Design/Production Interface," Journal of Ship Production, Vol. 2, No. 3, 1986, pp. 185-195. 56.Billingsley, D. W. and Ryan, J. C., "A Computer System Architecture for Naval Ship Design, Construction, and Service Life Support,” TRANS. SNAME, Vol. 94, Society of Naval Architects and Marine Engineers, 1986, pp. 309-324. 57.Shupe, J. A., "Decision-Based Design: Taxonomy and Implementation," Ph.D. Dissertation, Department of Mechanical Engineering, University of Houston, Houston, Texas, 1988. 58.Kamal, S. Z., Karandikar, H. M., Mistree, F. and Muster, D., "Knowledge Representation for DisciplineIndependent Decision Making" in Expert Systems in Computer-Aided Design, J. Gero Ed., Elsevier Science Publishers B.V., Amsterdam, 1987, pp. 289-321. 59.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, G. v. Oortmerssen Ed., Elsevier Science Publishers B.V., Wageningen, The Netherlands, 1990, pp. 221-231. 60.Mistree, F. and Muster, D., "Conceptual Models for Decision-Based Concurrent Engineering Design for the Life Cycle" in Proceedings, Second National Symposium on Concurrent Engineering, Morgantown, West Virginia, 1990, pp. 443-467. 61.Whitney, D. E., Nevins, J. L., DeFazio, T. L., Gustavson, R. E., Metzinger, R. W., Rourke, J. M. and Selzer, D. S., "The Strategic Approach to Product Design" in Design and Analysis

of Manufacturing Systems, National Academy Press, Washington, D.C., 1988, . 62.Finger, S., Fox, M. S., Navinchandra, D., Prinz, F. B. and Rinderle, J. R., "Design Fusion: A Product Life-Cycle View for Engineering Designs" in Proceedings, Second IFIP WG 5.2 Workshop on Intelligent Computer Aided Design, Cambridge, U.K., IFIP, 1988. 63.Hills, W. and Buxton, I. L., "Integrated Ship Design and Production During the Pre-Construction Phase,” TRANS. RINA, Vol. 131, Royal Institution of Naval Architects, 1989, pp. 189-210. 64.Muster, D. and Mistree, F., "The Decision Support Problem Technique in Engineering Design," The International Journal of Applied Engineering Education, Vol. 4, No. 1, 1988, pp. 2333. 65.Shupe, J. A., Muster, D., Allen, J. K. and Mistree, F., "Decision-Based Design: Some Concepts and Research Issues" in Expert Systems, Strategies and Solutions in Manufacturing Design and Planning, A. Kusiak Ed., Society of Manufacturing Engineers, Dearborn, Michigan, 1988, pp. Chapter 1, 3-37. 66.Kuppuraju, N., Ittimakin, P. and Mistree, F., "Design through Selection ... A Method that Works," Design Studies, Vol. 6, No. 2, 1985, pp. 91106. 67.Mistree, F., Marinopoulos, S., Jackson, D. and Shupe, J. A., "The Design of Aircraft using the Decision Support Problem Technique," NASA Contractor Report 4134, 1988. 68.Bascaran, E., "A Conceptual Model for the Design of Thermal Systems: Concurrent Decisions in Designing for Concept," Ph.D. Dissertation, Department of Mechanical Engineering, University of Houston, Houston, Texas, 1990. 69.Bascaran, E., Bannerot, R. B. and Mistree, F., "Hierarchical Selection Decision Support Problems in Conceptual Design," Engineering Optimization, Vol. 14, 1989, pp. 207238.

70.Karandikar, H. M., "Hierarchical Decision Making for the Integration of Information from Design and Manufacturing Processes in Concurrent Engineering," Ph.D. Dissertation, Department of Mechanical Engineering, University of Houston, Houston, Texas, 1989. 71.Smith, W. F., "The Development of AUSEVAL: An Automated Ship Evaluation System," M.S. Thesis, Department of Mechanical Engineering, University of Houston. Houston, Texas, 1985. 72.Bhattacharya, N., "A Comprehensive Computer Based Decision Support System for the Preliminary Design of Aircraft Tires," Master's Thesis, Department of Mechanical Engineering, University of Houston, 1990. 73.Allen, J. K., Krishmachari, R. S., Masetta, J., Pearce, D., Rigby, D. and Mistree, F., "Fuzzy Compromise: An Effective Way to Solve Hierarchical Design Problems" in Proceedings, Third Air Force/NASA Symposium on Recent Advances in Multidisciplinary Analysis and Optimization, San Francisco, California, NASA, 1990, pp. 141-147. 74.Allen, J. K., Simovich, G. and Mistree, F., "Selection Under Uncertain Conditions: A Marine Application" in Proceedings, Fourth International Symposium on Practical Design of Ships and Mobile Units, Vol. 2, Varna, Bulgaria, Bulgarian Ship Hydrodynamics Centre, 1989, pp. 80.1-80.8. 75.Zhou, Q.-J., "The Compromise Decision Support Problem: A Fuzzy Formulation," M.S. Thesis, Department of Mechanical Engineering, University of Houston, Houston, Texas, 1988. 76.Kamal, S. Z., "The Development of Heuristic Decision Support Problems for Adaptive Design," Ph.D. Dissertation, Department of Mechanical Engineering, University of Houston, Houston, Texas, 1990. 77.Mistree, F., Muster, D., Srinivasan, S. and Mudali, S., "Design of Linkages: A Conceptual Exercise in Designing for Concept," Mechanism and Machine Theory, Special Issue on

"Theories of Design - Application to the Design of Machines," Vol. 25, No. 3, 1990, pp. 273-286. 78.Mistree, F., Kamal, S. Z. and Bras, B. A., "DSIDES: Decision Support in the Design of Engineering Systems," Systems Design Laboratory Report, University of Houston, Houston, Texas, 1989. 79.Allen, J. K., Hong, J., Adyanthaya, S. and Mistree, F., "The Decision Support Problem Technique Workbook for Life Cycle Engineering," Systems Design Laboratory Report, University of Houston, Houston, Texas, 1989. 80.Adyanthaya, S., "Partitioning and Planning in the Decision Support Problem Technique," UG Honor's Thesis, Department of Mechanical Engineering, University of Houston, Houston, Texas, 1990. 81.Smith, W. F., Lyon, T. and Robson, B., "AUSEVAL - A Systems Approach for the Preliminary Design of Naval Ships" in Proceedings, Bicentennial Maritime Symposium, Sydney, Australia, The Institute of Marine Engineers, 1988, pp. 1-16. 82.Smith, W. F., "AUSEVAL - The Application of the Decision Support Problem Technique to Ship Design" in Proceedings, International Workshop on Engineering Design and Manufacturing Management, Melbourne, Australia, 1988, pp. 127-147. 83.Koops, A., Oomen, A. C. W. J. and Van Oossanen, P., "HOSDES: A New Computer-Aided System for the Conceptual Design of Ships" in Proceedings, Bicentennial Maritime Symposium, Sydney, Australia, The Institute of Marine Engineers, 1988, pp. 17-29. 84.Koops, A., Oomen, A. C. W. J. and Bras, B. A., "Computer Aided Design Assistance and Decision Support"

in Computer Applications in the Automation of Shipyard Operation and Ship Design VI (ICCAS), NorthHolland, Amsterdam, 1988, pp. 301311. 85.Muster, D., Mistree, F. and Allen, J. K., "Partitioning and Planning for Unified Life-Cycle Engineering Design: A Conceptual Exposition," USAF Contract FY 1457-88-05215, DM&A Inc., Houston, 1989. 86.Rogan, J. E. and Cralley, W. E., "Meta-Design -- An Approach to the Development of Design Methodologies," IDA Paper No. P-2152, Institute for Defense Analyses, Alexandria, Virginia, 1990. 87.Miller, J. G., Living Systems, McGraw-Hill, New York, 1978. 88.Buxton, I. L., "Engineering Economics and Ship Design," 3rd Edition, British Maritime Technology Ltd., Tyne & Wear, U.K., 1987. 89.Ignizio, J. P., Introduction to Linear Goal Programming, Quantitative Applications in the Social Sciences, J. L. Sullivan and R. G. Niemi Ed., Sage University Papers, Beverly Hills, California, 1985. 90.Ignizio, J. P., "Generalized Goal Programming: An Overview," Computers and Operations Research, Vol. 5, No. 3, 1983, pp. 179-197. 91.Ignizio, J. P., "Multiobjective Mathematical Programming via the MULTIPLEX Model and Algorithm," European Journal of Operational Research, Vol. 22, 1985, pp. 338-346. 92.Kuhn, T. A., The Structure of Scientific Revolution, University of Chicago Press, Chicago, 1970. 93.Schopenhauer, A., "Psychological Observations" in Complete Essays of Schopenhauer, T.B. Saunders Trans., John Wiley & Sons, New York, 1942, Book VII, pp. 54-63.


Sign up to vote on this title
UsefulNot useful