An Object-Oriented Framework for Distributed … Object-Oriented Framework for Distributed Computational Simulation of Aerospace Propulsion Systems John A. Reed and Abdollah A. Afjeh

The following paper was originally published in theProceedings of the 4th USENIX Conference on Object-Oriented Technologies and Systems (COOTS)

Santa Fe, New Mexico, April 27-30, 1998

For more information about USENIX Association contact:

1. Phone: 510 528-86492. FAX: 510 548-57383. Email: [email protected]. WWW URL: http://www.usenix.org/

An Object-Oriented Framework for Distributed Computational Simulation of Aerospace Propulsion Systems

John A. Reed and Abdollah A. AfjehUniversity of Toledo

An Object-Oriented Framework for Distributed ComputationalSimulation of Aerospace Propulsion Systems

John A. Reed and Abdollah A. Afjeh

The University of ToledoToledo, Ohio

{jreed, aafjeh}@eng.utoledo.edu

ends

t-enst-salenenteinfnsornd

ulded

Abstract

Designing and developing new aerospace propulsionsystems is time-consuming and expensive.Computational simulation is a promising means foralleviating this cost, but requires a flexible softwaresimulation system capable of integrating advancedmultidisciplinary and multifidelity analysis methods,dynamically constructing arbitrary simulation models,and distributing computationally complex tasks. Toaddress these issues, we have developed Onyx, a Java-based object-oriented application framework foraerospace propulsion system simulation. The Onyxframework defines a common component object modelwhich provides a consistent component interface for theconstruction of hierarchal object models. Because Onyxis a framework, component analysis models may bechanged dynamically to adapt simulation behavior asrequired. A customizable visual interface provides high-level symbolic control of propulsion system constructionand execution. For computationally-intensive analysis,components may be distributed across heterogeneouscomputing architectures and operating systems. Thispaper describes the design concepts and object-orientedarchitecture of Onyx. As a representative simulation, aset of lumped-parameter gas turbine engine componentsare developed and used to simulate a turbojet engine.

1 Introduction

As the aerospace propulsion industry moves into the21st century, there is increasing pressure to reduce thetime, cost and risk of jet engine development. To meetthe harsh realities of today’s marketplace, innovativeapproaches to reducing propulsion system design cycletimes are needed. An opportunity exists to reduce designand development costs by replacing some of the large-scale testing currently required for product developmentwith computational simulations. Increased use of

computational simulations promise not only to reducthe need for testing, but also to enable the rapid arelatively inexpensive evaluation of alternative designearlier in the design process.

As a result of these forces, several governmenindustry cooperative research efforts have beestablished to develop technologies that enable the coeffective simulation of a complete air-breathing gaturbine engine. In the United States, the NumericPropulsion System Simulation (NPSS) project has beestablished between the aerospace industry, Departmof Defense, and NASA. When completed, NPSS will bcapable of analyzing the operation of an enginesufficient detail to resolve the effects omultidisciplinary processes and component interactiocurrently only observable in large-scale tests [1, 2]. Fexample, more accurate predictions of engine thrust aefficiency would be possible if the “operational”geometry of a compressor rotor, stator, and casing codetermined based on an analysis of the combinaerodynamic, structural and thermal loadings [3].

Figure 1: Topology of Computational Simulation System

Disciplines

Model Fidelity

Com

pone

nts

Inlet

Fan

Compressor

Combustor

Turbine

Nozzle

0-Dimensional1-Dimensional

2-Dimensional3-Dimensional

Flu

ids

Str

uctu

res

Hea

t Tra

nsfe

r

Con

trol

s

Com

bust

ion

Mat

eria

ls

SimulationEnvironment

High PerformanceAffordable Computing

Engine Component Models

der-

m.tss

fgo+

g

ereyindtosasftenultsis

ln.nd

c-hes.

nttod-lt,

The topology of such as system is shown in Figure 1.In this system, the engine component models areintegrated to couple relevant disciplines, such asaerodynamics, structures, heat transfer, combustion,controls and materials. These models are then integratedat a desired level of fidelity (0-, 1-, 2-, or 3-dimensional)to form coupled subsystems for systems analysis. Forrequired computing speed at a reasonable cost,simulation models can be distributed across a networkedcomputing platform consisting of a variety ofarchitectures and operating systems, includingdistributed heterogeneous parallel processors. Asimulation environment provides a user-friendlyinterface between the analyst and the multitude ofcomplex software packages and computing systems thatform the simulation system.

The implementation of such as system is a majorchallenge. In this paper, we focus only on the design anddevelopment of a prototypesimulation environmentbeing developed in NPSS-related research.

1.1 Design Requirements

This section describes some of the high-levelrequirements which the gas turbine simulationenvironment must meet:

• Component Level Modeling. The primary require-ment is for a platform which provides a general andflexible component view of the engine. Conceptu-ally, this approach allows an engineer to developnew and different engine simulation models inde-pendent of the number of components in the engine,their type, fidelity level, or even location in the net-work.

• Customization. The environment must allow theuser to customize simulation functionality byallowing components to be replaced by other com-ponents having different functionality. Such “plug-gability” is essential for keeping the architecturecurrent. Similarly, it must be capable of supportingthe integration of new simulation techniques andcomputing methodologies with as little effort aspossible. Specifically, this intended to address theareas ofmultidisciplinary couplingandmultimodel-ing.

• Component Interoperability. In order for the pre-ceding design requirements to be possible, it isessential that the user be guaranteed compatibilitybetween all components used to develop simulationmodels. Component interoperability is enforcedthrough specifications of a general componentmodel.

• Distributed Connection and Data Transforma-tion. The introduction of interdisciplinary modelsand multimodels requires support for distributecomputing as it cannot be assumed that the highfidelity software will run efficiently (or at all) on thesame computer platform as the rest of the systeAdditionally, data transferred between componenhaving different fidelity levels and/or data formatmust be transformed accordingly.

• Portability . The environment must be capable ooperating without regard to hardware or operatinsystem combinations. This includes the ability tleverage extensive amounts of Fortran, C and C+legacy software.

• User Interface. Finally, the system must provide auser interface to reduce the efforts of developinnew models and executing simulations.

1.2 Alternatives

A great number of engine simulation softwarpackages are currently in use. Most of these aproprietary software, developed and maintained baerospace companies. Also a number of public domasoftware packages, developed by NASA anUniversities are also in use [4, 5]. One approach isdetermine the “best” software and modify it to addresthe design requirements listed above. However, it hbeen ours and others experience that this approach orequires more effort and produces less desirable resthan a completely new design [6, 7]. Generally, thisdue to the following [8]:

