(DRAFT)

DEFINITION OF REQUIREMENTS FOR AN AERONAUTICS AFFORDABLE SYSTEMS OPTIMIZATION PROCESS

(Revision 1)

Submitted to

NASA LANGLEY RESEARCH CENTER

By

Syracuse University

and

MADIC Team 2

Multidisciplinary Analysis and Design Industrial Consortium

Dec. 15, 1995


TABLE OF CONTENTS

Page No.

1. EXECUTIVE SUMMARY 3

2. OVERVIEW OF ASOP 5

2.1 ASOP Addresses a National Aerospace Challenge 5

2.2 ASOP Process Overview 8

2.2.1 Quality Function Deployment System Decomposition 9

2.2.2 Capture Life Cycle Cost 10

2.2.3 Multidisciplinary Design Optimization 11

2.2.4 Statistical Process Control 13

2.2.5 ASOP as a Distributed Multi-Company Effort 14

3. NII SCENARIOS 16

4. APPLICATION VIGNETTES 20

4.1 Vignette #1 Designing an Advanced Trainer 20

4.2 Vignette #2 Designing an Aircraft Engine Disk 25

4.2.1 Current Process 26

4.2.2 Improved Process Using ASOP 27

5. REQUIREMENTS DEFINITION 29

5.1 Concurrent Engineering Framework 30

5.1.1 Overview 30

5.1.2 Subsystem Requirements 34

5.2 System Infrastructure 48

5.2.1 Possible Implementations 49

5.2.2 Requirements on NII for ASOP Implementation 50

5.2.3 Requirements on Users of NII Implementation of ASOP 53

6. SUPPORTING TECHNOLOGIES 55

6.1 Numerical Propulsion System Simulation (NPSS) 55

6.2 The Framework For Interdisciplinary Design Optimization (FIDO) 58

6.3 Current Aircraft Simulation-Based Design Process 59

6.3.1 Physical Disciplines 61

6.3.2 Process Disciplines 72

6.3.3 Simulation Codes and Tools 72

APPENDICES 81


1 EXECUTIVE SUMMARY

Syracuse University in conjunction with the Multidisciplinary Analysis and Design Industrial Consortium (MADIC) is conducting a program to define the requirements for, and assess the current capabilities and future resources needed to support, the implementation of a nationally-distributed, multi-agency, multi-company, software framework for Integrated Product and Process Development (IPPD) on the National Information Infrastructure (NII) for use by the aeronautics industry. The framework envisioned will enable the implementation of an Affordable Systems Optimization Process (ASOP) which can be used by the Aerospace industry to simultaneously design product requirements, the product, and the associated manufacturing and support processes through the conceptual, preliminary and detailed design levels. Implementation of ASOP will result in a more competitive Aeronautics Industry by providing the capability to deliver quality, affordable, products to a global marketplace ahead of the competition. Such a capability is required if the industry goals of a 25% reduction in the sales price of commercial aircraft and a 25% to 40% reduction in the life cycle cost (LCC) for military aircraft are to be met, in addition to performance improvements.

ASOP is a process that achieves (1) the virtual co-location of multi-enterprise design teams enabled with full support of computing and data resources, (2) a computer generated synthetic environment for integrated product definition, and (3) a Multidisciplinary Design Optimization (MDO) process. The ASOP envisioned is a quantitative implementation of IPPD utilizing Quality Function Deployment (QFD), MDO, Taguchi methods and Statistical Process Control (SPC) to simultaneously design requirements, product, manufacturing and support processes at the conceptual, preliminary, and detailed design levels. ASOP can be used to minimize product life cycle cost for a given product utility or to maximize product utility for a given cost.

Teaming of industry, Government and academic organizations is becoming more essential in the creation of the best products at an acceptable developmental risk. An aeronautics ASOP implemented on the rapidly evolving NII offers the possibility of enhancing these teaming arrangements in the near future. High speed (>= 1 to 10 megabit/sec) links to every office can be expected. These NII "off-ramps" will link "clients" to a set of servers which will dispense text, video, audio and image (i.e. multimedia) information. Further

they will offer simulation, and database storage services as well as compute-intensive value added searches of the multimedia databases. All of these capabilities will greatly increase the possibility of a successful ASOP implementation providing that the specific requirements that ASOP places on the NII are well articulated to the NII developers.

The NII will be supported by a suite of software which can be termed Web (software) technology. This software suite, which is currently under intense development, will include (descendants of) the current World Wide Web technology such as Mosaic and Netscape servers and browsers. Implementation of ASOP will require that this software suite is effectively utilized.

Under the current effort, a combined industry and university team, with members including Rockwell International, Northrop Grumman, McDonnell Douglas, General Electric, General Motors, NPAC at Syracuse University, and Georgia Institute of Technology is considering the requirements that implementation of ASOP places on the NII. In addition requirements are being identified for an ASOP software framework, which interfaces with legacy systems within the aeronautics industry as well as utilizes the capabilities of the NII to the greatest extent. These team members are also soliciting input on ASOP requirements from the other aerospace companies, as well as participants from the Government, vendor, and university communities involved in developing the requisite technologies.

To assist all the participants in the requirements definition effort, two application vignettes were developed representing potential realistic applications of an ASOP in joint aeronautics product development programs. In the first vignette a new air vehicle is being designed. The goal is to develop a trainer for the primary trainer market. The example application describes a product development scenario starting with conceptual design and proceeding through the detailed design of the wing. The process of design trades involved in optimizing wing performance, maximizing aileron control power, and minimizing Life Cycle Cost in manufacturing and support are illustrated. The second vignette involves the design of a new aircraft engine disk. The interplay between the functional considerations and the manufacturing considerations are illustrated. The more effective LCC-focused multidisciplinary design optimization approach represented by ASOP is contrasted to the present day serial approaches.

A "first cut" set of requirements for ASOP and its implementation on the NII are defined with reference to these vignettes. Regarding the requirements for the NII, the results of a questionnaire circulated to potential users indicate: 1) the goal, from the ASOP users point of view, is to make the service widely available and essentially transparent; "like the telephone", 2) The workflow and configuration management services are critical to ASOP implementation and use and may be appropriate NII services 3) Security is expected to be an ongoing issue. The use of open, NII resources for highly secured projects will require reliable, available and trusted security environments on the NII. Regarding the software framework for implementing ASOP, an architecture for the required integrated design environments has been defined consisting of a Design Engine, Visualization Toolkit, Optimization Engine, Simulation Engine, Process Modeling Toolkit, Cost Modeling Toolkit, Analysis Modeling Toolkit, and Geometry Representation Toolkit. These modules are integrated through an Object Backplane and can communicate with one another through message passing. In addition, the system will interface to the NII, and provide a Graphical User Interface (GUI) which can serve as a front end. Examples of available technology that can support the implementation of the ASOP concept are presented. A system for cataloging the simulation codes needed for aeronautics product design is demonstrated. Both physical simulation codes/tools (e.g. for structures, aero, controls) and process simulation codes ( e.g. for manufacturing, product support) are considered.

2 OVERVIEW OF ASOP

2.1 ASOP Addresses a National Aerospace Challenge

The goal of reducing the life cycle cost of aircraft, while simutaneously improving performance, has assumed major importance. Cost is now a primary metric in the planning and completion of technology efforts within the government, the university and the industrial sectors of the aerospace community. Goals, such as "25% cost reduction in commercial aircraft sales price" for commercial aircraft , and "25% to 40% reduction in the life cycle cost (LCC)" for military aircraft are now accepted as necessary for the long term business health of the aerospace industry.

Highlighted in Fig. 2.1-1 are results of recent preliminary planning by the Department of Defense, DDR&E. These priorities were developed by consensus between the USAF, USN, ARPA, and NASA and the five major aircraft companies (Boeing, Lockheed Martin, McDonnell Douglas, Northrop Grumman, and Rockwell). Note that three of the five major fixed-wing aircraft have a priority goal of reducing LCC (Design + Production + Support costs). The other two aircraft families, the Special Operations Forces (SOF) and the Fast Response/Global (FR/GLOBAL), consider "cost" as a subordinant goal to performance due to the special mission features and the small number of aircraft to be purchased.

Click here for Picture

Figure 2.1-1 The Fixed-Wing Technology Development Approach of DDR&E Recognizes Reduced Life Cycle Cost as a Priority Technological Effort in Three of Five Aircraft Families

An examination of the origin of LCC shows it to be dominated by costs accrued in manufacturing production and logistics support. In each ot these two areas, the three dominant items are those associated with the engine, subsystems and software, and the structure as portrayed conceptually in Figure 2.1-2. Other costs, although significant in total, do not offer the large opportunity for LCC reductions stated in the goals for the aerospace industry. In essence, the achievement of the "goal" requires the equivalent of "throwing the structure away" and never performing "major structural improvements" over the useful life of the aircraft! This cost challenge requires a new look at how the cost is created during the "non-recurring" design and development of the aircraft, even though it may represent the smallest portion of the LCC.

Click here for Picture Figure 2.1-2. Life Cycle Cost Reduction Must Focus on the Decisions and Conclusions During the Non-Recurring Portion to Greatly Influence Production and Support Costs for the Engine, Subsystems and Software, and Structure

The design and development of aircraft, the non-recurring portion of LCC, involves the synergistic blending of engineering, manufacturing, and logistics support functions - often described as the Integrated Product and Proccess Development (IPPD). The intent is to logically and efficiently achieve the best performing, lowest risk, and lowest cost aircraft meeting the customers requirements. These requirements are stated formally in the customer's documents, and also "derived" during the design and development of the aircraft. The design and development of the engine, subsystems and software, and structures are the dominant non-recurring cost efforts; however, their requirements are strongly driven by the needs and objectives expressed by systems engineering, flight mechanics, and dynamics and control.

The cost and performance goals for future aircraft of the "Transport Airlift/Patrol" family of fixed-wing aircraft determined by the DDR&E study are shown in Fig. 2.1-3. These preliminary data, baselined against the C-17 and P-3, emphasize that substantial cost reduction must occur in concert with performance improvement in the next 15 years. For instance, a 20 % weight reduction, combined with a 10% increase in cruise Lift-to-Drag (L/D) and 20% reduction in support costs, are postulated as possible to achieve by the year 2000. Once asserted as possible, these goals represent a design "optimization" challenge worthy of intense technology activity in all aspects of IPPD.

Click here for Picture

Figure 2.1-3. The Industry and Government Consensus for Cost and and Performance Improvement Goals for Large Aircraft Requires Robust and Balance "Optimized" Design in an IPPD Environment

The "minimization" or "maximization" of technical and program objectives requires a systematic expansion of the existing processes employed in engineering design and development, manufacturing, assembly, and checkout, and logistics support. The elements of this expansion must include:

· Capturing the correct requirements,

· Representing all the significant cost and performance relationships of designing, developing, manufacturing, and supporting the aircraft,

· "Optimizing" the aircraft products in an efficient and robust manner, and

· Measuring results, whether simulation or actual, from the customer's operational utility viewpoint.

The customer's satisfaction and successful operation of the aircraft products are the most meaningful metrics to guide the "optimization" within the IPPD framework. The development of an "Affordable Systems Optimization Process (ASOP)" to achieve customer satisfaction and aircraft product feasibility is clearly required.

2.2 ASOP Process Overview

The overall approach for the Affordable Systems Optimization Process (ASOP) is depicted in Fig. 2.2-1.

Click here for Picture

Figure 2.2-1 An Approach to Developing Quality Affordable Products

The customer needs and system affordability drive ASOP. Quality Function Deployment (QFD) methodology is used to flowdown customer needs and to decompose the system into its subelements for MDO (Multidisciplinary Design Optimization). QFD also identifies the most important relationships between customer needs, operational requirements, design, manufacturing and support processes, and cost. Sensitivities are calculated for these key interactions, and MDO is performed to select the combination of system and process parameters which provide a maximum level of system utility relative to the customer's desires within stated constraints, including cost. Taguchi methods are used to insure the robustness of the product and processes,i.e., will the system perform acceptably given variances in its production and support processes. If not, the optimization process can be revisited to investigate alternate approaches or constraints using information obtained by Taguchi experiments. The final part of ASOP is the use of Statistical Process Control (SPC) to continuously improve the product through process improvements once production and system operation has begun. An important goal of ASOP is to "simulate" the outcome of SPC early in the design and development process to control LCC.

Several iteration loops are inherent in the ASOP approach shown in Fig. 2.2-1. Their specific purposes are:

1. Capturing changes to external requirements initiated by the customer or by new design and development knowledge. These changes must be in the context of balancing risk (cost, schedule, performance, reliability, and technology) against the customer's operational utility.

2. Modifying the aircraft product concepts in response to design information tested against "fixed" requirements.

3. Reiterating the "optimized" aircraft products, if robustness to uncertainty is not accomplished.

The iterations ensure that the aircraft products meet the customer's expectations, satisfy the operational utility requirements, and remain feasible to develop, manufacture, and support.

2.2.1 Quality Function Deployment System Decomposition

Click here for Picture Figure 2.2.1-1. Houses of QualityAre Used to Deploy the "Customer's Voice" to the Appropriate Disciplines

Quality Function Deployment (QFD) techniques, in particular, the House of Quality (HoQ), not only flowdown customer needs, but also provides a link throughout the process by decomposing the system and processes into subelements. QFD also identifies the key interactions between variables, subcomponents, disciplines, and processes. During MDO, this information may be used to determine the sensitivity data required. Qualitatively, QFD can provide insight into the relationship between system utility and cost. As depicted in Fig. 2.2.1-1, an orderly path can be built between the utility of the system and its resultant costs.

A series of houses are built to represent the flowdown of customer needs. In the first house, the customer's most important needs are reflected in statements of utility for the system. The design/function requirements, listed along the top of the first house, represent potential means of achieving the desired utility. A relationship matrix is completed between the "whats" (utility components) and the "hows" (design/function requirements) representing the strength of the relationship between the two. In addition to these relationships, the HoQ tool also permits consideration of importance weighting for the various customer utility measures, competitive assessments, and a conflict matrix which highlights inconsistencies between various requirements. These selected requirements variables, the "hows" of the first house, become the "whats" of the second house and are listed along its left side. In a similar HoQ process as described above, strength of relationships are drawn between the design/function requirements and the parts, features,and subsystems which potentially could satisfy them.

This process continues through the successive houses shown in Figure 2.2.1-1 and ultimately provides a direct link between customer needs and system cost, through the requirements, product design, manufacturing and support process variables. This approach not only provides the traceability necessary to perform the requisite utility versus cost tradeoffs, but it also decomposes the system and processes into their subelements and highlights the most critical relationships, eliminating lower level considerations. This is key to keeping the method at anappropriate level of detail for conceptual design.

2.2.2 Capture of Life Cycle Cost

Life cycle cost (LCC), expressed in a performance context, requires ASOP to represent, analyze, and simulate processes driven by evolving requirements in design, manufacturing, and operations and support. These processes are inter-related as implied by Fig. 2.2-1. For example, the design of a wing must simultaneously satisfy flight mechanics range, dynamics and control flying qualities, structural strength and durability, subsystem volumes, manufacturing and assembly reality, and efficient logistics support. This means that the representations will necessarily incorporate knowledge based design data bases with algebraic, ordinary differential, partial differential, and delayed difference equations.

The capture of Life Cycle Costs occurs in several steps, leading to the ASOP software topology to be discussed in Section 5.1:

· Definition of the design process to be followed - a Design Engine Process Controller.

· Visualization of the input and output data during design - a Graphical Interface.

· "Optimization" of a process - an Optimization Engine

· Simulation of the multidisciplinary, multi-fidelity " LCC processes - a Simulation Engine.

· Representation of manufacturing and support processes - a Process Modelling Toolkit.

· Determination of cost relationships to products - a Cost Modelling Toolkit.

· Representation of possible outcomes from complex processes - an Analysis Modeling Toolkit.

· Documentation of physical features of the products - a Geometry Toolkit.

2.2.3 Multidisciplinary Design Optimization

"Optimization" formally evolves from the calculus of variations, and includes an index of performance, equality and inequality constraint equations, adjunct equations, transversality conditions, and tests for local extrema. Numerical considerations have led to a large number of solution procedures dealing with unique aspects of the mathematics of "optimizing" a field of numbers characterized as continuous, discrete and mixed in nature. Section 5.1 will discuss these important details. The physics and project management aspects of "optimization" will be discussed in this overview. Specifically:

· What optimization means in an aerospace ASOP.

· What the role of first and second derivatives is for a process that can be modelled by equations with defined continuous first and second derivatives.

· What may be done to reduce the large numbers of design variables spread over a large number of aircraft design points.

· Why knowing uncertainty is important.

· Why robustness is key to closing the design against changing and uncertain requirements

Optimization: "Optimization" in the context of ASOP means the aircraft product concepts have been created, analyzed, and simulated to demonstrate they will be the "best" solutions to meet the stated and derived requirements of the customer. The products - aircraft, tooling, logistics support structure, training system, and other items - meet all the important operational utility metrics, guaranteeing a mission will be successfully accomplished. Included in this definition are the formal mathematical minimization or maximization of aircraft metrics such as minimum weight with maximum controllability, minimal cost durable tooling, minimum time assembly and checkout of the aircraft, minimal cost to repair structure and systems, and maximum training effectiveness of simulations and documents. It is clear that the unifying metric is cost, as most other metrics may be converted or parameterized using cost as the supreme metric.

First and Second Derivatives: The role of first and second derivatives of a mathematically defined process are important whenever they exist. The ASOP multidisciplinary design optimization (MDO) analytical process is based on a Taylor series expansion about a baseline. The baseline may be assumed or derived from previous activities. After establishing a baseline, sensitivities about the baseline are developed. For instance, in the method developed by Sobieski, the local sensitivities calculated may be used in a set of simultaneous equations defined by the chain rule and solved for global sensitivities. These global sensitivities are may then be used in the Taylor series expansion to estimate the utility function, constraints, and other quantities during the optimization process. Once the optimizer finds a local optimum, it may be used as the next baseline. The system is reoptimized using new sensitivities until the desired utility and cost are obtained. A full analysis of the solution may be analyzed or simulated and compared to the optimized values. If the comparison is poor, second-order sensitivities may be used to capture the non-linear effects, or limits may be decreased to stay within the linear range.

Reduction in Design Variables and Conditions: The representation of important design, development, manufacturing, and logistics support processes is easily and routinely overcome by the large dimensionality of the problem. Computation of sensitivities (by derivatives or logic based data bases) identifies where significant dependancies are present, and where variables appear to be independent. The design of experiments (analytical or experimental) identifies the minimal number of events necessary to portray a solution.

Taguchi identifies three stages of product/process design as: System Design,Parameter Design, and Tolerance Design. System Design is the stage where the product is configured to satisfy the customer's needs. This stage involves invention and innovation, and it is equivalent to the MDO stage of ASOP. At this point, MDO has determined an optimum. Due to the fact that MDO deals with controllable factors only, the optimum achieved may not be a robust design. A control factor for a particular product or process is one that affects the output and is easy and/or cheap to control. This is the point where the Parameter Design stage is used. Parameter Design is the stage involving optimization of an existing design or process. Here, parameter levels are chosen to improve quality, reduce cost, and make the existing design or process robust against uncontrollable variation. In order to be robust, the design cannot be significantly affected by noise (uncontrollable) factors in the product design, and the manufacturing and the logistics support processes. A noise factor is one that affects the output, but is uncontrollable or expensive to control. In order to insure robustness, Design of Experiments (DOE) methods developed by Taguchi need to be incorporated into the process. The main tool used in DOE is an orthogonal array which is a matrix that defines a designed experiment. The rows of this matrix correspond to the individual tests that make up the experiment, and the columns specify the factors or interactions included and their settings for each individual test. Each column is balanced against all others. These experiments are usually physical, but with the right simulation tools they may be performed computationally.

Uncertainty in Design: Determining and parameterizing a product's uncertainty is important to (1) focus the IPPD effort to determine the risk (cost, schedule, performance, reliability, technology), and (2) to design experiments to minimize the risk. Rational "optimization" of a product recognizes that the most important risk issues must be continually addressed and reduced to "low risk". This achieves products that fit within the customer's reasonable expectations, and within the customer's ability to successfully adjust expectations without loosing operational utility. The risk information offered the customer is the most effective way to evolve requirements and products successfully.

In Design of Experiment (DOE), controllable factors and noise factors are first identified. This information may be available from the QFD results. The discovery of interactions between controllable factors and noise factors is one of the keys to achieving an affordable design. The product and process factors are determined to minimize the effect of noise factors while maximizing the product's functional utility. Information produced by these experiments may be used in the subsequent optimization cycles to improve robustness.

Robustness: The determination of the product's robustness is important to ensure it remains a viable solution to missions problems presently unspecified, or to avoid "unknown unknowns" discovered during test, manufacturing, and operational support. A truely "optimal" product may or may not be robust. If not robust, a reasonable uncertainty may drastically reduce the product's ability to meet the operational utility expectations of the customer. The first and second derivatives of mathematical representations, and the "experience" in knowledge bases, measure the robustness relative to the product or a related product family.

2.2.4 Statistical Process Control

The final stage, Tolerance Design, is the fine-tuning stage of any process. It will be accomplished within ASOP by using Statistical Process Control (SPC) methods. These methods predict or measure the variation of product features from the nominal feature value needed to satisfy the customer's expectations.

Early Design Phase: Early in the design process embodied in IPPD, a representation of the expected variations in LCC must be determined to refocus a particular design on cost reduction in the manufacturing and logistics support phases. The ability to represent these statistical variations is accomplished in the ASOP simulation engine, the process modelling toolkit, and the analysis modelling toolkit. The intent of the non-recurring cost activities of design and development, and product "optimization", is to predict and control variation from goals such as reduced LCC of 25%.

Manufacturing and Support Phases: Once the product and processes have been designed and the production has begun, quality is maintained or improved by using Statistical Process Control (SPC). An explanation of the nature of variation in product may be found in the Rockwell publication 2502-N-5, "The X-R Chart for Statistical Control of Manufacturing Processes."

Variations in measured product are always present because of random fluctuations and inconsistencies in machines, material, and operator performance. No two items produced are exactly alike.

When variation is random and stable, the process is in a state of statistical control. The process has an identity, and its performance is predictable. The stable pattern of variation is caused by conditions that are inherent to the manufacturing system, such as spindle runout, bearing clearances, differences in material properties, accuracy of measuring equipment, and operator performance. We call this "common cause" variation.

When variation is sporadic and unstable, the process is out of statistical control. The process loses its identity and is no longer predictable. The unstable pattern is caused by such events as tool breakage, tool wear, bad materials, and operator error. This is called "special cause" variation.

The tools of SPC monitor the processes in order to determine if the process is in a state of statistical control. When the process is determined to be out of statistical control, these tools are used to determine the cause of the sporadic variation which is then corrected to maintain/improve the quality of the product.

The use of SPC is an on-going process during the life of the production line and the product. It is key to measuring the LCC mean of manufacturing and support processes. The representation of SPC measurements must be included as part of design to effectively reduce Life Cycle Cost.

2.2.5 ASOP as a Distributed, Multi-company Effort

Aerospace teaming - of industrial companies, academic organizations, and government organizations - is often essential to create the best products and to reduce the developmental risk. This reality means that the ASOP process and software must be implemented from a common viewpoint, recognizing that the present design software of the individual team members will remain proprietary. Figure 2.2.5-1 recognizes the distributed proprietary nature and postulates that the National Information Infrastructure (NII) will be key to accomplishing the ASOP goals.

Click here for Picture

Figure 2.2.5-1 Implementation of ASOP in a Distributed Multi-Functional Manner Requires the National Information Infrastructure to Manage Data Transfer

The rapid evolution of the NII must recognize that an Aerospace ASOP will be essential for the design, manufacture, and support of commercial and military aircraft. Aircraft and engine test cases will provide insight to determining and illustrating the ASOP requirements to the computer science and communications industry, primary developers of the NII.

The concept of distributed multi-company, multi-functional design has been demonstrated in several Government and commercial aerospace ventures in the last five years. The National Aerospace Plane (NASP or X-30) linked five companies (General Dynamics, McDonnell Douglas, North American Aircraft, Pratt & Whitney and Rocketdyne) and several USAF and NASA sites using the Rockwell CONSORT network. CONSORT was also used on two international programs, the X-31 and the Ranger 2000. The Boeing 777 "supplier network", linked to the Rockwell CONSORT network, guides aircraft structure from design drawing data bases to machines on the manufacturing floor. The cost savings of "virtual design and manufacturing" over a single co-located team are enormous, while encouraging low risk by doing the "best work" using the "best team" at the "best supporting location".

