CREATE-AV DaVinci: Computationally Based Engineering for Conceptual Design

Transcription

1 48th AIAA Aerospace Sciences Meeting Including the New Horizons Forum and Aerospace Exposition 4-7 January 2010, Orlando, Florida AIAA CREATE-AV DaVinci: Computationally Based Engineering for Conceptual Design Gregory L. Roth 1 and John W. Livingston 2 Aeronautical Systems Center, Wright-Patterson AFB, OH, and Maxwell Blair 3 and Raymond Kolonay 4 Air Force Research Laboratory, Wright-Patterson AFB, OH, Historically, decisions made during early phases of systems design and acquisition determine the majority of the life-cycle costs for those systems. Physics-based, high fidelity models that can support rapid analysis (minutes to hours) and rapid design (hours to days) would improve the quality of early acquisition decisions. The DaVinci software product is being developed in direct response to these needs. DaVinci is designed around a unified lifecycle engineering model encompassing multi-fidelity analysis for a wide range of applications. At its core, DaVinci provides next generation modeling capability for functional analysis, alternative design evaluation, trade-space exploration, and acquisition planning. The DaVinci infrastructure and architecture will enable a collaborative environment for all aspects of early acquisition processes and provide a much more effective mechanism for transferring detailed models and product descriptions between phases of acquisition throughout the life of the program. DaVinci will couple a rich graphical user interface with pre-engineered system components and large scale computing to allow systems engineers and acquisition stakeholders the use of computationally based engineering to enable rapid system engineering development iterations for requirements traceability, physics-based systems representations, and the creation of high-fidelity models suitable for early preliminary design. I. Introduction YSTEM design has become more and more complex recently due to a number of factors, including S organizational factors as well as the discipline of design itself. One of the main driving forces behind these changes is the highly competitive global marketplace. Aerospace companies are continually challenged to deliver high quality products to customers quickly while driving down costs to remain competitive. To gain an edge over the competition, a great need emerges for the infusion and development of new technologies that, in turn, can dramatically increase costs and complexity of designing aerospace systems. Additionally, business opportunities such as mergers have led to geographically distributed teams operating all over the world, making collaboration an operational reality. Historically, aerospace system design has been divided into isolated disciplines with relatively minimal interdisciplinary coupling and mostly linear interactions between disciplines. However, for a viable system study of advanced modern aerospace concepts, with their high level of integration, conflicting requirements and dependencies emerge which must be analyzed early in the conceptual design cycle, with a proper degree of fidelity 1 [email protected], Requirements Directorate, Bldg.11A, Rm. 022, Professional AIAA Member. 2 [email protected], Requirements Directorate, Bldg.11A, Rm. 001, Professional AIAA Member. 2 [email protected], Requirements Directorate, Bldg.11A, Rm. 001, Professional AIAA Member. 3 [email protected], Multidisciplinary Technology Center, Bldg. 146, Rm. 220, Professional AIAA Member. 4 [email protected], Multidisciplinary Technology Center, Bldg. 146, Rm. 218, Professional AIAA Member. 1 This material is declared a work of the U.S. Government and is not subject to copyright protection in the United States.

2 Performance (GFLOP/s), Cores (>1) to assess the impact of those requirements. Today s modern aerospace systems exhibit strong nonlinear, crossdisciplinary coupling (e.g. aeroelastically tailored vehicles, hypersonic vehicles) and require a multidisciplinary, collaborative approach to achieve realistic assessments of performance. The ever present need for optimized systems to remain competitive adds another layer of complexity on top of an already complex process. Current advances in the field of information technology have recently created the potential to alleviate some of these challenges while simultaneously enabling more knowledge to be applied earlier in aerospace system design and acquisition processes. In 2008, the U.S. Department of Defense initiated the Computational Research and Engineering for Acquisition Tools and Environments (CREATE) program to address the complexity of applying computationally based engineering to improve DoD acquisition processes. CREATE is a multiservice program, including representatives from the Army, Navy, and Air Force, with support from the Secretary of Defense. CREATE is developing and deploying three computational based engineering tool sets for acquisition programs to design aircraft, ships, and radio-frequency antennae by exploiting the exponential growth in supercomputer power. The Air Vehicles Project (CREATE-AV) is divided into products for: fixed wing analysis (Kestrel), rotary wing analysis (Helios), airframe-propulsion integration (Firebolt), and conceptual design (DaVinci). DaVinci is a computationally based engineering software product defined in direct response to identified gaps in conceptual design processes. DaVinci will be a unified life-cycle systems engineering modeling environment for advanced conceptual design and analysis enabling rapid development iterations for requirements traceability, detailed physicsbased systems representations, and high-fidelity models suitable for early preliminary design. A. Aerospace Design Complexity As described in Ref. 1, engineering is the process of applying the physical sciences and social sciences to analyze, design, optimize, simulate, or otherwise create systems to enhance our standard of living. Ultimately, this is a process of making decisions, decisions about how to develop models, what assumptions to make while retaining validity, what designs to choose, what restrictions to impose, and various other topics. All these decisions affect the users of the product, the environment the system operates in, investors and other stakeholders, and the engineering organizations responsible for the systems. Engineering design, on the other hand, is a process that begins with the identification of a need and ends with the communication, implementation, and presentation of a system or system of systems that addresses the need. In his 1969 book 2, Myron Tribus outlines the Anatomy of Design according to Allen B. Rosenstein as follows: 1) Identification of the needs (defining the problem) 2) Information collection and organization 3) Identification, idealization, recognition of system variables 4) Criteria development for optimum design 5) Synthesis 6) Test, evaluation, and prediction (analysis) of performance 7) Preliminary decision amongst alternatives 8) Optimization 9) Iteration 10) Communication, implementation, and presentation This same basic process is still carried on today in all fields of engineering design, including aerospace systems. Aerospace systems, especially military aerospace systems, can entail a level of complexity beyond many other systems due to not only the environment they operate in, but also the potential for human casualty. These complex systems and systems of systems involve the coordination, cooperation, and collaboration of many interacting participants, both human and machine Figure 1. Growth in computer power from 1945 projected through From 1990 through 2020, the number of processors (cores) per computer is also plotted 3. B. Software and HPC Complexity While Computational Based Engineering (CBE) has been making significant contributions, the future holds the promise of a major paradigm shift in problem solving from traditional methods toward CBE 3. Potentially, by 2020, supercomputers will be able to perform calculations a second (Figure 1). With this computing power, the Computing Power for the world's fastest computer (Floating Point Operations/s) Year