• Procedural design structures. Existing (publicdomain) simulation software tend to utilize globadata structures, such as FORTRAN commoblocks, to improve simulation execution timesHowever, the result is a lack of data encapsulatioand safety, making changes in design difficult andangerous.

• Discipline isolation. Most present-day simulationmodels offer only simplified coupling of interac-tions between, for instance, aerodynamics, strutures and controls. Consequently, the design of tsystem reflect the bias towards these disciplineThis makes it difficult to introduce new models tocouple additional disciplines.

• Assumed single processor/machine environme.Most simulation systems were designed notexceed perceived implementation limitations (harware, operating systems, memory, etc.). As a resu

nwo

n-

”mnal,ryterend%aryed

e.ngs,n

ng

thns

s,dld

ndfs

the software’s design impedes transport to modernparallel and distributed computing platforms.

• No Graphical Interface. Another drawback of mostpresently used simulation software is the lack ofgraphical user interfaces (GUIs). Engine models aredeveloped by hand through input lists. This is oftena tedious process which can also result in erroneousmodel definition.

An alternative approach which directly addresses thefirst limitation, and indirectly addresses the remaininglimitations is to applyobject-oriented technologyto thedevelopment of the simulation environment. Object-oriented technology is a collection of powerful design,analysis and programming methodologies for creatinggeneral-purpose adaptive models and robust, flexiblesoftware systems [9, 10].

An object-oriented (OO) approach is attractive formodeling gas turbine systems due to the natural one-to-one correspondence between objects in the applicationand computational domains. Consequently, multifidelityand multidisciplinary representations of enginecomponents can be conveniently encapsulated throughthe use of objects. Object class morphology provides thenecessary structure to accommodate a commonengineering model, and to define the essential interfacesfor component and disciplinary coupling. Inheritance ofmethods and variables in the hierarchy of classes allowsextension and customization of simulation models withan economy of effort. Moreover, the same structure canbe used in the design, analysis, simulation andmaintenance phases of the engineering cycle.

Several prototyping efforts to develop object-oriented gas turbine simulation systems have alreadybeen completed. The first was developed by Holt andPhillips [11]. In this work an object-oriented simulatorwas developed in Common Lisp Object System (CLOS)with component models based on the dynamic enginesoftware package called DIGTEM [4]. Similarprototyping efforts were carried out by Curlett andFelder [6] and Reed and Afjeh [12] in C++ and Javaprogramming languages, respectively. Results fromthese efforts were very encouraging. In particular, theuse of a graphical user interface in both the CLOS andJava simulation software greatly increased flexibility indeveloping engine simulation models.

1.3 Solution to Design Challenge

These prototyping efforts have illustrated theflexibility and reusability of the object-orientedapproach. However, this has been achieved mainly at theapplication level. In order to develop a next-generation

simulation environment, we need to apply OO desigconcepts to the entire architecture. In recent years, tcomplementary concepts,design patternsand OOapplication frameworks, have been shown to bebeneficial to developing reusable and flexible domaispecific software systems.

A framework is a reusable, “semi-completeapplication that can be specialized to produce custoapplications [13]. In general, the gas turbine simulatiosoftware now used are estimated to be ~80% identicwith the remaining percentage due to proprietamodifications of individual components. The greaamount of commonality suggests that it might bpossible to develop a generalized simulation softwapackage based on the 80% of common features, aallowing the end user to customize the remaining 20as desired. Frameworks can provide the necessinfrastructure to develop and mange such a generalizpropulsion simulation system.

The benefits of object-oriented frameworks are duto their modularity, reusability, and extensibilityFrameworks enhance modularity by encapsulativolatile implementation details behind stable interfacethus localizing the impact of design and implementatiochanges [14]. These interfaces facilitate the structuriof complex systems into manageable software piecesobject-basedcomponents which can be developedand combined dynamically to build simulationapplications or composite components. Coupled wigraphical environments, they permit visual manipulatiofor rapid assembly or modification of simulation modelwith minimal effort. Software component modularityalso permits placement across computer platformmaking them well-suited for developing distributesimulations. Reuse of framework components can yiesubstantial improvements in model development ainteroperability, as well as quality and performance othe computational simulation system. Frameworkenhance extensibility by providing “hooks” into the

Figure 2: Onyx Framework Layers

VisualAssembly

EngineComponent

ConnectorFramework

Framework

Framework

of-a).werupnt

ing,).re

wofbereto

framework. Coupled with the stable interfaces, thesehooks allow the engineer to “plug” new functionalityinto the framework as desired. This is essential forkeeping the simulation architecture current andfacilitating new analytical approaches.

In the next section, we describe the design andimplementation ofOnyx, an object-oriented frameworkfor aerospace propulsion simulation.

2 Overview of Onyx Framework

Onyx is structured as aframework of frameworks.Figure 2 illustrates the major structural frameworks andcomponents which are described in this paper.

• Engine Component Framework -A database con-taining collections of domain-specific componentmodels, such as a compressor and turbines, for usewithin the Visual Assembly Framework.

• Visual Assembly Framework- The Onyx graphicaluser interface (GUI) provides interactive controlover the execution of the framework. The VisualAssembly Framework forms one part of the OnyxGUI and provides tools to visually assemble andmanipulate a simulation model.

• Connector Framework- Provides a layered abstrac-tion mechanism for distributed interconnection ser-vices between component models. Connectors alsoare utilized in interdisciplinary and multilevel com-ponent connections.

Onyx was developed using the Java object-orientedprogramming language and run-time platform [15]. Javawas chosen for the Onyx framework because of itsexcellent object-oriented programming capabilities;platform-independent code execution (made possiblethrough the use of byte-codes and a Java VirtualMachine); free availability on all major computingplatforms; and, highly-integrated run-time classlibraries, which serve as the foundation for Onyx’sgraphical user interface, distributed computingarchitecture, as well as providing future implementationof database and native code interfacing.

To illustrate how Onyx can be used to develop gasturbine simulations, we will present a running examplethroughout this section. A transient, lumped-parameter,aero-thermodynamic turbojet engine component model,developed in our previous research, is integrated withinthe framework. The resulting simulation system iscapable of performing steady-state and transientanalyses of arbitrarily configured jet engine models.

3 Engine Component Framework

3.1 Design Challenges