ASOP adds a paradigm shift. The design for life cycle cost, in addition to the design for performance must be accomplished in a multi-company, multi-functional, distributed manner.

3 NII SCENARIOS

The National Information Infrastructure (NII) has both hardware (computer and network infrastructure) and software implications. The following features can be expected:

· High speed (>= 1 to 10 megabit/sec) links to "every" home and office. These NII "off-ramps" will link "clients" to a set of servers which will dispense text, video, audio and image (i.e. multimedia) information. Further they will offer simulation, and database storage services as well as compute-intensive value added searches of the multimedia databases. The networks will use Asynchronous Transmission Mode (ATM) on optical fiber and other technologies. The servers will include large parallel computers for both simulation and information applications. The clients will include workstations, personal computers and TV's connected to smart set-top boxes.

· The NII will be supported by a suite of software which can be termed Web (software) technology. This is currently under intense development but will include (descendents of) the current World Wide Web technology such as Mosaic and Netscape servers and browsers.

· The NII will be built recursively as a hierarchical set of enterprise systems with larger and larger enterprises. Thus a set of village and city networks(webs) link to form a county network; a set of county networks to a state; a set of state webs to a country; and a set of country networks to the full World Wide Web (WWW). Correspondingly a potential virtual corporation formed from the several organizations using ASOP, for example, to produce a new aircraft is part of the World Wide Web but also can be broken down into individual company webs; then to site webs within companies and further on into the networks integrating smaller subunits.

The "Web Software" in (2) can be used to implement both the WWW and any sub-network such as either a single site of a single corporation or more completely the full network linking all people and resources involved in the construction of a new ASOP implemented aircraft. A Web technology network can communicate with all or selected external Web sites for either outgoing and/or incoming traffic.

Several different scenarios can be considered for an ASOP enterprise. In all cases, as described above, offices can be expected to be connected to a reasonably high performance "open" physical infrastructure (the open NII) supporting real-time video delivery at VHS to HDTV resolution and other services mentioned in (1). The Web software will offer some nontrivial security as both defense and commerce applications are spurring great activity in this area. Note that DoD expects to use commercial infrastructure (the open NII) in military operations -- this is the Global Grid concept where open infrastructure is supplemented by limited theater specific infrastructure as necessary.

So two extreme scenarios for our ASOP enterprise network are:

1. Full use of Web Software internal and external to companies. In this case the "open NII" is used for communication both between major participating companies and the many smaller suppliers. Naturally the physical infrastructure internal to a site is proprietary but open Web Software is used through-out. Web "wrappers" (interfaces) would be used to link "legacy/conventional" (non-Web) systems tothe Web.

2. Totally proprietary software and dedicated links are used both internal to and for linkage between participating companies and suppliers.

Bandwidth, quality of service and security decisions may affect hardware infrastructure choices. ATM has quality of service built in (to guarantee bandwidth and latency) but current primitive network management software does not properly support this. Further immaturity (unreliability), lack of functionality and security issues may negate use of Web Software. We can construct several intermediate choices such as:

· Full use of Web software with use of dedicated proprietary links between major companies but with open NII networks used to communicate with the many smaller suppliers.

· The open NII and Web software used to communicate between corporations but ASOP performed on (existing) conventional hardware and software within individual corporations.

The different scenarios imply different constraints on the companies and their information technology support organizations. It would be important to discover what approaches would be adopted by the aerospace industry. The full use of the Web requires networking and compute configurations which may not be easy to deploy. Note the use of "wrappers" does allow an evolution to the Web with legacy systems interfaced through the so-called Computer Graphics Interface (CGI) process to the Web.

Web tools that are under active development constitute a distributed system for data access and process control. Tools that reside with a Web server (or are accessible from it) can be programmed to carry out an enormous range of processes from refined database access and database update to executing simple shell scripts to running large-scale simulations. The web server tools also support almost total control over what is done with the output from the process; it can be formatted and sent to the initiator, or to a group of people; it can be used to initiate another process; it can be added to a database; and so forth. Tools on the client side will enable detailed examination and analysis of all data obtained through the Web, with the user customizing his/her local environment to automatically ingest return data into the application of choice. Finally, the latest tools under development, such as Java and HotJava, will create a level of parity between server and client, such that the "server" will be able to initiate a process on the "client" and the "client" will be able to return results to the "server" -- eg to be stored in a database on the server.

The system described is highly modularized and customizable and can be programmed to be, among others, a distributed command and control system. Existing command and control systems typically represent hundreds of thousands of lines of interlocked code and are extremely difficult to alter reliably. The Web Tool environment will support quick and easy prototyping of trial systems and will support high levels of interactivity-- both of a single user with the (accessible) applications that reside on network Web servers and with other users, and in particular with a group of users collaboratively working with a set of Web server applications.

A simple example is presented below, involving software engineer Glen working on a Unix workstation, which illustrates the potential use of the NII and its associated capabilities. Glen has the following open windows:

1. An interactive video conference window with design engineer Sharon, who is using one of Glen's simulation codes to run an aerodynamics simulation of airflow over a new wing design. Linked with this window is a monitoring window tool that exhibits a small realtime visualization of the simulation; the same window is visible on Sharon's screen. For some simulations, it is possible to modify parameters (such as airflow speed wing composition, ...) during a run, via the simulation window tool, and observe how behavior varies in different regions of parameter space. The two conferencing individuals are located at different branches of the same company, in different states. Other parties, which might include engineers, managers and government agency representatives might participate in such conferences.

2. An interactive code debugging window for another code that is underactive development; it links with another window where Glen edits the code. The edit-debug process takes place on a computer local to Glen's facility

3. A WebTool window that provides instant access to both recent and archived mail, with comprehensive search capabilities. The WebTool environment also provides support for composing email, customized by Glen to facilitate his frequent exchanges with a select group of collaborators and managers.

4. The WebTool Mail window can also bring up a WebTool window to a shared memo database (searchable by dates, senders or recipients, or content) that has individualized access control, and that may be distributed over several sites, yet appears to a user as a single database. The database may also link to multimedia documents, such as graphs, 3-D drawings, and video clips from key simulations, that can be accessed (by point and click) and brought into appropriate local applications for viewing and manipulation and/or analysis. When such a document is downloaded (point and click) it will automatically launch the viewer or tool Glen has specified in a simple local configuration file. The actual multimedia documents may reside in several locations on the network.

5. Icon for a window to an international materials database that incorporates data from NIST and from corresponding agencies in other countries as well as a large amount of validated data from private industries. This database is available through subscription only, as it is a commercial venture with substantial value added. A click on the icon brings up a window that requires an access password, and then provides flexible search for information.

6. Window that is a shared whiteboard. Glen uses it most commonly to interact with a colleague who works on similar codes at another location, to discuss coding issues where both can see and edit the same piece of code. He also uses it often to communicate with his group secretary about wording of memos and letters or with the company travel office about flight schedules and accomodations.

For a more complete discussion of the potential uses of the NII and high performance computers in industry see APPENDIX II (Pg. 101) which contains a copy of a recent paper on the subject authored by Geoffrey Fox and Wojtek Furmanski.

4 Application Vignettes

Development of requirements for the implementation of an Affordable Systems Optimization Process (ASOP) on the National Information Infrastructure (NII) requires knowledge of the potential applications for an ASOP across several organizations, multiple disciplines and product development stages.(ASOP, as used here, refers to a set of tools, processes and capabilities to perform affordable system optimization.) The vignettes defined below are believed to represent realistic applications of an ASOP in joint aeronautics product development programs and and are intended to provide the necessary aid in gathering requirements information. The vignettes are not the definitive statement of ASOP capabilities or application, as it is expected that many additional,unforeseen, uses for an ASOP will emerge as it is developed and applied.

The vignettes were prepared as a result of discussions during the NASA/MADIC Workshop held 22-23 May 1995 to develop a "first cut" set of requirements for implementation of an ASOP on the NII. The vignettes provide an overview of an aeronautics ASOP vision and describe a context for collecting ASOP requirements information. In particular, the vignettes are to help identify critical information and related requirements for the implementation of an aeronautics ASOP using the emerging NII capabilities or services. Infrastructure requirements associated with ASOP implementation within a company are addressed to begin to prepare for utilization among an aeronautics team.

The vignettes regard the ASOP users as designers, analysts, manufacturing experts and product support personnel from a broad range of disciplines and organizations. The customer is considered a key participant to enable a closer optimization of the vehicle requirements against the vehicle design and operation. For example, the customer may reduce the range required of the vehicle in order to substantially reduce vehicle support or manufacturing costs. The ASOP users are expected to be knowledgeable in optimization techniques and their associated technical disciplines. They are not expected to be experts in using the NII or underlying computer systems technologies required for ASOP. ASOP's system infrastructure is expected to be transparent to the user community.

The genesis for the vignettes were the sample demonstration ASOP applications discussed in the original ASOP proposal and summarized at the MADIC/NASA workshop. While the proposal focused on validating requirements using existing technology and capabilities the application vignettes are meant to elicit requirements for both near-term and longer range ASOP needs and their associated infrastructure.

4.1 Vignette #1 Designing an Aircraft Trainer

For this vignette a new air vehicle is being designed. The goal is to develop an advanced trainer for the primary trainer market (not meant as indicative of JPATS) which will be affordable; easier to manufacture and support; provide high quality performance; and meet short field take-off and landing criteria. The scenario starts at the conceptual design stage and includes manufacturing and deployment life cycle states information. Several diverse organizations are involved from the aerospace industry, government agencies and academic organizations. Multiple disciplines are involved to support design and development of this new trainer. This scenario starts in two years (1997) with initial operations for the new air vehicle four years (2001) after starting.

The scenario starts with two companies, located in different parts of the United States deciding to work together to develop an advanced product for the primary trainer market. A survey of potential customers was made and an initial set of needs/requirements were identified to scope the design effort.

The team is initiating a "clean sheet" design with several (2-3) members from each company. Their objective is to work together to rapidly establish a series of concepts for refinement by a larger set of designers. Performance, cost, support, and similar objectives are to be included in this very early design effort to help drive toward an affordable product. Each organization has a number (5-10) of different software applications which they typically use in an interfaced/integrated fashion to perform early concept design activities. These applications establish basic mold line geometry, layout major components, perform initial sizing, and aid analysis of performance to allow the designer to rapidly cycle through design concepts. New techniques to include more extensive manufacturing and supportability optimization in this design stage are required to meet ASOP's vehicle affordability goals.

At this stage the two teams would like to share concepts; use ASOP to optimize the initial concepts for affordability; and conduct frequent on-line conferences to review vehicle concepts. Sensitivity analysis would also be conducted on the requirements to help determine the "robustness" of the concept designs to changes in the program requirements - i.e. would small increases or decreases in the requirements result in a significantly different design concept.

As this stage progresses the teams will begin adding members (possibly from other companies) to perform additional analysis and optimization on a smaller number of concepts. This would include refinement of structural concepts; supportability; geometry layouts; and other performance measures. A larger variety of application programs will be used for these tasks. It will be very important that configuration control is maintained on the analyses to insure that these are performed against a common design using common assumptions. The teams will continue interacting frequently and will need to share and exchange analysis/optimization results often.

At this point the original two companies may add team members for major systems like propulsion; avionics; environmental control; etc. These new team members will access ASOP and begin sharing data across the entire team. This process will continue until one-two concepts are selected for more extensive preliminary design. During the preliminary design stage the number of people involved will increase to 100-200 and they will use a wide variety of analysis and optimization programs. Collaboration across team members and disciplines will be the expected mode of operation and exchange of data will be frequent among the various disciplines and ASOP users. Manufacturing and supportability will be much more involved in the design and optimization process during this stage.

Access to industry and supplier databases for materials, subsystem, standard parts and similar data will be needed to speed the selection and refinement of optimum components. Typically, by the end of this preliminary design phase, 70% of the cost of the air vehicle is locked-in so it is important that the end design be robust; has considered all factors; and has been optimized as an affordable solution.

After the team has established a robust, optimized preliminary design the detailed design process will be conducted. For example a wing subteam may be established to conduct detailed component design, development and assembly optimization. Detailed analyses and simulations will be conducted to prove that the design meets all criteria. Manufacturing, material procurement, and logistics support will all participate to complete the design and make sure it will meet performance goals.

Considering the wing design in more depth, it is assumed that the goal is to develop a composite wing, illustrated in Fig. 4.1-1 meeting MIL Std and FAR Part 23 requirements.

Click here for Picture

Figure 4.1-1. High Aspect Composite wing Provides Design Flexibility to Illustrate the Balance of Engineering, Manufacturing, and Support Against Changing Customer Requirements.

It is high aspect ratio, with a simple flap and a single aileron, constructed with multiple spars. It has internal fuel pumps and fuel guages near the root bulkhead A stress concentration exists on the upper skin, rear spar, and root bulkhead during maneuvering flight at high load factor. The skin, spar and bulkhead may be manufactured as a cocurred assembly, or as individual parts later assembled by bonding or fastening. A fuel guage access panel exists on the upper wing skin sufficient to perform an inspection at the rear spar-to-bulkhead, high stress joint. The inspection is done yearly for the 300 aircraft fleet.

The intent of the conceptual IPPD wing design is to determine the camber, twist, weight, center of gravity that are optimum for performance, maximize aileron control power, and minimize Life Cycle Cost (LCC) in manufacturing and logistics support.

The typical LCC trades against weight are partially illustrated in Fig. 4.1-2 for the four subcase design problems: an "optimal" engineering design without panel detail, an "optimal" design including manufacturing detail for the upper skin panel, assessment of "optimal" support through the upper skin access panel, and a change in design and manufacturing requirements to reduce support costs. A possible result is that weight will increase (degrading performance) as support costs and total LCC reduce.

Click here for Picture

Figure 4.1-2 Life Cycle Cost and Performance (Weight) must be "Optimized" to Conflicting Requirements in Aircraft Design