3 possibility will exist to employ the spatial and temporal resolution necessary to accurately model the details of complex systems, deploy highly accurate computational mathematical solution algorithms, include all of the effects known to be important in a system, model a complete system (e.g. an entire airplane, ship, vehicle, planet, star, etc.) in multiple dimensions, and be able to run enough problems to carry out useful parameter surveys. The scientific and engineering challenges of developing CBE codes reflect the complexity of the scientific or engineering subject matter. The codes must be able to accurately calculate the trade-off of many distinct physical phenomena over time and distance scales spanning many orders of magnitude 3. Since CBE codes represent models of nature, the code must be verified to have no important defects (Verification) and the model must include all of the important effects correctly (Validation) 4,5. Incorrect and inaccurate calculations lead to wrong decisions and bad designs. Existing Verification and Validation (V&V) methods are inadequate for the present generation of CBE codes and research is needed to develop better V&V methods 3. Accurate numerical solution algorithms that can efficiently utilize many processors (up to 10 9 ) will be necessary, but few exist. Calculations of complex, multimaterial systems require multi-dimensional numerical representations of the objects. Methods for rapidly generating the required accurate geometries and meshes generally don t exist and need to be developed. Improved techniques for rapid analysis and visualization of the very large datasets generated by big codes are required to ensure that computational results will be useful in the decision making process. II. Conceptual Design Today Conceptual design today is characterized by a comparative evaluation of numerous alternative concepts for the most advantageous potential system application for a specified purpose. Much effort goes into preparing for this process in gathering needs and setting requirements. Once conceptual design of aerospace vehicles begins, significant experience and extrapolation of available data from previously developed vehicles is often required 6,7,8,9. Conceptual design tools 10,11 and statistical methods 12,13 are often employed that leverage this available data. While this process may work fairly well for conventional aerospace systems, it becomes particularly difficult for unconventional vehicle concept development, especially if extreme mission requirements are present 14,15,16,17. As described by Lu 18, aircraft conceptual design is a computationally intensive, multidisciplinary, highly coupled, iterative decision making process that requires the support of sophisticated computer based design environments. The advancements in related disciplines, such as systems engineering, optimization, aerodynamics, propulsion, structures, controls, economics, etc., have dramatically increased the complexity of aircraft conceptual design at both of the system level and the component/subsystem level. The rapid development of computing technologies over the last decade has also changed the way of how aircraft conceptual design is conducted. Today, like other design activities, aerospace conceptual design is being conducted in an extended enterprise environment. It is more of a collaborative endeavor that involves many individuals from different companies or different parts of a company, utilizing disciplinary analyses programs, which are often distributed around the world. Ultimately, a design environment that enables designers to streamline the use of multiple computing assets around the world is needed to increase efficiency. A. Design Processes Conceptual design is the system life cycle phase that begins with operational requirements and ends when preliminary design begins. Much of this effort is characterized by a comparative evaluation of numerous alternative concepts in an attempt to find the concept, or set of concepts, that best contributes to the anticipated future state based on a specifically envisioned environment, situation, and set of objectives. Many references describe this process in detail 8,10,19,20,21, but the basic process is outlined below. Conceptual system design is an iterative process starting with a set of agreed upon operational requirements. The collective wisdom of the engineering design team is often leveraged Figure 2. Increasing fidelity leads to increased resources to begin a process of focusing the nearly infinite required 22. set of possible concepts to a set of potential 3

4 solutions that satisfy the requirements 22 (Figure 2). This brainstorming process can save valuable time and resources, but at the risk of introducing biases that guide the process away from a truly optimized design. Next, a large number of concepts are evaluated to determine the potential of each concept to satisfy the requirements and/or excel in any of the key performance parameter areas. Often this process entails a perturbation process around a good design to locate potentially better designs and potentially a revision of the requirements as new information and knowledge is gained. At times, the cost to satisfy specified requirements is so large that stakeholders will allow revisions of Figure 3. Air Force conceptual design and systems engineering process 23. those driving requirements to reduce cost. Once the set of potential concepts for satisfying the (potentially modified) requirements is reduced to a small number, preliminary design can begin. The United States Air Force, Aeronautical Systems Center, Requirements Directorate, Engineering Design and Analysis Division is concerned with activities leading up to the conceptual design process as well as the conceptual design of aerospace systems themselves (see section II.B, DoD Acquisition Introduction). The Engineering Design and Analysis Division provides technical leadership, products, and sound systems engineering for the generation and evaluation of effects-based capabilities to support requirements development, technology development, and early acquisition planning 23. These tasks are achieved by evaluating capability needs through functional analysis and allocation; scoping the trade-space and generating capability options; assessing the impact of technology; analyzing the system performance, effectiveness, risk, cost, and schedule; and assessing system capabilities with multi-level fidelity modeling and simulation. The Air Force conceptual design and systems engineering process is depicted graphically in Figure 3. The kinds of disciplines involved in aerospace systems design is depicted in Figure 4. B. DoD Acquisition Introduction The DoD acquisition process is depicted graphically in Figure 5. Systems conceptual design takes place once a Materiel Development Decision is made, but before a full Analysis of Alternatives (AoA) preceding Milestone A. Once the warfighter has identified a need, the early Systems Engineering and JCIDS (Joint Capabilities Integration Development System) processes begin, where DoD strategic guidance, joint operating concepts, and joint functional concepts are considered as inputs to the DOTMLPF (Doctrine, Organization, Training, Materiel, Leadership & Education, Personnel, and Facilities) evaluation to determine if indeed a materiel solution is needed. A gap analysis is performed while considering user needs and technology opportunities. Operational requirements are then Figure 4. Disciplines involved in aerospace systems design (adapted from Ref. 24). generated. This leads into the conceptual design phase of the system and eventually into an Analysis of Alternatives (AoA) process where the most promising solutions are compared in detail to select a preferred concept to move forward into technology development processes. 4