A gas turbine engine is essentially an assemblyengine components inlet, fan, compressors, combustor, turbine, shafts and nozzle, etc. (see Figure 3These components operate together to produce po(or thrust). Engine components are themselves madeof other substructures. For example, a fan componemay be expressed as a collection of hub, stage, cassplitter and flowfield substructures (see Figure 3bThese in turn may be further decomposed into mobasic elements such as rotor and stator blades.

Onyx’s Engine Component Framework should allousers to simulate these structures at the various levelsabstraction as desired. For example, a user shouldable to construct an engine component model from mobasic models, and then use that component model

Figure 3: Engine Component Abstraction Diagram

(a)

(c)

FanInlet Combustor Nozzle TurbineCompressor

hub stage

rotor blade stator blade

splittercasing

0-D

1-D

3-D

2-D

flowfield

FEA

Fid

elity

Disciplines

(b)

CFD

CFD

ActuatorDisk Theory

FEA

Beam Model

UVelocity Diagram

TabulatedEmpiricalData Maps

TabulatedEmpiricalData Maps

2-D Grid

s.ofanr

tc.)

e

sessed

al

theessu-

hele-en-es,e

build an engine model. Such an approach makes the pro-cess of developing gas turbine simulation models bothsimple and intuitive. To achieve this, we have selectedan internal class structure which closely resembles thephysical structure of the domain.

The component models internal structure should:

• maintain a component models physical relation-ship. This includes arrangement of any substruc-tures as well as references to connected componentmodels.

• provide control over the execution of the compo-nents simulation algorithm, which we call, itsanal-ysis model.

In developing the component model structure, weshould not have to distinguish between single elementsand assemblies of elements in our internalrepresentation. For example, we should be able to treat asingle rotor blade in the same manner as a fancomponent comprised of several elements, thusallowing the construction of arbitrarily complex models.

We can represent the hierarchal structure of theengine, its components, and substructures usingrecursive composition. This techniques allows us to

build increasing complex elements out of simpler oneReturning to Figure 3b, we can combine multiple setsrotor and stator blades to form a fan component. The fcomponent can then be combined with othecomponent-level elements (compressor, combustor, eto form an engine model.

3.2 Engine Component Implementation

Figure 4 illustrates the structure of the EnginComponents Framework in Onyx. For simplicity, onlythe more important variables and methods in the clasare shown. The structure of these classes is bamainly on the Compositedesign pattern [16]. Thispattern effectively captures the part-whole hierarchstructure of our component models.

EngElement is a Java interface which establishescommon behavior for all engine component classincorporated into Onyx. It defines the basic methodneeded to initialize, run and stop engine element exection, as well as methods for managing Port objects. Tabstract class DefaultEngElement implements EngEment and provides default functionality for the interfacmethods. In most cases, users will subclass DefaultEgElement to create concrete engine component classsuch as class XyzEngElement, to implement th

<< Connector >>

getDataSet()setDataSet()

XyzEngElement

init()run()stop()

DefaultEngElement

add()addPort()init()getPorts()remove()

c.run();

removePort()

CompositeEngElement

init()run()stop()

stop()

model.execute();

ports

connector

forall c in children

model

<< Port >>


<< EngElement >>

add()addPort()init()getPorts()remove()removePort()stop()

DefaultPort


AeroPort


StructuralPort


0DAeroPort


1DAeroPort


0DStructPort


1DStructPort


<< Model >>

execute() DefaultModel

execute()

AeroModelexecute()

StructuralModelexecute()

0DAeroModel

execute()

1DAeroModel

execute()

0DStructModel

execute()

1DStructModel

execute()

Figure 4: Structure of Engine Component Framework

children

s.e

ls

disds,-

an

ssist.,utews.

heheseiss

krtndrtsichthea5.

.g.ses3-esfif

D,ntdayst

ge

f

required functional methods. The approach of providinga default abstract class for a Java interface is usedthroughout the Onyx system to give the user more flexi-bility when plugging in new classes. In this case, theuser may select to inherit the functionality provided byDefaultEngElement, or to inherit from another class andimplement the methods defined by the EngElementinterface.

CompositeEngElement represents a composition ofEngElement objects. Management operations for chil-dren are declared in DefaultEngElement to maximizecomponent transparency. To ensure type-safety, thesemethods throw an exception for illegal operations, suchas attempting to add or remove an EngElement fromanother EngElement, rather than a CompositeEngEle-ment.

3.3 Analysis Model Implementation

Computational simulation involves designing amodel of an actual or theoretical physical system,executing the model on digital computer, and analyzingthe execution output [17]. Models are generallydeveloped by defining a given problem domain,reducing the physical entities and phenomena in thatdomain to idealized form based on a desired level ofabstraction, and formulating a mathematical modelthrough the application of conservative laws.

Simulating complex systems requires the develop-ment of a hierarchy of models, ormultimodel, whichrepresent the system at differing levels of abstraction[18]. Selection of a particular model is based on a num-ber of (possibly conflicting) criteria, including the levelof detail needed, the objective of the simulation, theavailable knowledge, and given resources. For prelimi-nary gas turbine engine design, simulation models areoften used to determine the thrust, fuel consumptionrates, and range of an engine. These simulations gener-ally use relatively simple one-dimensional componentmodels to predict performance. However, in other situa-tions, such asmultidisciplinary analysis, higher-ordermodels are needed. For example, to prevent the possibil-ity of a fan blade rubbing the cowling, an engineermight perform a coupled aerodynamic, thermal andstructural analysis of the blade to determine the amountof blade bending due to the thermal and aerodynamicloading. Such an analysis would require several high-fidelity analysis models using fully three-dimensional,Navier-Stokes computational fluid dynamics (CFD) andstructural Finite Element analysis (FEA) algorithms.

Ideally, one would prefer using three-dimensionalanalysis for an entire engine as it provides greater detailof the physical processes occurring in the system. Thecomputational requirements for such an analysis,

however, far exceed present computer capabilitieConsequently, it is desirable for an EngElement to bcapable of accommodating views having multiple leveof fidelity and differing disciplines. Figure 3c illustratesthe concept of multiple views for a rotor blade anflowfield objects in a fan component. The rotor bladeanalyzed using various mechanical-structural methowhile the flowfield is represented by various aero-fluiddynamic methods. Based on the simulation criteria,appropriate analysis model may be selected.

The complexity of the various analysis modelsuggest that it is desirable to encapsulate the analymodel, or remove it from the structure of EngElemenThis would protect the modularity of EngElementallowing new EngElement classes to be added withoregard to the analysis model, and conversely to add nanalysis models without affecting the EngElement clas

We apply the Strategy design pattern [16] toencapsulate the analysis model in an object. TDefaultModel class is an abstract class whicimplements the Model interface. The interface definthe methods which all Models must support to bintegrated within Onyx. As an example, two analysmodels, 0DAeroModel and 1DAeroModel, are shown asubclasses of AeroModel.

3.4 Ports

Completing the Engine Component Frameworstructure is the Port class. In physical terms, a Porepresents a control surface through which energy amass flow between engine components. In Onyx, Podefine an interface between EngElements through whdata is passed. Port is an abstract class which definesdefault functionality, and maintains a reference toConnector. Connectors will be discussed in sectionPort is subclassed according to the discipline (eaerodynamic, structural, thermal, etc.), and these clasare then each subclassed by fidelity (0-D, 1-D, 2-D,D). Which subclass of Port an EngElement instantiatis determined by the discipline-fidelity combination othe EngElements analysis model(s). For example,EngElement has a single analysis model which is a 0-aerodynamic model, then an instance of EngElemecreates two 0DAeroPort objects to handle input anoutput. Because the analysis model is dynamic and mbe changed at run-time, the Port objects also muchange accordingly. Consequently, we apply theStatedesign pattern [16] to dynamically create and manathe Ports in an EngElement.

3.5 Example

To illustrate the application of the Onyx frameworkand the feasibility of this approach, a small collection o

nghisthe

st,centheo

tos is

sect

etl

s.e

e

ntaichallelmises.o

nd

en

lyMtg

ede

isfsit

ual

component object classes representing the inlet, com-pressor, combustor, turbine, nozzle, bleed-duct connect-ing-duct, and shaft, of a jet engine have been developed.An inter-component mixing volume class was alsodefined which is used to connect two successive compo-nents as well as define temperature and pressure at com-ponent boundaries. These concrete classes are allsubclasses of the abstract DefaultEngElement classshown in Figure 4.

Each class implements a specific mathematical(analysis) model which describes its physical operation.In this example, the analysis models are all relativelysimple differential-algebraic equations (DAE) devel-oped from an space-averaged treatment of the conserva-tive laws of thermo- and fluid dynamics. These arepatterned after the work of Daniele et al., [4]. A com-plete description of the models can be found in the workof Reed [7]. The analysis model for each component isencapsulated in an appropriate subclass of Default-Model, and present specific implementations of theinit(), run() andstop() methods which initial-ize the component and execute its analysis model,respectively.

Appropriate Port objects are created in each compo-nent object depending on the number and type of con-nections required. For example, a compressor classdefines two AeroPort objects to pass aero-thermody-namic data to adjoining components, and a Structur-alPort to pass data to a connecting shaft object.

4 Visual Assembly Framework


Aerospace engineers often use schematic drawingsto represent propulsion systems and subsystems. It isthen natural to represent computational simulations ofsuch systems using this visual metaphor.

In the previous section, we developed an object-oriented component model which allows us todynamically assemble arbitrarily complex enginesystem models. We now consider the development of aframework which supports visual assembly of thosecomponent models.

The main requirement of the Visual AssemblyFramework is to provide visual analogs for thecomponent model objects, and support for assemblingthem. This has several implications. The first is obvious:we need visual elements to represent the objects whichform Onyx’s engine component model. The second, lessobvious requirement, is that the concept of componentcomposition developed previously must also besupported visually. Finally, the framework must takecare of managing basic graphical functions window

management, displaying objects, moving and draggivisual elements, tracking mouse movements, etc. Treduces the programming burden for engineers usingframework.

In addition to these goals are some constraints. Firthe framework should decouple the visual user interfa(UI) objects from their counterparts in the componeframework. Although the visual elements represent tcomponent, we would like to allow a component’s UI tbe changed easily, possibly at run-time.

Second, our implementation should allow the useroverride the default visual representations as much apractically possible.

We have selected the Java platform in part becauof its integrated graphical support. Java’s AbstraWindow Toolkit (AWT) is part of the core classes whichare available in every Java Virtual Machine (JVM). ThAWT provides a collection of platform-independengraphical components for building graphicaapplications in Java. One drawback of the AWT is that itprovides only basic low-level graphical componentAnother drawback is the heavyweight nature of thAWT, due to implementing graphical objects with thnative windowing system.

We have opted instead to use the Swing componeset to implement our graphic interface [19]. Swing issubset of the new Java Foundation Classes (JFC), whis itself a subclass of the AWT. Therefore, our graphicinterface will retain the same portability made possibwith AWT. Swing however, adds more high-levegraphic components, as well as the ability to select fromultiple Look-and-Feel standards. However, thselection raises some immediate implementation issu

One attractive feature of Java is its capability tdevelopapplets compiled Java programs which canbe dynamically downloaded from a Web server and rulocally on the client’s machine using a Java-enablebrowser. The ubiquity of Web browsers makimplementing Onyx’s visual assembly framework as aapplet very attractive.

One drawback of using an applet is the relativelong time needed to implement new versions of the JVinto web browsers. Currently, the JFC is noimplemented in any browser, meaning that the Swinclasses used in Onyx would have to be downloadalong with the visual assembly framework each time thapplet was accessed.

Another drawback associated with using an appletits security restrictions which affect the partitioning oOnyx’s structure. Generally, this limits communicationbetween the applet to only the web server from whichwas downloaded.

Because of these issues, we have designed the visassembly framework as a Javaapplication. Applications

ills.actichonge,isnd-

nn.e

oted

to

-g-ofr),-

s

h-ndes

are similar to stand-alone programs. As the issues ofbrowser-JVM integration and applet security issues areaddressed, we will modify Onyx to permit the visualassembly framework to be distributed as an applet.

4.2 Visual Assembly Framework Design

A simulation model is constructed by creating Sche-maticIcon objects and connecting them to form anengine schematic. A SchematicIcon is composed of aVEngElement and one or more VPorts. VConnectorsare used to “wire” the SchematicIcons together. Figure 5illustrates these relationships.

• VEngElement is the visual analog of the EngEle-ment class in the component framework. VEngEle-ment is a subclass ofjava.swing.JButton ,and thus contains an Icon which presents an imageof the engine component; a Label which displaysthe name of the EngElement object instance.

• One or more VPorts are attached to the VEngEle-ment, and represent connection points betweencomponents. VPorts are color-coded to representthe type of Port it represents.

• A VConnector is the visual analog of the Connectorobject. It is represented as a line drawn between twoVPorts.

Each VEngElement, VPort and VConnector has apopup menu associated with it. The menu allows theuser to access various functions such as moving, delet-ing, copying, etc. In the VEngElement, the popup menuhas a special item for “customizing” the component.When selected, the customizer object is displayed.

Customizers are graphical interfaces which allow theuser to change an EngElement’s attributes. Typically,these are used to modify data in the EngElement analy-sis model. They may also be used to control the distribu-tion of the EngElement in a distributed simulation.

In designing the structure for our visual assembly weimmediately recognize from Figure 5 that each instance

of SchematicIcon represented in the framework wlikely have different Icons, display names and VPortOne solution is to define SchematicIcon as an abstrclass, and use inheritance to define subclasses whrepresents visually the various concrete SchematicIcclasses. Each class would then redefine the Icon imadisplay name, and VPort location and type. Thapproach however, typically leads to a very broad ashallow inheritance tree, indicating little use of inheritance.

A more useful approach would be to create aappropriate SchematicIcon using object compositioThis is accomplished through the use of thparameterized Factory design pattern [16], inconjunction with Java’s reflection mechanism. This alsallows us to address one of the design constraints lispreviously: decoupling a component’s UI from itscomponent model representation. Our solution isapply a variation of the JavaBeans “Info” classconcept [20].

We will illustrate this approach by creating a SchematicIcon object for an XyzEngElement object (see Fiure 6). When a user creates an instanceXyzEngElement (this process will be discussed latethe Visual Assembly Framework invokes the SchematicIconFactory’screate() method. This methodinvokes the getEngElemInfo() method in theXyzEngElement object which returns the info clasname,XyzEngElementInfo.class . The Factoryinstantiates this class using thejava.lang.reflect.Constructor newIn-stance() method. XyzEngElementInfo implementsthe EngElementInfo interface which defines two metods to create and return instances of PortDescriptor aEngElementDescriptor. We create and return instanc

Figure 5: SchematicIcon

VConnector

VEngElement

Label

VPort

Icon

SchematicIconFactory

loadJars()create()

XyzEngElementInfo

getEngElemDescriptor()getPortDescriptors()

XyzEngElement

getEngElemInfo()init()run()stop()

XyzEngElementInfo.classreturn

new EngElemDescriptor()return

new PortDescriptor()return

<< EngElementInfo >>

getEngElemDescriptor()getPortDescriptors()

Figure 6: SchematicIcon creation process

EngElementDescriptor

getCustomizerClass()getDisplayName()

PortDescriptor

getPortLocation()getPortType()

getIcon()

XyzCustomizer.classreturn

info

ne-

he-totor-a-to.

ort,

orort’see

ity,ce.fs.he

s7y,)

T-ld

f-s-

ss

er

gesof

us-ts,r-es

of these classes instead of simply returning the classname, since XyzEngElementInfo initializes theseinstances by passing parameters in the constructor ofeach class.

PortDescriptor encapsulates information concerningthe type, initial placement, and constraints of the VPortsfor XyzEngElement. EngElementDescriptor definesmethods which return the Icon image and display nameString used in the VEngElement button. The methodgetCustomizerClass () returns the class name forthe XyzEngElement’s Customizer. This class name isstored in the VEngElement object, and is lazily initial-

ized using thenewInstance() method.The combination of theFactory pattern and Java

reflection gives considerable freedom and flexibility icreating SchematicIcons. The composition of a SchmaticIcon can easily be redefined by subclassing ScmaticIconFactory. We can also use Java reflectionalter the specific classes that get instantiated in orderbuild the SchematicIcon without subclassing. Furthemore, we have effectively separated the UI implementtion from component implementation. One drawbackthis approach is the level of indirection introducedHowever, the user sees little of this complexity as heshe is only required to define the XyzEngElemenXyzEngElementInfo and a Customizer class.

4.2.1 Customizers

We face another dilemma in creating customizers feach EngElement. Customizer represents a UI fdefining and editing the attributes of an EngElemenanalysis model. Because it is strongly coupled to thdata structure for each specific type of EngElement, wwill likely end up with many different Customizerclasses. These may or may not have any commonalso we may not be able to take advantage of inheritanIn order to be flexible, Onyx must be capable ointegrating each of these specific CustomizerFurthermore, we would like to allow users as mucflexibility as is possible to customize the data UI, so wdo not want to limit their options through inheritance.

Our solution is to provide an interface which definea plug-point for user-defined customizers. Figureshows the Customizer structure. To maximize flexibilitthe Visual Assembly Framework allows the user to 1program a new customizer, or 2) to use the BasicabbedCustomizer. A user-defined customizer wouinherit from java.awt.Component and implementthe Customizer interface methods directly. Thecom-mitChanges () andsetTarget () methods are calledfrom the Visual Assembly framework. The constraint oinheriting fromComponent is necessary as all customizers are automatically added to an instance of VCutomizerDialog which expects its child to be a subclaof Component . VCustomizerDialog wraps the Cus-tomizer and provides a set of buttons to accept usinput. ThesetTarget () method identifies the objectto be updated, while thecommitChanges () method isused to update the object when the user accepts chanto the customizer data. XyzCustomizer is an examplea user-defined customizer.

