Ilan Kroo* and Masami Takai
This paper deals with the development of a program for aircraft design, combining a rule-based advice and warning system with an extensible set of analysis routines in an unconventional architecture. The system consists of several procedural modules for calculation of aircraft aerodynamics, structures, propulsion, and operating costs, which, when executed in the appropriate order, permit computation of desired results. Unlike conventional programs, the subroutines and order of execution are selected during the computation, based on the required results and on the currently available results. Unlike nonprocedural programming languages, however, the modules are procedural, allowing the programmer the flexibility to include either short definitions or complex local procedures. This structure is encapsulated in an executive routine with a highly-interactive, event-driven, graphical interface and expert system. The rule-based system is used to assist the user in selecting intelligent design solutions and appropriate analysis procedures. This paper discusses the structure of the program, some of the difficulties encountered in its development, and its potential applications.
Aircraft designers have recognized for many years the importance of preliminary design tools that permit rapid trade studies and assessment of design concepts at the earliest possible stage in a research or development program. A number of such programs for aircraft synthesis and automated sizing have been developed or envisioned in the last twenty years with mixed success (Refs. 1-6).
The problem is a difficult one. Early applications were constrained by limited computational capabilities: reasonable turnaround for trade studies or optimization required simple, if not simplistic, analyses. As computer speed and memory increase, more fundamental and general methods can be introduced. The analysis quickly becomes very complex, however, and sophisticated programs which can handle the subtleties associated with the evaluation of new aircraft concepts are been plagued by more than just slow turnaround times. The complexity of such codes, developed by several groups over some years, often rises to the point that no one person knows what the program is doing; bugs go unnoticed for years and the results again become incredible. It often requires extensive user training even to run the code and to change the code in some way is exceptionally difficult -- if the founding fathers did not envision that future aircraft might employ maneuver load alleviation, winglets, or three lifting surfaces, it may be more expedient to rewrite the code than to fool the program into thinking of winglets, for example, as oddly shaped stores.
These are among the many problems that have tempered the initial enthusiasm for the widespread use of computerized aircraft design methods. The situation is rapidly changing, however. Advances in computer hardware and improved algorithms for computation of aircraft aerodynamics and structures provide much-needed time and cost savings (Refs. 7,8). New operating systems provide support for event-driven, object-oriented, multi-tasking programs, easing some of the burden of large, complex code development and execution. The current work is focussed on two additional advances, important to the success of computer-based preliminary design tools: new ideas for program architecture and the application of artificial intelligence techniques to the problem. Preliminary work on a system for aircraft synthesis studies, based on the program described in reference 9 and employing the aforementioned ideas, was begun in June 1986. The objective was to investigate new program architectures and various ways in which AI methods could be applied to aircraft design. This was done by developing an easy-to-use, extensible system using these concepts. This paper describes the structure and operation of the program.
Experience with a variety of aircraft synthesis programs suggested that a primary feature of any new design system should be unprecedented extensibility -- in both the set of variables used by the program and the set of analysis routines. This requirement is especially important if the program is to be used to assess new technology. Much of the development of a new aircraft concept involves, not the design of the configuration itself, but the design of methods by which the concept can be analyzed and evaluated. A useful synthesis program should permit inclusion of these new methods in a straightforward manner and should recognize that there will be two types of 'users': those who use the system to analyze aircraft designs, and those who develop routines to be added to the system.
Although extensibility prevents rapid obsolescence, it can lead to a second major problem with synthesis codes, unmanageable complexity. This can be a problem to both types of users. It can be hidden from the more casual user by a well-designed, graphical interface, but it is more difficult to manage at the user/developer level. The current system incorporates a high degree of modularity to encourage extensibility and reduce complexity. This is done by separating the interface and database management functions from the computational routines, and by relying on the system itself to keep track of the complex interactions among the design variables.
Another objective of this research was to investigate the ways in which AI techniques could be usefully incorporated into the system, both to aid the user in the use of the system and to provide intelligent design advice.
The basic system is controlled by an executive routine which includes the user interface and machine-dependent i/o. This routine manages communication between the database, the user, and the analysis routines. The analysis routines consist of compiled modules (written in FORTRAN-77 in this implementation) which compute such quantities as density at a given altitude or required horizontal tail lift to trim. The analysis routines are linked to each other at run-time (loaded from the disk -- or memory cache -- when required). In the original structure of the Program for Aircraft Synthesis Studies (PASS), shown in figure 1, the names of the various subroutine modules and their order of execution was specified by the user in script routines. The name of the particular script was selected and the program would execute the desired analyses. The system kept track of the variables that had been computed, warned if the requested routine was unable to be executed because of unknown data, and finally prompted the user to enter the required data. Although this approach provided more flexibility and extensibility than a conventional fixed-input, fixed-output, hard-coded procedure, the user was required to provide information on the appropriate script or analysis routine needed to compute the desired quantity. Furthermore, the development of the scripts themselves could be a time-consuming task, with complex scripts needed to represent the dynamic relationships between variables and analysis routines.
Figure 1. Initial System Architecture
The current version of the system replaces the user-specified script routines with a routine that determines the appropriate computational path from the currently-specified values to the desired results. This computational path generator, described in the subsequent section, greatly enhances the system's ease of use and extensibility.
The current system also incorporates an expert advice and warning system which communicates with the database, the user and the individual subroutines. The system is shown schematically in figure 2.
Figure 2. Basic System Elements
The executive routine provides an event-driven front-end to the system. The user may select an existing design database, examine values of each variable, find and change a particular parameter, or select a variable to be computed. Menu options also permit two-parameter trade studies to be performed with results displayed graphically or in tabular form. A drawing of the current design may also be selected. (See figure 3.)
Figure 3. PASS Interface
The executive also provides an interface with the knowledge-based advice and warning system and with the computational path generator. The user can request that the expert system display warnings or provide design advice. An interactive graphical display of computational paths to the selected variables is also provided.
The quasi-procedural architecture of the system is the key to its usefulness for complex design tasks. In this system individual procedural modules are linked together at runtime in the appropriate structure to permit computation of the requested variable. This simplifies the task of developing additional analysis routines, permitting the programmer to concentrate on a specific subtask without requiring knowledge of the complete program structure and the required inputs and outputs of all other subroutines. This also simplifies the task of the user: one need only specify the name of the variable of interest and the system decides what programs need to be run and what data is required as input. This system incorporates a form of nonprocedural programming as discussed in reference 10, but rather than specifying low-level design relations that may need to be inverted, the system relies on straightforward compiled procedures as the basic building block of the method. This permits either short routines such as altitude-density relations, or more involved codes such as lifting surface analyses to be incorporated easily into the program. Nonlinear calculations, such as those requiring iteration, are common in aircraft analysis programs and are often much more easily implemented as procedural routines. Engineers are quite good at figuring out how certain values may be computed efficiently and this architecture permits 'natural intelligence'-- experience with a particular calculation, or deep understanding of underlying physical principles-- to be used as desired.
The heart of the quasi-procedural method is the computational path generator. This part of the system uses information on the required inputs and outputs of each of the available subroutines, performs a heuristic search of the tree structure connecting all of the variables, and decides on the order of the routines to be executed. Information on the inputs and outputs of a routine must be specified in order that it can be included in the path. This forces at least some form of documentation when a new routine is added.
Once this computational path has been generated, it can be reused. That is, if the user requests information about a variable that lies along the path to a previously selected variable, the path need not be recomputed. In fact, unless relevant inputs have changed, the variable itself need not be recomputed. This leads to an efficient method and is mandatory as the system becomes large. This process of path finding and consistency maintenance is described in greater detail in the following section; although it seems straightforward (and indeed is for trivial example problems), several subtleties arise when the system is put to practical use. Cases arise when the computational path may change during the design cycle -- either in response to changes in parameter values or availability of additional data.
Routines used to compute aerodynamic, structural, or economic properties of the current design are compiled as separate subroutines and loaded into memory when required as overlays. They are currently coded in standard FORTRAN-77, are machine independent, and have the same basic structure: 1) the values of the variables needed for the specific routine are loaded into local variables; 2) the procedural calculations are performed; 3) the values of the output variables are loaded back into the database. Steps 1 and 3 are accomplished by calling the routines GET and PUT which, in addition to loading and unloading data from the database, provide information needed for consistency maintenance. In the simple case of a linear computational path, this is all that the GET and PUT routines need to do. However, it is not always the case that the required input data is available when required. Just as the user was not required to specify the computational path to a particular variable, the author of a given subroutine should not be required to be sure that all of the input variables for the routine are available. So, when necessary, the GET subroutine may generate a new subpath on its own. This brings the advantages of the quasi-procedural method to the program developer as well as the user.
No synthesis program, no matter how sophisticated its architecture, is of much use without good analysis routines. An attempt has been made to incorporate methods appropriate for a practical preliminary design tool rather than a simple demonstration case. This has helped to identify several fundamental issues in the implementation of the system that would have otherwise escaped attention. The annotated computational path diagram in figure 4 illustrates some of the level of detail implemented in one version of the system (Airplane Design Workshop).
Constant (assign various constant values) MachNo (compute Mach number) TmpSub (temperature at given altitude) FuseGM (fuselage geometry routine) WingGM (wing geometry routine) CGest (initial C.G. estimation) SizeVT (statistical vertical tail sizing) TailGM (tail placement and geometry routine) PutWing (place wing for required stability) dCmdCL (dCm/dCL and a.c. of wing and tail) Placard (compute Vc for structural calculations) Weight (component weights including wing, fuselage, tail structures, iteration for ZFW) TOWreq (integration of range equation and iteration for required takeoff weight) Drag (aircraft drag at any cruise point) PDrag (zero-lift drag) ReNo (component Reynolds No.) TmpSub MachNo EnGeom (engine geometry) IDrag (Lift-dependent drag: vortex, lift-dependent viscous, and trim drag) Trim (wing and tail CL to trim) PDrag CDrag (compressibility drag rise) MachNo CDc (compute Mcc and CDc from fit vs. M / MDiv) Engine (engine data for SFC and max thrust) MachNo Drag TOFL25 (compute balanced field length per PART 25) CLmax (maximum lift coefficient) Mach ReNo Trim (Take-off rotation trim routine) Engine
Figure 4. Computational Path for Field Length Calculation
Several types of applications for expert systems in the aircraft design process have been identified and implemented in example cases (Refs. 11-13). Experience with the initial version of the PASS program suggested the need for a system which would serve two basic purposes: it should warn the user of problems in the design or analysis and it should then offer advice on how the problem might be corrected.
Warnings may include simple design rules such as 'A tri-jet probably should not have all wing-mounted engines.' or 'Fuselage-mounted engines usually require a T-Tail.' Other warnings may call to the users' attention constraint violations ('Take-off field length is too large.' or 'Aircraft cannot trim due to tail stall.') Finally, warnings may be used to call attention to a fatal problem with an analysis routine: 'ZFW iteration did not converge.' or 'Drag rise data not applicable at this Mach number.' Note that the last type of warning must be issued just after the problematic routine and must interrupt the current path. Since the system must check the database after each routine to be sure none of these serious problems have occurred, the system that posts these warnings must be fast and simple. In the program described here, the system that posts warnings operates on a simple set of if-then rules. After each routine it examines the database, quickly identifies crucial problems, and pushes the appropriate literal expression onto a stack. This stack is used both to provide the user with the required information, and as input for the expert advice system.
The second part of the knowledge-based system provides suggestions to the designer as to how the identified problems may be resolved or how the design might be improved. The expert advisor uses a forward and backward chaining inference engine to examine the current database, the rule base, and the warning strings posted by the warning system. This permits the system to diagnose problems and make suggestions ranging from simple observations such as 'The nose fineness is too low for this Mach number -- reduce Mach or increase nose length.' to less obvious solutions such as that depicted in figure 5. The performance summary chart indicates a problem with second segment climb. The expert system can recognize this and would suggest that a possible solution would be a reduction in take-off flap deflection. (The program can explain the reasoning, left here as a problem to the interested reader.)
Figure 5. Example of Design Problem for Expert System.
The inference engine used in this system was written by one of the authors (M. Takai). It is based on a LISP program (Ref. 14), but was extensively modified and coded in FORTRAN to facilitate the interface with the analysis routines. The system accommodates fuzzy reasoning (reasoning with uncertainty) and permits forward and backward chaining. In addition to all of the essential features of a generic inference engine, the system has several unique features which facilitate its use in the current application. Straightforward access to the database and to the analysis routines is provided by procedure attachment. One of these procedures is denoted *value and provides the current value of the desired variable in the database. Addition, subtraction, multiplication, division, and arithmetic comparisons are also provided as standard attached procedures which can be incorporated in any of the rules in the rule base. The user can also add customized functions in standard FORTRAN to the system. Procedure attachment is found in several LISP-based inference engines, but is not so easily incorporated in a FORTRAN system. This was a difficult, but successful, part of the system development
Another notable feature of the system is run-time knowledge activation. Since aircraft design problems may require a wide range of domain-specific expertise, efficiency in the knowledge search procedure requires that specialized knowledge be modularized and included in the active knowledge set only when needed. The system provides a convenient procedure for this purpose, accessed in the rules with the *include statement: IF (Engine Problem) THEN (*include Engine_module)
The basic procedure for finding the computational path from the specified data to the required variable relies on information about subroutine inputs and outputs provided by the developer of each individual subroutine. This association of path information with individual routines, rather than frames attached to the variables themselves, was selected to facilitate the use of new subroutines, since the computational path to a given variable depends on both the set of known parameters and the set of available routines. The procedure is illustrated in figure 6.
Figure 6. Quasi-Procedural Analysis Structure
When the system is asked to generate the computational path to the variable H, it first looks through the subroutine documentation to find those subroutines that provide H as an output variable (indicated by the letters at the tips of the arrows in figure 6). In this example, routines 4 and 5 are found. The computational path generator then turns its attention to the input variables of these subroutines (located at the root of the arrows) and tries to find the computational path to these variables. The process is repeated until a complete path is found, connecting the desired output variable to a set of input variables that are available in the database. (Known values are enclosed by a box in figure 6.) In this example, after routines 4 and 5 are identified as potentially providing the desired value of H, the system checks to see if the required inputs: D,E, and F, or G and J are available in the database. Since they are not, the system attempts to find a path to each of these variables in turn. The routines 1 and 2 are found to provide the required data with inputs that are currently available and so the path 1 - 2 - 4 is returned by the path generator. Note that the solution is not unique (2 - 1 - 4 would also work). This process can be regarded as a form of 'state-space search', a well known problem in AI, which may be solved using one of several heuristic search algorithms (Ref. 15). The path generation algorithm is clearly recursive and is coded this way in FORTRAN without significant problems.
The computational path is not always as simple as that portrayed in figure 6. In some cases two paths utilizing different subroutines may be possible. In this situation the system currently uses the first path found, but in future implementations it will rely on user-specified preferences. This makes it possible to specify that a more sophisticated routine should be used when possible. So, for example, one may ask for the center of gravity position to be computed using a detailed weight and balance routine. This would require knowledge of the wing position, which must be placed on the aircraft so that the stability criterion is satisfied. But this requires knowledge of the C.G. position, which is what we wanted to know. If a simple C.G. estimating routine is also available, however, (one that requires only fuselage length and engine location, for instance) the computational path generator will recognize that by including the simpler routine in the path, the preferred routine may be used subsequently to provide the desired result.
Although in simple cases this procedure has been found to be sufficient and very useful, certain situations arise when the method is not convenient and a slightly modified version of this procedure is employed. One of these situations arises when the computational path is changed on the basis of the values of computed variables. This occurs in the following example: we wish to compute the drag of an aircraft including supersonic wave drag when the Mach number is greater than 1.0. This could be done with a simple if test:
... if (Mach > 1.0) then call GET (WaveDrag) else WaveDrag = 0.0 end if Drag = Drag + WaveDrag
This routine differs from the standard analysis subroutine format discussed in the previous section. Rather than loading all of the required data from the database at the start of the code, the program GET's the data as required in the middle of the routine. It is only necessary to GET the value of WaveDrag when the value of Mach is greater then 1.0. If the value of WaveDrag is specified as a required input value to this routine, then whenever the drag is to be computed, the computational path will include a subroutine to compute wave drag, even when the Mach number is less than 1.0. While this seems unnecessary, but harmless, it actually poses severe problems. Since the wave drag routine may require many inputs (e.g. cross-sectional area distributions), the program will not be able to generate a computational path for drag even when the flow is subsonic unless the additional data is available to the database.
This situation is handled by including in the input and output documentation, only variables that are always required by the routine. If the program does not need to GET the wave drag, then the original information is correct; if it does encounter the GET, the system realizes that the WaveDrag has not been computed or specified and that a new computational path must be computed 'on the fly' in order to determine the value of WaveDrag. The path generator routine is called at this time and a new branch is added to the existing path. Note that if the routine that computes WaveDrag does something similar, the GET routine is called recursively.
Such real-time path generation can be very helpful to the developer of an analysis routine. Just as the system user simply asks for the value of a variable without specifying the routines needed to compute it, so too the programmer simply requests a variable value through the GET call and may then use that value in the routine. In fact, it is this same GET routine that is called at the top level when the user asks to compute a particular value.
Consistency maintenance refers to the process by which the system decides when some of the variables need to be recomputed in response to changes in other values. It is an essential element of the quasi-procedural method. In order to provide the correct value of a variable when requested by the user, the system needs to know whether or not the current value in the database is consistent with the user-specified inputs. If nothing has been done to require recomputation of the value, the system can quickly provide the result, while if the value is not consistent, the system needs to recalculate it by executing all, or part, of its computational path.
The simplest scheme for assuring consistency of the database is to recompute everything whenever a change is made. This is hopelessly inefficient on all but the most trivial problems and one of two more sophisticated schemes is required. One of these associates consistency information with each variable. If the validity of every variable is known, then the parameter of interest may be recomputed by executing the subroutine which provides this variable as output. However, some of the inputs to this routine may also need to be recomputed, and the inputs to the routines used to compute these values must also be checked. This method thus becomes very costly in some cases as the consistency search can quickly become very large.
The alternative method used in the present system, associates consistency information with computational paths. Figure 6 illustrates how the renewal of consistency information is performed. The figure depicts a complex computational path consisting of a main path (vertical line) and several subpaths*. When a variable is modified, the entire path 'downstream' of this point is considered invalid (shown in gray). When the value of a variable along this path is requested by the user or one of the subroutines, only the segment of the invalidated path between the modified data and the desired result must be reexecuted. This approach to consistency maintenance results in significant improvements in system performance.
This system and its derivatives have been used in several applications related to research and education.
The Airplane Design Workshop is an interactive program used to demonstrate the aircraft design process to visitors in a museum. It is based on the PASS program, incorporating many of the same analysis routines, database structure, and a subset of the advice and warning knowledge base. Its highly graphical interface allows the user to select any of 13 operational and geometric design variables (e.g. destination airport, Mach number, engine layout, tail size, wing sweep, etc.) defining a 200 passenger commercial transport aircraft. Iterative calculation of aerodynamic performance, structural weight, and economics then provides the user with performance information, including an estimated ticket price. By attempting to reduce the fare or the block time, or by simply experimenting with unconventional layouts, a great deal is learned about the design process: about the complex interactions among design variables and the goals and constraints facing the aircraft designer. The expert warning and advice system is one of the key features of the program, permitting uninitiated users to define a feasible, converged design in just a few minutes. The program runs on an Apple Macintosh II computer with multiple monitors.
The program has clear educational value in this application, but it has also been used to teach about aircraft design to an audience with more background in this field than most science museum visitors. A version of the program is used in the graduate aircraft design course at Stanford University, enabling students to carry out trade and sensitivity studies at a far more comprehensive and sophisticated level than could be done by hand. Lectures deal with many of the analysis methods in detail and the program supplements more conventional 'by-hand' assignments. The authors have encountered no test of a program's robustness and interface, more rigorous than provided by 30 graduate students with weekly assignments requiring use of the code.
Versions of the program have also been used in the study of various aircraft design concepts including the oblique wing research aircraft and the joined wing concept (Refs. 16,17). Work is currently in progress to add analysis routines appropriate for the more detailed study of joined wing aerodynamics and structures.
An interesting application of the quasi-procedural method involves the multi-disciplinary analysis ideas discussed in references 18-19. Decomposition of the complex design task into smaller subtasks requires knowledge of the interconnections among the system variables. It is just this structure that is computed by the current method and the possible use of this system in connection with those described in reference 20 is under study.
Experience with the development and use of the Program for Aircraft Synthesis Studies has demonstrated the importance of a system architecture that is designed from the outset to be extensible. It must be able to deal effectively with complex hierarchical relations among the parameters and must aid the user and developer in doing so as well. The quasi-procedural method provides these features and is well-adapted to use in aircraft preliminary design. The expert warnings and advice system has proven extremely helpful to the user in understanding the many effects of design changes and acts as a useful debugging tool for the developer of additional analysis routines. The authors have developed, tested, and thrown out several synthesis programs; ideas that seem acceptable in simple examples often are not appropriate in more realistic applications. Progress in this field will require extensive practical experience with a particular system.
The current system has demonstrated the utility of the quasi-procedural method and knowledge-based system in aircraft advanced design. Work is continuing to refine and extend the system. Topics that are currently being addressed include the following: Algorithm development -- implementation of more refined aerodynamics and structural analysis routines for the analysis of unconventional configurations. Computational path generator -- may be used to identify system decompositions and parallel tasks. Several interesting possibilities are associated with use in a parallel processing or multi-tasking environment. User preferences will be taken into account when multiple paths may be followed. Interface Issues -- include further development and investigation of a hypertext-based user interface. This would include variable name synonyms and additional user selectable information on subroutines and variables. Optimization -- A variable metric numerical optimization routine will be added to the currently-available trade study options.
The rule-based advice system can provide useful suggestions on possible design improvements. But this is just the first step in a more general system for knowledge-based optimization. (It is one thing to be able to give advice, and another to be able to take it.) An improved system which tries out some of the rule-based suggestions to see if they really do improve the design has been implemented in sample problems with promising results. Although this system cannot replace numerical optimization procedures in all cases, it is capable of dealing with many of the discrete design choices not well-suited to conventional numerical methods. The system can also be used to identify (through its 'expertise') design variables which are most likely to improve the design. It then may rely on a numerical optimizer operating in the restricted design space for the actual result. Since the expert system may select different design variables, the computational path from the design variables to the objective function will vary. This is an ideal example of a synergetic relationship between the expert system and the quasi-procedural method. The resident expert system may be able to aid the optimizer in other ways as well, providing suggestions for gradient step sizes or selecting the appropriate numerical method as discussed in reference 21.
When the system is capable of acting on its own advice it may use the results to form its own rules. Several difficulties are encountered in this learning process, but the possibilities are fascinating.
Prof. Kosuke Ishii at Ohio State University provided many fruitful comments on the implementation of the inference engine. Chris Uhlick and Alec Proudfoot played a major role in the development of the Airplane Design Workshop, a version of the aircraft synthesis program incorporating an early form of the warning and advice system. Apple computer has provided computers used for some of this work.
1. Galloway, T., Waters, M., "Computer Aided Parametric Analysis for General Aviation Aircraft," SAE Paper 730332, April 1973.
2. Gregory, T., "Computerized Preliminary Design at the Early Stages of Vehicle Definition," NASA TMX-62303, Sept. 1973.
3. Heldenfels, R., "Integrated Computer Aided Design of Aircraft," presented at AGARD/NATO Flight Mechanics Panel Symposium, Florence, Italy, Oct. 1973.
4. De Filippo, R., "ACSYNT User's Guide," Northrop Aircraft, 1983.
5. De Filippo, R., "Aircraft Synthesis Using Numerical Optimization Methodology," AIAA-83-2458, Oct. 1983.
6. Arbuckle, D., Sliwa, S., "Experiences Performing Conceptual Design Optimization of Transport Aircraft," in Recent Experiences in Multidisciplinary Analysis and Optimization, NASA CP- 2327, April 1984.
7. Kidwell, G., "Workstations Take Over Conceptual Design," Aerospace America, Jan. 1987.
8. Mitchell, A., Market Supremacy Through Engineering Automation," Aerospace America, Jan. 1987.
9. Kroo, I., "Tail Sizing for Fuel-Efficient Transports," AIAA-83-2476, Oct. 1983.
10. Elias, A., "Knowledge Engineering of the Aircraft Design Process," in Knowledge Based Problem Solving, Kowalik, J., ed., Prentice-Hall, 1986.
11. J. Alsina, J. Fielding, A. Morris, Progress Towards an Aircraft Design Expert System, in Computer Applications in Aircraft Design and Operation, T. Murthy, J. Fielding, Eds., Springer-Verlag, Berlin, 1987 .
12. Simos, D., "Some Thoughts on the Application of Artificial Intelligence Techniques in the Aircraft Project Design," Dept. of Transport Technology, Loughborough Univ., Internal Note, Oct. 1986.
13. Tong, S., "Coupling Artificial Intelligence and Numerical Computation for Engineering Design," AIAA-86-0242, Jan. 1986.
14. Ishii, K., Lee, S., "The POGIE Manual," Dept. of Mechanical Engineering, Stanford University, April 1987.
15. Nilsson, N., Problem-Solving Methods in Artificial Intelligence, McGraw-Hill Book Co., Inc., 1971.
16. Kroo, I., "The Aerodynamic Design of Oblique Wing Aircraft," AIAA Paper No. 86-2624, Oct. 1986.
17. Kroo, I., Gallman, J., "Aerodynamic and Structural studies of Joined Wing Aircraft," AIAA Paper No. 87-2931, Sept. 1987.
18. Barthelemy, J., "Development of Multilevel Optimization Approach to the Design of Modern Engineering Systems," NASA CR-172184, 1983.
19. Sobieszczanski-Sobieski, J. , Barthelemy, J., Giles, G., "Aerospace Engineering Design By Systematic Decomposition and Multilevel Optimization," ICAS-84-4.7.3, Sept. 1984.
20. Rogan, J., McElveen, R., Kolb, M., "Application of Decomposition Techniques to the Preliminary Design of a Transport Aircraft," AIAA Paper No. 86-2617, Oct. 1986.
21. Arora, J., Baenziger, G., "Uses of Artificial Intelligence in Design Optimization," Computer Methods in Applied Mechanics and Engineering 54 (1986).
22. Rogers, J., Barthelemy, J., "An Expert System for Choosing the Best Combination of Options in a General Purpose Program for Automated Design Synthesis," Engineering with Computers, 1, 217-227, 1986.