5 Gap Analysis DoD Strategic Guidance Joint Operating Concepts Joint Functional Concepts ICD JROC User Needs Technology Opportunities & Resources Materiel Solution Analysis A Technology Development Materiel Development Decision Pre-Systems Acquisition B (Program Initiation) Engineering and Manufacturing Development & Demonstration Post-CDR Assessment C The Materiel Development Decision precedes entry into any phase of the acquisition framework Entrance criteria met before entering phase Evolutionary Acquisition or Single Step to Full Capability LRIP/IOT&E Systems Acquisition IOC Production & Deployment FRP Decision Review FOC Operations & Support Sustainment = Decision Point = Milestone Review Figure 5. The DoD Acquisition Process. C. Capability Gaps in Current Practice Traditional aerospace system design programs currently used in practice are mostly monolithic programs and cannot provide the agility and functionality necessary to improve the efficiency or improve the effectiveness of aerospace systems conceptual design. These monolithic programs cannot provide satisfactory functionality to meet new design requirements due to the lack of domain flexibility and analysis scalability. These programs are often unable to handle unconventional configurations or account for new technologies. This is mainly due to their reliance on historical data, and perhaps in many cases, the inflexibility of the codes used to account for, or to be modified to account for, concepts and technologies outside the historical database, to create the relationships used throughout these programs. To account for these emerging needs, a new approach is needed which will yield a next generation conceptual design software environment. The DaVinci product is the CREATE (Computational Research and Engineering for Acquisition Tools and Environments) software intended to fulfill this need. It will enable the shortening of the design cycle time, improvements in design quality, and reductions in required resources. These reductions in required resources can be leveraged to allocate more design iterations or to incorporate higher fidelity analysis methods at the conceptual design stage. Furthermore, DaVinci will automate some common processes to free up human resources to apply to areas where computer automation is still too immature for success. The CREATE-AV (Air Vehicles) Planning Team has identified capability gaps in the DoD Air Vehicles acquisition process. These gaps can be categorized into three broad classes: Conceptual Design, Design Verification, and Design Environments 25. Each of the specific Computationally Based Engineering (CBE) products of the CREATE-AV Project addresses these gaps in an important way. 1. Conceptual Design The conceptual design capability gap addresses the lack of robust methodologies and tool sets to support concept development and early systems engineering required in the formulation, evaluation, and documentation of concepts and products to support stakeholder requirements. A critical component of conceptual design is the creation of standard processes to gather, vet, and refine stakeholder requirements. In addition, mechanisms to perform requirements analysis and functional analysis to identify and quantify measures of effectiveness and performance are needed. These metrics are a necessary precursor to conceptual design, exploration, and refinement. Current early-phase acquisition and early system engineering processes are limited in a number of significant ways. Synthesis tools (i.e., tools that estimate the performance of vehicle design concepts based on historical data for similar vehicles) are widely used in both government and industry. Historical data is often insufficient for evaluation of new, complex, and innovative technologies. The performance of past designs does not address many sources of design uncertainty. Another early-phase limitation is a continued difficulty in estimating vehicle weight and weight distributions of aerospace designs. Development of robust and accurate early cost estimating relationships as well as accurate predictive acquisition scheduling is incomplete or immature. Key system designs (e.g., airframe structure, engine deck, propulsion systems, etc.) depend on, and contribute to, vehicle weight and cost. Historical data is often not sufficient and first-principal tool sets do not exist. This limitation exists for both government and industry conceptual design groups. Early-phase acquisition is additionally limited by a lack of ability to account for physics coupling (viz., structures, aerodynamics, aero-elastics, thermodynamics & heat transfer, stability, controls, and acoustics) at a level of fidelity necessary to accurately predict responses of vehicle concepts. An ability to synthesize, evaluate, optimize, and assess uncertainty and risk of design concepts during early phase acquisition is critical to ensuring success during the subsequent technology development phase. 5

6 2. Design Verification The design verification capability gap addresses the need for multi-physics coupling in engineering analysis and design. Means for integrated, full-vehicle, full-physics, test and analysis of system designs via simulation methods are needed for the services to verify vehicle performance; perform operational certifications and qualifications; rehearse ground-based and full-scale operational tests; and evaluate planned or potential operational use scenarios all prior to fabrication of test articles, full-scale prototypes, or implementation of system modifications. Such analysis capability is essential for design risk reduction and escaping the traditional design-test-fix paradigm of acquisition. As in conceptual design, existing tool sets that might be used in this role are hindered by a significant lack of physics coupling (viz., structures, aerodynamics, aero-elastics, thermodynamics and heat transfer, stability, controls, and acoustics). High-fidelity tools do exist for most, if not all of the component physics, but they generally address a single physics or design issue. In some cases, existing tools employ mixed-fidelity physics, accurately predicting a principal physics issue, while accounting for the integration of other physics issues with only rudimentary or lower-order models. The domains of appropriate use for existing high-fidelity simulation methods are generally limited to single-physics applications (e.g., aerodynamics only, or structural dynamics only). Fullvehicle design verification requires multi-physics coupling. 3. Design Environments The design environments capability gap addresses the need for an environment that facilitates the application of CBE compute resources throughout the spectrum of acquisition engineering processes. Although system manufacturers do use CBE in conceptual design and subsequent engineering processes, the relevancy of CBE to existing government acquisition processes is typically limited to late-phase processes only. Both government and industry processes are limited by not only manpower but also computational power that is available to maximize the value of emerging software tools. As outlined in Ref. 25, paradigms to provide the acquisition community access to necessary CBE compute resources either do not exist, or have not been demonstrated. Infrastructure tool sets necessary for transitioning design data between phases of acquisition or between design states generally do not exist. When they do exist, they usually require inordinate degrees of user expertise, human resources, and calendar time. Problem setup tasks and a lack of robust case management software products represent very serious impediments to the effective use of CBE in acquisition. III. Designing for Tomorrow System conceptual design is a complicated, data intensive, multidisciplinary, highly coupled, complex, iterative process. However, most of the aerospace conceptual design programs in current use today are based on historical data and are at best treated as black boxes, being wrapped inside other integration and automation programs. Agility and flexibility is not provided for in these current use software tools for one to add new functionality without monumental effort, if possible at all. Even when these existing programs are successfully kept within acceptable interpolation limits and integrated into other control programs, the information management that passes engineering design data between components of these programs is not transparent. To be fair, some success has been gained by the use of integration software that has provided some level of automation and reduced design cycle times. However, these improvements are limited, as design engineers still do not have the functionality to extend these programs or effectively manage the design information passing. The key to improving the efficiency and effectiveness of system conceptual design activities is to improve the quality of design decision making and to reuse design information assets to a greater extent. The DaVinci suite of software tools will incorporate the state of the art in multidisciplinary design methodologies and advanced computing techniques. Several efforts for integrating relevant aerospace system disciplines and for addressing the complexities involved have been attempted over the years with varying levels of success. NASA sponsored a study of Advanced Engineering Environments (AEE) at the turn of the century, stating that technology is now ready and that engineers now have a historic opportunity to develop and deploy AEE technologies and systems 26,27. The AEE study committee identified a number of technical, management, cultural, and educational barriers that need to be overcome first in order to realize the vision of AAE systems. Table 1 gives the list of barriers identified in phase 1 of the study 26. Table 1. Barriers to achieving the AEE vision (adapted from Ref. 26). Integration of Tools, Systems, and Data 1 Lack of tool interoperability 6