In the second approach, the user can subclass VCtomizerPage, compose it with the desired UI objecand add it to BasicTabbedCustomizer. VCustomizePage can provide methods to handle common issu

VCustomizerDialog

createButtonPanel()

<< Customizer >>

commitChanges()setTarget()

Figure 7: Customizer structure

VCustomizerPage


BasicTabbedCustomizer


XyzCustomizer


addTab()

makeLayout()

DesignPointDataPage


TransientControlPage


customizer

Figure 8: Onyx Customizer

m-

.b-

toa

I-aof

z-s aesin

idev-e-

-e

such as laying out components. Since BasicTabbedCus-tomizer adds instances of Customizer, it is also possibleto add classes which inherit fromjava.awt.Compo-nent and implement Customizer. Figure 8 shows a pic-ture of an instance of DefaultTabbedCustomizer,including several VCustomizerPage page objects.

The Customizer structure provides considerableflexibility. It allows the user select to compose the UI orinherit functionality and structure when developing acustomizer. By adhering to an interface, users candevelop different customizers and plug them in as

desired. This process is made relatively easy with a siple change to the class name returned by thegetCus-tomizerClass () method in EngElementDescriptorFurthermore, since the VCustomizerDialog accepts suclasses ofjava.awt.Component , users can useJava Integrated Development Environments (IDEs)quickly construct customizers from AWT or Swing JavBean GUI components.