The design, development, manufacturing, and support for this wing is accomplished by a loosely federated grouping of diverse organizations following a well defined plan and under strict, mutually-defined, configuration control. An example of the IPPD plan for the wing demonstration example is shown in Figure 4.1-3. Here a three company team is `established' to manage the wing design problem. It is assumed company #1 is to manage the configuration data base for engineering, manufacturing, and support, and also control data base updates. Company #2 and #3 use the data base from company #1 and create the aerodynamic and structural data base with company #1. Company #2 is responsible for computing the areodynamic loads for the wing; company #3 is responsible for the structural sizing analysis. The manufacturing and support will be done by all companies.

Click here for Picture

Figure 4.1-3 Timeline for Designing, Developing, Manufacturing, and Supporting the Wing Demonstration Problem, Emphasizes the Importance of Data Base Management and Numerical and Verbal Communication

This wing problem represents a sub-scale version of communications and collaboration of a full aircraft project which may have participation by 100's of companies, thousands of personnel, over many local and regional computer networks, including several of the customers. In such projects, suppliers ,users (customers), and certifying authorities (FAA, etc.) will participate in the design activities to validate final requirements; optimize the design; and certify that appropriate analyses are completed. At the completion of the detailed design process the manufacturing and assembly activities are conducted to build and deliver the new affordable product, whether it be a wing or a full aircraft.

4. 2 Vignette #2 Designing an Aircraft Engine Disk

For this application a new aircraft engine disk is being designed. The design and manufacturing of aircraft engine disks is a complex process, requiring cross functional collaboration, as well as, close integration with third party suppliers. Intelligent design and manufacturing decisions require the use of accurate simulation tools to guide changes in the design and establish optimal processing parameters. Thus, there are generally several different types of analyses performed as part of the design process and typically one type of process simulation performed for each major manufacturing steps. Figure 4.2-1 shows the targeted disk design and manufacturing application.

Click here for Picture

Figure 4.2-1 Gas Turbine Disk Design and Manufacturing

The current six-step processes are summarized in the following Table in terms of required analysis, objective, and process owner.

   Process            Objectives            Analysis Type       Process Owner    
1)             * Meet Mission            Transient             Engine Company    
Mechanical     Requirements * Minimize   HeatTransfer                            
Design         Weight * Minimize Cost    Stress Frequency                        
2) Forging     * Near Net Shape *        Nonlinear,Elastic-p   ForgingVendor +   
               Minimize Forging          lastic                Engine Company    
               Operations * Formability                                          
3)Heat         * Requisite               Transient            Forging Vendor +   
Treatment      MaterialProperties *      HeatTransfer          Engine Company    
               Minimize Residual                                                 
               Stress * No Cracking                                              
4)Machining    * Minimize Distortion *   Elastic-plastic       Engine Company    
               Minimize Number of                                or  Vendor      
               Operations                                                        
5) Shot        * Desired Residual        Elastic-plastic       Engine Company    
Peening        Stress                                            or  Vendor      
6) Life        * Requisite Life          High cycle fatigue    Engine Company    
Prediction                               Low cycle fatigue                       

Table 1: Disk Design & Manufacture Simulation

4.2.1 Current Process

Traditionally, the design, analysis, and manufacture of aircraft engine disks has been performed in a sequential and iterative manner. The full ramification of design decisions on the interplay of reliability, manufacturing, and cost were not discovered until late in the development cycle, often requiring costly design and manufacturing process changes to correct. This approach in now widely recognized as being inefficient, and methods based on integrated product and process development are being introduced. Today, process simulation tools are manually employed to support and locally optimize the various steps in the manufacturing process. While substantial progress has been made over the last few years in the evolution and application of these tools, much work remains in order to achieve affordable, high quality designs in less time.

The detailed thermo-mechanical analysis of the disk is required in order to ensure that the disk satisfies the mission requirements imposed by the customer (military or commercial). A disk is not analyzed in isolation, but rather is analyzed as part of an assembly of blades, seals, other disks, etc. In addition, because of the required specialization in expertise, the thermal and structural analyses are usually performed by separate groups. Thus, the accurate and timely handoff of thermal data to the stress analyst is critical. The principle drivers in disk design are performance, weight, and cost. These factors are greatly affected by material selection, which inturn impacts downstream manufacturing. Once designed, the engine company works closely with the forging vendor, to secure a near net shape disk forging, which has also been properly heat treated to achieve a given set of metallurgical properties with minimum residual stresses. Achieving near net shape is important because the raw material costs for many of the alloys used in the engine are very expensive and because the more excess material there is in the forging, the longer and more costly the machining. Ideally, the forging vendor receives an electronic definition of the finished part, but his job is to derive the die shapes which will enable the part to be produced with a minimum number of forging operations, thereby substantially impacting tooling cost and turn around time. The task of reverse engineering the desired die shapes is nontrivial and is based largely on experience. There is not a single heat treatment process, but rather a variety of approaches which can be employed, depending on desired results and on equipment availability at the vendor. Within any given process, there are many process parameters available which can be adjusted to satisfy design requiremnts and provide the requisite metallurgical properties. Again, because of the alloys (superalloys and powder metals) employed by the aircraft engine industry, the requisite cooling rates can be high and result in substantial locked in residual stresses.

After heat treatment, the disk is machined. The goal is to machine the part in a minimum amount of time. Machining time is influenced by the number of setups. The number of setups is in large measure affected by whether the part "walks" on the machine tool. Excessive distortion during machining is a direct result of the residual stresses locked into the part from the previous forging and heat treatment operations. The distortion which occurs during machining is path dependent, i.e., the order which material is removed. The final part distortion is typically path independent, but is a direct function of the residual stresses. Excessive part distortion at the end of the machining process can result in the part being out of tolerance, and thus would be scrapped.

After machining, critical locations are often shot peened to locally provide a benign compressive stress layer in the part. This compressive residual stress layer is intended to extend the life of the part.

The final step in the process is to determine the life of the part. Part life is a function of the residual stress coupled with the operating stresses resulting from the thermo-mechanical analysis. Residual stresses can either help or hurt part life. Typically, the part is not stress free when it exits the manufacturing processes, and thus the accurate prediction of the initial stress state is critical to assessing part life. Clearly, if the manufacturing processes were simulated early in the design process, rather than as part of the manufacturing process, decisions which most directly effect cost, quality, and cycle time could be implemented early in the design process.

4.2.2 Improved Process Using ASOP

While the sequential process described above may be acceptable today, it is not completely satisfactory. Clearly, incremental improvements to the existing process, such as separately optimizing each step in the process, would result in substantial benefits. However, the real benefits will come by attacking the complete problem as a multidisciplinary design optimization problem. The ASOP concept provides an ideal approach, whereby the problem can be systematically decomposed into its constituent components and then globally optimized. Virtually all aspect of the concurrent engineering framework would be exploited during the design, analysis, and manufacturing of aircraft engine disks.

The scenario for the ASOP process would be as follows. The process would be decomposed into its relevant subprocesses, with the important design variables being identified for each subprocess. Using the design engine, the problem would be formulated. The global objective function would be established such as minimize cost, cycle time, or a combination of thereof. The relevant organizations would be intimately involved with the process, including design, manufacturing, and suppliers. Since the organizations are separate, requisite communication for collaborative design would occur over the NII. Also, the CAD/CAM environment, is likely to be heterogeneous, and thus, communication about the product would be through standards, making use of the framework's geometry toolkit.

A representative set of simulation tools used in the processs would include ANSYS for thermo-mechanical analysis, DEFORM for forging simulation, ABAQUS for heat treatment and machining operations, and internal codes for shotpeening and part life calculations.

Because ASOP drives towards multidisciplinary system optimization, the overall global optimimum will be achieved, thereby avoiding local suboptimum solutions at the individual processes level. Thus, the ASOP system will naturally provide a vehicle for integrating product and process design.This will permit trade studies to be performed on an individual process by the most knowledgeable people, without violating constraints in other processes. Because a forging vendor will be involved with the design and manufacturing process, intelligent decisions can be made to better design the dies, leading to minimum number of forging steps, for example. In addition, since the detailed disk design process is inherrently computationally expensive because of the large models and the nonlinear nature of the analysis performed for several of the steps, even without optimization. Thus, the use of parallel computations is virtually mandated when optimization is introduced into the process.

5 REQUIREMENTS DEFINITION

The requirements defined below for implementing an ASOP on the NII were based on consideration of the potential applications defined in Section 4. together with the knowledge that there is likely to be a much wider range of applicability for an ASOP in the aeronautics community than can be represented by two examples. A large scale aeronautics joint development project could involve large numbers (up to 20,000) of suppliers, a wide spectrum (thousands) of software modules, and large (1 terabyte) digital databases during it's life cycle. In the long term, the NII services and capabilities will likely need to support these large, diverse teams in order to support more effective and globally competitive aeronautics programs.

The MADIC Team has evolved an initial architecture which provides the framework for defining the requirements for implementing ASOP on the NII. A high-level view of the architecture, which contains six major components, is shown below.

Click here for Picture

Figure 5-1 Architecture for Implementing ASOP on the NII

The first major component is the Design Environment which encompasses the critical ASOP functionality from an aeronautics optimization perspective. The engineering and optimization tools required to implement ASOP reside in this component. The relationship between the various subelements of the Design Environment and the components of the ASOP design process described in Section 2 is shown in Figure 5-2.

Click here for Picture

Figure 5-2 Design Environment Supports ASOP Design Process

Referring again to Figure 5-1, the ASOP Object Backplane contains all the elements envisioned for the future NII Services Backplane customized to meet the specific ASOP Design Environment requirements and needs. The Local and Organization ASOP Infrastrucuture provides the linkage between the various members of an ASOP project team. The NII Services Backplane and the NII Network Infrastructure represent the features and services available as a national resource that would be shared with a wide range of users. Each of these six major components of the ASOP Architecture will be discussed in detail in the subsequent subsections.

With regard to the use of the NII by the Aeronautics industry for the implementation of ASOP, a general comment obtained from survey responses of potential users was that the NII is viewed as a robust enabler for ASOP. There was great interest in and strong support for employing NII services and capabilities to support aeronautic system optimization using ASOP. An "open" NII environment was preferred provided it meets government and commercial security needs and it can provide the bandwidth required for team interactions, simulation and optimization. Migration to robust NII services for database management, large scale data storage, computing resources and similar capabilities was typically supported and expected.

5.1 Concurrent Engineering Framework

5.1.1 Overview

The envisioned concurrent engineering framework, consisting of the ASOP Design Environment and the ASOP Object Backplane, must be capable of supporting product development from a life-cycle point of view, starting with requirements specification all the way through supportability. It must provide representational capability to support the various stages of the product development process, and must enable collaborative development by cross-functional teams. Critical issues involving manufacturability, process planning, assembly, etc. can therby be addressed early in the design process, resulting in affordable products that are of higher quality than those developed via the conventional sequential process. Changes made to the in-progress design must be quickly propagated and made accessible to the various cross-functional teams to take appropriate corrective action.

The architecture for the required integrated design environment is shown in Fig.5.1.1-1 and will include the following modules: Design Engine, Visualization Toolkit, Geometry Representation Toolkit, Analysis Modeling Toolkit, Cost Modeling Toolkit, Process Modeling Toolkit, Simulation Engine and Optimization Engine. These modules are integrated through an Object Backplane and can communicate with one another through message passing. The system will interface to the NII Infrastructure through the Design Team Infrastructure, and provide a Graphical User Interface (GUI) which can serve as a front end. These major system components are summarized below and elaborated in the following sections.

Click here for Picture

Figure 5.1.1-1 Affordable Systems Optimization Process Architecture

Design Engine

The Design Engine will support design activities from conceptual/preliminary through detailed design, as well as manufacturing, operations, and support. It will guide the development of system constraints and objectives from the requirements specification. It will be capable of information retrieval from the object database for subsystem and component designs and use this information to synthesize an initial starting design. The initial design is then passed down to the Simulation Engine for evaluation and to the Optimization Engine for iteration to a final optimum design.

Visualization Toolkit

The Visualization Toolkit will provide graphical depictions of component, subsystem, or system being designed in the ASOP system. These visualizations take two forms. The first is a depiction of the object being designed which can involve its geometrical shape, physical properties, its parametric properties within a design space, or functional subsystem schematics. The other form involves depicting operational performance as appropriate for the design. The visualization will be rendered through the use of advanced techniques such as animation and virtual reality.

Geometry Toolkit

The Geometry Toolkit will include a set of CAD/CAM integration agents which enable seamless access to a heterogeneous modeling environment, and supports the notion of using a common geometry basis for CAD/CAM/CAE applications and their integration. Common geometry means using the same geometry to support design, analysis, and manufacturing through the use of application-specific views of the product. The Geometry Toolkit will also provide support for advanced modeling capabilities like parametric modeling and knowledge-based engineering.

Analysis Modeling Toolkit

The Analysis Modeling Toolkit provides the representation for supporting analysis of component, subsystem, and system models from a multidisciplinary and multi-fidelity point of view. This representation should include a set of object models that house the computational grids and their related attributes, as well as an association with the geometry. In addition to the representation, the Analysis Modeling Toolkit will provide a set of objects which provide data coupling and mapping between different analytical views. The concept of connector objects, which are analogous to electrical cables with pins, wires, and plugs, and that were developed for NPSS (see Section 6.1), could be leveraged to support this toolkit. Finally, the Analysis Modeling Toolkit will provide a set of integration agents to interface with external CAE systems.

Cost Modeling Toolkit

The Cost Modeling Toolkit is a collection of tools which supports the development of cost models for a product. A cost model will contain information at multi-fidelity levels from various design stages. The toolkit will be accessible through the ASOP Simulation Engine. Communications between the toolkit and the ASOP framework will be implemented via agent processes.

Process Modeling Toolkit

The Process Modeling Toolkit is a collection of tools which emulate DFX - Design For X, where X represents things such as manufacturability, assembly, supportability, etc. The toolkit will be accessible through the ASOP Simulation Engine. Compatibility of I/O information between the toolkit and the ASOP framework will be resolved via agent processes.

Simulation Engine

The Simulation Engine provides response evaluation and sensitivity calculations for use by the Optimization Engine. It consists of three elements:

1. A set of simulation tools. The NASA NPSS "cube" is representative of the multidisciplinary, multi-fidelity tools necessary in a comprehensive design/manufacturing environment.

2. A set of integration agents that support generic simulation tools, and that enable application-specific simulation tools to be wrapped into the ASOP framework.

3. A simulation executive that provides a programmable control mechanism to specify the sequence and control the dynamic execution of the simulation tools. The Simulation Engine will support a variety of tools ranging from commercial, to proprietary, to public domain codes. The Simulation Engine would support both physical and process simulation codes, such as producibility and cost modeling.

Optimization Engine

The Optimization Engine, which controls and executes the optimization process, will support multidisciplinary and multi-level optimization employing the Simulation Engine iteratively for response evaluation. The major features that the Optimization Engine will support include:

· An architecture for hierarchic and non-hierarchic optimization techniques operating on component, subsystem, and system levels;

· An optimization toolkit with an advanced set of interoperable optimization methods;

· A program interface generator to enable rapid coupling of simulation codes to the Optimization Engine;

· A design expert system that utilizes design knowledge where applicable;

· An optimization controller capable of combining various optimization methods and other toolkits to provide seamless utilization of a variety of technologies available to the Optimization Engine.

Object Backplane

The Object Backplane will support the local organization infrastructure for high performance computing and communications. In addition, storage of in-progress and past designs will be supported using a persistent object database. Retrieval of past designs using case-based reasoning and artificial neural networks will be able to quickly determine a good starting point for a design, given a set of design requirements. The ASOP Object Backplane must be closely harmonized with the evolving NII and be transparent to "local" and "team" members to prevent design, manufacturing and support delays. This close coupling will enable ASOP to exploit the NII's services in terms of collaborative design, high performance computing, and communications via the World Wide Web; allowing the exchange of multi-media information across organizations for use by the concurrent engineering team in a form appropriate to the application at hand.

5.1.2 Subsystem Requirements

General

The ASOP framework must provide general support and services for a variety of subsystems which will promote standardization, facilitate integration, exploit high performance computing and communication, and enable multidisciplinary design optimization.

Common Product Model: A common product model is necessary to serve as the basis to support design, analysis, manufacturing, and operations and support. Today, such a model can be problematic because of the heterogeneous modeling environments which exist within major corporations and amongst their second and third tier suppliers. Support for these heterogeneous environments must be assumed, and thus, data accessibility, maintenance of data integrity, and reliable data exchange constitutes a minimum prerequisite for such a common basis for integrated product and process design.

Operational Modes: The ASOP environment will be able to operate either as an independent free-standing system or be subordinate to, and interoperable with, other environments. It will also support batch mode execution, without need for a GUI.

Configuration Management: The framework must support the evolution of design during the product development process. This means tracking change and enabling systematic archival and retrieval of designs.

Agent Technology: Agent technology will be used for module communication and system integration. Resource objects, called agents, present a formal mechanism for linking design resources in an integrated architecture, including via the NII. Specifically, agents are defined to have three components that provide a generic implementation. These are:

1. Resource - Programs, databases, and design experts that are responsible for carrying out design methods. Resources are the specific entities that an integrated framework will tie together.

2. Model - A generalization of the design process that is implemented in a resource. Models provide a mechanism for agents to publish what services can be provided by its resources. This also provides the basis for agent accountability in the ASOP process.

3. Wrap - A standardized communication mechanism among agents. The wrap provides transparent communications for resources within the system and through the NII.

Using agents, the architecture may be implemented both partially and incrementally. In the simplest sense, resources may be "hard-wired" through the wrap. At the other extreme, the architecture may take full advantage of agent modeling capabilities to build accountable design architectures that provide information context and data accumulation. Tools are defined as agents without models. In this case the user or requesting agent must be "expert" in the use of the tool resource and will be accountable for its use. Tools do not provide accountability directly.

Design Engine

The Design Engine (DE) is the main controller for the ASOP implementation. It plays four key roles in the design process. First, it must capture the design problem requirements, and the constraints on the final design while meeting these requirements, and insure they are correctly translated into appropriate internal data representations. Second, the DE retains models of the design process and uses them to provide guidance for the design process. Third, it must monitor the actual progress against the chosen design process model and report deviations. And last, it must provide information to the designer concerning design status and design details both during the design process and after its completion. The design engine must support the design process through the design timeline from conceptual via preliminary to detailed design, including manufacturing, operation, and support aspects. It also guides the designer in the synthesis of initial designs.

Problem Formulation: The first step in all ASOP design processes is the gathering of requirements. This process will closely follow standard QFD practices, and result in a prioritized requirements list with critical customer requirements explicitly identified. Similarly, a list of constraints on the designs potentially satisfying the requirements will also be gathered at this time. There are various types of constraints, such as cost and risk parameters, manufacturing process constraints, logistic constraints, and operational environmental constraints where the product will ultimately be used. It is essential that all constraints be identified and successfully represented before subsequent steps in the design can proceed.

In addition, the DE will have a built-in tool for decomposing the design process, such as DeMAID, which assists in structuring the discipline iteration loops to minimize unnecessary interactions.

Guiding Design: ASOP will have available design process models that will be used to both guide the design process and serve as the basis for monitoring progress or detect problems (see Monitoring below). An appropriate process model will be selected following completion of the problem formulation step. This choice will be strongly influenced by the nature of the design problem and presence or absence of a previously successful design to follow as a prototypical guide. Previous designs will contain both design details, design processes appropriate for designs of its type, and a legacy of lessons-learned to wisely guide similar designs. Guidance will be provided through a combination of appropriate cues to the designers and through direct calls to other modules of the ASOP system.

A major responsibility of this module will be to maintain linkage between the emerging design and the related requirements and constraints. Detected clashes between requirements and the design will trigger trade-off and/or optimization methods. This module will also be responsible for insuring that design data capture is completed at each step of the design process.

Monitoring: In parallel with guiding the design process, ASOP will also monitor progress internally. This critiquing process will be driven by the design process model selected for the design. If deviations from the design process model are detected, they are reported to the process guidance module, and the system users via the GUI.

Providing Information: Information will be required by the designer-users, both during the design process and after its completion. During design, it will be necessary for design status reports to be available, measuring progress against the requirements and constraints of the design, according to the process model being followed. It will also be necessary to provide appropriately detailed information about completed parts of the design to facilitate checking and implementation planning. It is expected that access levels to design information will be established, so that the range of users from customers to manufacturing and subcontractors can access information appropriate to their needs while other irrelevant but sensitive information is suitably protected.

Following the successful conclusion of the design process, the DE will administer the generation of all needed data files (e.g., CAD/CAM files, analysis reports, and so forth) to drive the implementation process and archive the design for later modification and re-use.

Implementation: The various DE features described above are expected to be provided through a suitably flexible integration of existing software tools. Integration will be accomplished using the facilities and standard ASOP data formats of the Object Backplane, described subsequently. Design process models, heuristic control knowledge, and process guidance knowledge will be retained in persistent data bases residing within the system. Previous design information is expected to reside initially outside ASOP data bases but is to be copied into ASOP and translated into its data formats as appropriate during the time the design process is active. User interaction will be provided through the GUI using ASOP Agent technology. An electronic copy of design data, as well as a hard copy of various reports will be provided using the facilities of the host computer system.

Visualization Toolkit

The Visualization Toolkit (VT) provides graphical depictions of the system or components being designed using ASOP. These visualizations take two forms. The first is a depiction of the component, subsystem, or system being designed which can involve its physical properties, its parametric properties within a design space, or functional subsystem schematics. The other form involves depicting operational performance as appropriate for the design. VT invocation usually occurs by the user through the GUI, but can also be called by the DE during status or report generation activities. Output from this module can utilize the CRT facilities of the GUI, Virtual Reality (VR) equipment if provided locally, hard copy, and electronic files as appropriate.

Invocation: Visualization requests will be issued primarily by the designer-users via the ASOP GUI facilities. Alternatively, visualization outputs will be part of some status and final reporting steps of the design process administered by the DE. In these cases, invocation of VT displays will come from the Design Engine with outputs presented to the users as directed by the Design Engine.

Design Visualization: Progress and final versions of a designed object can be evaluated and documented more completely using appropriate visualizations. ASOP will support three types of visualizations: location in design parameter spaces, geometric views and renderings, and functional schematics.

During design development and tradeoff analyses, visualizing exactly where the current design is located in multi-dimensional parameter spaces, the local and global shape of the design space surfaces and contours, and the design location relative to constraint boundaries can all be greatly aided by graphical depiction. Optimization-oriented tradeoffs are especially facilitated. Performance and cost analytical models will be utilized to drive the visualization methods, supplemented by simulation facilities as appropriate.

Mechanical views of the design will also be supported. These will be driven from ASOP CAD/CAM files using standardized data formats; 2D and 3D views will be supported as well as zoom capabilities.

Functional schematics are the third type of visualization supported by ASOP. These graphics capture the basic operational flow of the overall system performance strategy. Additionally, various functional subsystems will be individually visualized. Common examples here include electrical systems, hydraulic systems, fuel delivery systems, and power transmission systems. Conventional standard technology will be utilized and both CRT and hard copy versions will be supported.

Performance Visualization: Physical Visualization is a complementary way to view design information. In ASOP three forms will be supported. First, test data can be displayed which is generated primarily by the Simulation Engine. This data can relate to evaluation of system elements analytically at design time, or to evaluation of system elements subjected to real-world testing. A second class of performance related visualization is that of functional diagrams depicting the principles of operation by which the system performs. A third class is that of physical animations depicting system operation. This class of output will be driven by the Simulation Engine and require suitable display and computing power to be effective.

Visualization Output Methods: The VT output facilities will be highly dependent on the nature of the local host computer system. Minimally, CRT and B&W hard copy will be assumed. In addition, it is highly desirable for many mechanical design problems that VR facilities be included to permit manufacturing, operational, and maintenance design verification to be made more completely at design time. These VR facilities can also enable better understanding of the shape of parametric design surfaces, which is very helpful during optimization-oriented design trade-offs. In addition, electronic output files should be provided using ASOP standardized data formats.

Implementation: The Visualization features described above are expected to be provided through a suitably flexible integration of existing software tools. Integration will be accomplished using the facilities and standard ASOP data formats of the Object Backplane, described elsewhere in this document. On-going design data will be accessed from their commonly shared data bases using standard ASOP formats. Simulation Engine outputs will be obtained via agents for those system modules. User interaction will be also provided through the GUI using ASOP agents. Electronic copies of visualization displays will be provided using the facilities of the host computer system, as appropriate.

Geometry Toolkit

The architecture for Geometry Toolkit is shown in Fig. 5.1.2-1. It is comprised of two elements:

1. A generic object model to represent and manipulate analysis models;

2. A set of agents which support integration with external CAD/CAM systems.

The Geometry Toolkit is needed to facilitate the geometric aspects of the Analysis Modeling Toolkit, the Simulation Engine, and to supply data to the Visualization tasks of the ASOP system. As such it must also be able to interact with commercially available graphics and computer aided engineering systems.

Click here for Picture

Figure 5.1.2-1 Geometry Toolkit Architecture

The Geometry Toolkit should satisfy the following requirements:

· It will be able to facilitate the generation of geometric surfaces from various data types.

· It will be able to interpolate among defining two-dimensional surfaces to create three-dimensional surfaces, create a surface from defining points or generate it from parametrics or features.

· It will be able to create sub-components by cutting existing loft or other surface definition models.

· It will assist in the layout of sub-structure, systems or other geometry based entities.

· It will contain a knowledge base to help create surfaces or fairings between surfaces that were independently generated, like a wing and fuselage for instance.

· It will include a "smart" procedure for simplifying the geometry by projection or other means for use in simplified aerodynamic, structural, or systems analysis.

· It will support an analysis capability to determine and modify the smoothness of the surfaces.

· It will have the capacity to furnish geometric data for use in the Visualization segment of ASOP. Continuously changing views and magnifications require rapid response and large amounts of storage.

· It will have the capability to furnish a communication link between commercial graphics systems such as UG, CATIA and ASOP and even to furnish a communication among these commercial systems. Geometry and product modeling standards (IGES, PDES/STEP) will be supported. This will be of great benefit to multi-company team efforts and to contractor-subcontractor communication and efficiency.

Analysis Modeling Toolkit

The architecture for Analysis Modeling Toolkit is shown below.

Click here for Picture

Figure 5.1.2-2 Analysis Modeling Toolkit Architecture

This toolkit is comprised of three elements:

1. A generic object model to represent discrete analysis models;

2. A set of agents/connector objects which enables multidisciplinary & multi-fidelity coupling;

3. A set of agents which support integration with external CAE systems.

The Analysis Modeling Toolkit will need to interact heavily with other components, especially with the Geometry Toolkit, Simulation Engine, and CAE Systems such as commercial packages like IDEAS and PATRAN. The major required attributes of the Analysis Modeling Toolkit are described below.

Analysis Models: The Analysis Modeling Toolkit for the ASOP system can either be stand alone in which case it will have modules that correspond to each of the important Simulation Engine modules or it can be distributed and be contained in each Simulation Engine module separately. Some of the more notable analysis models that should be considered are:

· Structural Finite-Element Models (FEM)

· Computational Fluid Mechanics or Aerodynamic Grid Models

· Mass Models

· Thermal Models

· Dynamics and Control VMS Models

· Real Time Simulation with Pilot in the Loop

Some others that might be considered are Loads Models, Fabrication and Assembly Models etc. These modules should be model generators that facilitate the quick and accurate creation of analysis models to be used in the Simulation Engine.

Representation: The model generators can either be generic or specific to particular applications. They should be made easy to use by employing Knowledge Bases and practical default options. Both geometric and non-geometric information will be handled. For instance, finite element geometry as well as element types, properties, and degrees-of-freedom will be considered.

Parametric Variations: When possible the models should be parametrically variable and "feature based". This will ease the effort in generating the models or re-generating after changes have occurred. Also parametric variation will facilitate the calculation of sensitivities needed in the design optimization process.

Manipulating, Editing, and Checking: Models require checking and modifying. Smart or Knowledge-Based checking could assist in this process. Such a system could use simple calculations and analysis to check the models. For instance, a simple static analysis of the FEM or even a modal analysis could be used to find errors or missing data. Data also must be generated to feed to the Visualization tool to provide the user a clear picture of his model and the results of the check calculations. After errors or even bad judgments are uncovered, it must be easy to correct them. Editing systems that allow geometric and non-geometric data to be manipulated easily must be in place.

Intersecting: To ease the labor in creating a model it would be beneficial to have capabilities to automatically or semi-automatically join various geometrical models together, like, for instance, wings and fuselages. Also "glue" elements should be available to join high-fidelity sub-components to low-fidelity vehicle level or major component level models. This "glue" element can also be used to connect models of the same fidelity that were generated independently and are unconnected.

Connection: One of the big challenges in using various models is their connection to one another. Much of the accuracy of the global calculation can be lost at these interfaces if not done properly. Consider, for instance, the structural FEM and aerodynamic CFD grid interface. The deflections of the structure must be accurately translated to the aerodynamic mesh to obtain aeroelastic loads. Even more important, the aerodynamic pressure distribution must be lumped as forces at the nodes of the FEM in such a way that the local stresses are realistic and the global loads are preserved. If this is done incorrectly on a wing, for instance, the entire bending moment distribution can be compromised.

Cost Modeling Toolkit

The cost modeling toolkit must facilitate the development of cost models which meet the following functional requirements:

· Multi-fidelity levels of input parameters, corresponding to conceptual, preliminary, and detailed design studies

· Constructed/arranged in a hierarchical fashion to directly correspond to and receive data from product decomposition studies

· Sensitive to manufacturing process parameters (i.e., Process-Based, Activity-Based, or Feature-Based). Cost Models are desired to replace or work with parts of existing weight-based models.

· Reflect the time value of money (through interest and inflation/deflation) to most accurately capture production operations as well as accurately predict O&S costs

· Fully functional within an IPPD environment. Some of the commercially available parametric estimating models do not provide source code and may not be able to be suitably wrapped or included in an integrated environment.

· Provide a functional abstraction of the manufacturing environment in order for the cost models to be used early in an affordable system optimization process. The models must provide enough detail to make the design sensitive to or dependent upon manufacturing and operational activities while not providing too much data that will unnecessarily lengthen the design cycle time.

· Utilize detailed information for calibrated estimates at the preliminary, conceptual, and detailed design levels in actual dollars.

· Permit the desired cost elements to be used as design variables on a coequal basis with performance variables. The cost models need to not only be developed/used for more accurate estimation, they must be used for cost reductions, Design-to-Cost applications, and cost optimizations.

The elements of the envisioned cost modeling toolkit are shown below.

Click here for Picture Figure 5.1.2-3 Cost Modeling Toolkit

The key features of this toolkit include

· Tools which support the development of cost models for product and process, including

- Parametric/feature based costing

- Knowledge-based costing

- Simulation-based costing

· Establishment of historical life cycle cost database

· Support for multi-fidelity levels of cost modeling for various stages of the design process

Process Modeling Toolkit

The process modeling toolkit is aimed at providing a set of tools which simulate DFX (Design For X), where X represents such objectives as manufacturability, assembly, supportability, etc. The process modeling tools will be executed through the Simulation Engine's executive controller. Figure 5.1.2-4 provides an overview of the process modeling toolkit. The process modeling toolkit must support an Integrated Product and Process Development (IPPD) approach to design. It makes use of the product and process model databases. Through process simulation producibility will be assessed, emphasizing process visualization, tooling/design, process variability analysis, and dynamic process planning. The effects of the manufacturing processes on the ultimate goal, system affordability, must be captured in the process modeling toolkit.

Click here for Picture

Figure 5.1.2-4 Process Modeling Toolkit Architecture

Simulation Engine

The ASOP framework will be required to deal with information from an extensive range of disciplines at varying levels of fidelity. The framework will provide mechanisms to initiate the generation of this information and to collect the information and make it available to the rest of the process. In addition, it will comprehend that each discipline may provide information at several levels of fidelity. The architecture for the Simulation Engine is shown in Figure 5.1.2-5. It is comprised of three elements:

1. A programmable executive controller, which dynamically controls the sequencing and scheduling of the simulations tools.

2. A set of agents which support generic simulation tools, and which enable application-specific simulation tools to be integrated into the Simulation Engine.

3. A suite of generic and application-specific simulation tools which may be application specific, commercial codes, public domain, or company proprietary legacy tools. Intrinsically, the simulation tools are not a direct part of the Simulation Engine, but rather they are external codes which are integrated into the Simulation Engine via the toolkit's agents.

Click here for Picture

Simulation Executive: The simulation modules will be executed under the control of the Design Engine and Optimization Modules. This executive will provide the methods to specify the execution sequence of the modules. It must be able to pass sufficient information to initiate the appropriate module on the appropriate computing platform. This executive could be used to interactively drive the analysis modules in a multidisciplinary analysis environment. The executive should also be able to invoke any sensitivity calculations provided by the simulation modules. Since these calculations usually require significant computing resources, only those sensitivities needed should be requested.

Figure 5.1.2-5 Simulation Engine Architecture

Integration Methods: A set of agents will be provided to allow for easy integration of the simulation tools. While it is recognized that this process cannot be fully automated, the generic steps will be identified, and tools provided to ease the process. Capabilities must exist to handle both the inflow (design variable values) and the outflow of information (performance values).

Simulation Codes: A large number of simulation codes covering various disciplines are currently used by the aerospace industry within their own engineering framework to support a vehicle design as described in Section 6.3. These codes provide the baseline for the suite of codes required to implemement the ASOP concept. Both physical simulation codes (e.g., structures, controls, aerodynamics, etc.) and process simulation codes (e.g., composite layout, product support, etc.) are presently being employed.

As shown in Fig. 5.1.2-5, the array of required simulation tools can be depicted as a three-sided cube. One side refers to the multiplicity of the codes, which is certainly the present case within the aerospace industry, where each company uses the tool of its choice to solve problems. This is not to say there are no codes that are shared. In fact, many large (and small) structural and CAD tools, such as NASTRAN and CATIA are used by many companies. This commonality often is mandated by prime/subcontractor relationship or by the availability and maturity of commercial products. However, due to the nature of the aerospace business, where proprietary code and data often are primary factors in winning contracts, proliferation of codes is inevitable. Examples of typical codes used by the aerospace industry are presented in the Section 6.3.

Another side of the simulation cube refers to the analysis type, which is the theory or methodology used by the simulation code. Because the understanding of the physical phenomena within the various relevant disciplines (e.g., aerodynamics, electromagnetics, buckling,, etc.) is not perfect, there tends to be different modeling and analysis techniques. Different companies tend to use different (sometimes proprietary) analysis types, which have been tailored to be consistent with that particular companies experience

The last side of the simulation cube refers to the fidelity. Different code will generate adequate answers for particular situations (more precisely, design phases). There is no need to model nonlinearities in one code, if only small perturbation results are needed. Furthermore, the fidelity of the answers is as good as the assumptions made. One cannot get nonlinear results from a nonlinear codes if the inputs are generated from a linear code. Fidelity often is associated with the design phases (more on that in the next section). In the conceptual design (CD) phase, where quick and approximate solutions are needed to establish a baseline configuration, high-fidelity codes are unnecessary. The opposite is true in the final design (FD). The design phase associated with each of the codes listed in Section 6.3 is indicated for reference. It is a good indication of the fidelity (e.g., low with CD, high with FD) as well as the analysis type (linear theory with CD, nonlinear with FD).

Not surprisingly, there are many more physical than process simulation codes available in the aerospace industry today. The existing physical simulation tools tend to be fairly mature and established and the results produced range, by and large, from reasonable to excellent. The same cannot be said about process simulation codes. More effort is required to develop process simulation codes that can be used reliably in the ASOP concept if process issues are to be addressed properly in the early stages of design

Additional Capabilities:

· The system must be able to recover from a simulation module failure. As a minimum, it must be able to identify that a failure has occurred and be able to communicate this to the optimization and design engines. Depending on the type of failures, it will be able to take one of the following actions: retry the current simulation run, discard and signal to the calling module to continue exploring alternatives, or pause the ASOP process and signal a message to the GUI requesting the designer's attendance.

· The simulation engine must provide estimates of execution times from each of its modules and an assessment of the accuracy of each disciplines responses. A priori time and accuracy estimates could be used to select the appropriate analysis modules used. A posteriori accuracy estimates will be used in the optimization engine.

Optimization Engine

The optimization engine is that part of the process in which formal, often mathematically-based steps are taken, based on information generated in the simulation modules, to improve product performance, by modifying the design description. This part of the process must contain certain characteristics that will be driven by the Design Engine and similarly puts certain requirements on the simulation processes. The main features of the Optimization Engine are depicted in Fig. 5.1.2-6.

Click here for Picture

Optimization Toolkit Requirements: This toolkit must contain standard optimization methods that can be applied to a wide range of problems. These in general are well known methods, but the toolkit must be constructed so that these methods are accessed with a standard format and return results in a standard format. Specifically, the toolkit will contain:

Figure 5.1.2-6: Optimization Engine Architecture

· An extensive set of continuous, gradient based algorithms such as method of feasible directions, generalized reduced gradient, and sequential linear programming. Higher order methods such as sequential quadratic programming that make use of Hessian information will also be employed.

· A similarly extensive set of discrete and mixed variable algorithms.

· Global methods such as Simulated Annealing and Genetic Algorithms.

· Non-gradient or sub-gradient methods such as polytope and direct search methods.

The toolkit will also contain a selection of methods to handle multi-objective problems which could include methods such as goal programming and Pareto optimality methods. In addition, it will contain methods to access and use domain specific knowledge about the optimization. Finally, the toolkit will contain methods to support multilevel optimization strategies. These methods which are particularly important for multidisciplinary design range from the tightly coupled, all at once methods, to the loosely coupled Coordinated Subspace Optimization methods (CSSO).

Optimization Controller Requirements: The optimization controller must be capable of combining various optimization methods and other toolkits to provide seamless utilization of the wide range of technologies available to the optimization engine. It will be interruptible by the user, and the user must have the capability to restart the problem with a different optimization strategy and modified constraints. In addition, the controller itself should be able to recognize when it needs to move among different algorithms. For example, to be able to switch from a global algorithm, such as simulated annealing, to a local gradient based algorithm for local convergence. Finally, since different disciplines will present different levels of complexity to the optimizer, the multidisciplinary optimization controller should be able to exploit these differences. For example, if one discipline is relatively linear with respect to its design variables, while another is highly nonlinear, the controller should request only enough information from each discipline in order to efficiently pursue the design. In this sense, it must be knowledgeable about the construction and use of various explicit approximation techniques such as Taylor series expansions or Response Surfaces, either supplied by the simulation modules or constructed by the optimization process.

Additional Capabilities: The optimization engine must provide additional capabilities that are not traditionally associated with optimization methods, including:

· Ability to work with sensitivities as supplied by the various analysis and simulation modules. If these sensitivities are not available, a mechanism will be available to calculate them by repeated calls to the analysis modules.

· Ability to store (or access stored) information from the analysis modules that will allow the construction of approximate models by response surface techniques. The optimization engine will provide response surface methodologies such as least squares methods, design of experiments methods, and neural network fitting methods.

· Methods to develop robust designs that are relatively insensitive to material, operating conditions, and mission variability. This variability information will be provided by the simulation modules, but the optimization toolkit will have methods to produce designs based on this information.

· In general, each discipline analysis module will not provide information of equal accuracy in the same time frame. Thus, at any point in the decision cycle, the optimizer will either be missing information or will have complete information at differing quality levels. Optimization methods need to be provided that can operate in this environment.

· Ability to exploit both the inherent parallelism in the multidisciplinary analysis problem and any parallelism in the particular optimization algorithm chosen.

· Automated tools to handle sacrificing or set-based strategies which allow alternative designs to be considered more deeply into the design cycles.

Object Backplane

The object backplane provides a common data model for agent collaboration. The data model provides an unambiguous data format that serves as a model for agent protocols. The backplane allows for agents to operate as design objects and design data to be represented. The object backplane will need to support the following services:

Collaboration Services that

· employ emerging "open" NII services to support design teams and team collaboration through PC based video and CAD conferencing and reliable easy-to-use electronic data exchange

· can be expanded for a large concurrent user base

· can access additional NII bandwidth as needed

Configuration Control Services that

· focus on configuration control for aeronautics products and associated data, including versioning, status, accounting and audit functions

· provide services for managing a common product model across a distributed team, using common semantics for data types across the project and supporting re-use of design information for new projects

· support rollback of configurations and long-term archive of product and data configurations

Metacomputing Services that

· facilitate distributed computing services that are available across an ASOP project team

· support access to shared supercomputer resources as needed for ASOP projects

· provide interfaces to "open" NII services for ASOP users

Security and Access Services that

· provide a wide range of data/system security for ASOP, protecting and exchanging company proprietary data and government classified data

· support access control to ASOP capabilities through login and password controls

· ensure only authorized users can access, modify or use ASOP services and information

Object and Data Services that

· specialize generic "object/wrapper/agent" technologies to ASOP requirements

· provide object management, distribution, control, and retrieval services

· store and archive ASOP related data objects for reuse, using a common data model. This data model must evolve as determined by a design's fidelity and accuracy requirements. Also, design data must be accountable.

· implement specific data exchange standards for data objects; i.e. STEP Application protocols

PVM, MPI, CORBA, OLE, and OpenDoc are examples of developing or proposed standards that provide some or all of the above requirements.

The Object Backplane will be coupled to the NII through the Team Infrastructure to allow for leveraging the growing computing and communication services available on the NII. Services range from information dissemination, such as on the World-Wide-Web (WWW), to underlying transport mechanisms such as TCP/IP to software environments such as JAVA. In addition, the NII also provides direction for new computing technologies such as fine-grained and parallel computing. A detailed discussion of the NII services and functions required to support ASOP are presented in Section 5.2.

5.2 System Infrastructure

This section discusses possible infrastructure implementations and defines requirements needed to implement an aeronautics ASOP from a System Infrastructure perspective. These infrastructure requirements include functions and services associated with both the NII and Team Infrastructure portions of the ASOP architecture shown in Fig. 5.2-1. The infrastructure requirements information provided was developed from responses to a survey questionnaire used to solicit information from potential ASOP users. Where they are available these preliminary results are included below. ASOP requirements are defined for several categories, related to various services. Inputs are typically provided for a near-term 1-2 year ASOP environment, and a longer range 5-6 year ASOP environment. The survey requested inputs for maximum expected sizes, where applicable, since the purpose was to define critical NII requirements. Quantitative information (order of magnitude, best guess) was requested in the initial surveys and is provided as it is presently available. Additional refinement of these requirements and their associated metrics is continuing. In some areas descriptive or short answer information best defines the requirement at this time.

Click here for Picture

Figure 5.2-1 ASOP Architecture

5.2.1 Possible Infrastructure Implementations

The links among partnering companies involved in an aerospace manufacturing design project are likely to include both proprietary telecommunications lines and the shared NII infrastructure. For key partners with ongoing tightly integrated relationships and with a predictable need to transfer large amounts of data (including televideo conferences) frequently, dedicated high speed lines will probably be essential: These lines have the advantage of being relatively secure and of avoiding general contention for the bandwidth of the network lines.

Cost considerations, however, would counter indicate use of dedicated lines for connections among companies for which data exchange is highly sporadic, and certainly with industrial partners that are involved only in a small fraction of the total design process. We note that many relationships are of uncertain duration as well, and network communication may be needed quickly with a partner that has not previously been linked via a data network.

Thus we anticipate a shifting balance between the use of dedicated lines and use of shared NII networks. The NII infrastructure is developing rapidly and can be expected in the middle term to support services that are now immature or lacking. Certainly, there will be highly secure encryption that will eliminate concerns about stealing data. There will also be greatly improved security for protecting LANs from break-in when they are connected to the NII. R&D is in progress on large-scale routing management of the NII, to produce a software infrastructure that will distribute network traffic in real time to support rapidly fluctuating bandwidth requirements among the thousands of locations. How sophisticated and effective such software becomes will largely depend on the demand from the commercial sector. Similarly, demand will determine the timing and effectiveness of software that will support scheduling for specified bandwidths between specified locations at pre-specified times.

Since global optimization is a key feature of ASOP, any infrastructure being designed to implement ASOP on a industry wide basis must be capable of accommodating this feature. Global optimization will imply the existence of many automated information feedback loops. Typically these loops will operate over multiple locations on the network. Thus, a change in design strategy or in some key parameter in sub-system "A" will produce effects in many other areas of the overall design database, and these will in turn have effects that impact back on sub-system "A". The impact could be on the long term maintainability (having gotten data from sub-system "Q" that the changes in "A" will alter the metal fatigue patterns generated at the interface between a component of "A" and one of "Q") or it could be a recommendation from company "X" that with the new design parameter, the alloy used for part of "A" should be altered slightly, with a subsequent change in manufacturing cost and in life cyclecosts (LCC) for supportability.

In order to accomplish global optimization in a reasonable time with a reasonable budget, much of this feedback will need to take place automatically,typically over the NII at fairly low bandwidth, with automatic notification of the appropriate engineers. High bandwidth feedback will occur when a parameter change in one sub-system generates a change in the overall design of another sub-system, and the entire CAD model needs to be shared among the engineers of both sub-systems, along with several levels of cost impact data. A central shared data system will need to be maintained as a repository of (complex) options and associated costs, together with analysis packages that can quickly estimate total lifetime costs of multiple variants of a design. Presumably, the easier, faster and more effective such an evaluation system becomes, the more complete and complex a job of design experimentation can be done. Since the optimization is being attempted in what is really a multi-multi-dimensional space rapidly varying with time, extensive experimentation is likely to be valuable.

5.2.2 Requirements on NII for ASOP Implementation

This section identifies requirements ASOP will impose on the NII from a variety of infrastructure and/or services viewpoints. The organization sizing data is to provide guidance on the number of "NII connections" likely to be needed for any one project. From this information, indications of the number of concurrent ASOP efforts on-going at any one time can be estimated to define the overall magnitude or size of the ASOP requirements on the NII.

In certain categories magnitudes are not defined but descriptions of the services expected to be part of the overall NII environment are identified. These service requirements are more yes/no requirements in that the service is either "totally" NII provided or is not provided.

NII Network Infrastructure:

· The number of separate companies expected to participate in an individual system optimization project using ASOP will range from 3-5 in the near term to as many as 50 in the longer term.

· The number of organizations in an individual company expected to participate in a typical ASOP system optimization project will range from 1-3 in the near term to 5-10 in the longer term.

· In a conceptual design phase the largest ASOP systems project is expected to involve up to 30 individuals. In the longer term up to 50 individuals are expected to be involved. Note for preliminary and detailed design levels of ASOP application hundreds (200-400) to thousands(2000) of individuals are expected to participate in a large aeronautics ASOP project.

· ASOP is expected to be used in 5-10 different locations (distributed facilities) for a typical systems optimization project.

· For an average sized system optimization project, ASOP will be used by 5-10 individuals in the near term and up to 50 individuals in the longer term.

· The infrastructure must be highly reliable and available to be effective for ASOP. Near-term availability requirements of 90% moving to longer range requirements of 99+% were identified. Scheduled down (maintenance) time would be acceptable in the early implementation stages but high reliability will be quickly needed to gain user confidence and ASOP utilization.

· NII capabilities are required to be pervasive and available at the desktop for the most effective ASOP implementation.

NII Services

Collaboration Services:

· Up to 2 hours/day of on-line, collaboration (video conference; live motion simulation, etc.) is expected to occur between distributed ASOP optimization project users. Note this is expected to occur sporadically, and depending on the speed and availability additional collaboration needs will probably emerge.

· In the longer term, highly complex 3-D real time simulation is required. Less complex conferencing and file transactions are required in the near term.

· Typically, 5-10 individuals are expected to simultaneously participate in the highly complex collaborations using ASOP. At times up to 30 individuals are expected to participate simultaneously.

· The largest "batch transactions" of data exchange between distributed ASOP participants is expected to be in the 20mbyte range for CAD geometry and related data files. Large 500+ mbyte exchanges of ASOP data is also needed.

· 8-10 "batch transactions" per day are expected between ASOP sites to support a typical system optimization. The expectation is that more data will be shared as common data as opposed to "batch exchanged" between sites.

· 10mbyte sized interactive transactions are needed to support an ASOP system optimization project. Comments were made that additional bandwidth and faster interaction is always useful.

· Approximately 2 hours/day of "interactive oriented" data exchange and use is expected between sites for an ASOP systems optimization project. This will be used in a collaborate, work off-line, collaborate mode.

· All of the types of data currently used will be required for NII implemented ASOP projects. Increased amounts of manufacturing and supportability data will also be required. Additional use of more common, neutral forms of the data will be progresively utilized. The Concurrent Engineering Framework and Simulation Codes sections provide additional details on ASOP data types.

Object and Data Services:

· At this time IGES is used and required. A migration to STEP is expected to support exchange of product definition data. Services supporting use of the STEP standard for ASOP will be required.

Metacomputing Services:

· Multiple types of computing resources are required from the NII for ASOP and they are expected to be available on some type of service/lease/as needed basis. For an optimization project up to 20% of the computing resources will require "supercomputers" with the remaining resources split between UNIX and PCtypes of resources.

· In the near term, simulation is relatively small for a large optimization project. Near-term resource requirements are focused on wireframe or dynamic time simulations. Longer range requirements are for resources to support much more "virtual reality", full-motion, 3-D types of simulation.

· Requirement is for reliable, transparent, "pick up the phone" types of network connections and communications. Local bandwidth requirements to 500 Mbit per second were identified. The requirements for secure, shared networks as opposed to dedicated lines was defined.

· Database management system services required to store, manage, query and update the information will be required for ASOP and should typically be considered as part of an overall ASOP system or set of capabilities.

· In the longer range, standard database management system services should be available on and supported by the NII. Near term these are expected to be embedded in the ASOP implementation as part of ASOP.

· Large scale repositories of "public domain" or published information will be required for longer range ASOP implementations.

· These large information repositories will need to be facilitated by the NII and are expected to be migrated from a set of ASOP repositories to a set of NII repository services.

· Utilization of ASOP for major system optimization projects will require large scale storage facilities for the associated ASOP information.

· The required data storage facilities will initially not be part of either ASOP or the NII. In the longer term, data storage facilities were typically expected to be available as NII services.

Security and Access Services:

· Generally the current "open", Internet environment is not considered usable for ASOP optimization projects. Some exceptions may be made for training and demonstrating capabilities or use.

· "Standard" commercial security environments, such as banking, are expected to be acceptable for a large percentage (50% and greater) of ASOP system optimization projects.

· A top secret, highly classified security environment is required for 10%-30% of ASOP system optimizations. In addition, this level of security will often be required (4 on a scale of 5 where 5 is often and 1 is never).

Configuration Control Sevices:

· Workflow management services are required for ASOP utilization. These include services for tracking on-going tasks, approving actions, notifying users, and controlling access to a set of data or files.

· Configuration management services are required for ASOP utilization. These include versioning data files, identifying current components of a product's configuration, and tracking requirements and assumptions.

5.2.3 Requirements on Users of NII Implementation of ASOP

The following section identifies an initial basic set of requirements imposed, individually and collectively, on companies/universities/Government agencies participating in an ASOP design team. In the present context, the team is defined as the group of individuals, from across an organization or enterprise, which is responsible for a particular project implementation. This team represents the "end-users" of an ASOP implementation in that they will be using the ASOP capabilities to produce an affordable aeronautics system product to meet particular customer needs and requirements. While the specifics of a team implementation will vary between different enterprises, programs, and customers they are typically expected to be relatively small groups of people working together on a discrete project or a portion of a larger program. Note however, that a wide variation is expected due to the complex nature of organizations, teaming arrangements, and possible contractual issues associated with any single instance of a team.

Infrastructure requirements to support teams participating in an ASOP system project are divided into two parts (see Fig. 5.2-1). The first are the requirements on the individual companies/uiniversities/Government agencies having participants on the team (termed Local ASOP Infrastructure). The second are the collective requirements on the business enterprise within which the team is operating (termed Organization ASOP Infrastructure). A business enterprise is defined globally herein as an organization responsible for developing and providing products which meet customer needs. This enterprise could be a single company; however, in the present context, it is generally envisioned as comprised of more than one company and possibly involving university and Government agency participants. A wide variation is expected in the form, functions and structure of these enterprises due to the complex nature of an overall aeronautics system development environment

While many of the requirements below may seem obvious, it is important that they be recognized and provided for if ASOP is to be effectively utilized in the user environment. Additional requirements are anticipated related to NII administration, billing for services, access procedures and the like which will also have to be met in order to take advantage of a NII ASOP implementation.

Local ASOP Infrastructure

· An NII ASOP user must have a reliable connection to the appropriate networks for accessing the aeronautics ASOP implementation. For instance, a company would have to provide sufficient network bandwidth for the ASOP users associated with a particular project. This will typically require bandwidth capable of utilizing interactive video conferencing, supporting highend simulations, and rapidly transferring required data files.

· An NII ASOP user must have access to an appropriate computer in order to use ASOP capabilities. Depending on the project, individual's task, life cycle state, and similar factors the computer resource may range from a graphics capable PC class device to a high end, UNIX workstation.

· Typically a company must supply each user with these computer and network resources to support an aeronautics ASOP implementation using the NII.

Organization ASOP Infrastructure

· The Organization must provide the appropriate level of shared services support for an ASOP team environment. Examples include, network servers, shared computer processors, disk storage devices, and video conferencing facilities.

· The Organization is expected to provide the Wide Area Network (WAN) types of services required to participate in a distributed ASOP implementation. This would include access to public and/or private long haul communications services at the appropriate bandwidths for ASOP utilization. Depending on the specific requirements of a project this could include installation of "private" communication lines capable of supporting special bandwidth, security, or access requirements of a project.

6 SUPPORTING TECHNOLOGIES

Implementing ASOP, as described in the previous sections of this document, is a major undertaking that can not practically be accomplished by any single company but requires a cooperative effort between industry, Government, and the university community. To be successful, this implemetation effort must leverage as much of the exisiting relevant technology as possible. Although an exhaustive search for existing relevant technology has not been yet been made, efforts have been conducted as part of the present study to identify certain technologies which are considered important and should be leveraged in any ASOP development program. These technologies are discussed in the following paragraphs. Considerable discussion is devoted to the simulation-based design process, as presently practiced by the aeronautics companies, since this process and the suite of simulation codes involved will form the base for implementation of the ASOP concept.

6.1 Numerical Propulsion System Simulation (NPSS)

The Numerical Propulsion System Simulation is a project led by NASA Lewis in conjunction with the aeropropulsion industry, software suppliers and other research centers to develop a multidisciplinary, multi-fidelity engine simulation system where the goal is to enable a full engine simulation in a few days. As such, it contains many of the concepts contained in the ASOP implementation requirements. The project has been active for several years, and therefore the group has an extensive knowledge base of the issues associated with planning and implementing such a generic system with a diverse set of requirements. This is an asset that can be leveraged in further ASOP developments. The NPSS implementation is directed towards aeropropulsion, but the concepts are clearly more universal. Specifically, some of the concepts that are being developed for what is called "zooming", or moving along models of different levels of fidelity during either the analysis or design process, would be most helpful in developing more detailed specifications.

The NPSS project is building a simulation environment that provides a generic 1D component view of an engine design and analysis system. The environment will provide the engineer with the ability to create, and configuration manage engine simulations, as well as track and query notes, test data, and results associated with specific engine simulations. Additionally, the environment will allow the engineer to numerically "Zoom" to higher order fidelity models on a component specific basis while operating at the 1D system view. The assembly of the component codes can be done independently of the computing architecture and location of the overall engine simulation. To accomplish this feature, the NPSS infrastructure will be developed using Object Oriented technology. Specifically, the Object Oriented paradigm will be used to:

· Define a modular and flexible code assembly environment;

· Enable "zooming" through clear data interfaces;

· Enable multidisciplinary coupling of disciplines through common geometry representations.

The first products for NPSS are currently defined to be:

1. NPSS WorkSpace providing a common windowing environment for all products. Imbedded in the WorkSpace is a configuration management API and a file manager both supporting the access to conceptual and preliminary engine simulations;

2. NPSS Steady State Cycle Deck Launcher enhances and standardizes the way to create engine customer decks. The engine customer deck is the entity used by the airframers in their simulations;

3. The National Cycle Program (NCP) requirements and management team is formed. Over the next two years, this effort will lead to a US standard cycle code for use by all the aeropropulsion industry.

The current implementation is shown in Fig. 6.1-1 below.

Click here for Picture

Fig. 6.1-1 Current Implementation Of The NPSS System

NPSS execution is controlled by a pre-planned execution sequence or by direct human interaction through an NPSS workspace which will be a "windows-like environment" for engine simulation.

A key feature of NPSS is the ability to support multidisciplinary coupling the various disciplines involved in engine design. Interdisciplinary state-of-the-art analysis at the NASA Lewis Research Center is applied to aeropropulsion systems by the Interdisciplinary Technology Office. Aeropropulsion systems are inherently multidisciplinary. Most engine components and systems are effected by aerodynamic loads, structural loads, heat loads, and material properties. These effects on performance must be compensated for by the control system. This requires a multidisciplinary analysis approach to evaluate the effect of these coupled loads on performance. NPSS is an engine simulator designed to provide an integrated process for conducting multidisciplinary analysis. The NPSS system will provide a robust, easy-to-use propulsion system design and analysis tool, including the framework and key analysis models, that will significantly enhance existing design capabilities. This new system will have full design and analysis capability from engine cycle to aircraft mission analysis through a flexible, modular architecture and through the establishment of standards. This will permit easy integration of design tools such as multidisciplinary analysis codes and data bases into a standardized graphical user interface. The key elements within NPSS that provide this capability are:

· clear data interfaces through the development and/or use of data exchange standards,

· modular and flexible program construction through the use of object-oriented programming,

· integrated multi-level of fidelity analysis techniques that capture the appropriate physics at the appropriate fidelity for the engine systems,

· multidisciplinary coupling techniques

· high performance parallel and distributed computing.

NPSS will work closely with National and International Standards organizations to implement existing engineering standards and recommended practices within NPSS, expand standards as required and develop new standards when necessary.

The simulation engine is clearly the backbone of NPSS, and several years of thought have been invested in this concept. The major idea from which ASOP has borrowed heavily is the concept of a simulation cube (see Fig. 5.1.2-5) which encompasses analysis types, fidelity, and subsystems or subsystem disciplines along its three axes.

Visualization technologies with potential application to ASOP are also being developed as part of the NPSS project. A viewing system call PEV (Portable Extensible Viewer) which is designed to fit the requirements of the aeropropulsion user community is currently under development. While similar to other viewing systems, and based on NURBS geometry, it should be further evaluated as an element of the visualization subsystem for ASOP.

The principal method of geometric data communication within NPSS was chosen to be based on NURBS representations. A master engine database exists with NURBS translators into and out of this where necessary. It is planned to rely heavily on existing and evolving data standards to accomplish these transfers. Interfaces have been developed from the master database to several aero, structural and thermal codes with common discipline interfaces. Loads are exchanged between these common discipline interfaces by NURBS also. This approach is clearly one that could be taken in implementing ASOP and should be considered further. It is possible that the discipline interface codes could have use in such a system.

6.2 The Framework for Interdisciplinary Design Optimization (FIDO)

Since multidisciplinary optimization is a key feature of ASOP, technology efforts in this area are of particular interest. One of the signficant ongoing technology efforts is the work underway at the NASA Langley Research Center to develop a Framework for Interdisciplinary Design Optimization. FIDO as it now stands is a general programming environment for automating the distribution of complex computing tasks over a networked system of heterogeneous computers. The FIDO system is organized into distributed service, computational, and auxiliary segments, which communicate through a communications library. The generic communications library is built on top of the Parallel Virtual Machine (PVM) process networking system and provides a set of C language utilities for integrating C and FORTRAN routines as software agents. In addition, FIDO provides a data management system that allows for data to be properly distributed to scheduled analysis tasks used in problem execution.

Currently, FIDO has been demonstrated with a multidisciplinary HSCT optimization problem (minimize gross weight subject to aerodynamic and structural constraints) that includes aerodynamics, structures, propulsion, performance, optimization, and interdisciplinary analysis and couplings. Based on this problem, the FIDO system addresses issues concerning data accuracy, unit conversions between analyses, grid matching, file management, and networking of processes. In this implementation, stand-alone FORTRAN codes were converted into subroutines and are combined with task drivers written in C to form agents/segments. These drivers are responsible for sequencing their execution with the FIDO problem executive (master segment). In addition, drivers, and in some cases analysis routines, exchange data with the common database using the communications library. Data object schematics are defined in include files that are compiled with the database and analysis codes for use by the communications library. A particular design problem, a set of particular files associated to a user, is maintained in a linked UNIX directory structure that is available across the communications network as a shared file system.

The FIDO project is currently moving toward a more complex HSCT problem that examines aero-elastic wing couplings and requires the use of higher-fidelity software agents (FIDO Version 3). This problem entails the parallelization of CFD and structural codes (CFL3D and COMET), automatic geometry and grid generation, enhanced data management and visualization services, and the automatic differentiation of computer codes (ADIFOR). In addition, the compilation of agents/segments is being made easier through the development of a platform independent build process. A path declared directory structure replaces the linked directory structures found in earlier versions and therefore minimizes file system overhead. Finally, use and application of WWW type services are being explored.

6.3 Current Simulation-Based Aircraft Design Process

As mentioned previously, implementation of the ASOP concept will require the broad utilization of the existing aircraft design technology base. It is the purpose of this section to review the current practice of simulation-based air vehicle design as a means of establishing that baseline technology. This baseline information was solicited from three of the aerospace companies participating in the present requirements definition effort; namely, McDonnell Douglas, Northrop Grumman and Rockwell International.

Click here for Picture

Aircraft typically are designed in three phases as shown in Fig 6.3-1. Conceptual design (CD) is the initial stage where the configuration of the aircraft is defined. It uses customer requirements, historical data, and some user preferences (such as materials) to generate a rough planform sketch. In most companies, this procedure is heavily driven by the weight of the aircraft (which determines the range, payload, structure, etc.) and results calculated using "back-of-envelope" equations. First-level trade-offs (such as two tails vs. one tail, delta vs. movable wings) are carried out at this phase. The output of the CD is an configuration to be analyzed further.

Figure 6.3-1 Aircraft Design Phases

Preliminary design (PD) takes the definition of the aircraft generated by the CD and subjects it to a more detailed analysis. Although the shape of the aircraft exists, many properties must be further defined and geometries modified to accommodate the requirements (such as stealth or drag). Additional trade-offs are performed to ensure all requirements are met. The result may be an airplane that mildly resembles the initial configuration given by the CD. At this stage the engineering analyses (including process simulations) must be performed in sufficient detail to prevent any "show stoppers" (such as a performance inadequacy or a manufacturing problem) at a later stage that may significantly increase the cost. The output of the PD is a well defined configuration.

Final design (FD) refines the configuration produced by the PD. Physical specifications are generated at this phase for manufacturing. Detailed nonlinear engineering simulations are formulated to ensure proper performance. Trade-offs are made (but only incrementally) to prevent adverse impact on other disciplines. Interaction between physical and process discipline simulations tend to be largest at this stage. At the end of the FD, aircraft is ready for manufacture.

There are three other phases as indicated in Fig. 6.3-1. They are production, vehicle usage (fleet maintenance), and upgrades. Each of them may involve redesigns of pieces of the existing aircraft. However, since a configuration exists, preliminary or final design procedures can be quickly applied.

Each phase of the aircraft design process involves a complex interplay between many engineering disciplines. This interplay occurs through the exchange of information generated by computational simulations in each of these desciplines. The simulation computer codes involved can be roughly divided into two major categories. Physical simulations refer to those associated with disciplines governed by laws of (Newtonian) physics, where "exact" answers typically can be computed provided that dynamic modeling is properly carried out. Structural analysis and computational aerodynamics are good examples. Process simulations, on the other hand, refer to those associated with disciplines where human and other non-physical factors play a large role. The result is that solutions are highly variable and must often be statiscally approximated. Manufacturability and supportability are some of the examples. This division is being blurred since continuing attempts are being made to model those manufacturing processes, for example, that can be described by physics. Composite material curing and resin transfer molding are such cases.

Click here for Picture

Figure 6.3-2 Aircraft Design Process

In the design process, each discipline requires inputs that come from the outputs of other disciplines. Presently all of these data are loosely passed around when requested by design team members; however, the interplay between physical and process disciplines are weak. In other words, a general integration framework as shown in Fig. 6.3-2 is largely non-existing in the current aircraft design practice, except in special cases involving a small number of disciplines or codes. Cost estimation, which is becoming a very important element of the aircraft design, is still not well integrated with the overall process. The consequence is inability to quickly and efficiently trade off designs based on both performance and cost.

6.3.1 Physical Disciplines

The major physical disciplines and the interplay between these disciplines occuring in a typical aircraft design is shown is Fig. 6.3.1-1. It is these disiciplines and their interactions, together with the process disciplines to be discussed in Section 6.3.2, which must be considered in the development of an infrastructure which will enable design trades to be accomplised more accurately and efficiently.

Click here for Picture

Figure 6.3.1-1 Physical Discipline Interactions

The discussion which follows will concentrate on describing the various physical disciplines and how they interact. Since the design team is generally organized along discipline lines reference will often be made to the discipline group. Interactions with the Configuation Development group and the Vehicle Management System (VMS) group, shown in Fig 6.3.1-1, will not be discussed.


Aerodynamics

Figure 6.3.1-2 Aerodynamics Discipline Interactions

Click here for Picture

The aerodynamics group in an aircraft design is responsible for initial sizing of the aircraft, analyzing the mission in terms of aerodyanamic performance (lift and drag), provide aero loads and coeffiecients, and define the ultimate configuration of the aircraft with inputs from the (low-)observable and structures group. Major interactions and breakdown of the aerodynamics group are shown in Figs 6.3.1-2 and 6.3.1-3.

Figure 6.3.1-3 Aerodynamic Discipline Breakdown

Click here for Picture

Control and Dynamics

Click here for Picture

Figure 6.3.1-4 Control & Dynamics Discipline Interactions

The control and dynamics group is reponsible for flight control law analysis and synthesis, its implementation, verification, and validation, and flying qualities evaluation. It interacts primarily with aerodynamics and propulsion group for aero coefficients and engine data. It also works with VMS to provide necessary information to the pilot. Major interactions and breakdown of the control and dynamics group are shown in Figs 6.3.1-4 and 6.3.1-5.

Click here for Picture

Figure 6.3.1-5 Control And Dynamics Discipline Breakdown

Click here for Picture

Loads and (Structural) Dynamics

Figure 6.3.1-6 Loads & Dynamics Discipline Interactions

The loads and dynamics group is responsible for producing a detailed flight load (both transient and steady-stated) distributions and fatigue criteria report. It performs flutter and servo-aeroelastic analyses. It checks for landing gear loads and flutter-producing external store configurations. It analyzes ground vibration survey data and provides equipment shock and vibration test requirements. Loads and dynamics group interactions are shown in Fig.6.3.1-6

Click here for Picture

Observables

Figure 6.3.1-7 Observables Discipline Interactions

The observables group deals with the radar and infrared (IR) signatures of the aircraft. It works with many groups, notably aerodynamics and structures, to develop configuration that will minimize radar cross-section. It also collaborates with avionics group to use electronics to actively reduce radar cross-section. It interfaces with propulsion and subsystems groups to reduce the IR emissions. This is a relatively recent addition to the vehicle design since stealth characteristics have not been considered until last few years. Major interactions of the observables group are shown in Fig 6.3.1-7.

Click here for Picture

Avionics

The avionics group provides all the electronics necessary to keep the aircraft flying and provide display information to the crew. It requires knowledge all the sensors that provide important flight data to the crew. These include engine, attitude, weapon status, heat, etc. Major interactions of the avionics group are shown in Fig 6.3.1-8.

Figure 6.2.1-8 Avionics Discipline Interactions

Click here for Picture

Propulsion

Figure 6.3.1-9 Propulsion Discipline Interactions

The tasks performed by the propulsion group are to carry out engine and airframe integration and analyze the installed engine performance. The group is respoonsible for steady-state and transient engine characteristcs. It also evaluates propulsion system effectivess and survivability. In many cases, it includes analysis of auxiliary power unit. Major interactions and breakdown of the propulsion group are shown in Figs. 6.3.1-9 and 6.3.1-10.

Click here for Picture

Figure 6.3.1-10 Propulsion Discipline Breakdown

Click here for Picture

Subsystems

Figure 6.3.1-11 Susbystems Discipline Interactions

The subsystems group is responsible for three main tasks: power generation and distribution, cooling, and heat disposal. It deals both electrical and hydraulic power. In cooling, it analyzes the refrigeration cycle. In heat disposal, it studies different methods of getting rid of the heat produced by equipment and crew. In doing so, it becomes responsible for fuel and secondary power systems as well. Major interactions and breakdown of the subsystems group are shown in Figs 6.3.1-11 and 6.3.1-12.

Figure 6.3.1-12 Susbystems Discipline Breakdown

Click here for Picture

Click here for Picture

Thermal Analysis

Figure 6.3.1-13 Thermodynamics Discipline Interactions

The thermodynamics group is reponsible for the thermodynamic profile of the aircraft. That includes avionics and other mechanical systems. It also computes the structural temperature, and hence the IR signature and develops methods for its suppression. It works with both environmental control systems and propulsion group to take care of both internal and external heat. Major interactions and breakdown of the thermodynamics group are shown in Figs 6.3.1-13 and 6.3.1-14.

Click here for Picture

Figure 6.3.1-14 Thermodynamics Discipline Breakdown



Weight/Mass Properties

Click here for Picture

Figure 6.3.1-15 Weight/Mass Properties Discipline Interactions

The weight/mass properties group is responsible for initial configuration design (which is heavily weight-driven as mentioned before). It tracks weight distribution and provides detailed accounting. It also is reponsible for designing ballast to ensure proper weight distribution and shifts in center-of-gravity are known. Major interactions and breakdown of the weight/mass properties group are shown in Figs 6.3.1-15 and 6.3.1-16.

Click here for Picture

Figure 6.3.1-16 Weight/Mass Properties Discipline Breakdown

Structures/Materials

Click here for Picture

Figure 6.3.1-17 Structures Discipline Interactions

The structures/materials group is responsible for many tasks. Among them, generation of aircraft model, stress and strain analysis, fatigue analysis, generation and verification of internal loads, material selection and analysis (including composites), structural optimization, reconciliation of finite-element analysis with test data, etc. Because of the number of tasks, the structures group usually is divided into several smaller subgroups. Major interactions, of the structures/materials group are shown in Figs 6.3.1-17 through 6.3.1-18.

Click here for Picture

Figure 6.3.1-18 Flowchart Of Major Design Phases In Structures

As mentioned previously (see Fig. 6.3.1-1), each of the physical disciplines and sub-disciplines requires inputs that come from outputs of other disciplines. The data flow between the various structures sub-disciplines is shown in Fig 6.3.1-19.

Click here for Picture

Figure 6.3.1-19 Mathematical Models And Data Flow Among Various Structure Sub-Disciplines

An example of the interactions and data flow between multiple disciplines in the aircraft design process is shown in Fig. 6.3.1-20.

Click here for Picture o

Figure 6.3.1-20 Interdisciplinary Data Transfer Flow Path

The data types passed among these disciplines are described in the following table.

Table 6.3.1-1 Description Of Data Sets Transferred Between Disciplines

DATA SET      DESCRIPTION                                                              
A2L           * Aerodynamic dynamic coefficients for: lift and side forces; rolling,   
              pitching and yawing moments. * Aerodynamic static coefficients for:      
              normal, side, and trim, forces; rolling, pitching and yawing moments.    
C2L           * Fuselage cross-sectional heights and widths at the body panel          
              boundary stations. * Surface reference plane coordinates, mean         
              camber slope, and upper surface slope * Geometric information needed     
              for computation of: coordinates, slopes, lengths, etc., of aerodynamic   
              & structural models; reference axes, lines and stations about which      
              running loads, shears, moments & torsions are calculated.                
C2W           * Surface reference plane coordinates and upper surface slope (right     
              surface for vertical surfaces).                                          
C2S           * Surface reference plane coordinates and upper surface slope (right     
              surface for vertical surfaces). * Geometry of a refined aerodynamics     
              model grid used for the calculation on moments, shears and torsions. *   
              Coordinates of all structural model node points in the airplane          
              reference system.                                                        
D2MS          * Mode Shapes at prescribed gear attachment points, generalized masses   
              and natural frequencies.                                                 
D2S           * Matrix of time histories of all inertial and applied forces and        
              moments at the nodes of the dynamics model. * Location in the plane of   
              the airplane reference system at which gust loads will be output from    
              the discrete gust loads program. * Time histories of wing and tail       
              shear, moments and torsion about swept and unswept axes, and shear and   
              moments at stations along the fuselage centerline.                       
L2S           * Geometry of aero model nodes and panel areas. * Adjusted thrust,       
              drag, angular velocities, and traslational and angular accelerations.    
              * Inertia loads at CG's of mass points due to translational and          
              angular accelerations and angular velocities. * Skin pressures at        
              upper, lower, left and right surfaces. * Running Loads and torsions at   
              specified wing  or body stations due to aerodynamic, inertia or          
              applied loads, in airplane reference system. * Loads normal to the       
              surface reference plane of the aerodynamics model.                       
MS2D          * Landing gear load time histories corresponding to catapulting,         
              arresting, and taxing conditions.                                        
MS2S          * Ratios of total airplane lift to lift at unit angle of attack, at      
              selected instants of time, corresponding to ground loading conditions.   
              * Vertical and drag load factors due to lift, engine thrust and          
              initial gear loads.  These factors are obtained for each of the          
              selected critical ground loading conditions.                             
SD2L          * Cap and shear panel loads due to moments, shears and torsions at       
              predetermined points on the aircraft model. * Critical search stations   
              at which moments, shears and torques will be calculated.                 
SD2S          * Area, thickness and moment of inertia for each structural element in   
              the structural model.                                                    
S2D           * A flexibility influence coefficient matrix for the dynamics model      
              relating displacements and rotations to unit loads and moments. * A      
              matrix that transforms panel point inertia and applied forces into any   
              type of internal loads.                                                  
S2L           * An influence coefficient matrix that relates streamwise rotations      
              and unit applied loads at the aero node points.                          
S2SD          * A matrix of influence coefficients used to determine structural        
              properties (bending and torsional stiffnesses).                          
W2L           * Overall gross weights, CG locations and inertias for various flight    
              conditions.                                                              
W2S/L         * Weight and inertias of concentrated masses. * X, Y, and Z              
              coordinates of concentrated masses in the airplane reference system. *   
              Weights in the Aero grid for distributed mass items in the wing (i.e.,   
              structure, fuel and control surfaces).                                   

6.3.2 Process Disciplines

The process disciplines of interest in an integrated product design are manufacturability, maintainability, reliability, and affordability (commonly referred to as the "ilities"). Although many existing tools, models and methodologies are currently used for defining specific processes and their associated costs, the process disciplines are currently not integrated well with design activities and do not provide the early manufacturing and cost feedback required to achieve design-to-cost affordability. During conceptual design, the design team is required to select various product configurations based on requirements without adequate decision support information.

6.3.3 Simulation Codes and Tools

The complex interplay between disciplines in the simulation-based design process occurs through the exchange of information generated by computational simulations in each of the disciplines. These simulations, as previously mentioned, can be divided into two major categories (see Fig. 6.3.1-1). Physical simulations associated with the disciplines governed by laws of (Newtonian) physics where "exact" answers typically can be computed provided that that dynamic modeling is properly carried out. Structural analysis and computational aerodynamics are good examples. Process simulations, on the other hand, refer to those associated with disciplines where human and other non-physical factors play a large role. Manufacturability and supportability are some of the examples. Physical simulations, having various levels of fidelity, have been under development for many years and are widely available. Process simulations and tools on the other hand are not as highly developed.

Generally, the "ilities", a term often used to encompass the process technologies, are not analyzed using rigorous mathematical models such as those used for aerodynamics or structural analysis. However, some of the relationships between product features and "ility" effects can be described in the form of math equations by analyzing data for statistical trends. In addition, physics-based simulations and non-linear finite element analysis can be used for specific manufacturing processes such as super plastic forming or autoclave curing. These models are constructed to analyze thermodynamic or elastic effects of a process and are useful in determining the producibility and the best control parameters for the process.

Most tools that are used today are process-based simulations or knowledge-based systems. Generally, process models are created for specific manufacturing processes such as sheet metal forming or machining. Each of the tools is driven by inputting information about the product features. Features can be viewed as information that refers to form or function of a part or product. There are both design features which are additive and manufacturing features which are generally based on material removal. Mapping from design to manufacturing can be difficult. CAD systems are evolving to have more and more feature-based design capability. Standard definition of feature sets will provide a better database structure for future integration of applications.

Click here for Picture

Figure 6.3.3-1 Cost Model Generation

An example scenario is the cost model (Fig. 6.3.3-1) developed by Northrop Grumman under the Affordable Composites Program. This cost model takes into consideration for member companies: rates, labor standards, material yield, scrap/rework, and process performance. Cost center rates are discretely developed for each major process such as fiber placement, autoclave curing, quality, hand lay-up, robotic fastening and machining. Product physical dimensions are part of the input. This includes geometric features such as skin thickness, length, width, perimeter inches, square feet, number of plies, cap thickness/length/width, stiffener thickness/length/height, flange width, material type and so on. Production standard modules were developed from team members best practices. This includes processes such as resin transfer molding, water jet trimming, inspection, hand lay-up, autotape lay-up, secondary bonding, robotic fastening, co-bonding, auto tow placement, rapid ply cutter and autoclave cure. Processes are further broken down to production operations such as support, maintenance, change support, discrepancy disposition, and corrective action development. Tooling costs are calculated on a life cycle basis that includes key parameters. The model makes probabilistic scrap and rework projections as well as risk assessment The model utilizes product descriptions and process descriptions as input. It is further integrated with improvement opportunity analysis that funnels process improvement ideas into a manufacturing discrete event simulation to validate process enhancements for continuous improvement. The output of the model is a cost summary.

In this scenario, the design features must be manually input into the model. Knowledge about processes and cost must continually be updated to make the model viable. The simulation allows analysis of "what if" scenarios and the cost of change.

Approaches to developing a range of process models are now becoming understood. The basic steps for knowledge-based module development are to:

· Gather Data - data must be of appropriate detail and scope for the module topic.

· Assimilate Data - the raw data must be sorted and put into formats which can be used in the next step.

· Develop Relationships - develop from the data relationships between the process features and the data. in the case of cost, this task involves mapping cost data to specific processes and product features. This mapping can involve statistical analysis.

· Identify Constraints - this can be done by consultation with the process experts, knowledge of capabilities, and analysis of data.

· Method Documentation - document the cost estimating relationships, producibility constraints, feature relations and methods used to automate each module.

· Develop computerized knowledge based system - using the feature definitions, data, and relationships.

Approaches to developing simulation-based process models are very similar to the knowledge-based approach described above except simulations generally require complete specifications before they can be executed. This problem can be surmounted by developing standard templates for the unknown data and continually refining the simulation model as more data is known. With each refinement, the result of the simulation will be more valid.

Historically, regression analysis has proved effective to develop relationships between design parameters and downstream effects on cost and supportability. Parametric cost models exist which leveraged this approach. Supportability codes exist which predict reliability and supportability of aircraft based on initial performance parameters. These codes are based on historical data and new designs must be analyzed based on complexity factors and relationships to historical aircraft data.

Ideally, activity-based cost databases can provide up-to-date cost feedback for processes. This would enable a direct tie to actual manufacturing data which is far more accurate and does not require manual update. The effects of continual process improvement would be reflected in the actual cost data gathered for specific processes. The challenge is to force a major accounting change in the aircraft industry and to determine the best way to group activities.

The assembly process is key to affordability. Early in the design, as depicted in Fig.6.3.3-2, assembly, as well as other process factors, must be analyzed at a top-down level to determine optimum product configurations. Presently, conceptual and preliminary design phases require that decisions be made with incomplete product definition since there are few tools that can be used at this stage to simulate the assembly process.

Recent advances in assembly simulation software and graphics capable hardware makes it possible to validate the design earlier in the design process when not all the product definition is known. Geometry for the "missing" pieces and needed tool designs are created within the simulation environment. Known geometry can be input directly from the source CAD system. The simulation model can incrementally check out various design alternatives and be used for validation in every phase of the design. Each subsequent phase will have more and more detail information.

The assembly process is more complex because the features must be defined and understood for "mating" relationships among the parts. Assembly is a 3D process and requires ergonomic and kinematics analysis to ensure that parts can be assembled as configured. Typical conceptual design scenario might involve trade studies to determine whether a unitized composite structure is more cost effective than a built-up metal structure. Cost models that only compare part costs will always favor the structure with the cheaper material and simpler manufacturing process. Simulation also provides a mechanism to validate maintainability using ergonomics. Major costs are in the rework/scrap resulting from mis-matched parts during assembly as well a repair of structure during maintenance of the product . The design must be optimized by analyzing the total product configuration for affordability, producibility, and supportability.

Click here for Picture

Figure 6.3.3-2 Manufacturing/Process Modeling

Simulation Code Matrix

In the process of baselining the simulation codes and tools available to support the implementation of the ASOP concept, the notion of a requirements matrix was developed. This matrix serves as a means of cataloging the availability of the necessary simulation tools and the design phase in which they are used. The matrix which was formulated, is arranged as a set of tables that order the software elements in a hierarchical form in three levels of categories and sub-categories. The major categories in the tables are:

1. Platform Design Codes and Tools

2. Manfacturing (mfg) Process Tools

3. Product Support Tools

4. Cost EstimationTools

5. Information Management Tools For Design and MFG Process Data

Each of these categories are further broken down into the following sub-categories:

1. Platform Design Codes and Tools

1.1 Vehicle management systems

1.2 Configuration development

1.3 Mass properties

1.4 System integration and "-ilities"

1.5 Structures and materials

1.6 Flight sciences (aero, loads and dynamics, propulsion, control, thermo)

1.7 Propulsion integration

1.8 Subsystems

1.9 Crew Systems

1.10 Avionics

1.11 Simulator

1.12 Environment

2. Manufacturing Process Tools

2.1 Planning

2.2 Tool design/fabrication

2.3 Quality

2.4 Producibilty

2.5 Procument, materials/supplier capability

2.6 Training, qualification

2.7 Production knowledge database

2.8 Test

3. Product Support Tools

3.1 Integrated logistics support (ILS - customer financed)

3.2 Contractor logistics support (CLS - contractor financed)

3.3 Spares

3.4 Engineering support tools

4. Cost Estimation Tools

To demonstrate the applicability of this matrix set to cataloging the available simulation codes, tables in the following subcategories have been completed by the participating companies indicated:

1.5 Structures and Materials (Northrop Grumman)

1.6 Flight Sciences (McDonnell Douglas)

2.1 Planning (Northrop Grumman)

2.4 Producibility (Northrop Grumman)

4.0 Cost Estimation Tools (Northrop Grumman)

These tables are presented in the following pages. The utilization categories in the tables indicated by CD, PD , FD and D/PV indicate respectively: Conceptual Design, Preliminary Design, Final Design and Design/Process Verification. A brief desription of each of the codes listed in these tables is presented in APPENDIX I.

Completion of this matix set by each of the members of a collaborative design team would be one of the first steps in initiating a joint product development using the ASOP concept, or any other collaborative design concept.

1.5 Structures and Materials

APPLICATION                     APPLICATION                                         
                                SOFTWARE                                            
CATEGORY         COMMERCIAL     GOVERN'T/PUBLIC   INDUSTRY          CD  PD  FD  D/  
                                DOMAIN            PROPRIETARY                   PV  
Structural     PANDA, PANDA2                      COGS (1) WISE,        X   X   X   
Design/Sizin                                      SAFE, AMSA,       X   X           
g/                                                STF67, STF69      X   X           
Layout(CD,                                                                          
PD, FD)                                                                             
External      NASTRAN            PANAIR           COGS M1 TO M5,        X   X   X   
Loads                                             L20 to L40, L42   X   X   X       
                                                  to LF14FSD,       X   X   X       
                                                  PANAIR (2), MMP   X   X           
                                                  APPLE                             
Global/Local                    COMET (Testbed)   COGS                  X   X   X   
Loads                                                                               
Linear        NASTRAN, ANSYS,   COMET             MBREA ASA, ACSM    X  X   X   X   
Structural    STAGS                                                     X   X   X   
Analysis                                                                            
Buckling      NASTRAN, ANSYS,   COMET             COGS  PANBUC,         X   X   X   
              STAGS, BOSOR4,                      STRIPS, SSPA,     X   X   X   X   
              BOSOR5                              ASA, ACSM         X   X   X       
                                                                    X   X   X       
Post-bucklin  STAGS PANDA2      COMET              DTORTH, SNAPPS    X  X   X   X   
g and                                                                   X           
nonlinear                                                                           
response                                                                            
Aeroelastici  NASTRAN                             COGS, FASTOP,         X   X   X   
ty and                                            GIRAF                             
Flutter                                                                             
Material      NASTRAN, ANSYS,   IPACS             COGS, HOLES           X   X   X   
Properties    STAGS, BOSOR5                       MACLAMINATE,      X   X   X       
(constitutiv                                      STRX, ASA, ACSM   X   X   X       
e,                                                                                  
strength,                                                                           
thermal,                                                                            
toughness,                                                                          
etc.)                                                                               
Fatigue         NASTRAN,                          ASA, FASFLX,      X   X   X       
              ANSYS,                              KNOTCHD           X   X   X   X   
              CAEDS/IDEAS                         FATLIFE2,             X   X   X   
                                                  CRACKS4D COGS,        X   X       
                                                  MBREA, XBE                        
                                                  FRANC2D & 3D (3)                  
Durability,                     FLAGRO            COGS, MBREA,       X  X   X   X   
damage                                            XBE SUBLAM,           X   X   X   
tolerance,                                        FATLIFE2,                         
and                                               CRACKS4D                          
inspection/N                                                                        
DE                                                                                  
Residual                                          COGS                  X   X   X   
Strength                                                                            
Thermal       NASTRAN, ANSYS,   COMET             COGS                  X   X   X   
Response      STAGS                                                                 
Structural                                        COGS, MBREA.          X   X   X   
joints                                            HOLES STEPS7,     X   X   X       
                                                  FASFLX,           X   X   X       
                                                  KNOTCHD, ACSM                     
Structural                                        WISE, SAFE,       X   X           
Weights                                           AMSA,                             
Structural    NASTRAN, ANSYS,                                                       
Acoustics                                                                           
Structural    NASTRAN, ANSYS,   MAGNA, COMET      COGS, V6, V7          X   X   X   
Dynamics &    STAGS PROTOFLEX                                           X   X   X   
Ride quality                                                                        
Vibration     NASTRAN, ANSYS,   COMET             COGS, FASTOP       X  X   X   X   
(modal        STAGS BOSOR4                                              X   X   X   
analysis)                                                                           
Smart         ANSYS             IPACS             PROTO--CSI            X   X   X   
Structure                                                                           
Test-         NASTRAN, ANSYS    IPACS, NESSUS     COGS               X  X   X   X   
coupon,                         FPI                                     X   X       
component,                                                                          
assemblies,                                                                         
full                                                                                
vehicles,                                                                           
certificatio                                                                        
n                                                                                   

NOTES: (1) COGS is a general purpose finite element analysis & optimization code that has a simple, flexible matrix analysis language called COMAP.

(2) PANAIR was modified by Grumman to account for wing flexibility.

(3) FRANC2D & 3D were developed by Cornell University under partial funding from Grumman.

1.6 Flight Sciences

APPLICATION                     APPLICATION                                         
                                SOFTWARE                                            
CATEGORY         COMMERCIAL     GOVERN'T/PUBLIC   INDUSTRY          CD  PD  FD  D/  
                                DOMAIN            PROPRIETARY                   PV  
Aerodynamics                                      MODSDF, CAD/UG    X   X   X       
-Performance                                      CVSUIT ACE 13     X   X   X   X   
(Computation                                      Additional        X   X           
s)                                                programs                          
  -                                               Digital HILIFT,                   
Performance                                       Missile DATCOM,   X   X   X       
(Databse                                          Digital DATCOM,                   
Development)                                      MODSDF                            
                                                  VECC/SHABP,                       
                                                  LODST,REALPLOT,H                  
                                                  IM                                
  -                                               MODSF WTDS,       X   X   X       
Performance                                       ADEPT, TABLEMAN                   
(Wind                                                                               
Tunnel                                                                              
Testing)                                                                            
  -                                               MODSF WTDS,       X   X   X       
Performance                                       ADEPT, TABLEMAN                   
(Flight                                                                             
Testing)                                                                            
  -                                               HULLLEX, RUF,                     
Performance                                       MECA, RECON92,                    
(Special                                          SALVO8                            
Skills)                                                                             
   -                                              WTDS, ADEPT,                      
Stability &                                       TABLEMAN PRISM,   X   X   X       
Control                                           DYNAMIC MODSDF,   X   X           
(Database                                         Digital DATCOM                    
Development)                                      VORTEX-LATTICE                    
   -                                              WTDS, ADEPT,                      
Stability &                                       TABLEMAN                          
Control                                                                             
(Wind                                                                               
Tunnel                                                                              
Testing)                                                                            
   -                                              RECON92,                          
Stability &                                       SALVO8, MECA                      
Control                                                                             
(Special                                                                            
Skills)                                                                             
   - Store                                        MODSDF,           X   X   X       
Separation                                        COLLIDE, AEROSDF                  
(Trajectory                                                                         
Analysis)                                                                           
   - Store                                        WTDS, ADEPT,                      
Separation                                        TABLEMAN                          
(Proximity                                                                          
Database)                                                                           
   - Store                                        WTDS, ADEPT                       
Separation                                                                          
(Wind                                                                               
Tunnel                                                                              
Testing)                                                                            
   - Store                                        MODSDF            X   X   X   X   
Separation                                                                          
(FlightTesti                                                                        
ng)                                                                                 
Configuratio                                      CADE, KC14,                       
n Synthesis                                       LODST, ASVS,                      
                                                  HAVSO                             
CFD                              FAST, PLOT3D      MACGS, NASTD,                    
-Configurati                    FAST, PLOT3D      CFPOST MACGS,     X   X   X   X   
on                              FAST, PLOT3D      NASTD, CFPOST     X   X   X       
screening                       FAST, PLOT3D      MACGS, NASTD,     X   X   X       
-Performance                    FAST, PLOT3D      CFPOST MACGS,     X   X           
data                                              NASTD, CFPOST     X   X           
-Diagnostics                                      MACGS, NASTD,                     
-High lift                                        CFPOST                            
-Store                                                                              
carriage                                                                            
Thermal                                            HEATRAN,                         
analysis                                          MARTHAN,                          
General                                           P/THERMAL,                        
Heat                                              PATHEAT                           
Transfer                                                                            
                                                   ALOOP, CAECS,     X   X   X   X  
Environmenta                                      ICCA                              
l Control                                                                           
Systems                                                                             
                                                   THERMPROP TANKQ   X   X       X  
Thermal/Tran                                                                X       
sport                                                                       X       
Properties                                                                          
Cryogenics                                                                          
                                CFL3D, MALIK,     AIR3D,                            
Aerodynamic                     LSA, SCURRY       AFWAL/PNS,        X   X   X   X   
Heating                         MINIVER STAPAT,   BLIMPK, SCHNOZ,       X   X   X   
- Empirical                     AEROHEAT CEBECI   SCRAM, VSLNQH         X   X   X   
-                               HERBERT PSE,      ATTAC, PATMIN             X   X   
Streamline                      FIDAP[            ACTIVEX,                  X   X   
- Boundary                                        ACTINV4,                  X   X   
Layer    -                                        ACTIVLE2, CYLA2                   
CFD &                                                                               
Specialized                                                                         
- Special                                                                           
Methods                                                                             
  Radiation   NEVADA, VIEW                                          X   X   X   X   
View Factors                                                                        
  Thermal      FIDAP  FIDAP          LEWICE       ATM, ICCA             X   X   X   
Management    FIDAP NEVADA      CFL3D-E           CAPTEM, HELICS    X   X   X   X   
- Crew                                            FATSO TUBEFLOW    X   X   X   X   
Station                                           ACE, CMA,             X   X   X   
- Thermal                                         SPECTRE ICEHEAT       X   X   X   
Protection                                        NASTD                 X   X   X   
- Dcut Flow                                                             X   X   X   
- Ablation                                                              X   X   X   
- Icing                                                                             
- CFD                                                                               
Tehrmal                                                                             
-Spacecraft                                                                         
Environment                                                                         
  IR                                              COOL IR, IR                       
Signature                                         COOL, IRIMG3D,    X   X   X   X   
                                                  NAP,NCSD,                         
                                                  QUICKIR, RADIF,                   
                                                  SPIRITS                           
  Support                                          GABRIEL,                         
Programs                                          MCSORT,           X   X   X   X   
- Graphics                                        PLOTTER, PLUTO    X   X   X   X   
-                                                 ADAMS, ANGEL                      
Miscellaneou                                                                        
s                                                                                   
Guidance/Nav  MATLAB,                             DEVSIM, MODSDF,                   
igation/      MATRIX-X                            RUNFQR, SLAP      X   X   X   X   
Control       CONTROL-C, CSSL                     GENAERO,          X   X   X   X   
              IV                                  HOLIST, HSR,                      
                                                  VECTOR GSC                        
Propulsion                                        VEGAS,                            
                                                  DEFGEOMB,         X   X   X       
                                                  DEFGEOMC, NIDA,       X           
                                                  NNEP, PSIP,           X           
                                                  GETUP, IMS,                       
                                                  MACGS, NASTD,                     
                                                  CFPOST DUXX,                      
                                                  FLIPP, RSCDIFF,                   
                                                  DATEN, EJECTOR,                   
                                                  HOTJET, XGAS,                     
                                                  DRAGDRS,                          

2.1 Planning

APPLICATION                     APPLICATION                                         
                                SOFTWARE                                            
CATEGORY         COMMERCIAL     GOVERN'T/PUBLIC   INDUSTRY          CD  PD  FD  D/  
                                DOMAIN            PROPRIETARY                   PV  
Assembly       IGRIP                                                            X   
Planning                                                                            
Advanced &                                        CCDP                          X   
detailed                                                                            
work                                                                                
instructions                                                                        

2.4 Producibility

APPLICATION                     APPLICATION                                         
                                SOFTWARE                                            
CATEGORY         COMMERCIAL     GOVERN'T/PUBLIC   INDUSTRY          CD  PD  FD  D/  
                                DOMAIN            PROPRIETARY                   PV  
Producibilit                                      CAPES                         X   
y Code                                                                              
Ergonomics                                                                          

4.0 Cost Estimation Tools
APPLICATION                     APPLICATION                                         
                                SOFTWARE                                            
CATEGORY         COMMERCIAL     GOVERN'T/PUBLIC   INDUSTRY          CD  PD  FD  D/  
                                DOMAIN            PROPRIETARY                   PV  
Cost                                              CAPES FVCM TOPS               X   
Estimation                                                                      X   
Code                                                                            X   

APPENDICES

APPENDIX I - Simulation Code Descriptions

Presented below are brief descriptions of the simulation codes included in the sample tables presented in Section 6.3.3, Pgs. 77-80.

1.5 Structures and Materials:

ACSM - ADVANCED COMPOSITES STRUCTURES MANUAL

This MacIntosh/Hypercard program provides an efficient method of performing stress and buckling analyses and other labor intensive analyses now commonly done by hand or less user-friendly, stand-alone programs.

The current capabilities of ACSM are as follows:

* Lamination Theory

* Plate Buckling

* Mechanical Joints

* Material Allowables

* Environmental Effects

* Curved Beams

* Section Properties.

AMSA - AEROSURFACE MULTIPLE STATION ANALYSIS, FOR BOXBEAM WEIGHT

AMSA - Aerosurface Multi-Station Analysis Program A computer program that calculates the basic torque box weight of aerodynamic surface in metallic and/or advanced-composite materials utilizing preliminary applied loads and aerosurface geometry. A total surface weight is derived by calculating the remainder of the structure empirically

ANSYS - ENGINEERING ANALYSIS SYSTEM

An extensive structural- and thermal-analysis package from Swanson Analysis Systems that is used for linear stress, buckling, vibration, and transient response analyses. Its nonlinear transient-response analysis capability is especially powerful.

APPLE - AMSA PROGRAM PRELIMINARY LOADS ESTIMATE

APPLE - AMSA Program Preliminary Loads Estimate (RAVES Program W17)

A computer program that generates loads for use in the initial phases of Preliminary design so that MPAC personnel may determine an early estimate of the weight of the wing and tails. This program also interfaces with AMSA and the results may be plotted with APPLEPLT.

ASA - AUTOMATED STRESS ANALYSIS (VARIOUS)

The Automated Stress Analysis (ASA) project provides a more efficient method of performing, documenting and archiving detailed stress analyses. Its emphasis is to provide a Desktop Engineering Environment (Macintosh) for those labor intensive analyses now commonly performed by hand or less user-friendly, stand-alone programs.

The current listing of the ASA program capability is as follows:

* Column Buckling (stepped columns for various boundary conditions)

* Combined Stresses (inplane bi-axial plus shear loading)

* Databases (materials and fasteners)

* Excel Programs (moments inertia, loads on a rivet pattern)

* Fasflx (joint flexibility analysis)

* Knotchd (determines stress conc. factors for fatigue life pred.)

* Maclugs (axial, transverse, & oblique lug analysis)

* Panel Buckling (loaded in compression or shear for various b.c.'s)

* Splice (1D splice analysis)

BOSOR4 - ELASTIC BUCKLING OF SHELLS

INTERACTIVE PROGRAM FOR STRESS, STABILITY, AND VIBRATION OF COMPLEX, BRANCHED ELASTIC SHELLS OF REVOLUTION.

BOSOR4 performs stress, stability, and modal vibration analysis of complex branched shells of revolution made of elastic material. It can be used to analyze prismatic shells and panels. It perform moderately large deflection axi-symmetric stress analysis, small deflection non-symmetric stress analysis, modal vibration with axi-symmetric or non-symmetric prestress included, and buckling analysis with axi-symmetric or non-symmetric prestress. Symmetric and non-symmetric buckling modes can be found. There is provision for realistic engineering details such as eccentric load paths, internal supports, arbitrary branching conditions, and a library of wall constructions, including layered orthotropic with temperature-dependent material properties. The user provides input data in an interactive mode. Plots may be obtained of prebuckled states, and buckling or vibration mode shapes.

BOSOR5 - PLASTIC/CREEP BUCKLING OF SHELLS

INTERACTIVE PROGRAM FOR BUCKLING OF COMPLEX, BRANCHED SHELLS OF REVOLUTION INCLUDING LARGE DEFLECTIONS, ELASTIC-PLASTIC MATERIAL BEHAVIOR AND CREEP.

BOSOR5 performs axi-symmetric collapse and non-symmetric bifurcation buckling including elastic-plastic material behavior and creep. It does not supersede BOSOR4, as it has no modal vibration capability or linear non-symmetric stress analysis capability. It will handle segmented or branched, multi-lateral, stiffened shells. The wall may be layered. Smeared stringers and smeared or discrete rings are permitted to go plastic. Only static analysis is performed by BOSOR5. The strategy for solution of the nonlinear prebuckling problem is such that the user obtains reasonably accurate answers even if very large load or time steps are used. This strategy is based on a sub incremental iteration method in which the size of the sub increment is automatically determined so that the change in stress is less than a certain prescribed percentage of the effective stress. Discrete rings of arbitrary cross section are considered to be assemblages of thin rectangular elements. The input is interactive, as with BOSOR4, and the plotting capability is the same as that in BOSOR4. Cold bending and welding fabrication processes can be simulated by application of thermal loading cycles before application of a service load such as external pressure.

CAEDS/IDEAS - COMPUTER AIDED ENGINEERING DESIGN SYSTEM

Grumman has implemented I-DEAS (CAEDS on IBM platforms) for finite element modeling tasks. With I-DEAS Finite Element Modeling modules, meshing can be created directly from I-DEAS solid models, developed wireframe or from imported geometry from CAD packages. Automatic, mapped and discrete meshing are supported. Adaptive meshing feature for the automatic refinement based on element distortion or analysis results are also available. Post processing, including color contour and animated deformations, are used for analysis checkout and presentation.

I-DEAS Model solution provides an integrated on line solver as well as interfaces to external solvers (NASTRAN ANSYS ABACUS). In addition open architecture features provide an environment for the integration of Grumman's ASTRAL analysis and optimization system.

COGS - COMAP ASTRAL INTERACTIVE GRAPHICS SYSTEM

The COGS system contains capability for generating the data associated with a structural finite element model, a lifting surface airloads model and a dynamic transient response model. Modules of the system can calculate; aerodynamic influence coefficients, aerodynamic node loads, inertia loads due to aircraft accelerations, transient dynamic loads due to various forcing functions such as aircraft landing and catapulting. Other modules can transform these loads from their respective models to the structural model and calculate and interactively plot moment, shear and torsion curves as well as envelopes of these curves. COGS can also calculate: internal loads, stresses, strains, deflections, vibration modes and frequencies, flexibility coefficients for either dynamic analysis or for aeroelastic corrections, and buckling loads and mode shapes. The system can also perform; multilevel substructuring, plastic analysis, non-linear variable contact analysis and crack growth calculations. The COGS system also contains modules for optimizing a structure for strength as well as for deflection, frequency, aeroelastic and flutter requirements.

Realistic structural design requires that many technologies be integrated in a highly organized manner. The Grumman developed and maintained COGS computing system has been designed to specifically function in this stringent design/analysis environment. COGS is an integrated computing system that gives a "co-located design - analysis - manufacturing team" the ability to analyze and design structure in a fully integrated interactive graphics environment. As used here, the word analyze implies the ability to calculate all external loads due to various conditions such as; maneuvers, gusts, landing, catapulting, taxiing, and thermal environment as well as calculating the response of the structure to these loads including: internal loads, deflections, mode shapes, frequencies, stresses, strains, etc. The word design implies sizing the structure so as to maintain structural integrity while satisfying specified requirements on deflections, frequency, flutter speed and aeroelastic behavior.

The basic approach that has been followed in developing the COGS system has been to modify and incorporate existing capability where it exists; and to investigate, evaluate and incorporate 3rd party software where appropriate. The heart of the COGS system (COMAP/ASTRAL Interactive Graphic System) is the highly modular, language driven ASTRAL/COMAP finite element analysis system with its associated interactive data management capability. ASTRAL/COMAP is an automated structural analysis (FEA) program built on top of a general matrix capability (COMAP). Data is stored and retrieved in the COGS system in the form of matrices or pseudo matrices. Many of the original "Grumman IDEAS" programs have been added to the ASTRAL/COMAP system in order to take advantage of a common data format, a common database, and the COGS archive and recovery procedures. Computing modules from the Grumman developed FASTOP system have also been added to ASTRAL/COMAP to given the system the ability to perform structural optimization tasks within a realistic design environment. The COGS system also has data conversion routines which interface with NASTRAN.

During recent years, the COGS system has been ported to a work station computing platform. WS-COGS (Work Station - COGS), is a fully functional and updated version of the "main frame COGS system" which operates on the RS6000 class of UNIX workstations. It is integrated with the SDRC CAEDS analysis software which runs under a totally new X-Windows user interface. Interfacing with CATIA is currently accomplished through the SDRC CAEDS system.

COGS has and is being used in the analysis and design of a wide variety of Grumman's major projects including: F-14A, F-14D, A-6E, EA-6B, E-2C, C-2A, X-29, Lavi wing and vertical tail, V-22, C-17, Shuttle Wing, NPBIE, M161 Hydrofoil, PDX Tokamak, BSTS, JPATS, and JSTARS.

COMET (Testbed) - GENERAL NON-LINEAR FINITE ELEMENT CODE

The Computational Structural Mechanics branch of NASA LaRC has developed a computational structural analysis framework called COMET, previously referred to as the TESTBED, that has as its goals (1) the development of advanced structural analysis methods, and (2) the identification of requirements for next generation structural analysis software that will exploit new and emerging high-performance computers to reduce the design cycle time for new airframe structures or for modification of existing airframes. COMET was designed to provide a common, highly modular, machine independent, structural analysis environment for three types of users: engineers solving complex structural analysis problems, researchers developing advanced structural analysis methods, and developers designing the software architecture to exploit new multiprocessor and vector computers.

CRACKS4D - FATIGUE CRACK GROWTH LIFE

The CRAKS4D program computes structural life based on crack growth for a wide variety of fatigue problems. The program is used primarily to determine the crack propagation life of a fatigue critical geometry in aircraft structures. The 'two-stage' fatigue analysis is the combination of the crack initiation life from FATLIFE2 and the crack propagation life from CRAKS4D.

Many stress intensity solutions for varied geometry's found in literature have been incorporated into the program. Analyses can be performed with constant amplitude load spectra as well as variable amplitude fatigue load spectra. Several equations for cyclic crack growth rates, and load interaction retardation models, are available

DTORTH - DIAGONAL TENSION ANAL. OF CURVED ORTHOTROPIC PANELS

DTORTH -Diagonal Tension Analysis of Curved ORTHotropic Panels (RAVES Program W40)

Stability and strength analysis of blade, J, and hat stiffened composite panels. Performs a series of stability checks on skin and stiffener. Post buckled strength is estimated using a modified version of Kuhn diagonal tension theory.

FATLIFE2 - FATIGUE LIFE DESIGN CURVES

The FATLIFE2 program predicts fatigue life for notched structural members based on the Grumman local strain method. The program predicts one-stage fatigue failure life, crack initiation life for two-stage fatigue analyses, and does life screening for determining critical members in a Finite Element Model (FEM) substructure. Program is also used to convert the sequence/load file input format to the 'flight-by-flight' format.

FASFLX - FASTENER FLEXIBILITY & EFFECTIVE BEARING THICKNESS

FASFLX is computer program which calculate stiffnesses and parameters used for fatigue life predictions of mechanically fastened joints.

FASTOP - FLUTTER & STRENGTH OPTIMIZATION PROGRAM

FASTOP is an automated procedure for flutter and strength analysis and optimization of aerospace vehicles. It performs multi-disciplinary analyses and near-minimum-weight structural sizing of a lifting surface. Two major subprograms are used to perform successive analysis and resizing functions in a single computer submission. The strength-optimization program (SOP) performs applied-load calculations, strength and flexibility analyses, and automatic resizing of a structural idealization to achieve a fully stressed design. The flutter-optimization program (FOP) performs a vibration-mode analysis, flutter analysis, and automatic structural resizing, if required, to achieve a desired increased flutter speed.

The FOP flutter-analysis module, in addition to contributing to the structural sizing process, is the primary Grumman tool for assessments of aircraft flutter characteristics. Oscillatory pressures and generalized aerodynamic forces are computed for a given set of vibration modes using either the subsonic doublet-lattice or supersonic Mach-box method. A supersonic harmonic-gradient procedure that uses a surface-geometry idealization similar to the subsonic doublet-lattice method was recently added. Flutter solutions may be obtained by either the more computationally efficient "k" method or the more physically realistic "p-k" method. To allow the user to study a flutter mechanism, several parameter variations have been automated.

FLAGRO - NASA FATIGUE CRACK GROWTH LIFE PROGRAM

The NASA / FLAGRO program computes structural life based on crack growth for a wide variety of fatigue problems. This program is for used to determine crack propagation life on NASA structure. While the FLAGRO program has a large data base of material constants and an adequate selection of stress intensity factor solutions, the input spectrum format is not currently compatible with existing Grumman formats.

FPI - GENERAL PROBABILISTIC INTEGRATION CODE

FPI (Fast Probability Integration) is a general, approximate technique for obtaining probabilistic distributions (probability density & cumulative distribution functions) of response variables (performance functions) that are functions of random variables. The major advantage of FPI is its speed: it is at least an order-of-magnitude more efficient than the conventional Monte Carlo simulation method. This is especially true in the important tail regions of the distributions, i.e., at very low or high probabilities, because, in contrast to Monte Carlo simulation, the FPI solution time is independent of the probability level. FPI contains a number of advanced methods in order to compute accurate results quickly. FPI presently contains FORM/SORM, convolution, advance first order, conventional Monte Carlo, importance sampling, and adaptive importance sampling solution methods. Any of these methods can be used in conjunction with the advanced mean value algorithm with iterations (AMV+). Also, FPI calculates very useful probabilistic sensitivity factors that rank the relative influence of the random variables on the response.

FRANC2D & 3D - FRacture ANalysis Code 2D and 3D

These systems were designed expressly for the deterministic simulation of arbitrary crack growth in complex structures. Their unique features include topological data structures, automatic remeshing to accommodate arbitrary crack growth, and state-of-the-art engineering workstation user interfaces. They have been applied to a wide range of cracking problems in a number of industrial sectors including aircraft structures and powerplants at companies such as General Dynamics, Grumman Aerospace Corporation, General Electric, and Pratt and Whitney. The STAGSgeneral purpose shell analysis program has been mated to FRANC3D to create a simulator of growth of multiple curvilinear cracks in arbitrary, stiffened, thin shell structures in the presence of geometrical and material nonlinear behavior.

GIRAF - GENERALIZED INDICIAL RESPONSE & FLUTTER (Program V23)

Utilizes a transformation of harmonic unsteady aerodynamic forces to an indicial form in the time domain to permit transient aeroelastic response calculations as well as flutter analyses. The "p" method flutter-solution option permits realistic subcritical damping trends to be obtained for correlation with test results. Extra equations may be defined by the user to represent effects such as control-system dynamics and kinematic relationships, or to obtain additional output such as various types of structural loads. Forcing function options include: excitations commonly used for flight flutter testing; vertical and lateral discrete and harmonic gusts; and user-defined force time histories.

HOLES - STRENGTH OF COMPOSITES WITH HOLES

The HOLES code is designed to aid in the failure analysis of composite laminates containing open or loaded holes The code incorporates a stress analysis routine capable of modeling many of the common geometry's that occur in composite structure. The Whitney-Nuismer failure criterion is used, in which the code searches for the maximum allowable strain at a specified distance from the edge of the hole. The distance "the characteristic dimension" depends upon the material and laminate properties and is determined by experiment. Versions of this code are available on Macintosh and HP9845 computers.

IPACS - PROBABILISTIC ANALYSIS OF COMPOSITE STRUCTURES

IPACS (Integrated Probabilistic Assessment of Composite Structures) performs efficient probabilistic analysis of laminated composite structures. Basically, IPACS synergistically combines the following two probabilistic codes into one integrated computer program: PICAN for material (point) response and NESSUS for structural response. The input to IPACS includes mean values, standard deviations and assumed distributions for constituent properties and fabrication variables. Based on uncertainties in these random variables, IPACS computes means, standard deviations, probability density functions, cumulative distribution functions and probabilistic sensitivity factors for (1) material properties at the ply and laminate levels and (2) structural responses at the structures level. We have formulated and implemented a procedure that permits IPACS to predict structural reliability for open-hole specimens under longitudinal tension loading.

KNOTCHD - NOTCH STRESS AT A HOLE

KnotchD is a computer program which analyzes a single fastener hole in a eccentrically loaded plate and determines the stress concentration factors for fatigue life predictions. The types of fastener analyzed include standard types, protruding or countersunk, and interference-fit. Pin loads can be balanced by a combination of tension and shear.

L20 - INERTIAL LOADS - USER'S MANUAL

Computes forces and moments at locations of panel-point masses due to maneuver accelerations and angular velocities. Input data includes distributed weights, inertia's, and associated geometry for each aircraft component (e. g., wing, forward fuselage, or fin). An output file is created for use in finite-element structural analyses.

L20X - FUSELAGE NET LOADS PROGRAM

Computes fuselage air, inertia and net integrated running loads at locations of panel-point masses due to maneuver accelerations and angular velocities. Input data includes, distributed weights, inertias, fuselage running air loads, concentrated masses and associated geometry for each aircraft component (e.g., wing, fuselage, vertical, and horizontal stabilizers). An output file of integrated fuselage running loads is created for use in the finite-element structural analysis.

L23 - MANEUVERS USER'S MANUAL-TIME HISTORIES & CRITICAL CONDITIONS

First transforms coefficients and derivatives to appropriate airplane reference system, if required, and corrects aerodynamic data for structural twist. The main portion of the program solves the equations of motion for responses to control inputs. Provision is made for constraints such as available pilot effort and maximum control-surface hinge moment. External and internal component loads are computed based on unit distributions of air and inertia loads that are supplied as input.

L24 - FLEXIBLE-A/C DISCRETE GUST LOADS (SYM)

Computes time histories of flexible-aircraft motions and loads due to various vertical-gust-velocity profiles with spanwise uniformity. The airframe idealization consists of two rigid-body modes (vertical translation and pitch) plus symmetric free-free vibration modes based on a beam-type model. The aerodynamic idealization is based on modified strip theory, and unsteady lift effects are represented by means of auxiliary differential equations developed from indicial lift functions. The program output includes shear, bending-moment, and torsion time histories, as well as aerodynamics-model node loads at selected time points for use in finite-element structural analyses.

L26 - FLEXIBLE-A/C POWER SPECTRAL GUST LOADS (SYM) WITH RANDOM TURBULENCE

Computes statistical variations of flexible-aircraft motions and loads due to random vertical turbulence with spanwise uniformity. Airframe and aerodynamic idealizations are the same as in L24. The following results are computed for each response parameter: (1) frequency-response function (responses to unit sinusoidal gusts with various frequencies); (2) response power-spectrum (product of turbulence power spectrum and square of frequency-response function); (3) gust-response factor and characteristic frequency; (4) number of exceedances per unit time for various response levels. Results for several flight conditions may be combined to obtain overall exceedance rates for a complete mission.

L29 - SIMPLIFIED FORMULA POWER-SPECTRAL GUST LOADS

Calculates exceedances per unit time of incremental normal load factor for various phases of an aircraft mission, and provides a summation for the total aircraft usage. Results are based on a single-degree-of-freedom response idealization (rigid-body vertical translation), a von Karman turbulence spectrum, and gust-intensity probability parameters from FAA-ADS-53.

L30 - SINGLE-DEGREE-of-FREEDOM GUST RESPONSE ANAL.- DISCRETE

Similar to L29, except that a discrete-gust model is assumed. Gust-intensity probability parameters are taken from NACA TN 4332.

L40 - SUBSONIC AERO LOADS ON NON-PLANAR SURFACES

Computes rigid or flexible static aerodynamic load distributions at selected subsonic Mach numbers for general configurations comprised of multiple interfering nonplanar surfaces and slender bodies. Rigid aerodynamic influence coefficients (AICs) are obtained by a vortex-lattice formulation relating angle-of-attack distributions to pressure distributions. These AICs are modified for flexibility effects, if desired, and then multiplied by user-specified angle-of-attack distributions to obtain pressure distributions. The final output consists of aerodynamics-model node loads for use in finite-element structural analyses, and shears, bending moments, and torsions.

L42 - COMBINED LOADS PROGRAM - USER'S MANUAL

For a given surface, this program combines and integrates aerodynamic-model node loads from L20, L24, and L40 to calculate shears, bending moments, and torsions. It also will integrate forces applied to structural nodes to check the transformed (aero-model to structures-model) load distributions.

L43 - SUPERSONIC AIRLOADS

Similar to L40, except that aerodynamic influence coefficients are obtained by the Woodward procedure, and configurations are restricted to combinations of surfaces only. An option is available to obtain a graphical display of the panel idealization.

LF14FSD - F-14 A/C LOAD BALANCE PROGRAM

F14 aircraft Load balance program. Input data includes aircraft weight, c.g., mass inertia, kinematics, exposed surface loads (e.g., wings, fins, stabilizers) and aerodynamic running fuselage loads. The aircraft inertia loads are placed in equilibrium by means of adjustments to the fuselage aerodynamic loads. An output file is created for use in finite-element structural analysis. It includes condition kinematics and node load sets.

M1 - SYMMETRICAL LANDING PROGRAM ANALYSIS OF SYMMETRIC LANDING CONDITIONS

Computes time histories of rigid-aircraft motions and selected loads due to either symmetrical shipboard arrestments or field landings. Aerodynamic forces are approximated by the resultant lift and moment on the rigid aircraft as well as incremental tail lift due to aircraft pitching. The program generates a file containing time histories of landing-gear and arresting-hook attachment-point loads for use in airframe transient-response calculations.

M2 - NOSE TOW CATAPULTING PROGRAM

M2 is a method to predict dynamic loads during nose tow catapulting, including airframe flexibility. It computes time histories of landing-gear loads and aircraft motions induced during the early part of a nose-tow catapult launch when transient loads due to holdback release are prominent. Airframe flexibility is accounted for by introducing symmetric free-free vibration mode shapes. The program generates a file containing time histories of landing-gear attachment-point loads for use in airframe transient-response calculations.

M3 - DYNAMICS OF UNSYMMETRICAL LANDING PROGRAM

Computes time histories of flexible-aircraft motions and selected loads due to unsymmetrical landings. The airframe idealization consists of six rigid-body degrees of freedom plus symmetric and antisymmetric free-free vibration mode shapes. The gear idealization can include both articulating behavior and bending flexibility. Aerodynamic forces are approximated by the resultant lift and moment on the rigid aircraft as well as incremental tail lift due to aircraft pitching. The program generates a file containing time histories of landing-gear and arresting-hook attachment loads for use in airframe transient-response calculations.

M4 - A METHOD OF PREDICTING DYNAMIC LOADS DURINGSYMMETRICAL A/C TAXIING

Computes time histories of aircraft motions and loads due to taxiing over unyielding terrain having arbitrary height variations in the direction of travel. The aircraft idealization includes the non-linear load-stroke characteristics of the tires and the oleo-pneumatic shock struts, free-free symmetric vibration mode shapes, and gross aerodynamic forces. The program output includes a variety of responses and loads (e.g., shears, bending moments, and torsions) computed from user-specified coefficients. A file containing time histories of shock-strut vertical loads for use in airframe transient-response calculations also may be obtained.

M5 - LANDING GEAR OBSTACLE ENCOUNTER

Computes time histories of landing-gear vertical loads as the gear rolls over an obstacle. The gear idealization includes nonlinear load-stroke characteristics, velocity-squared damping, bearing friction forces, compressive flexibility of the hydraulic oil, and cylinder wall growth. Flexibility of the trunnion attachment to the fuselage, axle flexibility, and overall aircraft flexibility as represented by free-free vibration mode shapes also are included. The program generates a file containing time histories of trunnion vertical load for use in airframe transient-response calculations.

MACLAMINATE - COLLECTION OF COMPOSITE PLATE ANALYSIS ROUTINES

MACLAMINATE is an integrated collection of routines for the analysis of laminated composite plates. The routines emphasis those procedures which require full stacking sequence information. The routines currently included in MACLAMINATE are:

1. Material allowables and user materials databases.

2. Laminate A, B, and D stiffness matrices for general (unsymmetric and unbalanced) laminates. Alternate forms of the matrices are also available, including the inverse of A and D, and the reduced A and D matrices. Engineering constants (Young's modulus, shear modulus, and Poisson's ratio) are also calculated.

3. Thermal expansion coefficients and thermal curvatures for unsymmetric laminates.

4. A generalized procedure for determining laminate strains, curvatures, load intensities, and moments, based on any consistent combination of knowns and unknowns.

5. Layer-by-layer stresses and strains, along with first-ply-failure margins based on one of several standard failure theories. Layer stresses include residual thermal effects.

6. Buckling of rectangular plates. Two buckling solutions are implemented. The first is a Ritz solution for a simply-supported plate. This solution is preferred when shear loads are present and the plate aspect ratio is close to one, or when an unbalanced laminate is used. The other solution is based on the STRIPS formulation and can solve for any combination of classical boundary conditions on two opposing edges. Both solutions can handle any combination of inplane loads, and use thick plate (shear deformable) theory.

MAGNA - LARGE SCALE F.E. SYSTEM FOR NONLINEAR ANALYSIS OF STRUCTURES

The MAGNA program is a large scale finite element system for the nonlinear, dynamic and static analysis of structures. It was developed to specifically address the bird-strike analysis of aircraft windshields by the University of Datyon Research Institute under contract to the Flight Dynamics Laboratory at the Wright-Paterson Air Force Base. It is also applicable to many other types of nonlinear structural response problems and it can interface with PATRAN

MMP - MASTERS MANEUVERS PROGRAM - COMPUTES LOADS ASSOCIATED WITH TIME HISTORIES & CONDITION SEARCH

Calculates six degree-of-freedom aircraft response and associated component loads for specification flight loads maneuvers; stores output for subsequent analysis. Pilot inputs are computed by a recursive procedure which includes the flight control system. Coordination with the Guidance and Control version of the program is maintained through the use of common core subroutines, aerodynamic data tables and control laws. A condition search option tracks component loads within time histories and selects critical conditions based on structural search criteria. The program will calculate discrete gust loads, including dynamic modes and unsteady aerodynamic effects, and will also determine the aerodynamic increments required to match flight test time histories.

MRBEA - 2D BOUNDARY ELEMENT ANALYSIS

The Multi-Region Boundary Element Analysis (MRBEA) program is a solution only processor which resides on the Cray Y-MP computer for the analyzing two dimensional elastic, variable contact and linear elastic fracture mechanics models using the boundary element method. The MRBEA program has been developed to meet the demands of the user community, to include the following capabilities: The ability to model multiple-regions, this allows for changes in material and/or thickness effects. Allowing these multiple-regions to coincidence at a single point. Orthotropic material definition for analyzing composite structures, a boundary element to finite element interface allowing the user to use a boundary element model as a superelement. The ability to analyze more than one loading condition within a single run for fatigue analysis. A variable contact algorithm, used in conjunction with the point load capability, has been developed to analyze a wide variety of pin/sheet problems. The program is also capable of evaluating the stress intensity factors for Mode I and Mode II fracture problems by equating the classical elasticity stress solution to the boundary element solution in a small neighborhood around the crack tip.

NASTRAN (MSC)

An extensive structural-analysis package from the MacNeal-Schwendler Corporation that is used for linear stress, buckling, vibration, and transient response analyses. The ASTRAL/COMAP structural-analysis package includes translation routines from NASTRAN to COMAP format and vice versa.

NESSUS - PROBABILISTIC ANALYSIS OF COMPOSITE STRUCTURES

The NESSUS (Numerical Evaluation of Stochastic Structures Under Stress) probabilistic structural analysis computer program combines state-of-the-art probabilistical algorithms with general purpose structural analysis methods to compute probabilistic response and the reliability of engineering structures. Uncertainty in loading, material properties, geometry, boundary conditions, and initial conditions can be simulated. The structural analysis methods include nonlinear finite element and boundary element methods. The probability and reliability calculations are performed by the FPI (Fast Probability Integration) module of NESSUS.

PANAIR - PREDICTS SUBSONIC OR SUPERSONIC LINEAR POTENTIAL FLOWS ABOUT ARBITRARY CONFIG. USING HIGHER ORDER PANEL METHOD

PANAIR computes rigid or flexible aerodynamic loadings on general configurations for subsonic or supersonic Mach numbers. External surface contours are modeled by arbitrarily positioned piecewise linear quadrilateral panels, upon which linear pressure distributions are obtained. The pressure field is integrated on individual panels to obtain forces and moments, and across selected regions of panels to obtain shears, bending, and torsion. Further output provides distributions of pressure in user specified planes, and complete configuration pressure contours, which can be viewed graphically with the NASA program PLOT3D.

PANBUC - BUCKLING OF COMPOSITE PANELS & H/C CORE SANDWICH PANELS

This code determines the overall and local instability modes of failure for composite plates and honeycomb core sandwich panels in in-plane compression and/or shear loadings. The code is capable of analyzing both symmetric and unsymmetric composite plates and sandwich panels. The analysis includes the effects of interlaminar shear and membrane-bending coupling terms on the buckling load. Simply-supported or fully-clamped edge boundary conditions can be selected.

PANDA - BUCKLING OPTIMIZATION OF COMPOSITE PANELS

PANDA is an interactive program through which minimum weight designs of composite, elastic-plastic stiffened, cylindrical panels and complete cylindrical shells can be obtained subject to general and local buckling constraints and stress and strain constraints. The panels or shells are subjected to arbitrary combinations of uniform in-plane axial, circumferential, and shear loads. Nonlinear material effects are included if the material is isotropic or has stiffness in only one direction (as does a discrete or smeared stiffener). The panel can be stiffened with both stringers and rings. Several types of general and local buckling modes are introduced as constraints in the optimization process, including general instability, panel instability with either stringers or rings smeared out, local skin buckling, local crippling of stiffener segments, and general, panel, and local skin buckling including the effects of stiffener rolling. Certain stiffener rolling modes in which the panel skin does not deform but the cross section of the stiffener does deform are also accounted for.

PANDA2 - POSTBUCKLING OPTIMIZATION OF COMPOSITE PANELS

PANDA2 is an interactive program for minimum weight design of stiffened, composite panels with post-buckling and stress constraints. It finds minimum weight designs of laminated composite flat or curved cylindrical panels or cylindrical shells with stiffeners in one or two orthogonal directions. Stiffeners can be blades, tees, angles, or hats. Truss-core sandwich panels can also be handled. The panels or shells can be loaded by as many as five combinations of in-plane loads, edge moments, normal pressure, and temperature. Transverse shear deformation effects are included. The material properties can be temperature-dependent. Panels can be optimized for service in their locally postbuckled states. The presence of overall (bowing) imperfections as well as local imperfections in the form of the local buckling mode are included. Constraints on the design include buckling, displacement and stress. PANDA2 includes processor, STAGSMODEL, that automatically generates an input file for the STAGS computer code. Thus, STAGS, which is a general purpose nonlinear finite element analyzer, can easily be used to check the load-carrying capacity of panels designed with PANDA2.

PROTO-CSI (Control-Structure Interaction)

PROTO-CSI is a toolbox that takes structural dynamics and translates (given user specs) into appropriate control models. PROTO-CSI greatly facilitates this process by reading data files from all popular finite element codes, like NASTRAN and ANSYS. Once the structural model is defined, the user can then specify actuators and sensor location, types, and scale factors. Initial conditions for position and velocity can be specified. Modifications are easily handled by PROTO-CSI. Changes in sensor or actuator locations, types, or scales can quickly be made from within the program. If the structural model is modified, the users need only to read in the new data while preserving the sensor and actuator specifications. Natural frequencies, damping factors, and generalized mass can be viewed and modified. The model can be displayed along with the node numbers. Mode shapes can be visualized and animated. When the model is fully specified, the appropriate state space matrices will appear as a file block in our proprietary CACSD environment, where control laws can be designed. The full closed-loop behavior of the structure can then be simulated and visualized as a 3D mesh model. The image can be rotated, translated, or scaled to provide the best view. PROTO-CSI will provide a great reduction in the time and effort required in designing control system where flexible vibrations are of great concern.

PROTOFLEX

This code provides an interactive menu-driven environment for creating state space plant models of flexible structures such as spacecraft, aircraft, or ground vehicles. It formulates the equations of motion describing the dynamic behavior of a flexible vehicle subject to externally applied time dependent loads such as unsteady aerodynamic forces, and internally generated loads such as controller forces. The code also formulates the Euler angle kinematic equations, and the measurement equations representing the response of several common types of physical sensors (e.g., accelerometers, rate gyros, etc.). Typically, PROTOFLEX functions as an interface between sources of modal data, such as vibration tests or finite element analysis codes such as NASTRAN, sources of aerodynamic data, such as wind tunnel or flight tests or unsteady aerodynamics codes such as FASTOP, and control system design codes such as PROTOBLOCK. PROTOFLEX outputs the plant and measurement equations in a format that can be readily imported into PROTOBLOCK, connected to the vehicle control system model, and then analyzed with MATLAB.

-ANALYTICAL FUSELAGE ESTIMATE,COMPUTES SHELL WEIGHT

SAFE - Semi-Analytical Fuselage EstimateA computer program that computes fuselage shell weight utilizing preliminary applied loads and fuselage geometric data. Empirical methods are then used to calculate the remainder of the fuselage weight.

SNAPPS - SNAPPS - Speddy Nonlinear Analysis of Postbuckled Panels in Shear/ NONLINEAR RESPONSE & DISBOND OF STIFFENED COMPOSITE SHEAR PANELS

This code is used for the prediction of disbond failure in a stiffened composite panel loaded in shear beyond initial buckling. The code performs the calculation of the maximum principal tensile stress in the panel immediately under the toe of the flange and enables margins-of-safety to be written against the transverse tensile strength measured in a simple coupon test. The analysis is based on the simplifying assumptions which were verified by a non-linear STAGS analysis.

SSPA - SIMPLE SUPPORTED COMPOSITE PLATES

SSPA (simply-supported plate analysis) is used to calculate the buckling loads for simply-supported, anisotropic plates. In addition, it can be used to find plate deflections and moments for an anisotropic plate under combined uniform normal pressure and inplane loads. The analysis uses a thick-plate theory which allows for transverse shear rotations. The program is written in FORTRAN, and is available for the Macintosh.

STAGS - NONLINEAR ANALYSIS OF STRUCTURES

STAGS (STructural Analysis of General Shells) is a finite element code for general-purpose nonlinear analysis of stiffened shell structures and general structures. Its capabilities include stress, buckling, vibration, and transient analyses with both geometric (postbuckling & nonlinear collapse) and material nonlinearities permitted in all analysis types. A latest version of the code, called STAGS2.0, has recently been released. New enhancements in this latest version include a transverse shear deformable shell element, more advanced nonlinear solution strategies, accumulation of buckling modal imperfection shapes from previous linear or nonlinear runs, a crack propagation capability, and more comprehensive pre- and post-processing features such as a link with PATRAN.

- COMPOSITE BONDED JOINT ANALYSIS

analyses the strength of a multiple-step lap-bonded joint. One or both adherends may be composite laminates which may be of hybrid materials. The elastic properties of the composites are found from lamination theory, while the strength is determined by the use of filament fracture, the Hill von-Mises yield criterion and the interlaminar shear cutoff failure criteria. The code modifies an elastic analysis of the joint by correcting for the non-linear behavior of the adhesive and, in addition, includes the thermal effects induced during the cure cycle. The user may interact with the code to make changes to joint geometry and/or laminates.

STF67 - STIFFENER 67 ANAL., FOR HAT-STIFFENED COMPRESSION PANELS

STF67 - STiFfener 67 Analysis Program.

A computer program to analyze hat-stiffened compression panels.

STF69 - STIFFENER 69 ANAL., FOR TORSIONAL FLEXURE OF J-SEC. SKIN

STF69 - STiFfener 69 Analysis Program

A computer program that analyzes torsional flexure of integral J section compression skins in diagonal tension.

STRIPS - BUCKLING OF STIFFENED COMPOSITE PANEL

The program STRIPS is used to find the critical buckling loads for prismatic structures made from composite materials. The method is based on the "exact" finite-strip method, in which displacements are assumed to vary sinusoidally in one direction, and the governing differential equations are solved in closed form to describe the variation of the displacements in the perpendicular direction. A thick-plate theory is used so that finite transverse shear stiffness effects are included. This code is capable of analyzing many of the common cross-sections that occur in aircraft construction, while requiring far less input data and computer resources than would be needed using conventional finite-element methods. The program in written in FORTRAN, and is available on BPCVAX and the Macintosh.

STRX - UNOTCHED STRENGTH OF COMPOSITE LAMINATES

This code is used for determining the average strength of unnotched unitary and hybrid composite laminates subjected to uniaxial or combined in-plane loadings. STRX is a ply-by-ply progressive failure analysis in which the the stiffness contribution of each ply is modified as the individual plies fail. The failure criteria used are maximum strain for the fiber and a modified Hill von-Mises yield criterion for the matrix. The code produces a stress-strain table detailing the failed plies, the changed stiffness and the final failure.

STRX (Fortran - VM/CMS Timeshare)

SUBLAM - SUBLAMINATE ANAL. METHOD FOR PREDICTING DISBOND AND DELAMINATION LOADS

SUBLAM was developed to provide accurate assessments of the forces that can delaminate composite laminates of cocured and bonded structures. The method uses interconnecting high-order plates to represent the cross-section of a structural element. The plates can be both stacked and connected end-to-end. When stacked, the interfacial tractions generated between two plates can be calculated, providing a measure of the delaminating stresses. The plate equations are solved exactly, thus giving accurate numerical results even in the cases where the stress gradients are steep.

The plate equations have been derived for completely general stacking sequences of composite plies, i.e., unsymmetric and unbalanced laminates are allowed. This generality, combined with the ability to stack plates, means that a single laminate can be broken into multiple plates, each representing a portion of the total laminate. Thus, the term sublaminate analysis has been applied to described the method. The generality of the method allows us to create models for determining interlaminar stresses in a simple laminate, bondline stresses in a joint, or stresses within a complex, built-up structural element. Both flat and cylindrically curved plates are available.

SUBLAM is written in FORTRAN, and is available on BPCVAX.

V6 - TRANSIENT RESPONSE LOAD PREPARATION PROGRAM

Transforms time histories of landing-gear and arresting-hook attachment-point loads obtained from the M programs into a linear combination of these loads desired as input to V7. If the original M-program load time histories are directly applicable as input to V7, the V6 program may be bypassed.

V7 - TRANSIENT RESPONSE COMPUTER PROGRAM FOR THE RESPONSE OF MECHANICAL SYS. TO COMBINED FORCE & MOTION EXCITATION

Computes flexible-airframe response time histories due to landing, taxiing, and catapulting. Forcing-function time histories, such as landing-gear attachment-point loads, may be either those obtained directly from the M programs, or a linear combination of the M-program loads obtained via V6. Output includes time histories of modal and physical motions, applied and generalized forces, and shears, bending moments, and torsions.

WISE-ONE - SYNTHESIZES AIRPLANE IN VERY EARLY STAGES OF DESIGN

WISE-ONE - Weight Integrated Sizing Evaluation - Level ONE

A computer program that synthesizes airplanes in the very early stages of design (prior to the creation of a 3-View drawing) by translating requirements into vehicle size (i.e., weight, geometry)

WISE-TWO - ANALYZES/OPTIMIZES AN A/C DESIGN, USES 3- VIEW DWG.

WISE-TWO - Weight Integrated Sizing Evaluation - Level TWO

Sharing some logic/code with WISE-ONE, this computer programs analyzes/optimizes an aircraft design by combining Level Two weight analysis (inputs from the 3-View drawing) with mission requirements.

XBE - 2-D BEA FOR WORKSTATION

The XBE program is a self-contained workstation Boundary Element Analysis code, which incorporates a complete graphical pre and post-processor along with the solution algorithm. The XBE computer code has two modes of operating expertise, a semi-automatic mode for new users, and a fully manual mode for the experienced user. In the semi-automatic mode, the pre-processor contains a certain amount of artificial intelligence such as auto-meshing algorithms to aid in the construction, analysis and post-processing of a boundary element analysis. The expert mode, allows the analyst complete control of all aspects of the analysis. Although this version was derived from the MRBEA program, currently the XBE package can only accommodate one region, and does not include the variable contact algorithm. Once a solution is formulated and entered automatically into the XBE database, the analyst can choose from a variety of post-processing options. These options include a color contour plot of the model results, stress and displacement plots of section cuts created on-the-fly, integration routines and deformed geometries.

1.6 Flight Sciences

CSSL IV

Continuous System Simulation Language is commercial software that has many canned routines and model components to facilitate linear simulation, a replacement for the older IBM CSMP. The user can be fairly lazy about sequencing models and calls; CSSL will order calculations appropriately. It has limited plotting facilities, good enough for diagnostics and quick jobs. It is run on the IBM mainframe.

DEVSIM

DEVSIM is a FORTRAN 77 based simulation of the C-17 airplane. It provides simple, user-friendly interface to the C-17 real time common software model of the airplane. The shell can be easily used for other analysis and simulation tasks. As with GSC, the model components are the same as those used for training and development motion-based simulators. Simulation can be driven with pilot control inputs (controls or surfaces) or state variables (speed, altitude, attitude). DEVSIM does not incorporate any plotting utilities, but the outputs of the simulation can be saved and plotted later using plotting software. DEVSIM has been run on HP Workstations, but is now running only on either VAX or IBM mainframe.

GENAERO

GENAERO is a generic linear simulation tool developed at MDA. It generates a time history file. GENAERO is used for flying qualities simulations. All aircraft specific data is contained in input files which are easily modified. GENAERO operates on a VAX/VMS computer system. GENAERO requires a basic aerodynamics model. Other flight characteristics, such as maximum and minimum achievable AOA and short period and dutch roll frequency and damping, must also be supplied. The dynamic response characteristics can be modified through the input files.

GSC

The Generic Simulation Code (GSC) was developed as a tool for generating Checkout and Proof-of-Match data for use by the FAA and the training simulator industry. The main feature used for Proof-of-Match report is the ability to plot flight test time histories overlaid with the simulation output. The flight test time histories can be shifted in time so that a particular event can be aligned with the simulation output. Moreover, GSC can drive the simulation with control inputs from the flight test time histories. Furthermore, there is a built in pilot model for performing takeoffs and landings. GSC also includes tools for analyzing time histories (calculating period and damping). Trim routine is using Jacobian method, so that user has wide open means of trimming the airplane. In short, the GSC provides all the utilities needed for static (trim) and dynamic (time histories, or cross-plots) simulation.

GSC is a combination of executive and user shell for running real time simulation software. The executive portion provides means for scheduling different simulation models, which are integrated into one load module in a sequential manner. It provides easy means of defining which modules are to be scheduled or skipped during a simulation run.

The user shell portion provides easy definitions of common block variables that have to be accessed (either to change their value or display or plot them during the simulation run), applying different integration techniques, means of driving variables using recorded flight test data or user defined tables, plotting time histories or cross plots of variables on any available device (using DISSPLA software), overlaying of simulation responses with flight test data (for validation of the simulation models), or specifying multiple termination conditions. At the present time GSC is available on the IBM mainframe and VAX.

HOLIST

HOLIST is a program used in hypersonic research at MDA. One of the options of the program is to generate a three degree of freedom trajectory. HOLIST operates on Silicon Graphics 40 work stations. HOLIST requires aerodynamics, propulsion, and mass property models to operate.

HSR

As part of the High Speed Research program, aerodynamic and propulsion models are being supplied to all the participants. A UNIX-based simulation has been fabricated on a Silicon Graphics Indigo workstation to support out-the-window real time graphics.

MATLAB

MATLAB is destined to replace SLAP. We are currently growing into it through application to HSR with models supplied by NASA. Our version is on the HP workstation.

MODSDF

Modular S.D.F. (i.e. MODSDF) predicts the trajectory and attitude of a vehicle in three dimensional space. It is a high fidelity, non-linear, stand-alone, continuous system simulation of vehicle motion that employs a fixed-step fourth-order Runge-Kutta integration scheme and a validated six degrees-of-freedom (i.e. S.D.F.) equations-of-motion algorithm. MODSDF uses an efficient Graphical User Interface (GUI) and an easy-to-understand menu system to minimize the training required for new users. It's structure allows project-specific analysis requirements to be easily incorporated while simultaneously preserving the integrity and generic quality of its embedded methods.

MODSDF is used to obtain:

a.) Evaluations of Flight Control Systems Designs

b.) Time-Dependent Flying Qualities and Performance Characteristics

c.) Flight, Store, and Ground Loads

d.) Weapons Separation Characteristics

e.) Aircraft Carrier Suitability/Performance Characteristics

f.) Ground Handling and Field Performance Characteristics

g.) Verification of Manned Simulator Models

h.) Initial Aircraft and Store Separation Flight Test Program Plans and Clearances

i.) Reproduction of Flight Anomalies for Incident/Accident Investigations

RUNFQR

RUNFQR is an executive program used to create plots for the commercial Flying Qualities Reports. It has canned routines with user input panels for doing standard analyses such as series of trims, static longitudinal stability in terms of stick force vs. speed, calculating minimum control speeds, and the like. It runs the same models that are used, for instance, in GSC. It is hosted on the IBM mainframe.

SLAP

SLAP is an analysis program developed at MDA to calculate flying qualities and control system metrics through linear airframe/control system analysis. The user builds the control system by entering all elements of the block diagram and then entering the connectors between the blocks. Airframe models are created by supplying data files of the linearized derivatives. SLAP operates on a VAX/VMS computer system. Because models can be built with SLAP, no inputs are required. However, linearized derivative data extracted from the MODSDF program can be loaded into SLAP. Frequency response, time history and root locus data can be generated using SLAP.

VECTOR

VECTOR is an achievable dynamics analysis program developed at MDA. Vector will determine the maximum short period frequency in the longitudinal axis, the maximum stability axis coordinated roll rate in the lateral axis, and the maximum dutch roll frequency in the directional axis. Vector operates on a VAX/VMS computer system. VECTOR requires a bare airframe model consisting of aerodynamics, maximum deflections of control surfaces, and maximum rates of deflection of control surfaces. After VECTOR has identified the control deflections needed to achieve the maximum dynamics, a time history of the motion is generated.

TABLEMAN

TABLEMAN (TABLE MANipulation) is a command line program for table data manipulation. The program is essentially a calculator for multi-dimensional data tables. Up to five dimensions are allowed. TABLEMAN provides ECHO and DO features allowing users to record and playback series of commands to reduce repetitive tasks.

WTDS

WTDS (Wind Tunnel Data System) is a FORTRAN computer program with interactive graphic features that will perform much of the routine analysis required fir reporting wind tunnel results. The program permits the user to rapidly access test data, display these data in a plotted format of his choosing, and operate on these data. The program is tutorial in nature and designed to prompt the user to enter data or to choose program options as needed.

MACGS

The McDonnelll Aircraft Computational Grid System (MACGS) is a general purpose, arbitrary grid topology grid generation system developed by McDonnelll Douglas. It supports the generation of multi-zone structured (which are either patched with common zone boundary interfaces or overlapping) and unstructured grids. MACGS is comprised of three modules: ZONI3G, GMAN, and GPRO. ZONI3G, which is based on the Air Force-sponsored I3G program, is used to decompose the domain into zones and generate surface and zone boundary grids. GMAN provides the capability to generate zone volume grids, and to specify boundary conditions and coupling information at zone boundaries. GPRO manipulates zones (such as transforming, splitting, and combining) and supports inputting and outputting files in various formats. The interactive, graphical user interfaces of ZONI3G and GMAN support both the novice and expert users.

NASTD

NASTD is an implicit, approximately factored, upwind code which solves the three-dimensional, Favre-averaged Navier-Stokes and energy equations. It can be run in two or three dimensions for internal or external, subsonic, transonic, supersonic, or hypersonic viscous or inviscid flows. It includes a zonal capability and significant boundary condition flexibility. Several explicit operators are available, including central difference, Coakley upwinding, a Roe scheme, and several TVD schemes. A Beam-Warming type approximate factorization scheme is used in the implicit operator. A parabolized Navier-Stokes marching algorithm and an explicit Runge-Kutta time stepping procedure are also available. Two one-equation models (Baldwin-Barth and Spalart-Allmaras) and several low-Reynolds-number k-epsilon and k-omega two-equation turbulence models are available.

CFPOST

CFPOST is a post-processing utility for analyzing CFD results. It performs many varied functions such as listing and plotting results, generating reports and producing files for other plotting packages and post-processors. CFPOST provides commands for the user to precisely specify the information of interest, the domain of interest, and the units of measure in which the results are to be presented.

VEGAS

VEGAS is a CFD based tool for forebody analysis.

DEFGEOMB

DEFGEOMB is a design tool for bump inlets.

DEFGEOMC

DEFGEOMC is a design tool for caret inlets.

DUX

DUX is a unigraphics (UG) based package intended for the rapid generation and analysis of inlet diffuser and exhaust ducts. The duct geometry generation capabilities make use of UG in an HP workstation environment to quickly design ducts to meet specific requirements. The intent of DUX is to allow the user to iterate on a geometry early in the design cycle and screen out poor designs before conducting more refined levels of analysis.

FLIPP

The Flush Inlet Performance Prediction program (FLIPP) is a quasi-empirical based analysis method for flush inlets. FLIPP is primarily inteded for use in the conceptual and or preliminary design environment.

NIDA

The NIDA code has both design and analysis capabilities for 2-D and axisymmetric inlets in the supersonic flight regime to approximately Mach 5. In the design mode, the program is capable of defining the external-compression surface for either multiple ramps/cones or a single ramp/cone followed by an isentropic turn for a given wave focal point and Mach number. In the analysis mode, the program used both analytical and empirical techniques to predict inlet total pressure recovery, airflow, and component drags on all external and mixed compression inlets.

RSCDIFF

RSCDIFF is a rapid advanced design tool for subsonic diffuser design and analysis. RSCDIFF can be used to predict engine face recovery. Capabilities include the analysis of serpentine diffusers and bifurcated ducts. The design options allow pre-selected offset and area distributions.

NNEP

Navy/NASA Engine Program (NNEP) is a one-dimensional, steady-state, thermodynamic engine performance prediction program capable of modeling various turbine engines.

PSIP

This program calculates installed performance for advanced aircraft. Corrections to performance are made for inlet recovery, inlet drag, additive drag, nozzle boattail drag, nozzle thrust coefficients, bleed and bypass. In addition, PSIP has the ability to install mixed flow or separate flow engines, model vectorable nozzles, and calculate drag due to nozzle plume scrubbing.

GETUP

GETUP is a flight simulation program which calculates aircraft flight path and engine throttle history for given mission profiles and aircraft performance characteristics. The user must supply the aerodynamic characteristics of the aircraft, the propulsion characteristics, and a description of the mission segments. GETUP then simulates the aircraft flight through the prescribed mission profile, calculating a time history of throttle position, velocity, altitude, heading, and fuel usage. GETUP contains a set of predefined maneuvers which provide the capability to quickly simulate the missions selected. These maneuvers include: takeoff, short takeoff, vertical takeoff, vector, sustained turn, rejoin, split-s, pitchback, terrain following, dive/toss, popup, landing, and vertical landing.

DATEN

DATEN is an empirically based code for predicting the thrust and pumping characteristics of ejector nozzles. It consists of a large ejector nozzle data base and an empirically derived set of correlation equations relating ejector nozzle geometry, primary and secondary flow conditions, and performance parameters.

DRAGDRS

DRAGDRS is a tool used to evaluate the drag of axi, 2-D, and SERN nozzles using IMS correlations. It is useful when evaluating several nozzle configurations at a small number of operating conditions. It is intended for preliminary design studies at a limited number of operating points.

EJECTOR

EJECTOR predicts ejector nozzle performance based on 1-D equations.

HOTJET

HOTJET is a program fit for predicting nozzle drag with hotjet based on coldjet data.

IMS

Calculates integral mean slope (IMS) for input nozzle geometry and projected areas. It is usually calculated by a stepwise numerical integration, with tabular inputs of dA/dx (or dy/dx for 2-D) versus increments in projected area.

XGAS

XGAS predicts exhaust plume characteristics.

MACGS

The McDonnell Aircraft Computational Grid System (MACGS) is a general purpose, arbitrary grid topology grid generation system developed by McDonnelll Douglas. It supports the generation of multi-zone structured (which are either patched with common zone boundary interfaces or overlapping) and unstructured grids. MACGS is comprised of three modules: ZONI3G, GMAN, and GPRO. ZONI3G, which is based on the Air Force-sponsored I3G program, is used to decompose the domain into zones and generate surface and zone boundary grids. GMAN provides the capability to generate zone volume grids, and to specify boundary conditions and coupling information at zone boundaries. GPRO manipulates zones (such as transforming, splitting, and combining) and supports inputting and outputting files in various formats. The interactive, graphical user interfaces of ZONI3G and GMAN support both the novice and expert users.

NASTD

NASTD is an implicit, approximately factored, upwind code which solves the three-dimensional, Favre-averaged Navier-Stokes and energy equations. It can be run in two or three dimensions for internal or external, subsonic, transonic, supersonic, or hypersonic viscous or inviscid flows. It includes a zonal capability and significant boundary condition flexibility. Several explicit operators are available, including central difference, Coakley upwinding, a Roe scheme, and several TVD schemes. A Beam-Warming type approximate factorization scheme is used in the implicit operator. A parabolized Navier-Stokes marching algorithm and an explicit Runge-Kutta time stepping procedure are also available. Two one-equation models (Baldwin-Barth and Spalart-Allmaras) and several low-Reynolds-number k-epsilon and k-omega two-equation turbulence models are available.

CFPOST

CFPOST is a post-processing utility for analyzing CFD results. It performs many varied functions such as listing and plotting results, generating reports and producing files for other plotting packages and post-processors. CFPOST provides commands for the user to precisely specify the information of interest, the domain of interest, and the units of measure in which the results are to be presented.

HEATRAN

HEATRAN is a general heat transfer program used to compute transient temperatures of the three dimensional thermal nodes simulating passive structure and active fluid systems. Accounts for energy storage, conduction, convection, heat flux and radiation.

MARTHA

MARTHA is a general heat transfer program used to compute steady state and transient temperatures for simple 2D or 3D structure and fluid systmes. Accounts for energy storage, conduction, convection, heat flux, and radiation. Provides quick structural design assessment.

P/THERMAL

P/THERMAL is a finite element and finite difference thermal analysis system. Capable of solving for both steady state and transient combined modes (conduction, convection, gray and multi group spectral radiation, advection, and arbitrary temperature boundary conditons) heat transfer problems.

NEVADA

Analyzes external radiation environments and radiant inter-change couplings between surfaces having specular or diffuse characteristics. A Monte Carlo ray tracing technique is used for up to thirteen geometric surface types.

VIEW

Calculates geometric view factors utilizing a combination of double area integration, contour integration, and ray intersection methods.

THERMPROP

Creates files of thermal properties for solids and fluids in HEATRAN format.

FIDAP

Computes incompressible flow with heat transfer.

MINIVER

Computes aerodynamic heating to a variety of vehicle configurations. Program interfaces with PATRAN and HEATRAN.

STAPAT

The Specific Thermal Analyzer Program for Aircraft Transparencies (STAPAT) is an aerothermodynamic computer code specifically applicable and limited to the study of high-temperature resistant transparencies for high-speed aircraft.

AERHAT

Computes aerodynamic heating for a variety of vehicle configurations.

CAPTEM

The Cabin and Pilot Thermal Environment Model (CAPTEM) was developed to predict pilot comfort and evaluate the various pilot cooling techniques. CAPTEM is used to conduct transient thermal analyses of fighter aircraft with a human body thermal model.

CAECS

This Computer Aided Environmental Control System (CAECS) is used to analyze steady state performance, determining typical sizing data for components, and evaluating relative aircraft penalties for virtually any air cycle or vapor cycle aircraft environmental control system.

ATM

The Aircraft Thermal Management (ATM) computer model was developed to analyze a generic thermal management system to be representative of the next generation fighter aircraft.

LEWICE

The computer code LEWICE is an analytical, time dependent ice accretion model that evaluates the thermodynamics of the freezing process that occurs when supercooled droplets impinge on a body.

GABRIEL

GABRIEL (Graphics Algorithm for display of Basic Results Input from an External Load file) is an interactive plotting program which displays results input from an external load file.

2.1 Planning

IGRIP by Deneb

IGRIP is a commercial software (from Deneb) modified by Northrop Grumman to model assembly operations based on real geometry and factory layout. It is used to develop the sequence and the motions that are necessary to assemble the structure. It also is used to work out assembly and sequencing scenarios to resolve tool access and workpiece interference. The inputs to IGRIP are actual geometry files from CAD programs that model the structure pieces, while the outputs may be actual assembly sequence displayed either visually or in work instructions. Run time depends on the complexity of the workpiece in question.

CCDP - Computerized Composite Development Project

CCDP is a Northrop Grumman proprietary integrated software that provides state-of-the-art assistance to accomplish all phases of laminate composite production - from structural analysis to robotics lay-up and in-process verification. Sophisticated mathematical analysis and scientific programming was used to develop the complex geometric computation algorithms for CCDP. The system was developed over several years as a team effort of application area experts, systems analysts and software designers. CCDP is a collection of software modules that are integrated by a common data structure. Application modules in production automate design, numerical control programming, and inspection product data generation for large, complex contoured composite parts. The CCDP system relies on CAD systems for geometric input and output, but was designed to be independent of the particular brand of CAD system to ensure portability and flexibility. The output from CCDP is a set of instructions that assist users in composite assembly.

2.4 Producibilty

Cost and Producibility Expert System (CAPES)

CAPES is a Northrop Grumman proprietary software consisting of a cost and producibility expert system for both metallic and composite structure. It was developed for use by the designer during the preliminary design phase to provide downstream manufacturing information upstream where most of the acquisition costs of a product are locked in. CAPES is based on design features such as stiffening concept, stiffening dimensions, part curvature, complexity, bonding process, and part dimensions (which constitute the inputs). These parameters are used by CAPES to estimate the weight of the part or assembly and derive manufacturing costs (which are the outputs). CAPES breaks out both recurring and non-recurring cost details by feature. The system also has producibility rules (which are another set of outputs) for metallic parts which warn the designer of potential manufacturing problems before design is released.

4. Cost Estimation Tools

Cost and Producibility Expert System (CAPES)

CAPES is a Northrop Grumman proprietary software consisting of a cost and producibility expert system for both metallic and composite structure. It was developed for use by the designer during the preliminary design phase to provide downstream manufacturing information upstream where most of the acquisition costs of a product are locked in. CAPES is based on design features such as stiffening concept, stiffening dimensions, part curvature, complexity, bonding process, and part dimensions (which constitute the inputs). These parameters are used by CAPES to estimate the weight of the part or assembly and derive manufacturing costs (which are the outputs). CAPES breaks out both recurring and non-recurring cost details by feature. The system also has producibility rules (which are another set of outputs) for metallic parts which warn the designer of potential manufacturing problems before design is released.

FVCM

Fixed Variable Cost Analysis Model is a a Northrop Grumman proprietary software used for decision support. It analyzes the cause and effect relationships which drive cost in the factory operations area. The system allocates costs based on activities (i.e., the inputs are cost/activity), provides for 'what-if' analysis (i.e., sensitivity analysis), and determines the aggregate effects of process changes on rates, overheads, and overall costs (which are the typical outputs).

TOPS - Target Optimized Production Simulation

TOPS is a Northrop Grumman proprietary software used for strategic planning of recurring production cost of a total aircraft or an aircraft structure component and program sizing. It uses Lotus 1-2-3 to capture historical data (of aircraft production) from Grumman, Northrop, and Vought. The output is cost.

Appendix II

This appendix, contained in the following pages, consists of a copy of a recent paper authored by Geoffrey Fox and Wojtek Furmanski which discusses potential industrial uses of the NII and high performance computing. It is intended to supplement the information presented in Section 3.


Last updated 13th February 1996 by: mab@npac.syr.edu