7 2 Continued proliferation of tools, which aggravates interoperability issues 3 Existing investments in legacy systems and the difficulty of integrating legacy systems with advanced tools that support AEE capabilities 4 Little effort by most software vendors to address interoperability or data exchange issues outside of their own suite of tools 5 Multiple hardware platform issues computers, hardware, databases, and operating systems 6 Lack of formal or informal standards for interfaces, files, and data terminology 7 Increasing complexity of the tools that would support AEE capabilities 8 Difficulty of inserting emerging and advanced technologies, tools, and processes into current product and service environments 9 Supplier integration issues 10 Difficulty of integrating AEE technologies and systems with other industry wide initiatives, such as product data management, enterprise resource management, design for manufacturability/assembly, and supply chain management Information Management 1 Proliferation of all types of information, which makes it difficult to identify and separate important information from the flood of available information 2 Difficulty of maintaining configuration management for product designs, processes, and resources 3 Need to provide system agility so that different types of users can easily input, extract, understand, move, change, and store data using familiar formats and terminology 4 Difficulty of upgrading internal infrastructures to support large bandwidths associated with sharing of data and information 5 Need to provide system security and to protect proprietary data without degrading system efficiency Culture, Management, and Economics 1 Difficulty of justifying a strong corporate commitment to implementing AEE technologies and systems because of their complexity and uncertainties regarding costs, metrics, and benefits 2 Lack of practical metrics for determining the effectiveness of AEE technologies that have been implemented 3 Unknowns concerning the total costs of implementing AEE technologies and systems and the return on investment 4 Difficulty of securing funding to cover the often high initial and maintenance costs of new AEE technologies and systems in a cost-constrained environment 5 Risk and someone to assume the risk (management, system providers, or customers) 6 Planning and timing issues when to bring in the new and retire the old 7 Difficulty of managing constant change as vendors continually upgrade AEE tools and other technologies 8 Diversity of cultures among different units of the same company Education and Training 1 Need to upgrade labor force skills along with technology and tools to support an AEE capability 2 Difficulty of incorporating AEE technologies into university design curricula Phase 2 of the AEE study assessed the long term (15 year, circa 2015) vision for incorporating AEE technologies into both the current and future engineering work force. The highlights of this report included NASA s Intelligent Synthesis Environment (ISE) Initiative to develop AEE technologies and systems focused on integrating widely distributed science, technology, and engineering teams and enabling the rapid creation of innovative, affordable products for science and engineering applications as well as a future perfect expansion on this 15-year vision 27. 7

8 The ISE s 2015 vision foresaw the ability to conduct first-of-a-kind missions routinely with high levels of confidence, even for missions for which little or no experience or experimental data were available to predict system capability. The ISE vision included the evaluation and optimization of attributes across the complete life cycle at all stages of design refinement and product tradeoffs with minimum design iteration. According to the ISE vision, almost all evaluations would be done virtually, not physically, with immersed environments operated by geographically and temporally distributed collaborative teams. Rework and late trade-offs would be eliminated. Because the ISE vision was also to support missions, such as deep-space probes, where human supervisory control would not be practical, the ISE vision emphasized autonomous system capability for some functions, such as selfdirected exploration and fault repair 27. The future perfect expansion on the ISE 2015 vision takes these ideas even further 27. The missionrequirements process envisioned for the future perfect was to use, at a minimum, real time simulation of all aspects of product and mission performance that were to account for and describe the effects of uncertainty and risk on product attributes and prospects for mission success. This vision also emphasized first-of-a-kind product customization and included the capability for customers to design their own products using the system s automated optimization capabilities. In this vision the steps of concept development, preliminary design, and detailed design were collapsed into a single step. Inherent in this merging of design and development steps was the integration of product design with the development of manufacturing methods (i.e., an extension of existing design for manufacturing and assembly methods). An expert system was envisioned to generate design alternatives, which were then to be optimized in a single pass while requirements were cascaded down through system and component levels. This capability was to be error-free and was to eliminate the need for iteration, physical prototypes, experimental refinement, or rework. Although this vision was recognized as optimistic and likely not to become a reality by 2015, it did, and still does, serve as a useful reference point for judging improvements to current processes. Since 2000, when the NASA AEE reports were published, technology has continued to advance, and design engineers have never been in a better position to achieve the AEE dream. Table 2 lists some of the more notable previous efforts to integrate the various aerospace disciplines into a single environment with reasons why they are not ideal for the present CREATE effort. Table 2. Notable previous efforts to integrate design disciplines. Approach/Tool Intelligent Multidisciplinary Aircraft Generation Environment (IMAGE) 28 Leading Edge Advanced Prototyping for Ships (LEAPS) 29 Numerical Propulsion Simulation System (NPSS) 30 Developing Organization Year Published Reason for not Using in Current Effort Georgia Tech 1996 Dated and source code not readily available, wraps existing codes Carderock Division of Naval Surface Warfare Center (NSWC) 2001 Based on a structured database, Navy software focused on ships NASA Glenn 2001 Propulsion system simulation tool, difficulties integrating with other software, controlled access of program Adaptive Modeling Air Force 2002 Product of Technosoft, Inc., too focused on a Language (AML) 31 core parametric geometry modeling capability, requires yearly licensing agreements Advanced Engineering NASA 1999, Environment (AEE) 26,27, , & 2003 Built with Phoenix Integration s ModelCenter framework, lacks detailed geometry representation, requires yearly licensing agreements Conceptual Design Shop CADWG Built with Phoenix Integration s ModelCenter (CDS) 33 8

9 Next Generation Aircraft Conceptual Design Environment (NextADE) 18 framework, MATLAB controls, and AMRAVEN CAD/geometry/meshing, requires yearly licensing agreements Georgia Tech 2007 Ph.D. thesis focused on object-oriented framework and data management, wraps existing codes, uses Phoenix Integration s ModelCenter for integration, requires yearly licensing agreements BIVIDS 34 Boeing 2008 Industry owned and focused on a core parametric geometry modeling capability Integrated Design & Engineering Analysis (IDEA) Environment 24 NASA Langley Vehicle Analysis Branch 2008 Previously known as CoHAVE and AdVISE, built on previous AML work, mainly for wrapping existing codes, requires yearly licensing agreements A. System Engineering Capability Needs The DaVinci Requirements Team, with tri-service representation composed of members from the Air Force Aeronautical Systems Center Requirements Directorate, Engineering Division (ASC/XRE); the Air Force Research Laboratory, Multi-Disciplinary Technology Center (AFRL/RB); the US Army Advanced Design Office AFDD (AMRDEC); and the Navy NAVAIR/ developed the following list of minimum system engineering capability needs/concepts that must be present in DaVinci: problem formulation; modular, parametric model builds; model fidelity tailoring; component set extensions; model/software variation/version control; multi-level optimization/exploration; lo-fidelity to hi-fidelity model correlation; and decision support & report generation. Each of these concepts is expanded below. 1. Problem Formulation The problem formulation phase begins once the warfighter has identified a need. Support is provided for the JCIDS process and the DOTMLPF (Doctrine, Organization, Training, Materiel, Leadership & Education, Personnel, and Facilities) evaluation analysis to decide if a materiel solution best fulfills the identified need. Next, functionally is traced from user needs to engineering needs so that alternatives worthy of investigation can be identified. This is when the trade space is established as well as the KPPs (Key Performance Parameters), MOOs (Measures of Outcome), MOEs (Measures of Effectiveness), and MOPs (Measures of Performance), otherwise known collectively as Figures of Merit (FOM). The problem formulation process is accomplished by functionally decomposing the stakeholder needs, desires, and requirements into easily digestible pieces. The identified functions are aligned to system elements and user products such as plots, reports, and DoDAF (DoD Architecture Framework) views are generated. 2. Modular, Parametric Model Builds Engineering models are built to explore system alternatives and help set engineering requirements. A design engineer finds and integrates pre-engineered components and system elements with the needed functionality relevant to the current project. This process helps establish the necessary procedures and develop the parametric associations between system elements. The model building phase also allows the determination of the design variables for feedback and feedforward in the process flow diagrams. Internal design optimization loops as well as solution convergence criteria are chosen at this stage. 3. Model Fidelity Tailoring For success in applying available resources to obtain the greatest amount of decision support potential, the use of both right-fidelity (as opposed to high-fidelity) and appropriate coupling of disciplines within the models is essential. Tailoring model fidelity allows the maximization of useful results while minimizing the required resources for solution. A next generation system engineering capability should allow for multiple fidelities to be developed for each set of components. These components should quantify uncertainty in some manner for future control or drive down and for uncertainty roll-up for calculating likelihood in risk assessments. Ensuring geometric consistency between fidelity levels is essential by including some sort of featuring/defeaturing capability. 9