4.2.2 Frames, Panes, Managers and SchematicIcons

Engine schematics are built by adding Schematiccons to a EngSchematicPane which is contained inSchematicFrame. EngSchematicPane is a subclassjava.swing.JLayeredPane , and maintains a list-ing of the SchematicIcons it contains, as well as theirorder (i.e., their layer). EngSchematicPane also keepreference to an EngSchematicManager, which providsupport for selecting and moving SchematicIcons withthe EngSchematicPane (see Figure 9).

The SchematicFrame and related classes provrequired support for user interactions: dragging, moing, etc. We also support in the visual framework, thhierarchal composition concept introduced in the component framework.

In our requirements for a visual assembly framework, we indicated our desire to support visually th

SchematicPane

getAllIcons()

<< SchematicManager >>

beginDragIcon()dragIcon()

Figure 9: SchematicFrame structure

SchematicIcon

getVEngElement()getVPorts()

EngSchematicPane

EngSchematicPane()

manager

engDragIcon()

DefaultSchematicManager

beginDragIcon()dragIcon()engDragIcon()

EngSchematicManager

beginDragIcon()dragIcon()engDragIcon()

icons

Figure 10: SchematicFrames showing visual composition

g

r-inntonic-n-d

asso

ndIn

by

ndange

isenexre