10 4. Component Set Extensions A set of pre-engineered components should be available out of the box for modern system engineering design tools. However, this set must be able to be extended as new problems arise and existing components become incapable of addressing current engineering challenges. This implies that the design tools of tomorrow will require agility to be extended for unanticipated uses. Sound systems and software engineering design provides a set of base software components that can be built upon with minimal need for rewrite. 5. Model/Software Variation/Version Control As with all large, complex systems, engineering design tools intended to be modified and extended to solve modern engineering design problems in an agile fashion will need a form of version and variation control on not only the software, but also on the engineering models themselves. This tracking ensures the user is invoking the intended set of software components and engineering tools. The organization and tracking of design software and engineering components is accomplished with version control and configuration management. A standardized component certification and registration process can help. 6. Multi-level Optimization/Exploration The best engineering design processes include a thorough understanding of the potential solution space and available design space. This understanding enhances the potential of finding the solution or set of solutions that best satisfy the stakeholder needs. Parametric execution of engineering models can ease the burden of exploration. Engineering sensitivity analysis and surrogate models help with understanding the characteristics of the solution space. Multi-level, multi-fidelity, multi-disciplinary, multi-objective optimization computational expense can be alleviated by employing a collaborative, distributed environment. 7. Lo-fidelity to Hi-fidelity Model Correlation Ultimately, since all meaningful systems and systems of systems are highly complex and require some set of modeling approximation of reality, an understanding of assumptions and accuracy is needed. Hi-fidelity models may capture the physical reality better, but often at the expense of greater computational expense. Lower-fidelity models help, but insight is lost in the process. By incorporating a process by which hi-fidelity models are used to calibrate lower-fidelity models, a balance can be obtained based on the current problem that allows some of the benefits of both model fidelities to be realized. 8. Decision Support and Report Generation Finally, all information and knowledge gained needs to be persisted for future use. Each type of stakeholder has a preferred view of the data. By allowing the user to tailor their view to their preferences enhances user adoption. The systems engineering design software should support many points of view and allow the end user to choose preferred visualization types. Currently, with no standardization of data formats, import/export utilities are needed for data coming from a variety of sources. Data files generated by next generation engineering design tools should attempt to use an emerging standard like XML schemas and agreed upon data dictionaries. B. CREATE-Air Vehicles The CREATE-AV (Air Vehicles) Project is one of three primary elements of the CREATE Program, established in FY2008 by the Department of Defense (DoD) Director of Defense Research and Engineering to improve engineering processes for acquisition of major new military weapon systems 25. The CREATE-AV Project will develop and deploy a set of Computationally Based Engineering (CBE) software products for the air vehicles acquisition engineering workforce. The products are being developed in response to regularly updated and prioritized requirements to address key capability gaps in acquisition processes of this community. The products aim to: 1) Increase the capacity of acquisition program engineers 2) Reduce workloads through streamlined and more efficient acquisition engineering workflows 3) Minimize the need for rework due to early detection of air vehicle design faults and performance anomalies The focused, strategic goals of the CREATE-AV project are expected to provide significant, measurable benefits to the acquisition engineering workforce and stakeholder organizations. 1. HPC Modernization Program Goals The High Performance Computing Modernization Program (HPCMP) key goal is to enable the DoD community to exploit the power of supercomputers to fulfill its mission better. The HPCMP Office recognizes that supercomputers are becoming more powerful through increased complexity, and, because of this among other reasons, fewer and fewer DoD codes will be able to fully exploit these newer computers. This realization has motivated the need for the CREATE program to develop application codes that can exploit the next generation of 10

11 computers and impact the DoD acquisition community. The main purpose of CREATE is to enable major improvements in the DoD acquisition process through better system engineering design and systems integration to: 1) Enable rapid, early development of optimized designs 2) Detect/fix design flaws early in the design process before major commitments are made 3) Begin system integration earlier in acquisition process 4) Increase acquisition program flexibility and agility to respond to rapidly changing requirements The CREATE program will also be used to improve the ability of DoD institutions to develop and exploit largescale computational science and engineering tools by building organic technical capability of DoD institutions. 2. CREATE-AV Products The CREATE-AV Project will develop and deploy four CBE software products to the defense acquisition engineering community for air vehicles. These are DaVinci (for conceptual design and early phase acquisition processes), Kestrel (for preliminary level fixed wing analysis), Helios (for preliminary level rotary wing analysis), and Firebolt (for airframe-propulsion integration analysis). An element of the project known as Shadow-Ops has been created to establish lines of communication between project development teams and targeted organizations within the defense acquisition engineering community and to provide important quality controls for project CBE software products. The DaVinci product with a focus on the early phases of DoD acquisition, conceptual design, and preparing input for the more detailed, preliminary level studies is described in more detail in the following sections. C. DaVinci CBE for Conceptual Design DaVinci is a CREATE-AV CBE software product defined in direct response to the conceptual design gaps described in section II.C.1, Conceptual Design. The purpose and goals of DaVinci include: bringing multidisciplinary, multi-fidelity, physics based, CBE tools to common engineers; providing a seamless, extensible, flexible, systems engineering infrastructure spanning the full system lifecycle from requirements generation through sustainment; generating high quality, meshable geometry for CFD/CSM/CEM tools; exploring, optimizing, and understanding the system trade-space and tradeoffs; enabling effective conceptual studies, uncertainty quantification, and sensitivity analysis; enhancing collaboration across geographically distributed teams; enhancing systems requirements definition and KPPs (Key Performance Parameters); evaluating benefits of new or innovative technologies; and assessing the impacts of requirements on system capability. The DaVinci product will enhance the DoD acquisition process from pre-jcids through MS-B (pre Materiel Solution Analysis through Technology Development in the acquisition process) by providing a multi-disciplinary, multi-fidelity, computationally based systems engineering design tool set to exploit the exponential growth in supercomputer power 35. DaVinci will consist of an architecture and framework that provides an open collaborative environment for early air vehicle systems engineering. The intent is to provide unified life-cycle, engineering model-centric, data persistence tools that encompass functional analysis and allocation, alternative concept generation, trade-space exploration, and acquisition planning. The DaVinci framework will be populated with a set of software support elements. These will include, for example, engineering tools that enable performance, effectiveness, risk, cost, and schedule analysis and requirements and technology impact trade studies. In addition, DaVinci will include a key software element that allows the conceptual designer to quickly and intuitively build parameterized, associative, attributed models (including geometry, outer mold lines (OML), and corresponding layout of internal structure and Figure 6. Key components of the DaVinci architecture. sub-systems) necessary 11

12 to feed higher-fidelity analysis tools (e.g., CREATE-AV Products Kestrel and Helios). This represents a key enabling technology an ability to quickly generate model descriptions suitable for aerodynamic and structural meshing. This capability will facilitate the relevance of Computationally Based Engineering and High Performance Computing to the earliest phases of acquisition, providing decision makers with consistent-fidelity, multi-physics based decision data, including uncertainty and sensitivity analysis, in a timely manner. The DaVinci product also represents an important mechanism for communicating model descriptions between phases of acquisition, currently a significant part of the design environments list of capability gaps described earlier. Figure 6 graphically shows the main architectural components of the DaVinci product. 1. Stakeholder Needs and Requirements Stakeholder needs and requirements are collected by the CREATE-AV Planning Team members annually. These inputs are refined and formalized by the DaVinci Requirements Team and Development Teams. A requirements reconciliation process further refines these stakeholder needs. The FY2009 requirements process highlighted five key areas: parametric Non-Uniform Rational B-Splines (NURBS) based meshable geometry, model featuring and defeaturing, design variable sensitivities, automatic unit analysis & conversion, and uncertainty quantification & propagation. Each of these focus areas is further elaborated below. a) Parametric NURBS-Based Meshable Geometry High quality, NURBS-based, parametric geometry capable of supporting high fidelity analyses (i.e. signatures, CFD, CSM, and vulnerability analyses) is required to generate both the outer mold line (OML) for CFD and signature analysis, and to generate internal structural details for CSM analysis. The DaVinci product will leverage efforts by the CREATE-MG group for the geometry engine and necessary Application Programming Interface (API) calls. Efforts in this area continue as DaVinci and CREATE-MG collaborate on solving this need. b) Model Featuring and Defeaturing Model featuring and defeaturing is required to smoothly flow between different fidelity levels. An illustrative example concerns the joints of structural members as one transitions from beams, plates, and shells to full threedimensional elements. The one dimensional or two dimensional nature of the lower fidelity analyses allow the joints to be modeled as pin joints where thickness can be ignored. Once the third dimension is added to the structural models, these joints are no longer simple. Additionally, the thickness of these members must be expanded on one or both sides of the zero thickness simple elements. Many of these elements will be expanded half on either side of the zero thickness element for internal structure, but elements on the outer mold line must be expanded internally to avoid disrupting the outer aerodynamic shape. This need will be addressed in time once the other needs are met. c) Design Variable Sensitivities (First Derivatives) Shape optimization supports design engineers using either numerical or gradient methods. For design applications with a large number of design parameters, only the gradient methods are computationally practical. However, the gradient methods are possible only where the design space is continuous and smooth. Thus, numerical methods are often resorted to for creating a family of design variants. The gradient methods are often used to converge on the optimal solution once a numerical method has closed in on the proper area of the design space. The end game is to integrate numerical and gradient methods within a consolidated model data structure. In other words, how can one efficiently integrate design variant management with design sensitivity trails? Refs. 36 and 37 are examples of past developments with design variants. A wealth of ongoing development exists in the area of design sensitivities, including: 1) Finite Difference Sensitivities (FDS) 2) Complex Difference Sensitivities (CDS) 3) Analytic Sensitivities (AS) 4) Automatic Differentiation (AD) 38 a) Standard AD (ADIFOR and ADIC) b) Sensitivity Class (SC) DaVinci is focusing attention on SC methods, since, in general, these present the potential for producing the most efficient and accurate sensitivity data. Also, the SC approaches offer a natural division of labor between software specialists in sensitivity management and product design engineers. The design engineer should focus on design while the details of managing sensitivities remain out of sight. The SC goal is to enhance standard programming languages so they appear as similar as practical to the original programming language while sensitivities are automatically calculated in the background. 12

13 d) Automatic Unit Analysis and Conversion The automatic unit analysis and conversion focus area has been prototyped as well. This need was based on the great convenience and reduction in errors it brings to the system conceptual design process. Some unit systems are more likely to lead to errors in understanding or mistakes in conversion than others. Automatic unit analysis and conversion protects against operating on inconsistent values due to unit mismatches and can help with conversion errors. e) Uncertainty Quantification and Propagation Uncertainty quantification and propagation is important to understand the quality of results obtained by exercising engineering analysis and design methods and programs. Parametric trade studies are conducted for the purpose of establishing a balanced set of requirements which includes performance, supportability, risk, and uncertainty. Not only does this indicate an explicit need for uncertainty quantification, it also gives an indirect need through the assessment of risk (the product of the likelihood of an event and its impact on the systems of interest). At a minimum, uncertainty will be represented by upper and lower limits with a mean for values of interest. This will be expanded to common probability distributions over time, and eventually to general probability distributions. Uncertainty propagation will be handled by exact analytical formulae when available, or will be calculated by Monte Carlo simulations in the general case. Advanced concepts such as polynomial chaos theory will be investigated at a later time. 2. DaVinci Product Scope The scope of the DaVinci effort can be seen in Figure 7 as well as Figure 6. DaVinci is on an annual release schedule with the first release in 2010 focusing on meshable geometry, and a second release in 2011 focusing on design space exploration. Further releases are planned through Topics receiving immediate attention include: approved, pre-engineered components; interfaces to other CREATE products; and agile infrastructures. Other important considerations include: knowledge persistence & mining, tailorable user interfaces & viewers, build environments for conceptual design models, design/analysis/trade-space exploration tools, and collaboration environments. These will be incorporated in future releases of the DaVinci product. Figure 7. DaVinci product scope and delivery schedule. 13