rent,anin

ofreed

rlyort

fr

g

composition of EngElements in the Engine ComponentFramework. This is implemented using the Schematic-Frame, EngSchematicPane and SchematicIcons classes.We illustrate it with an example (see Figure 10).

4.3 Example

In section 3.5, the EngElement classes representingengine components found in a turbojet engine weredeveloped. We now demonstrate using the classes in theVisual Assembly Framework to create a simple turbojetengine. For each EngElement class, the user also definesan EngElementInfo class with appropriate descriptorinformation; including the icon, display name, custom-izer, and VPort locations. The customizer, EngEle-mentInfo, and EngElement model and port classes foreach EngElement are then collected into a Java archive(jar) file.

When the Visual Assembly Framework is started,Onyx searches the default loading directory, and loadsthe classes for each of the jar files. The EngElementclasses are extracted and stored for instantiation by afactory object. The EngElementInfo classes are alsoextracted and used to obtain the display names and iconsfor each of the loaded EngElements. The icons and dis-play names are listed in the Visual Assembly Toolboxwhich is displayed alongside the initial Schematic-Frame, calledMain (see Figure 10). From theMainwindow, the user selects theCreate Compositemenu command, which creates a new SchematicFrameand places a Composite SchematicIcon in the Main win-dow. This SchematicIcon represents the top-level viewof the turbojet engine, and the user names itTurbo-jet . This also sets the title name of the new Schematic-Frame toTurbojet .

Next, the user begins to construct the turbojet enginemodel. From the Toolbox, the user selects anInlet ,Fan, Shaft , Turbine and Nozzle engine compo-nent to add to theMain SchematicFrame. This actioncreates an proper SchematicIcon for the each compo-nent and displays them in the EngSchematicPane. At thesame time, Onyx instantiates their respective EngEle-ments and adds them to an instance of CompositeEn-gElement in the Engine Component Framework. Ouruser next selects theMain SchematicFrame, and usingtheCreate Composite command, instantiates a sec-ond SchematicFrame, which the user namesCore .

From the Toolbox, the user now selectsCompres-sor , Combustor, Shaft and Turbine compo-nents to add to theCore . SchematicIcons for thesecomponents are created and displayed in theCore Eng-SchematicPane. Onyx instantiates their respectiveEngElements and adds them to a second instance ofCompositeEngElement in the Engine Component

Framework. At this time, a SchematicIcon representinthe Core SchematicFrame is added to theMain Eng-SchematicPane.

We now have two loosely coupled composite hierachal structures: one composed of EngElements withCompositeEngElements in the Engine ComponeFramework; and its corresponding visual representaticomposed of SchematicIcons within EngSchematPanes. Also notice, from Figure 10, that the relatioships between SchematicIcons, VPorts anVConnectors are maintained in both theMain andCore frames.

5 Connector Framework


We have developed a component model for gturbine components, as well as a compatible interfacethat they can be assembled both programmaticallyand visually to form more complex systems ofobjects. In order for these components to interact asimulate the given system, they need to communicate.the Onyx architecture, EngElements communicatesending messages via a Port.

Consider a physical connection between a Inlet aFan EngElements as shown in Figure 10. Inlet and Fare physically and logically connected and exchanmessages, such asgetDataSet(), to retrieve data inorder to update their analysis models. Normally, thprocess would be relatively straightforward, with thgetDataSet () request being forwarded from the Favia the Fan’s Port to the Inlet’s Port, and finally to thInlet, where the request is carried out. In the Onyarchitecture, however, this process is made mocomplicated by at least two situations.

5.1.1 Multifidelity Connections

The first situation occurs when two EngElements aconnected which have analysis models with differediscipline and/or fidelity combinations. If, for examplethe Inlet component has a 1-D Fluid model and the Fhas a 2-D Fluid model, then we have a mismatchfidelity. When the Fan processes thegetDataSet ()message, it would have some intelligence capabletransforming its 2-D data into a 1-D data set beforeturning it to the Inlet. Other methods are also needto perform additional transformations (2-D to 0-D, 2-Dto 3-D, etc.). Such transformation methods are cleanecessary in order for the Onyx architecture to suppinterdisciplinary and multifidelity modeling

Holt and Phillips [11] introduced the concept oconnectorobjects to provide appropriate methods fo“expanding” or “contracting” the data, and mappin

t,eynetheme

e,in

y

tslesin

e

an

inur

echlt

from different discipline domains. Connector objects areessentially intelligent Command objects, as describedby the Commanddesign pattern [16]. As with thecommand objects, connectors provide flexibility bydecoupling the collaborating objects, making themeasier to reuse. An EngElement no longer need knowthe discipline-fidelity of the EngElement to which it isconnected. Figure 11 shows an interaction diagramusing connectors.

5.1.2 Distributed Connections

The second problematic situation results from thefact that an EngElement is to be distributable to othermachines. The complex and intensive computationalnature of jet engine simulations require that theframework be capable of distributing computations on anetwork of computers. This permits access to high-performance mainframe or workstation clusters forcomputationally intensive tasks and, at the same time,permits user control from the local computer. Also, thisfeature allows on-line monitoring of computations anddynamic allocation of computational resources foroptimum performance while a simulation is in progress.

Although the distribution of objects across a networkis a relatively complex task, our goal is to design Onyxto perform this distribution in a manner totallyconsistent with non-distributed simulations.Consequently, the distribution of components across thenetwork should be as transparent as possible to the user.No actions, other than selecting a remote machine onwhich to run a component, should be required todistribute the component at run-time. To illustrate theprocess, we return to our Inlet-Fan example.

In this scenario, the user would like to run the Fancomponent on a remote machine. In the VisualAssembly Framework, the user creates an Inlet and Fan.Accessing the Fan’s customizer (see Figure 8), the user

selects the “Distribution” page and selects from the listhe name of the remote machine on which to run thFan. Now, the user (implicitly) creates a Connector bdrawing a connecting line between the Inlet and FaPorts. Notice, that with the exception of selecting thname of the remote machine, the process is exactlysame as connecting components which run on the samachine.

Placing a component object on the remote machinhowever, means that the two components residedifferent Java Virtual Machines. This raises a difficultsince a Connector has two variables,port1 andport2 , which keep references to the Port objecconnected to the Connector. One of these variabwould normally be referencing the Fan, but since it isa different virtual machine, it cannot be referenced.

We can address this problem by having thConnector reference aremote proxy, as defined in theProxydesign pattern [16]. The remote proxy provideslocal representation for an object in another desigspace.

5.2 Connector Framework Implementation

The Connector Framework structure is shownFigure 12. The Java interface, Connector, defines ointerface functionality. As with previous interfaces, wprovide an abstract class, DefaultConnector, whiimplements the interface, provides defau

OnyxaConnectorFramework fanPort inletPort

new

setConnector(aConnector)

getDataSet()

transform()

getDataSet()

Fig. 11 - Interaction diagram

<< Connector >>


port1

<< Port >>


Figure 12: Structure of Connector Framework

LocalConnector

LocalConnector()

RemoteConnector

RemoteConnector()

DefaultConnector

getDataSet()

setDataSet()isRemote()

port2

proxy

<< RemotePort >>


<< Transform >>

transform()DefaultTransform

transform()

Fluid2Dto3D

transform()

1DThermaltoStruct

transform()

transform

Fluid1Dto2D

transform()

nr,y

er-ntre

eir

e.is)

ndae

f’se.

onvens

fto

ndasefulofn

ndthese

inga

nof

ensedtoxs

implementation of each method, and defines thevariables port1 , port2 , and isRemote .LocalConnector inherits all of its functionality andvariables from its superclass. It represents a normal(non-remote) Connector. References to theport1 andport2 objects are passed into the constructor.RemoteConnector’s constructor takes an additionalargument to identify the remote machine.RemoteConnector defines aproxy variable to hold thereference to the proxy object. The constructor alsoinitializes Onyx’s interconnection service to bindproxy to the remote object.

Onyx’s distribution mechanism is currently based onthe Java Remote Method Invocation (RMI), a corecomponent of the Java platform. RMI uses client stubsand server skeletons to interface with the local andremote objects. The stub represents the remote proxyobject which is referenced by the RemoteConnectorproxy variable

Because RMI is designed to operate fully within theJava environment, it is limited to connections betweenmachines which are running the Java Virtual Machine.By assuming the homogeneous environment of theJVM, Onyx can take advantage of the Java object modelwhenever possible. This provides a simple andconsistent programming model. Given that mostcomputing platforms now provide a JVM, this shouldnot limit the use of the framework. However, we are alsoin the progress of integrating CORBA for providingnon-Java distributed object support. This is especiallyimportant for incorporation of the multitude of legacyapplications not written in Java which currently exist inthe aerospace industry.

Our Connector now provide two sets offunctionality: 1) it can transform data sets between twocomponents of different fidelity, and 2) it establishesand maintains communications between distributedcomponents. Although both functions are based ondecoupling the connected components, we would preferthat Connector has a more singular functionality. Thiswould make it more reusable in the future. To achievethis, we delegate the transformation responsibility to aseparate Transform object. Connector selects anappropriate Transform object using aStatepattern [16],based on the fidelity-discipline combination of theconnection. The Transform object utilizes theStrategypattern [16], to allow different transformationalgorithms, such as Fluid1Dto2D, to be interchangeable.

The Connector makes connections betweenEngElements transparent. Both distributed andmultifidelity connections can be made without regard tolocation of the component, or its fidelity. Modifying thedistribution mechanism can be performed either bysubclassing DefaultConnector, or implementing

Connector directly. Also, connection implementatiodetails are fully encapsulated by the Connectoallowing EngElement and Port to remain unaffected ban changes to the distribution mechanism.

5.3 Example