14 3. DaVinci Priorities The DaVinci concept was born out of the needs addressed in the Capability Gaps in Current Practice (section II.C) and resourced by the High Performance Computing Modernization Program. The needs of conceptual designers worldwide and the need to propagate lower fidelity models into higher fidelity models and then back again has motivated the following set of priorities for DaVinci. a) Model-centric, System Engineering Infrastructure Early systems engineering processes to support capability decomposition, systems characterization, exploration, and requirements generation has led to a strong preference for a model-centric, system engineering infrastructure. While easing early acquisition activities, this infrastructure supports passing of engineering knowledge and design wisdom throughout the life cycle of the system. No longer will data, information, and understanding be lost from one phase of acquisition to another or over long time spans. Conceptual design models (and indeed any other model) will be persisted in standards based formats to withstand the currents of time and organizational processes. b) Rapid Parametric Geometry Modeling Tool Traditionally, much time is invested in generating geometry models for varying fidelity levels of analysis. Therefore, a leading priority for DaVinci is to provide the users with a rapid parametric geometry modeling tool. This allows the user to vary the design and perform parametric sweeps of the design space, all the while being capable of generating meshable quality geometry for propagation into higher fidelity tools like computational fluid dynamics codes or finite element method software. c) Problem Formulation and Set-up Capability Another difficulty of real world design engineering is the process by which a problem is formulated from stakeholder desires. To alleviate this challenge, a priority exists to assist the user with proper problem set-up. Operational requirements verification is one area receiving attention to ensure these requirements are captured correctly. d) Decision Support and Trade-space Exploration Tools Multi-attribute decision support of materiel development decisions throughout the lifecycle is arguably the main purpose of DoD engineering activities. Because of this, decision support and trade-space exploration tools are extremely important to conceptual design engineers. Many technologies feed decision support and trade-space exploration. Some of these under consideration for DaVinci include: gradient based search methods, evolutionary based search methods, evidence based probability routines, and Bayesian methods for belief propagation. e) Collaborative Large Scale Computing Environment Finally, as highlighted previously in the discussion on the highly competitive aerospace marketplace, collaboration across geographic boundaries and use of large scale computing environments has become the norm. These priorities will be addressed as soon as the previous priorities above are addressed. IV. Software Infrastructure Agile software infrastructures are desirable to allow the rapid development of the tools that address customer needs. A number of technologies have matured recently to facilitate this capability. As Watson points out 39, the software engineering of customizable architectures, leveraging the Web, supporting distributed, collaborative problem solving, and providing middleware constitute some of the enabling technologies. Problem solving environments (PSE) are attractive approaches to enable an agile software infrastructure that also has additional benefits to the user. A problem solving environment is a computational system that provides a complete and convenient set of high level tools for solving problems from a specific domain 40. The PSE allows users to define and modify problems, choose solution strategies, interact with and manage appropriate hardware and software resources, visualize & analyze results, and record & coordinate extended problem solving tasks. A user communicates with a PSE in the language of the problem, not in the language of a particular operating system, programming language, or network protocol. The initial developmental period of DaVinci is focused on exploring and demonstrating the merits of an agile infrastructure paradigm in terms of facilitating rapid development and deployment of multi-physics analysis capability to members of the targeted acquisition engineering community in a way that is both adaptable and maintainable. A. Desired Characteristics Since an integrated conceptual design and virtual simulation environment usually consists of several to many application tools created for different purposes, practical realization of such an integrated environment can be a challenge. These multiple heterogeneous application tools typically have been developed independently, written in different programming languages, worked on different computer platforms, and were installed on different 14

15 computers at different locations. Moreover, each of them had its own problem definition language and means for representing information. In a nutshell, these application tools were not interoperable. This lack of interoperability among common application tools created artificial barriers for communication and information sharing within the virtual integrated simulation environment 18. The following characteristics have been identified by the DaVinci team as desired for practical realization of an integrated conceptual design, virtual simulation, and systems engineering environment. 1. Services Based Design Services based design allows access to not only spare computational cycles but also to legacy codes and software not owned internally. Event driven programming can be beneficial. Service based components also support distributed computing and supercomputing as well as heterogeneous codes that need various different operating environments (both software and hardware). 2. Collaborative, Distributed Environment Geographically distributed teams are common in today s engineering organizations. All team members need to access a common, unified system model concurrently and interactively. A unified system model reduces the potential of stale information and the situation where one disciplinary expert advances his agenda while lessening the effectiveness of another disciplinary expert. 3. Extensible Component Building Blocks Modern object oriented programming practices with well defined interface definitions of components enhances extensibility. A well designed architecture will allow for base components to be developed by extending existing code with inheritance like capabilities and with pre-existing templates. 4. High Performance Computing Simplicity Today s computational resources dwarf those of yesterday, and this trend is expected to continue into the foreseeable future with new chip architectures and multi-core designs. Leveraging these resources to solve complex system engineering problems, while hiding the details form the design engineer, can boost productivity greatly. Computational platforms of interest include desktop workstations, networks of workstations, grid computing environments, and high performance computing center environments. 5. Highly Secure Cyberspace With distributed computing environments and for solving problems of national interest, a need arises to address computer security and information assurance. An architecture/infrastructure with security designed in from the beginning possesses a much better chance of addressing the cyber-security challenge. 6. Interactive Visualization Visualization of the results in a manner most productive to the stakeholders is essential. Interactive visualization allows the user to view results as the problem solution progresses to maturity. User tailoring of the different views and content of the data can ease the burden of report generation. 7. Design Space Exploration Any architecture/infrastructure for systems design must support exploration of the design space. Many techniques exist that may be of interest including: Design of Experiments, Latin hypercube sampling, automated optimization techniques (gradient based, stochastic, etc.), computational steering to give the user more control, and surrogate modeling. 8. Knowledge Management and Persistence An architecture/infrastructure supporting both knowledge gained from legacy codes and process as well as organizing new knowledge in an archive that can be easily searched and mined is necessary. Much engineering expertise and knowledge is locked within legacy applications, and this resource should be utilized through wrapping these codes, or through extracting useful components from these codes. Archiving, retrieving, comparing, and mining the input and output from computer simulations can significantly enhance scientific and engineering productivity. 9. Multidisciplinary Multi-Fidelity Capability Not all users will be experts in all disciplines for a given engineering problem or optimization, and subject matter experts may not always be available on the distributed, collaborative team. Because of this, a need exists to provide expert guidance to non-experts for all components of the software tool set. Providing alternate user interfaces for different skill levels is an option as is providing complete and thorough user documentation. 10. Decision Support Decision support capabilities help guide the decision maker based on engineering and scientific investigations. Recommender systems function as an automated reasoning assistant, guiding user decisions based on calculated 15