For test purposes we have established a simple peto-peer distribution mechanism for the EngElemeobjects in our example model. EngElement objects ainstantiated on the remote machine and export thinterface so that theirinit() , run() and stop()methods may be called by Onyx from a local machinIn addition, a RemotePort interface was defined andexported to allow connections from local (non-remotePort objects. This interface allows the connectors aports to invoke the getDataSet() methods to returnserialized object containing necessary engincomponent operating states.

Future efforts in this area will investigate the use omobile object technology, such as ObjectSpaceVoyager [21], to allow the user to dynamically relocatEngElement objects to other platforms on the network

6 Concluding Remarks

Designing and developing new aerospace propulsitechnologies is a time-consuming and expensiprocess. Computational simulation is a promising meafor alleviating this cost, due to the flexibility it providesfor rapid and relatively inexpensive evaluation oalternative designs, and because it can be usedintegrate multidisciplinary analysis earlier in the desigprocess [22]. However, integrating advancecomputational simulation analysis methods suchCFD and FEA into a computational simulation softwarsystem is a challenge. A prerequisite for the successimplementation of such a program is the developmentan effective simulation framework for the representatioof engine components, subcomponents asubassemblies. To promote concurrent engineering,framework must be capable of housing multiple viewof each component, including those views which may bof different fidelity or discipline [23]. In addition, theframework must address the challenges of managthis complex, computationally intensive simulation indistributed, heterogeneous computing environment.

Object-oriented application frameworks and desigpatterns help to enable the design and developmentaerospace simulation systems by leveraging provsoftware design to produce a reusable component-baarchitecture which can be extended and customizedmeet future application requirements. The Onyapplication framework described in this paper provide

va

kle

irwsisx.rs

yhedion

lert

.o

.

Figure 13: Onyx Aerospace Propulsion System Simulation Framework

<< EngElement >>

CompositeEngElement

<< Port >>

<< Model >>

XyzEngElementInfo

VCustomizerPage

<< Customizer >>

DefaultSchematicManager

<< SchematicManager >>

BasicTabbedCustomizer

SchematicIcon

DefaultEngElement DefaultModel

XyzModel

DefaultPort

<< EngElementInfo >>

PortDescriptor

EngElementDescriptor

<< Transform >>

DefaultTransform

DefaultConnector

<< Connector >>

EngSchematicPane

SchematicPane

EngSchematicManager

TransientControlPage

DesignPointPage

XyzCustomizer

VCustomizerDialog

SchematicIconFactory

XyzEngElement

User-defined Classes

V isual Assembly FrameworkConnector Framework

Engine Component Framework

an ensemble of framework components which, together,form an integrated framework for propulsion systemsimulation. Figure 13 shows how the individualframework component structures combine to form theOnyx framework.

Onyx promotes the construction of aerospacepropulsion systems, such as jet gas turbine engines, inthe following ways. First, it provides a common enginecomponent object model which: encapsulates thehierarchal nature of the physical engine model, iscapable of housing multimodel and multifidelityanalysis models, and enforces componentinteroperability through a consistent interface betweencomponents. Second, it enables the construction and ofengine models and customization of the simulation at ahigh level of abstraction through the use of visualrepresentation in the visual assembly framework. Third,it supports both connection and transformation of databetween multifidelity components running in adistributed network environment. Finally, the object-oriented design, built-in support for graphical interfacesand heterogeneous distributed processing, andautomatic memory management, in Java greatlysimplify and unify the design and development of Onyx.

In addition, Java’s byte code and widely available JaVirtual Machine allows Onyx to be highly portable.

The use of object-oriented application frameworand design pattern methods in Onyx help to decoupdomain-specific simulation strategies from theimplementations. This decoupling enables nesimulation strategies (e.g., components, analymodels, solvers, etc.) to be integrated easily into OnyBy applying these design strategies, Onyx allows useto dynamically alter simulation models during anphase of the simulation. The example presented in tpaper serves to illustrate the flexibility, extensibility, anease of using Onyx to develop aerospace propulssystem simulations.

Acknowledgments

The work described in this paper was made possibby funding from the NASA Lewis Research CenteComputing and Interdisciplinary System Office (GranNo. NCC-3-207), and the University of Toledo. MrReed is partially supported by a University of ToledDoctoral Fellowship. We would like to thank GregFollen at NASA Lewis for his continued support

d

y

s,le

-

,”

e

n.

d

Special thanks also to Murthy Devarakonda for hisguidance in preparing this paper. More information onOnyx is available at www-mime.eng.utoledo.edu/~jreed/.

References

[1] Claus, R. W., Evans, A. L., Lytle, J. K., andNichols, L. D., 1991, “Numerical PropulsionSystem Simulation,” Computing Systems inEngineering,Vol. 2, pp. 357-364.

[2] Claus, R. W., Evans, A. L., and Follen, G. J.,1992, “Multidisciplinary Propulsion Simulationusing NPSS,” AIAA Paper No. 92-4709

[3] Evans, A. L., Lytle, J., Follen, G., and Lopez, I.,“An Integrated Computing and InterdisciplinarySystems Approach to AeropropulsionSimulation,” ASME Paper No. 97-GT-303.

[4] Daniele, C. J., Krosel, S. M., Szuch, J. R., andWesterkamp, E. J., 1983, “Digital ComputerProgram for Generating Dynamic Engine Models(DIGTEM),” NASA TM-83446.

[5] Plencer, R., and Snyder, C., 1991, “The Navy/NASA Engine Program (NNEP89) - A User’sManual,” NASA TM-105186.

[6] Curlett, B. P. and Felder, J. L., 1995, “Object-oriented Approach for Gas Turbine EngineSimulation,” NASA TM-106970.

[7] Reed, J. A., 1993, “Development of an InteractiveGraphical Aircraft Propulsion System Simulator,”MS Thesis, The University of Toledo, Toledo,OH.

[8] Drummond, C., Follen, G., and Cannon, M.,1994, “Object-Oriented Technology forCompressor Simulation,” AIAA Paper No. 94-3095.

[9] Taylor, D. A., 1990, “Object-OrientedTechnology: A Manager’s Guide,” AddisonWesley Publishing Company, Inc., Reading, MA.

[10] Booch, G, 1991, “Object Oriented Design withApplications,” The Benjamin/CummingsPublishing Company, Inc., New York, NY.

[11] Holt, G., and Phillips, R., 1991, “Object-OrientedProgramming in NPSS Phase II Report,” NASACR-NAS3-25951.

[12] Reed, J. A., and Afjeh, A. A., 1997, “A Java-based Interactive Graphical Gas TurbinePropulsion System Simulator,” AIAA Paper No.97-0233.

[13] Johnson, R. and Foote, B., 1988, “DesigningReusable Classes,”Journal of Object-OrientedPrograming, Vol. 1, pp. 22-35.

[14] Schmidt, D. C., 1997, “Applying Design Patterns

and Frameworks to Develop Object-OrienteCommunications Software,” Handbook ofProgramming Languages, Volume I, P. Salus, ed.,MacMillian Computer Publishing.

[15] Arnold, K. and Gosling, J., 1996, “The JavaProgramming Language,” Addison WeslePublishing Company, Inc., Reading, MA.

[16] Gamma, E., Helm, R, Johnson, R., and VlissideJ., 1995, “Design Patterns: Elements of ReusabObject-Oriented Software,” Addison WesleyPublishing Company, Inc., Reading, MA.

[17] Fishwick, P. A., 1997, “Computer Simulation:Growth Through Extension,”TRANSACTIONS ofThe SCS, Vol. 14, pp. 13-23.

[18] Fishwick P. A. and Zeigler, B. P., 1992, “AMultimodel Methodology for Qualitative ModelEngineering,” ACM Transactions on Modelingand Computer Simulation, Vol. 12, pp. 52-81.

[19] Swing, 1997, “The Swing Connection,” Availablefrom http://java.sun.com/products/jfc/swingdoccurrent/index.html.

[20] Englander, R., 1997, “Developing Java BeansO’Reilly & Associates, Inc., Sebastopol, CA.

[21] Voyager, 1998, “ObjectSpace Voyager CorPackage Technical Overview,” Available fromhttp://www.objectspace.com/.

[22] Jameson, A., 1997, “Re-Engineering the DesigProcess through Computation,” AIAA Paper No97-0641.

[23] Irani, R. K., Graichen, C. M., Finnigan, P. M., andSagendorph, F., 1994, “Object-baseRepresentation for Multidisciplinary Analysis,”AIAA Paper No. 94-3093.

Documents

An Object-Oriented Framework for Distributed … Object-Oriented Framework for Distributed Computational Simulation of Aerospace Propulsion Systems John A. Reed and Abdollah A. Afjeh