16 data, previous inferences, and user preferences. These types of systems can also guide the user from a high level description of the problem through the necessary steps to solve the problem under investigation. B. Computing Hardware The DaVinci vision includes running the various software suites on anything from simple hardware (like a personal notebook) to high performance computing facilities (like the DSRC DoD Shared Resource Center hardware resources). This spectrum also includes networks of workstations, compute grids (including the global information grid GIG), and open environments similar to the Internet. These varying hardware resources, and the likely vast range of operating systems present, motivate the use of a run time environment as the primary platform for implementation. While other platform types are possible, run time environments have proven themselves many times as quite capable of cross platform and cross operating system operations without the hastle of recompiling for each of these alternatives. V. Conclusions and Future Work Several topics relevant to current efforts on the DaVinci CREATE-AV CBE software product for conceptual design have been discussed in some detail. DaVinci is part of the CREATE-AV (Air Vehicles) project, which in turn is part of the CREATE (Computational Research and Engineering for Acquisition Tools and Environments) program. DaVinci is tasked with addressing the conceptual design, design environments, and to a lesser extent, the design verification capability gaps in current practice today. Ultimately, DaVinci exists to help bring more high performance computing smartly to early phases of DoD acquisition. At a minimum, DaVinci must enable the use of HPC in early phase DoD acquisition by providing multi-disciplinary, multi-fidelity, computationally based systems engineering design tool sets; must rapidly produce high quality parametric associative meshable geometry & system models for design space exploration to support decision making; must enable model propagation to preliminary/detailed design (Kestrel and Helios for example); and must enable the user to perform: model development, model execution, model storage and retrieval, and model information extraction. DaVinci is in the concept exploration and demonstration phase of a three phase, ten year effort. Much still remains to be done, including final decisions on software architecture, middleware stacks, data structures, supporting persistence mechanisms, and a host of other concerns. The vision is clear that this kind of tool is needed to remain competitive in an ever tightening margin with other aerospace system conceptual design organizations. References 1 Roth, G. L., Decision Making in Systems Engineering: The Foundation, 2007 International Symposium on Collaborative Technologies and Systems, Tribus, M., Rational Descriptions, Decisions, and Designs, Pergamon Press, Inc., Post, D. E. and CREATE Team, A new DoD initiative: the Computational Research and Engineering Acquisition Tools and Environments (CREATE) program, SciDAC Oberkampf, W. & Trucano, T., Verification and Validation in Computational Fluid Mechanics, Progress in Aerospace Studies, 38, , Post, D.E., & Votta, L.G., Computational Science Demands a New Paradigm, Physics Today, 58, 35-41, Mukhopadhyay, V., A Conceptual Aerospace Vehicle Structural System Modeling, Analysis, and Design Process, Griffin, M. D., and French, J. R., Space Vehicle Design, 2 nd ed., AIAA Publication, Reston, VA, Roskam, J., Airplane Design, The DAR Corporation, Lawrence, Kansas, Aerospace Design Engineer s Guide, 5 th edition, AIAA Publications, Reston, Virginia, September Raymer, D., Aircraft Design, A Conceptual Approach, 3 rd ed, Przemieniecki, J. S. (ed.), AIAA Educational Series, Reston, VA, McCullers, A., Flight Optimization Systems Software (FLOPS) Release 5.91 User s Guide, NASA TM Ardema, M., Chambers M., Patron, A. Hahn, A., Miura, H., and Moore, M., Analytical Fuselage and Wing Weight Estimation of Transport Aircraft, NASA TM , May Rocha, H., Li, W., and Hahn, A., Principal Component Regression for Fitting Wing Weight Data of Subsonic Transports, Journal of Aircraft, Vol. 43, No. 6, Nov-Dec, 2006, pp Nickol, C. L., Guynn, M. D., Kohout, L. L., Ozoroski, T. L., High Altitude Long Endurance Air Vehicle Analysis Alternatives and Technology Requirements Development, AIAA Paper Conceptual Design of UAV Systems, University of Kansas Course Publication No. AA51530, Liebeck, R. H., Page, M. A., and Rawdon, B. K., Blended-Wing-Body Subsonic Commercial Transport, AIAA Paper Liebeck, R. H., Design of the Blended-Wing-Body Subsonic Transport, AIAA Paper

17 18 Lu, Z., "Data Management in an Object-Oriented Distributed Aircraft Conceptual Design Environment, Doctor of Philosophy Thesis, School of Aerospace Engineering, Georgia Institute of Technology, May Anderson, J.D., Aircraft Performance and Design, The McGraw-Hill Companies Inc., Torenbeek, E., Synthesis of Subsonic Airplane Design: An Introduction to the Preliminary Design of Subsonic General Aviation and Transport Aircraft, with Emphasis on Layout, Aerodynamic Design, Propulsion and Performance, Netherlands: Delft University Press, Aircraft Design Process Wikipedia article retrieved on 2009, Nov 23, 22 Livingston, J., XRE Conceptual Design Overview Briefing, 14 January Roth, G. L., CREATE-AV DaVinci Program Management Review Briefing, 15 December Robinson, J. S. and Martin, J. G., An Overview of NASA s Integrated Design and Engineering Analysis (IDEA) Environment, Joint Army-Navy-NASA-Air Force (JANNAF) 6 th Modeling and Simulation / 4 th Liquid Propulsion / 3 rd Spacecraft Propulsion Joint Subcommittee Meeting, Orlando, FL, December 8-12, Meakin, R. L., Computationally Based Engineering for Air Vehicle Acquisition: The CREATE-AV Project, Parallel CFD 2009, 21 st International Conference on Parallel Computational Fluid Dynamics, Moffett Field, California, USA, May 18-22, Advanced Engineering Environments (Phase 1): Achieving the Vision, National Academy of Engineering and National Research Council, Advanced Engineering Environments (Phase 2): Design in the New Millennium, National Academy of Engineering and National Research Council, Hale, M. A., Craig, J. I., and Mistree, F., DREAMS and IMAGE: A Model and Computer Implementation for Concurrent, Life-Cycle Design of Complex Systems, Concurrent Engineering: Research and Applications, June (2): p Hurwitz, M., Information Integration via Navy LEAPS in Enabling the 21st Century Acquisition Enterprise, 3rd Simulation Based Acquisition Conference, Binder, M., Numerical Propulsion System Simulation Introduction Multimedia CD, Washington, DC, Zweber J. V., Kabis, H., Follett, W. W., and Ramabadran, N., Towards an Integrated Modeling Environment for Hypersonic Vehicle Design and Synthesis, AIAA , September Monell, D., Mathias, D., Reuther, J., and Garn, M., Multi-Disciplinary Analysis for Future Launch Systems Using NASA s Advanced Engineering Environment (AEE), AIAA , June Mukhopadhyay, V., Hsu, S-Y, Mason, B. H., Hicks, M. D., Jones, W. T., Sleight, D. W., Chu, J., Spangler, J. L., Kamhawi, H., and Dahl, J. L., "Adaptive Modeling, Engineering Analysis and Design of Advanced Aerospace Vehicles," AIAA Paper Bowcutt, K. G., Kuruvila, G., Grandine, T. A., and Cramer, E. J., Advancements in Multidisciplinary Design Optimization Applied to Hypersonic Vehicles to Achieve Closure, AIAA , April Roth, G. L., Computationally Based Engineering for Air Vehicle Acquisition: Conceptual Design, Parallel CFD 2009, 21 st International Conference on Parallel Computational Fluid Dynamics, Moffett Field, California, USA, May 18-22, Hunten, K., McCulley, C., De La Garza, A., and Blair, M., The Application of the MISTC Framework to Structural Design Optimization, presented at the 46th AIAA/ASME/ ASCE/AHS/ASC Structures, Structural Dynamics and Materials Conference, Austin TX, April Blair, M., AVEC: A Computational Design Framework for Conceptual Innovations," 47th AIAA/ASME/ASCE/AHS Structures, Structural Dynamics and Materials Conference, Newport RI, May 2006, AIAA , Automatic Differentiation web site visited on 2009, Dec 03, 39 Watson, L. T., Lohani, V. K., Kibler, D. F., Dymond, R. L., Ramakrishnan, N., Shaffer, C. A., Integrated Computing Environments for Watershed Management, Journal of Computing in Civil Engineering, October 2002, pp Rice, J. R., and Boisvert, R. F., From Scientific Software Libraries to Problem-Solving Environments, IEEE Comput. Sci. Eng. 3(3), 1996, pp