Project Integration Architecture: Application … Integration Architecture: ... Project Integration...

William Henry JonesGlenn Research Center, Cleveland, Ohio

Project Integration Architecture:Application Architecture

NASA/TM—2005-213611

March 2005

https://ntrs.nasa.gov/search.jsp?R=20050161644 2018-07-09T00:07:47+00:00Z

The NASA STI Program Office . . . in Profile

Since its founding, NASA has been dedicated tothe advancement of aeronautics and spacescience. The NASA Scientific and TechnicalInformation (STI) Program Office plays a key partin helping NASA maintain this important role.

The NASA STI Program Office is operated byLangley Research Center, the Lead Center forNASA’s scientific and technical information. TheNASA STI Program Office provides access to theNASA STI Database, the largest collection ofaeronautical and space science STI in the world.The Program Office is also NASA’s institutionalmechanism for disseminating the results of itsresearch and development activities. These resultsare published by NASA in the NASA STI ReportSeries, which includes the following report types:

• TECHNICAL PUBLICATION. Reports ofcompleted research or a major significantphase of research that present the results ofNASA programs and include extensive dataor theoretical analysis. Includes compilationsof significant scientific and technical data andinformation deemed to be of continuingreference value. NASA’s counterpart of peer-reviewed formal professional papers buthas less stringent limitations on manuscriptlength and extent of graphic presentations.

• TECHNICAL MEMORANDUM. Scientificand technical findings that are preliminary orof specialized interest, e.g., quick releasereports, working papers, and bibliographiesthat contain minimal annotation. Does notcontain extensive analysis.

• CONTRACTOR REPORT. Scientific andtechnical findings by NASA-sponsoredcontractors and grantees.

• CONFERENCE PUBLICATION. Collectedpapers from scientific and technicalconferences, symposia, seminars, or othermeetings sponsored or cosponsored byNASA.

• SPECIAL PUBLICATION. Scientific,technical, or historical information fromNASA programs, projects, and missions,often concerned with subjects havingsubstantial public interest.

• TECHNICAL TRANSLATION. English-language translations of foreign scientificand technical material pertinent to NASA’smission.

Specialized services that complement the STIProgram Office’s diverse offerings includecreating custom thesauri, building customizeddatabases, organizing and publishing researchresults . . . even providing videos.

For more information about the NASA STIProgram Office, see the following:

• Access the NASA STI Program Home Pageat http://www.sti.nasa.gov

• E-mail your question via the Internet [email protected]

• Fax your question to the NASA AccessHelp Desk at 301–621–0134

• Telephone the NASA Access Help Desk at301–621–0390

• Write to: NASA Access Help Desk NASA Center for AeroSpace Information 7121 Standard Drive Hanover, MD 21076

William Henry JonesGlenn Research Center, Cleveland, Ohio


NASA/TM—2005-213611

March 2005

National Aeronautics andSpace Administration

Glenn Research Center

Available from

NASA Center for Aerospace Information7121 Standard DriveHanover, MD 21076

National Technical Information Service5285 Port Royal RoadSpringfield, VA 22100

Trade names or manufacturers’ names are used in this report foridentification only. This usage does not constitute an officialendorsement, either expressed or implied, by the National

Aeronautics and Space Administration.

This report contains preliminaryfindings, subject to revision as

analysis proceeds.

Available electronically at http://gltrs.grc.nasa.gov


William Henry JonesNational Aeronautics and Space Administration

Glenn Research CenterCleveland, Ohio 44135

ABSTRACT: The Project Integration Architecture (PIA) implements a flexible, object-oriented, wrapping architecturewhich encapsulates all of the information associated with any application. The architecture allows the progress of aproject to be tracked and documented in its entirety. Additionally, by bringing all of the information sources and sinks ofa project into a single architectural space, the ability to transport information between those applications is enabled.

1 Introduction

In the late 1980’s, the Integrated CFD and Experiments(ICE) project [1, 2] was carried out with the goal of pro-viding a single, graphical user interface (GUI) and datamanagement environment for a variety of CFD codes andrelated experimental data. The intent of the ICE projectwas to ease the difficulties of interacting with and inter-mingling these disparate information sources. The projectwas a success on a research basis; however, due to varioustechnical limitations (for instance, the difficulty of devel-oping object-oriented constructs in a non-object-orientedlanguage) and the loss of key personnel, it was deemedinappropriate to advance the effort beyond the successesachieved to that point. Thus, a re-engineering of theproject was initiated in 1996. The effort was first renamedthe Portable, Redesigned Integrated CFD and Experments(PRICE) project and then, as the wide applicability of theconcepts came to be appreciated, the Project IntegrationArchitecture (PIA).

Two key re-engineering decisions were made: the C lan-guage used by the ICE project would be abandoned in favorof the now-available C++ object-oriented extension to thatlanguage and the graphical user interface would be elimi-nated as a product element of the project. The first decisionwas but a matter of circumstances; had C++ been availableto the original ICE team at project outset, it would almostcertainly have been selected for use. The second decision,to remove the GUI from the project product set, was takenonly after a period of time and reflected two truths: first,that a cross-platform GUI with the scope of functionalityenvisioned was far beyond the resources of the PIA projectand, second, that such a GUI was duplicative of other ef-forts within the Agency.

During the intervening years, work has proceeded andan operational demonstration of the PIA project has beenachieved. The current effort has not achieved the com-plete range of functionality developed in the original ICE;however, the architectural dividing line has been more thor-oughly defined and adherence to it has been more rigorous.Portability of the architecture, not only across platforms,but to distributed object architectures, has been demon-strated. This path ahead is more clearly defined.

2 Goals

Put in simple terms, the basic goal of the PIA effort is tocapture in its entirety the usage of any application in a sin-gle, useful, well-defined form. This capturing is not limitedto the simple output of the application itself, but furtherincludes coordinating information and the specialist’s owninsights into the meaning of the information.

The nature of a ‘application’ is, by project design, nebulus:it is considered to be any computer-realized ‘thing’ whichprovides or generates useful information. This may includegeometry definitions extracted from Computer Aided De-sign (CAD) programs, geometry or other specifications de-rived from design code predictions, results of experimen-tal investigations, analysis, simulation and modeling, andmore. Furthermore, applications are not considered to belimited to technical areas; business models, quotation sys-tems, financial analysis, and the like may also be viewed as‘applications’ by PIA, thus allowing the intermingling ofall information about a project.

By bringing all of the information of the process into onearchitectural design, a number of advantages are expectedto (and, it is believed, do) accrue.

NASA/TM—2005-213611 1

1. The information about the information (referred to insome conceptions as the meta-data) is encapsulatedwith the information itself. Information about the con-ditions at which the information was generated, or themerit of the information, is no longer separately storedin a specialist’s unlocatable journal.

2. A common tool set for the use of applications is pos-sible. A single GUI with a single look-and-feel canbe devised so as to reduce the specialist’s learningcurve for additional applications to that solely relatedto the application. The specialist’s habits of exploringa problem can now be the same from one applicationto the next.

3. Common browsers and search engines may be imple-mented to peruse the supply of information in detailand convert it into information in general for end con-sumers of that knowledge.

4. By wrapping every application in a well-defined arch-itecture, it is now possible to code into such applica-tions the knowledge to acquire information automat-ically from other applications. Because of the archi-tectural design, such coded knowledge is based uponthe kind of information desired, rather than upon theapplication generating that kind of information.

5. Wrapped applications coded to obtain informationbased upon its kind may then be combined in a di-rected application graph to build, in effect, super-applications. Applications of differing fidelities anddisciplines may be mixed together as appropriate tothe project.

6. The building of super-applications enables project-wide optimization and/or sensitivity analysis to beconducted.

3 Self Revelation

Perhaps the key technology that enables the goals aboveis that of self revelation, the ability of a thing to reveal toothers its own nature. Such a capacity can be implementedby many different techniques; however, this capacity is avery natural element of object-oriented technology.

The concept of self revelation as discussed in the two sec-tions below can be very quickly understood by the simpleanalogy of meeting a new person at a party. One of thenatural things to do in such a situation is to ask what theperson does; if that person answers, for example, that sheis a medical doctor, an entire course may be set based upon

the inquisitor’s needs. If the inquisitor has a medical con-dition for which he desires a free opinion, it may be ap-propriate to inquire further as to the doctor’s specialty. Onthe other hand, if the inquisitor has not the first interest inmedical topics, it may be time to discretely spill somethingand hurry off for a napkin.

To see the importance of this concept, consider the anal-ogous alternative: what if one did not have the ability toinquire of new people met at a party? In that event onewould be either non-functional as a party animal, or par-ties would have to be incredibly rigid in their formulationso as to meet the practical breadth of programmed expec-tation in the participants. Either no conversations could bepermitted because the ability to predict the relevance wouldbe entirely lacking, or all guest-to-guest interactions wouldhave to be predetermined and pre-scripted so as to assurethat one talked with others about relevant subjects. In ei-ther case, a lack of self revelation would be quickly seen astruly confining.

3.1 Self Revelation of Kind

The revelation of kind identifies the essential character ofthe revealing entity. In the object-oriented implementationof PIA, this sets expectations as to the kind of informa-tion and functionality a particular object has: it is a free-stream Mach number parameter, or it is an operation thatmay or may not be enabled and, if enabled, will executeand do something, or it is an application offering parame-ters, identifications, and operations, or it is any one of analmost unlimited variety of other things. The key featureis that, upon finding out its kind, precise expectations as towhat it has and what it is willing to do may be confidentlyinferred.

The revelation of kind is effected in two ways by PIA: aninterrogative form and a declarative form. In the interroga-tive form, a predicate of kind is posed to the object and ei-ther affirmed or denied. In the declarative form, an inquiryis made of the object and a value is returned declaring thetype of the object.

Because of the derivational nature of object technology,both of these revelational forms support the concept ofdepth. That is, an object may be of a particular kind atsome derivational depth but, because of further derivation,may not appear to be of that kind on its surface. Theexamination of such layers of meaning is referred to inthe PIA nomenclature as ecdysiastical analysis (from theGreek ekdysis, ekdyein, to get out of, strip off).

NASA/TM—2005-213611 2

3.2 Self Revelation of Content

The revelation of content identifies the extent to which ex-pectations based upon the revelation of kind are, in fact,fulfilled. Here, the revealed kind of an object allows oneto expect that it has content of a given nature, but that na-ture may yet be nebulus by design, or may be variable in itsamount, or may be variable in other specified ways.

Consider for example an application object. As will be dis-cussed shortly, an application object is known to have a setof operations encapsulated in operation objects; however,by specification, it is not known whether or not there ac-tually are any operation objects (that is, the set could benull), nor if there are any such operation objects, preciselywhich kinds will be present. Code consuming an applica-tion object must deal with it on that basis; that while anoperation object set is defined, it may be empty and, if itis not empty, that further interrogation of individual oper-ation objects will be necessary to determine the nature ofthe operations available.

4 Application Architecture

Building upon the concept of self revelation, an applica-tion architecture as depicted in Figure 4.1 has been devised.While the structure may, at first, appear daunting, it is, infact, a quite orderly thing which may be easily understood.

An application presented in the image of PIA begins witha central application object, labeled PacAppl in the uppercenter of the figure, which is the root structure from whichall further components emanate. Four principal compo-nents are currently provided by the PacAppl object:

1. A set of operations that the application is willing toperform,

2. A mass of data which the application currently con-tains,

3. A structure by which the contained data is identified,and

4. An ecdysiastical sorting of the information-bearingobjects in the application.

The first three components are depicted in the figure in theupper left, the upper central to lower left diagonal, and thecentral right, respectively. The fourth component is not de-picted due to its structural complexity. Each of these com-ponents is taken up in its own subsection below.

4.1 Application Components

4.1.1 Parameter Configurations

The architectural discussion begins with the holders of pa-rameters (the objects which hold application data of allforms) depicted as the structure proceeding to the lower leftfrom the PacAppl object. These objects, labeled PacCfg inthe figure, are called ‘configurations’. If one considers theaggregate of all data in an application (both input and out-put of all types and forms) to constitute an n-dimensionalspace (where, admittedly, n can be quite a large number),then a parameter configuration is considered to identify ex-actly one point in that dimensional space. Put less formally,a configuration is simply a distinct set of input data and (asappropriate) the output data it gives rise to.

Because of this definition, a changed data value consti-tutes a new data configuration and, commonly, results in anew PacCfg object. Because the data set of a typical PIA-wrapped application is expected to be large, it was decidedthat simple replication of the entire data set each time a newconfiguration occurred would be wasteful. Thus, as de-picted in the figure, PacCfg objects are arranged in an n-arytree and the PacAppl object identifies the PacCfg acting asthe patriarch of that tree. Descendent PacCfg objects areconsidered to inherit missing data components from theirancestral configurations, thus eliminating the need to repli-cate unaltered data.

The potential operation of this architecture can be seen inthe figure. The PacCfg object acting as the patriarch ofthe configuration tree (that is, the PacCfg object directlypointed to by the PacAppl object) will often contain thefully populated data set of the problem being explored.In the figure this would be the parameter objects labeledA/Inl/Cfd through F/Noz/Cfd. Descendent PacCfg objectswould contain only the parameter objects being changedin the course of research investigation. In the figure, thefirst two direct descendents of the patriarch change only theE/Duc/Cfd parameter object while the third direct descen-dent also changes the F/Noz/Cfd parameter object. Thethree further descendents of the first direct descendent goon to hold modified values of the A/Inl/Cfd parameter ob-ject. The bottom leftmost configuration thus has its ownA/Inl/Cfd parameter object, inherits its E/Duc/Cfd itemfrom its direct parent, and inherits all remaining parame-ter objects of the comprehensive set from the patriarch.

Parameter objects within a configuration are maintainedas a map (implemented in fact as a balanced, binarytree) sorted by a fully-qualified name (for example, theA/Inl/Cfd name above). Duplicate names are not al-lowed, so each parameter object must have a unique, fully-qualified name. The reason for this arrangement is to avoid

NASA/TM—2005-213611 3

PacAppl

PacCfg

PacCfg PacCfg PacCfg


Par: C/Inl/Cfd

Par: A/Inl/Cfd Par: E/Duc/Cfd

Par: B/Inl/Cfd Par: D/Duc/Cfd Par: F/Noz/Cfd

Par: E/Duc/Cfd Par: E/Duc/Cfd Par: E/Duc/Cfd

Par: F/Noz/Cfd

Par: A/Inl/Cfd Par: A/Inl/Cfd Par: A/Inl/Cfd

Op: Kill

Op: Init Op: Run

Pid: Cfd

Pid: Duc Pid: Inl Pid: Noz

Pid: D Pid: E Pid: A Pid: B Pid: C Pid: F

Figure 4.1: PIA Application Architecture

the needless replication of data structure in cases whereonly that structure uniquely identifies a particular param-eter object to be held in modified form in a dependent con-figuration. The structure of data is moved into the contentof the fully-qualified name so that only that particular pa-rameter object need be replicated (in modified form) in adescendent configuration.

To make this fully-qualified name concept more concrete,consider a multi-block CFD code in which each block hasa set of repeated attributes whose particular value may varyfrom block to block. Thus, block 1 would have the at-tributes A, B, and C, as would block 2, block 3, and so on.Without the movement of structure into the fully-qualifiedname, it would be at least necessary to replicate blocks 1,2, and 3 in order to change the B attribute of block 3 soas to make it clear that the modified B attribute is, in fact,the B attribute of the third block. By moving structure intothe fully-qualified name, perhaps by naming the attributeB/Block3/SomeCfdCode, it is only necessary to replicatethe modified B attribute in the descendent configuration.The fact that it is the B attribute of the third block is madeclear by the fully-qualified name.

By expanding the configuration tree as work progresses, aresearcher may parametrically explore a design space withreasonable economy while leaving a comprehensive docu-menting trail behind. As will be discussed in a later section,a number of distinct policies may be implemented with re-gard to the establishment of a new configuration as opposedto the modification of an existing configuration.

4.1.2 Parameter Identification

The configuration structure discussed above introduced theconcept of the fully-qualified name whose purpose was tocapture the structure of data without requiring the needlessreplication of that structure within each parameter configu-ration. The revelation of structure within the data (which isa revelation of content for the PacAppl object) is taken upby the identification structure depicted at the central rightof the Figure 4.1. These are the objects whose labels beginPid, each of which is followed by a name text.

This parameter identification element of the applicationarchitecture is, again, arranged as an n-ary tree. In thiscase, the tree structure is used to reveal the correspondingdata structure of the application. The fully-qualified nameof a parameter is developed by concatenating the names ofeach of the tree elements leading to the final identificationof that parameter. In the example of the figure, all data pro-ceeds from the application root, Cfd. Cfd has three majordata structures: Duc (Duct), Inl (Inlet), and Noz (Nozzle).Descending from this level, Inl has three parameters, A, B,and C, Duc has two parameters, D and E, and Noz has oneparameter, F. Thus, the fully-qualified name of the B pa-rameter obtained by concatenating the names of the pathelements leading to its identification would be B/Inl/Cfd.

Beyond this point, the parameter identification structure isunremarkable. The only point to be made is that, withinany group of siblings in the tree, the names of identifieddata items/structures must be unique. Thus, the Noz iden-tification cannot be repeated at its level. Shifting to the

NASA/TM—2005-213611 4

example of the multi-block CFD code, this means that thename ‘Block’ may not simply be repeated. Instead, namessuch as ‘Block01’, ‘Block02’, ‘Block03’ and so on mustbe generated (probably as a dynamic response to problemsetup) to make the multiple-block level of the data structureunambiguous.

4.1.3 Operations

A key element of most applications is not solely that theyhold data, but that they do something with that data. Oftensome algorithm is executed during which inputs are turnedinto outputs. To reveal these operations, the PacAppl ob-ject identifies a map of operational objects (labeled Op fol-lowed by a name in upper left of Figure 4.1) sorted by op-eration name, which must be unique. In the example of thefigure, three operations, Init (Initialize), Kill (Kill a run-ning operation), and Run (take the input data and run theoperation to completion, acquiring new output data), areprovided.

Some operations may require specific interaction with theresearcher. For instance, an operation obtaining input froma file may need to prompt the researcher to identify thefile to be used. For this purpose, a GUI call-back class,PacGUI, is defined which provides a known, well-definedset of such interactions. Such an object must be supplied toeach operation each time that operation is invoked.

While standards as to what a particular operation nameshould connote are being contemplated (for instance, ‘Run’will probably connote a batch style run to completion while‘Start’ would indicate an interactive operation initiation tobe terminated by some later ‘Stop’), there is no standardor requirement for the operations that any particular PIA-wrapped application is to provide. Thus it is that the HighSpeed Research (HSR) Inlet Unstart test support (the firstapplication actually adapted to this architecture) providesneither ‘Start’ nor ‘Stop’, but instead provides ‘LoadFrom-File’ and ‘CreatePlaceHolder’ operations.

4.1.4 Object Sorting

A fourth structure has been defined and implemented, but itis not shown in the figure. The structure provides a sortingof objects of the application by their derivational heritage.For example, a far-field Mach number parameter object issorted as being

1. A far-field Mach number parameter,

2. A Mach number parameter,

3. A dimensional, double scalar parameter, which is, infact, non-dimensional,

4. A dimensional, double scalar parameter,

5. A double, scalar parameter,

6. A scalar parameter,

7. A parameter,

8. A describable application object,

9. A directed graph object,

10. A status-bearing object, and, finally,

11. An object.

The need for this derivationally-exhaustive sorting arisesbecause a particular application may specialize parametersbeyond the level that is well known. Continuing the exam-ple above, an application may define and use many particu-lar, custom types of far-field Mach number parameters, buthave no parameter object instances that are exactly a far-field Mach number parameter as defined for all applicationsby the architectural standard. Without the derivationally-exhaustive sorting, an inquiring application would have toexamine each parameter to determine if it was, in fact, akind of far-field Mach number, while with the sorting aninquiry can be directed immediately to those specializedparameter objects even though none may be exactly a far-field Mach number parameter object.

This object-sorting structure has been unused to this pointsince its utility is principally of use to search engines andthe like, which are themselves as yet unrealized.

4.2 Operating Context

By now the reader will be impatient to learn the signifi-cance of the great, sweeping curves that run from each ter-minal node of the parameter identification tree, and fromeach node of the operation identification tree to the lowerleftmost node of the configuration tree. The answer is thatthe objects of both these structures operate within the con-text of a particular parameter configuration which must beidentified when certain functions are invoked.

Identifications and operations offer IsVisible and IsEnabledmember functions, respectively. These operations indicatewhether or not their presenting objects are active (after theirkind) within the context of the current parameter configu-ration. By this means, an Initialize operation could refuseto work when queried in the context of a parameter con-figuration that either had or inherited a populated data set.

NASA/TM—2005-213611 5

Similarly, an identification of, say, a turbulence model pa-rameter would respond that no such parameter exists if theturbulence model, itself, is turned off in the identified con-figuration, even though it might well inherit such a parame-ter from an ancestral configuration in which the model wasturned on.

5 Configuration Policy

As illuminated above, the application architecture is quiteabstract and leaves an enormous amount of room for ma-neuver in adapting an application to the PIA environment;however, the architecture also leaves considerable lattitudeto the consuming tool (most commonly, a conforming GUI)to make of things what it will. One of these areas is theconfiguration policy to be applied when modifying a dataitem.

As noted in the architecture section, the modification of adata item identifies a new point in the n-dimensional dataspace and, customarily, results in the generation of a newconfiguration object attached to the configuration tree at apoint appropriate to inherit all the other unmodified param-eter objects. This is a policy which is, itself, not actuallyprovided by the PIA implementation, nor is it necessarilymandated by the architecture. The decision to actually im-plement this policy is left to the consuming tool.

The reason for leaving this policy decision to the consum-ing tool is that this is not the only reasonable policy. Sev-eral additional policies are suggested in the following sub-sections and it may be that a GUI might well wish to offersome or all of these policies to the researcher to facilitatethe work being conducted.

5.1 Replication

This policy is the one initially suggested above. A newconfiguration is generated and attached, presumably as thedirect descendent of the configuration containing the dataitem to be modified, and the encapsulating parameter objectis replicated in that new configuration with the modifiedvalue. This might be considered the basic step in designspace exploration.

5.2 Modification

If the data item is contained in a configuration with no de-scendent configurations (or, for additional complexity, nodescendent configurations inheriting the data item), the en-capsulating parameter object can be modified as it resides

in the existing configuration, provided that no output re-sults exist in that configuration or that such output resultsas do exist are either marked invalid or are discarded. Thispolicy, while not so utterly clear as the previous, might beuseful when casting about trying to find a meaningful start-ing point.

5.3 Invalidation/Re-execution

In this policy, the data item may be modified despite (in-deed, because of) the fact that descendent configurationsinherit the data value. Here, the policy goes beyond sim-ply invalidating the output data dependent on the data itemto be modified. The policy would specify the automatic re-execution of the application to regenerate those results withthe effect that an entire design space might be analyzed asthe result of a single act. Note, though, that the semanticsof architecturally identifying the re-execution act have notyet been devised; however, if and when the implementa-tion of such a policy should come to hand, the developmentof appropriate semantics would not seem to be a difficultproblem.

5.4 Subgraph Replication

The previous policy has the disadvantange of discarding theprevious results of the design space represented by the de-scendents of the configuration. A further extension of thepolicy could be to (1) replicate the encapsulating parame-ter object for modification in a new, sibling configuration,(2) replicate the descendent subgraph inheriting the origi-nal value as a descendent subgraph inheriting the modifiedvalue and, then, (3) invalidate and regenerate the output re-sults in that replicated subgraph. This policy allows theparametric study of complete design spaces while retainingall of the previously generated results.

6 The Base Object

Very nearly all of the object classes involved in implement-ing the PIA application architecture described above arederived from a common base class, PacBObj. This baseclass provides several key features:

1. The (inherited) ability to participate in a directedgraph,

2. The ability to be ‘described’,

3. The ability to transmit declared events, and

NASA/TM—2005-213611 6

4. The ability to traverse upward through the applicationstructure.

6.1 Directed Graph Capabilites

The ability to participate in a directed graph allows thedirect implementation of the n-ary trees of the parameterconfiguration and identification structures through inher-ited characteristics. An n-ary tree is, after all, merely adirected, acyclic graph in which only one immediate pre-decessor is ever allowed.

As will be noted later, further use of the directed graph ca-pability is made.

6.2 Descriptive Capabilities

The ability to be described brings a good deal of usefulfunction to the entirety of the architecture. The descriptionsthat may be added to any such object include but are notlimited to

1. A name,

2. A set of access controls,

3. An annotation,

4. A short, descriptive text,

5. A change history,

6. A drop-down prompt,

7. One or more graphical descriptions,

8. A Universal Resource Locator (URL),

9. A descriptive, multi-line text,

10. A type,

11. A measurement unit description, and

12. A related parameter reference.

Indeed, virtually any sort of descriptive element can be de-vised and added to the repertoire merely by deriving a classfrom the appropriate descriptive base class (which is, itself,derived from PacBObj and may, thus, be described).

Because not all objects will necessarily have descriptive el-ements and certainly not all objects will have all descriptiveelements, it was desired to make the descriptive system one

of minimal overhead. Thus, instead of a series of com-ponents embedded in the PacBObj class, the only fixedcomponent of the descriptive system is a pointer to an or-ganizing head which, if present, ecdysiastically sorts a setof description objects by type. Thus, the only unavoidableoverhead is that of a single pointer which, occassionally,may be null.

The only limitation of the descriptive system is that, withina descriptive set, only one instance, at most, of any partic-ular controlling descriptive type (that is, at most one name,one annotation, one URL, etc.) is permitted. This limita-tion is offset to an extent by the fact that the descriptivesystem is implemented in a layered, hierarchial manner inparallel with the derivational class hierarchy and that dis-tinct descriptive sets may exist at each such level. Thus, forexample, a scalar double kinematic viscosity object mightbe described at the level of

1. A kinematic viscosity,

2. A viscosity,

3. A dimensional scalar double parameter,

4. A scalar double parameter,

5. A scalar parameter,

6. A parameter, or

7. A PacBObj object.

This presumes, of course, that that is the derivational classhierarchy of the object.

Within this descriptive hierarchy, the top-most description(that is, the description of the most derived class level) ofany kind is considered to be the preferred description; how-ever, the facilities exist to reveal the entirety of the descrip-tive hierarchy should it be desired.

6.2.1 Engineering Logs

The multi-line, descriptive text form is provided as the pos-sible basis of an engineering log facility. Here an indefinite,expandable number of text string elements in an ordered listcan be associated with any PacBObj derived object. Allthat is lacking is for the consuming GUI to provide an ap-propriate editing facility to access, modify, and update thetext. This form does not offer any implicit time stamping;however, if such a feature were desired, it could be addedeasily enough in a derived class.

NASA/TM—2005-213611 7

6.2.2 Change Histories

A change history descriptive form is provided. It providesan implicitly time-stamped, ordered, multi-line descriptiveform. This form is implicitly used by the PacPara (pa-rameter) base class to record parameter modifications asprevious value texts. All currently implemented parame-ter classes utilize this capability in their corresponding Set-Value services.

6.2.3 Access Controls

The final descriptive form worthy of further discussionis the access control description. Again, any PacBObj-derived object can attach access control descriptionsthroughout its descriptive hierarchy. These descriptions,while defined only in terms of base class functionality, typ-ically consist of an ordered list of access control entriesagainst which an identified user is checked. The first en-try matching the user provides the access characteristicsgranted. Should no such match be made, a default policyis applied. Since descriptions, and hence access control de-scriptions, are themselves derived from PacBObj, accesscontrols may be applied to access controls. This recursiveloop is broken by a self-controlled access control whichprovides access control characteristics not only for the ob-ject it describes, but for itself as well.

Perhaps the most remarkable thing about the access controldescriptive form is that it was added to the descriptive sys-tem on the order of a year after the descriptive system hadbeen designed, implemented and, in a project sense, ‘put tobed’, thus illustrating the power and flexibility of the basicdescriptive concepts. It is also important to note that theaccess control descriptive form (as with all the other de-scriptive forms) incurs no object ‘cost’ beyond the singlemap head pointer (which may be null) until it is actuallyused.

6.3 Declared Events

The PacBObj base class implements an event facility inwhich some utilizing entity may attach one or more objectsof PacEvent derivation to a PacBObj-derived object. Thisevent base class defines a number of different event typesbut, as a base class, provides at most a default responseshould the event be declared. The PacBObj base class im-plements corresponding event functions which, if invoked,will identify each attached event object and transmit theevent declaration to it.

Utilizing code is responsible for developing and attachingderived event class forms which do something meaningful

should an event be declared. Just exactly what act occursis left entirely to the utilizing code. Automated correctionsmay be applied, email may be sent to a user, a notationmade in a log file, or nearly any other thing may occur inresponse. Further, there is no requirement that the event ob-jects used be of the same kind and, even beyond this, thereis no artificial limitation on the number of event objects thatmay be attached to a particular PacBObj object, nor uponthe number of PacBObj objects that may be attached to aparticular event object.

As a facility defined and implemented in the PacBObjclass, the event mechanism is available throughout virtuallyall of the application architecture. Applications, parameterconfigurations, operations, parameters, parameter identifi-cations, descriptions, and more may all declare events fornotation, action, or other response by utilizing code.

6.4 Upward Reference

The basic direction of the application architecture is downfrom encompassing components to more specific compo-nents. Applications identify operations, configurations,and parameter identifications, configurations identify pa-rameters, parameters identify descriptions, and so on. Inimplementation, though, it is frequently necessary to tra-verse in the oppositive direction; an operation object mayneed to identify its application object so that it can thenlocate the parameter identification structure.

This need is met by a pointer member and supporting codein the PacBObj class which references the next higher levelelement of the application structure. Parameters, for ex-ample, reference their containing parameter configurationobject.

The supporting code permits traversals of this upward link-age in search of a particular kind of object. Thus, simple re-quests may traverse several structural levels. Further, suchcode need not be sensitive to the number of levels skippedto locate the desired structural level. A description seek-ing to locate the application object need not be concernedwhether or not it directly describes a parameter in a config-uration of an application; its uplevel reference coding willwork equally well if it is a description of a description ofa description of a parameter in a configuration of an ap-plication, or if it is a description of an identification of anapplication, or a description of an operation of an appli-cation. This allows wide application of coding that must,itself, still traverse the structural form of applications.

NASA/TM—2005-213611 8

7 Parameters

Data items to be placed in configurations are encapsulatedin objects derived from a common parameter base object,PacPara, which is itself derived from PacBObj. As men-tioned in the previous section, the PacPara class imple-ments an implicit change history protocol which notes allthe previous values of the encapsulated data item as time-stamped text entries kept in an ordered list.

7.1 Dependent Parameters

The parameter base class utilizes the directed graph capa-bilities inherited by it to implement a dependent parame-ter mechanism. PacPara provides implementing code toregard each successor of a graph in which the presentingobject participates as being dependent upon the data valuewhich the presenting object encapsulates. In the event thatthat value is changed, those objects dependent upon thatvalue (throughout the range of the graph) are informed.

Of somewhat greater complication than this is the realiza-tion that the replication of a benefactor parameter requiresthe replication of its dependent parameters. If a benefactorparameter in a particular configuration is to be replicatedand modified in a descendent configuration, the dependentparameters of that original benefactor cannot also be de-pendents of the replicated parameter. In turn, the replicated(and modified) benefactor cannot simply inherit the depen-dents of the original parameter since their values (presum-ably) represent correct dependent values for that originalparameter, not the modified value of the replicated parame-ter. Thus, PacPara must (and does) provide code that willcorrectly replicate the dependent subgraph of a replicatedparameter so that the modified value of the replicated bene-factor may be correctly propagated to the replicated depen-dents in that subgraph.

7.2 Infusion of Semantic Meaning into Parameter Ob-jects

The self revelation of kind mechanism provided by thefoundation object of the developed class system is used bythe parameter object hierarchy to infuse semantic meaninginto parameters [3]. The first derivations of parameter ob-jects specialize parameters by their basic structural forms;scalar, vector, matrix, organizational, and the like. Furtherderivation then associates an atomic kind; long, double,Boolean, string, and the like with these forms as appro-priate.

A further specialization of double parameter kinds declaresthem to be dimensional in nature, that is being a measure-

ment in some system of measurement such as the metricsystem of measurement. (The concepts of dimensionalityare discussed in greater detail in [4].) From this point agreat majority of engineering parameters may then be de-rived, each drawing upon the dimensional base facilitiesto present themselves in the system of measurement re-quested.

Many other engineering parameters are non-dimensional.Thus, the next specialization of dimensional objects is,paradoxically, to a non-dimensional form which may thenbe used as a basis for these non-dimensional parame-ters. The basing of non-dimensionality upon a dimensionalfoundation allows the free combination of these parame-ters with dimensional values. Thus, a Mach number maybe multiplied by a computed speed of sound to result in adimensional speed available in whatever system of units isdesired.

The related parameter descriptive mechanism is utilized toassociate other parametric information with semantically-defined parameter objects. Consider the following utiliza-tion of the capability.

1. A vector of double values is specialized through sev-eral layers of derivation to be a one-dimensional-gridof total-pressure values. (The derivation of the class isshown in Figure 7.1.) That kind of parameter object isthen defined as associating through the related param-eter descriptive mechanism a vector of linear positionmeasurements which reveal the X-coordinate valuesof that one-dimensional grid.

2. Another parameter specialization through derivationcreates a vector of those one-dimensional-grid total-pressure parameter objects which is declared to be atime-history of those parameters. (The derivation ofthe class is shown in Figure 7.2.) The related param-eter descriptive mechanism is again used to locate atime-value vector the elements of which are definedas being the times associated with the correspondingelements of the time history vector.

By working to the semantic meanings of these two classes,a consumer of the second parameter object may discover itto be a time history of one-dimensional-grid total-pressurevalues for which it may further obtain (1) the times at whicheach grid result is valid and (2) the positions of the gridpoints.

This infusion of semantic meaning through derivationalspecialization exposed through self revelation of kind and,to an extent, content is an enabling technology for the prop-

NASA/TM—2005-213611 9

agation of information between applications, as will be dis-cussed shortly.

PObject

PObjSta

PObjDgn

PacBObj

PacPara

PacParaArr

PacParaArrDoub

PacParaArrDoubDim

PacParaArrDoubPrs

PacParaGasArrPtl

PacParaGas1DGridPtl

Figure 7.1: Derivation of a One-Dimensional Grid of TotalPressures

PObject

PObjSta

PObjDgn

PacBObj

PacPara

PacParaArr

PacParaArrPara

PacParaTimHist

PacParaGasTHst1DGridPtl

Figure 7.2: Derivation of a Time History of One-Dimensional Grid of Total Pressures

8 Persistence

Saving the state of an encapsulated application, whetherimplicitly or explicitly commanded, is a self-evident re-quirement and was, in fact, one of the very first challengesconfronted. Review of various commercial data base prod-ucts at the start of the project revealed all of them to begenerally intolerant of evolutionary change, which itselfwas another requirement of the PIA effort. This was notan overriding concern though because, for administrativereasons, these products simply were not available to theproject.

To meet the persistence requirement, an object serializa-tion capability was implemented. In this approach objectcontents are written out to or read back from an archivefile (or other repository) under the control of a Serializefunction. (The ‘Serialize’ name is entirely arbitrary.) Anarchive object keeps track of what objects have been seri-alized or de-serialized so that redundant references to anobject are treated as such and do not cause redundant seri-alizations or de-serializations of the object.

The drawback of this serialization is also its strong point: aSerialize function must be manually coded for every classthat might participate in such an operation. For the mostpart such coding amounts to mere tedium; however, it isin this coding that the groundwork for evolutionary changecan be laid. If one takes the precaution of serializing anarchive version number as the very first step of object se-rialization, then conditional code for the de-serialization ofold object versions can be generated when object revisionsare defined. By this means, old objects may be recoveredeven when the base class of a class has been changed. Thisallows quite extraordinary revisions to an implemented PIAwrapping to be effected without loosing old, archived ver-sions of the implementation.

As utilized in the C++ implementation of the architecture,the serialization of objects is explicitly commanded and re-sults in an act which saves the entire application wrapperinstance to persistent storage, or recovers that entire objectset from storage. As will be discussed later, the CommonObject Request Broker Architecture (CORBA) implemen-tation of the architecture is implicitly persistent; however,the same serialization mechanism is, in fact, used, but onan object-by-object basis rather than across the entire ap-plication wrapper object set as a whole.

9 Information Propagation

The infusion of semantic meaning into parameter objectsthrough derived class specialization and self revelation

NASA/TM—2005-213611 10

mechanisms forms the basis for the interapplication trans-fer of information by allowing one application to ‘look’ atparameters of another application and discern on an auto-matic basis the semantic nature of the observed parame-ter objects. This basic technology enables a number of in-terapplication information transfer modes from user-drivencollaborative exchanges through automated browser/searchengine harvesting of information to completely automatedapplication graphs for comprehensive engineering analysisof a project as a whole.

Because the propagation of parametric informationthroughout application graphs could be implemented en-tirely within the PIA framework, it was the first form ofinformation transfer implemented by the PIA project [5].The basic goal is as has been previously suggested: to ar-range disparate applications into a cooperative graph whoseoperation carries out all of the analyses relevant to an engi-neering project as a whole.

Consider as an example of the arrangement of applicationsinto a graph for the purposes of information propagationthe situation depicted in Figure 9.1. Here, an analysis con-trol application is made the initial node of the applicationgraph. This pseudo-application exists solely as a conve-nient point for declaring new configurations of the overallproblem and setting parameters within those configurationsto control the analysis done. Two read-only applications, awrapping of CAD geometry information and a wrappingof Particle Imaging Velocimetry data are the initial node’simmediate sucessors, each leading to the ‘real’ applicationin this example, a wrapping of an two-dimensional flowsolver. The design of this particular graph, then, is to pro-vide three sources of information to the flow solver, eachof those pieces providing an independent part of the inputwhole for that solver.

The basic conceptual view behind the arrangement of anapplication graph is that there always exists some sourcedefinition of a proposed configuration of the project whichthen feeds as input to various analyses of that configura-tion. Those analyses then produce results with two po-tential aspects: intermediate values which are of use forfurther forms of analysis and final answers contributing to-ward a judgement of the engineering merit of the design.

Another aspect implicit in this view of information propa-gation throughout directed application graphs is that suchapplications operate in what might be called a batch modethat reliably turns input information into output informa-tion. The information propagation scheme as implementedto date does not contemplate an interative cycle upon thegraph until some result balance is achieved. Note, though,that the architecture does not preclude such a formulation

at some future point.

Yet another feature of information propagation as presentlyimplemented by the architecture is the forced synchroniza-tion of parameter configurations. Information propagationis required by the implementing code to be from a par-ticular parameter configuration and, potentially, the con-figuration subgraph which it heads, to a precisely corre-sponding parameter configuration in the receiving applica-tion and, potentially, the configuration subgraph which iteither heads or which is created for the purposes of prop-agation with the particular receiving parameter configura-tion as its header. By this enforced stipulation, the conceptof a project configuration as encapsulated by the configu-ration object scheme is made more real and, it is expected,the problem of mismatched configurations within a projectanalysis will be eliminated. No longer will the weight ofthe thin tank wall be combined with the strength of the thicktank wall to produce a winning design in all departmentsexcept manufacturing.

To see this synchronization of configurations, consider firstthe pre-propagation situation depicted for two applicationgraph members in Figure 9.2. The parameter configura-tion graph of the successor application is, clearly, a subsetof the configuration graph of the predecessor application.(The supposition here is that the configuration graph of thesuccessor application, in fact, corresponds exactly to theleft portion of the graph of the predecessor application, pre-sumably because of prior acts of information propagation.)After information propagation has occurred, as depicted inFigure 9.3, new parameter configuration graph nodes havebeen created in the graph of the successor appplication soas to exactly duplicate the configuration node from whichthe information propagation occurred and to duplicate thesubgraph which that configuration node heads, from eachelement of which information propagation has also oc-curred.

The information propagation implementation also recog-nizes that not all applications are entirely reliable in theiroperation. (Indeed, it was the twitchy nature of sophisti-cated, high-fidelity CFD codes that gave part of the im-petus to the PIA project in the first place.) To deal withthis, the information propagation support utilizes the eventmechanism built into the PacBObj base class to allow inap-propriate operations to alert supposedly corrective entities,whether automated or human-interactive. There is, throughthis facility, the ability to apply corrective measures andre-attempt a particular operation in the overall propagationactivity. Failing such corrective actions, the informationpropagation system will mark the affected parameter con-figurations as being defective and will prevent further prop-agative acts based upon those configurations.

NASA/TM—2005-213611 11

PacApplPacOp

PacOp PacOp

PacOp PacOp

PacCfg


PacCfg PacCfg PacCfg PacCfg

PacId

PacId PacId PacId

PacId PacId PacId PacId PacId Analysis Control Application

PacApplPacOp

PacOp PacOp

PacOp PacOp

PacCfg



PacId

PacId PacId PacId

PacId PacId PacId PacId PacId CAPRI / CAD GeometryPacApplPacOp

PacOp PacOp

PacOp PacOp

PacCfg



PacId

PacId PacId PacId

PacId PacId PacId PacId PacId Particle Imaging Velocimetry (PIV)

PacApplPacOp

PacOp PacOp

PacOp PacOp

PacCfg



PacId

PacId PacId PacId

PacId PacId PacId PacId PacId NPARC/WIND 2D Flow Analysis

Figure 9.1: A Simple Arrangement of Applications into a Graph for Information Propagation

PacAppl

PacAppl

PacCfg


PacCfg PacCfg PacCfg PacCfg PacCfg PacCfg

PacCfg PacCfg PacCfg PacCfg PacCfg PacCfg PacCfg PacCfg PacCfg

PacCfg

PacCfg PacCfg


PacCfg PacCfg PacCfg PacCfg PacCfg

Figure 9.2: Parameter Configuration Graphs of Two Application Graph Members Prior to Information Propagation

PacAppl

PacAppl

PacCfg




PacCfg




pApp->Propagate( pCfg)

Figure 9.3: Parameter Configuration Graphs of Two Application Graph Members After Information Propagation

The process of information propagation as currently imple-mented proceeds in the following general manner.

1. The process is begun by delivering a propagation com-mand citing a specific parameter configuration to anapplication object which is, itself, a member of an ap-plication graph. Typically, this application object will

NASA/TM—2005-213611 12

be acting as the initial node of that application graph.

2. The application object does what it may to convertits own input information into output information.Should this element of the process fail, informationpropagation is discontinued.

3. The application then passes the propagation operationon to each of its immediate successors in the applica-tion graph. The identified parameter configuration ispassed on in this act.

4. Each receiving successor application establishes thatit has a corresponding parameter configuration, or cre-ates such a corresponding parameter configuration inits own configuration graph. Further it verifies thatit has, or it creates, a subgraph corresponding to anysubgraph headed by the identified source parameterconfiguration.

5. Each receiving successor application then examinesthe parameter objects available in the source param-eter configuration (and in the subgraph which it mayhead) and, based upon the semantic meanings re-vealed by those parameters, acquires such informationas it may. The information is encapsulated in the cor-responding parameter configuration(s) of the receiv-ing application.

Each receiving successor application is free to exam-ine the extended predecessor applications of its ownpropagating immediate predecessor application, to theextent that those may exist, to acquire informationfrom the parameters of those applications, too, in theevent that not all relevant input is available from itsown immediate predecessor applications.

6. When each receiving successor has received a propa-gation act from each of its own immediate predecessorapplications, it then operates so as to convert its owninputs into outputs and then passes the propagation acton to its immediate successors.

7. The propagation of information continues in this man-ner throughout the graph until terminal nodes of thegraph are reached and, recognizing that they haveno successors, those terminal applications return thepropagation act back up the graphical chain to theoriginator of the act.

It should be remembered in all of this that it is the technol-ogy of self revelation exposing infused semantic meaningthat makes the implementation of information propagationtenable. Applications wrappers need only be coded to lookfor the kinds of information they desire to acquire during

propagation, as in a process of filtering that that is of in-terest from that that is not. It is not necessary to code forconnection to a specific source application to obtain an ex-pected kind of information, nor is it necessary to code forspecific topological arrangements of applications.

10 Documentation

Complete, class-by-class, member-by-member documenta-tion has been generated in Hyper-Text Markup Language(HTML) format and placed on a central server at the GlennResearch Center. The documentation provides not only ba-sic explanatory text as to what particular components do,but also tries, when appropriate, to discuss why particularchoices were made, what expectations exist for the use ofparticular capabilities, and the like. The root URL for thisdocumentation is

http://www.grc.nasa.gov/WWW/price000/index.html

It must be strongly emphasized that these pages are the in-formal generation of the researcher involved and do not, inany way, shape, or form, represent an official statement ofthe Government of the United States.

11 Experience

To date, three applications have been wrapped in the C++implementation of the PIA Application Architecture: a pre-sentation of experimental data from an inlet unstart ex-periment for the High Speed Research project (known asHIU), a presentation of flowpath geometry informationfrom Computer Aided Design (CAD) sources accessedthrough the Computational Analysis Programming Inter-face (CAPRI) cross-vendor package, and an operationalwrapping of the Large Perturbation Inlet (LAPIN) analy-sis code.

11.1 HSR Inlet Unstart

The wrapping of the HIU test was encouraging because, upuntil the invitation to do that effort, experimental aspects ofthe PIA task had been greatly de-emphasized. Penetrationof the ICE project into the experimental arena had beenshallow and, as a consequence, experimental data handlingby the PIA project was considered of minor importance.Thus, it was gratifying to see the concepts conceived almostentirely with analytical tools in mind bent so amiably to theneeds of the experimental environment.

NASA/TM—2005-213611 13

On the other hand, the experience with the HIU test hasinstantly and forcibly demonstrated the inadequacy of thesingle virtual address space in which the C++ implementa-tion of the PIA effort must live. The HIU test has generatedsomething on the order of 25 GigaBytes of experimentaldata. Without lapsing to a meta-data concept, such a dataload is utterly crushing to the C++ implementation environ-ment. While a meta-data solution is possible, other growthdirections (to be discussed shortly) mitigate against such animplementation, even as a short-term solution.

One judgement that was derived from the HIU experienceis that the 25 GigaByte size was not an unusual thing. Ex-perimental propulsion efforts are expected to often havedata volumes of this magnitude. Further, a comprehensiveCFD investigation saving all intermediate results and stepsas envisoned by the architecture could also produce datavolumes of this magnitude. Given the fact that the PIAeffort is to allow the researcher to browse from one suchvolume of data to the next and, ultimately, migrate infor-mation content between such repositories, the need to ex-pand the implementation into a more accommodating formis unavoidably clear.

It should be noted that the HIU implementation predated allof the actual work related to the infusion of semantic mean-ing into parameter objects. This was an expedient guidedby scheduling factors. Because no information propaga-tion activity was projected within the useful lifetime of theHIU application (indeed, information propagation was onlya distantly conceived notion at that time), this expedientwas consider entirely acceptable.

11.1.1 HIU Implementation

The data to be managed in the HIU application consistsof time-series data streams sampled at several thousandsamples per second from each of some 150 different datasources. For the most part these data sources consistof high-response pressure transducers variously distributedbetween static and total pressure measurements; however, anumber of other inlet, engine, and free stream data sourcesare also involved. The data from an individual data pointis provided as two computer files: an interleaved, binarydata file of all the data sources in round-robin order andan associated, text-based format file identifying the precisecontents of the binary file.

It was immediately determined that each individual datapoint from the experiment would be loaded into a single,private parameter configuration object. To allow the re-searcher to structure configuration objects into an easilycomprehensible arrangement, it was also decided to pro-

vide a placeholder capability by which empty configurationobjects could exist as the direct parent of a series of relateddata points.

Because of the essentially static nature of experimentaldata, the HIU application required little further function-ality. The following tasks were the only ones of any signif-icance.

1. An operation to convert an empty PacCfg object intoa placeholder was developed. In the conversion pro-cess, the subject PacCfg object took on a non-emptyappearance.

2. Several operations were developed to read a co-ordinated format and data file pair and place theparameter-encapsulated information into an emptyPacCfg object.

3. A CreateApplication member function (of the Hiu-Appl application class derived from the PacApplclass) was developed. The main task of this mem-ber function override was to construct the identifica-tion structure identifying all the data elements of a testpoint.

The Placeholder Operation

The placeholder operation is quite simple. A protocol in-ternal to the HIU application wrapper was established bywhich the presense of a reading number parameter, knowninternally by the name ‘RdngNo’, was considered to makea configuration non-empty. Since the data loading opera-tions would be coded to refuse to operate if a reading num-ber parameter were present in the target configuration, itwas only necessary for the placeholder operation to placean empty reading number parameter in the selected config-uration to give it a non-empty, placeholding appearance.

As a side effect of the operation, the user is prompted toprovide a name for the placeholding configuration whichis then set into the descriptive system for the target Pac-Cfg object. This allows the placeholding object to exhibita useful, memory-jogging name in all further operations.

The Data Loading Operations

Three data loading operation classes are, in fact, currentlyprovided by the HIU application. Each differs only in theexpected layout of an individual binary value in the datafile. This difference is effected by a function override in

NASA/TM—2005-213611 14

data loading operation classes derived from the base dataloading operation. Thus, the real guts of the data loadingoperation was written only once and was inherited by thevariant forms.

As would be deduced from the description of the place-holder operation, the first significant step of data loadingis to assure that the target configuration object is, in fact,empty based upon the established internal reading num-ber parameter protocol. With that matter satisfactorily re-solved, the user is then prompted via a supplied PacGUIobject to provide the names of the format and data files.

Most of the data loading operation is relatively uninspiring;however, a few points of interest do exist which illustratethe sort of implementation freedom which exists behind thePIA architectural wall.

The first of these interesting points is the handling of themismatch between the data item names used in the formatfile and the corresponding names used in the HIU applica-tion. The experimentalists, out of whatever basis seemedreasonable to them, used strictly upper-case alphanumericidentifiers. The HIU application elected to use mixed-caseidentifiers to achieve a more esthetically pleasing appear-ance. To bridge the gap between these two selections,a synonym table was added to the developed applicationclass, HiuAppl. When the format file specifies a data itemname that is not directly found in the identification struc-ture, an attempt is made to resolve the problem throughapplication of the synonym table. Since this protocol is en-tirely internal to the HIU application, the addition of thefacility to the derived application class is entirely appropri-ate.

A related extension was touched on above: the locationof data items by name in the identification structure. Itwas considered desirable not to code the data loading op-eration with explicit knowledge of the structuralization ofthe data encapsulated by the n-ary tree of the applicationdata identification structure. (To do otherwise would meanthat each alteration of the identification tree would have tobe matched by a coding change to the data loading opera-tions.) On the other hand, the n-ary tree of the identifica-tion structure offers no find-by-name facility since there isno requirement that nodes of the tree have names uniqueacross the tree, even though that is in fact the case inthis particular application. (The directed graph class uponwhich the identification structure is based does have a findcapacity, but it consumes an ordered set of names to makebranch selections as each node of the tree is traversed.)Thus, it was considered expedient, though not absolutelynecessary, to provide in the patriarch of the identificationgraph a map sorting identification objects by their simple

names. By consulting this map, the data loading operationis able to locate the identification object for a particular dataitem, for instance the ‘RdngNo’ parameter, directly. Again,since this mapping is a matter entirely internal to the HIUapplication, it is something appropriately done behind thePIA architectural wall.

The data loading operation provides a non-catastrophic re-sponse in the event that the format file identifies a data itemthat cannot be located in the existing identification struc-ture. Subject to the consent of the user through the pro-vided PacGUI interaction object, an entry is made in the‘Found’ category of the identification structure using thename supplied by the format file for the data item. Thus,even though the wrapping of the HIU experiment is a rela-tively static thing involving the production of programminglanguage code, a certain modest flexibility to adapt to newdata items on the fly is built in.

With regard to the actual mechanics of data loading, theprocessing of the format file identifies the order of the dataitems contained in the binary data file. As each such itemis identified, its identification object is located (through thevarious internal mechanisms just discussed) and used to ob-tain the fully-qualified name by which the correspondingparameter object is to be sorted within the parameter con-figuration. A new parameter object is obtained (in point offact, a PacParaArrDoub object), the fully-qualified nameassociated with it, and it is placed in the data configurationobject. A pointer to the parameter object is also recordedin an ordered list called the interleave list and automaticchange notation is turned off in the parameter object for theduration of data loading. When all of this is accomplishedand the format file is exhausted, data loading commences(after appropriate intialization of indicies to 0) by succes-sively obtaining the next binary item from the binary fileand placing it in the next slot of the next parameter objectin the interleave list. As the process proceeds, the inter-leave list is indexed most rapidly. Each time the interleavelist end is reached its index is reset to 0 and the next itemcounter for the parameter arrays is incremented. When thebinary file is exhausted, data loading stops.

As mentioned previously, the actual obtaining of a singlebinary data item is encapsulated in a separate member func-tion of the data loading operation object. The base class im-plementation of the data loading operation simply assumesthat binary data items are double items (that is, the prima-tive C++ data type double) in the native form of the exe-cuting machine. The other two derived operation classesdiffer from the base class only in overriding the data itemacquisition function to load items as float items in nativeformat or as float items in byte-reversed format.

NASA/TM—2005-213611 15

Identification Extension

An adjustment to the data identification process was neededin the HIU application. As touched on above in the de-scription of the data loading operation, the need to locateidentification objects directly by the simple name of thedata item was met. This capacity was introduced in theHiuPid class which was directly derived from the PacPidclass. The actual creation of the empty map was added toan override of the CreateInitialNode member function andadditions to the map were made automatic through an over-ride of the AddSuccessor member function. Since an objectof the HiuPid class is used as the patriarch of the identifi-cation graph and since the inherited AddMember functionassures that a graph may only add members that are of orderived from the class of the patriarch, it is certain that ev-ery identification added to the HIU identification graph willnecessarily make an entry in this internally-defined map.

CreateApplication Function

The implementation of the CreateApplication memberfunction, while being a great mass of tedious drudgery, isnot particularly remarkable given the discussion above. Afew remarks are more than enough.

A script engine is executed to build the identification graph,organizing the potpourri of some 150 data items providedby the experimentalists into more manageable groupingsthought to be appropriate to the situation. By using identi-fication objects of the HiuPid class, the internal mappingfrom simple name to associated identification object is au-tomatically constructed.

In building identifications, it was recognized that in an ex-perimental data situation, the parameter inheritance mecha-nism of the parameter configuration graph should be turnedoff. In the course of testing, data items are lost due to in-strumentation failures and the like. Sometimes bad dataare simply recorded and a record made that they are, infact, bad. Other systems succeed (often at some pointdown stream from the point of acquisition) in discardingsuch bad items. It was realized that should such bad itemsbe discarded by the time of presentation through the HIUPIA wrapper, values inherited from previous configurationswhen the item was good would not be appropriate for dis-play. Thus, a small feature of the identification class requir-ing that a parameter actually exist in the identified config-uration was turned on to cure this problem. In practice, theact required far less effort than its explanation.

A second script engine builds the synonym table in the Hiu-Appl application object for the known text differences be-

tween the experimental nomenclature and the names usedby the HIU application. Yet a third such engine obtains in-stances of each of the implemented operations objects andadds them to the application.

11.1.2 HIU Work Not Completed

The HIU implementation reported above was considered asonly an initial plunge into the demonstration. The experi-mentalist involved wanted not merely to see and browsethe data, but to reduce that data through a number of de-fined computations resulting in derived quantities such asthe local Mach number. It was planned to implement suchcalculations as additional operations of the HIU applica-tion, in accordance with general PIA design; however, dueto the demise of the entire High Speed Research Project, itis doubtful that this work will ever be done, at least for theHIU application.

This missing effort is brought up to illustrate a philosoph-ical point of PIA design: that, to the extent the HIU appli-cation is different from every other application, such com-putations are appropriate specializations of the applicationthat are well encapsulated behind the PacOp operation ob-ject architectural wall. A point of discussion may arise,though, should one care to assert that the computation ofthings such as local Mach number is, in fact, somethingcommon across many applications. To the extent such anassertion might be true, such operations would then prop-erly fall beyond the PIA architectural wall into the provinceof the code consuming the application, that being generallya GUI. Since the PIA architecture does not constrain itselfto any particular operating environment, it might be thatdifferent, specialized GUIs could be developed to addresssuch common, repeated operational needs.

Additionally, it should be noted that, even though a par-ticular PIA application might provide such specialized op-erations, the architecture cannot prevent consuming envi-ronments from applying such inferential computations todata which is exposed. This application of consuming en-vironment operations becomes more likely, and is indeedenabled, as more semantic information is provided by thederivational specialization of parameter objects. In the HIUapplication all data was placed in PacParaArrDoub pa-rameter objects for the simple reason that PIA work had notyet developed any more semantically meaningful classes.As classes identifying the data as something on the orderof fluid flow total pressure, fluid flow static pressure, andthe like, become available, it is likely that specific, special-ized consuming environments will be able and inclined toprovide common, computationally derived quantities eventhough the specific application might also provide such

NASA/TM—2005-213611 16

quantities.

Also, it is expected that many parameter forms will providewidely-applicable functionality peculiar to their kind. Forexample, conversions from experimental values obtained indiffering flow regimes (for example, subsonic, transsonic,supersonic, and hypersonic) to ‘true’ total pressure valueswould be well included in a total pressure parameter classwhere they could be utilized by experimental applicationwrappers.

11.2 Cross-Vendor CAD Access

A wrapping application was developed which presents ge-ometry information developed from CAD information ob-tained through the cross-vendor CAPRI application pro-gramming interface. This wrapping is reported in detailin a companion publication [6].

The key achievement of this wrapper was to present a Pac-ParaGeoBdry boundary object, along with its supportingcomponent objects. This object demonstrates key elementsof the parameter object concept. First, by its revelationof kind, it presents the semansis of a logically-completeboundary built upon the concatenation of a number of opengeometric faces. Then, after being recognized as a bound-ary object, a number of defined services, among these theability to obtain open and closed cross sections and to com-pute the area of such closed cross sections as might be ob-tained. As will be discussed shortly, the Large PerturbationInlet (LAPIN) analysis code used this object with its knownservices to obtain needed geometric input information.

Another aspect of the geometry wrapper was the con-siderable behind-the-scenes maneuvering that went on inachieving its function. The implementation of the CAPRIinterface and the CAD toolkit underneath that interface pre-cluded a straightforward parent to child to grandchild pro-gram structure to obtain the desired geometric information.Instead, it was necessary for the wrapping process layer toinvoke a shell script (in actuality, a DOS batch file), whichin turn invoked the CAD toolkit, which at the direction ofthe shell script connected to a Dynamic Link Library (DLL)created to implement the needed geometry extraction func-tionality, which in turn created the geometric parameter ob-jects and ‘piped’ them through to the patriarchial wrapperapplication layer by serializing them through a communi-cations socket to that patriarchial layer. All in all, a ratherconvoluted approach to information retrieval, and still en-tirely transparent to the consuming code (in this case, thePIA testbed GUI). As did the HIU experience in a differentway, this demonstrates the nature of the architectural mech-anism: provided functionality (the acquisition of geometry

data) was obtained through an apparently straightforwardinterface while, in fact, highly convoluted maneuvers oc-curred to implement that interface.

11.3 Large Perturbation Inlet Analysis

As with the geometry wrapper, the wrapper to the LAPINcode is reported fully elsewhere [7]. This wrapper is morerepresentative of the expectations for a typical applicationwrapper. It presents the comprehensive data set of theLAPIN application and several operations. These oper-ations include the ability to load the parameter set fromsources traditional for the legacy application and to oper-ate the code and recover its output.

Of particular interest here is the parts of the wrapper sup-porting information propagation. The specializations pro-vided by this wrapper are, as expected by the general de-sign of information propagation, relatively narrow, consist-ing principally of code for the parameter harvesting stageof the information propagation act. The implementation isin the form of a filter looking for parameter objects of thekind PacParaGeoBdry, the very kind the geometry wrap-per works to present.

When the parameter harvesting operation is complete, thefollowing decision tree is executed.

1. A geometric item is selected. A geometric assemblyis selected in preference to geometric boundaries. Ifother than exactly one geometric item parameter hasbeen identified, the geometry part of the informationpropagation process is abandoned.

Currently, there is no discrimination applied betweenmultiple geomtric items; however, mechanisms do ex-ist by which inappropriate items might be excludedfrom consideration so that exactly one geometric pa-rameter survives the harvesting process.

2. The geometric item is sectioned in the (X:Y) plane,which is a service provided by both the PacParaGeo-Asmb and PacParaGeoBdry classes.

3. Heuristics are applied to the obtained cross-sectioncurves to identify two open sections taken to be thoseof the flow path. If two open sections cannot be iden-tified by these rules, the geometry part of the informa-tion propagation process is abandoned.

4. The obtained open sections are sorted and ordered toproceed radially outward (that is, in ascending arith-metic order for the Y coordinate values) and from foreto aft (that is, in ascending arithmetic order for the Xcoordinate values).

NASA/TM—2005-213611 17

5. If the two sections are mirror images of each other(a service provided by the PacGeoCurv class whichencapsulates sectioning curves), a LAPIN type 0 in-let formulation is generated from the outer curve andthe geometry part of information propagation is con-cluded.

The type 0 inlet designation is an internal formulationof LAPIN and merely designates an axisymmetric in-let with no centerbody.

6. If the first section curve begins on the X axis (that is,if the first curve point has a Y coordinate value that isapproximately 0.0), a LAPIN type 1 inlet formulationwith an axisymmetric assumption is generated fromthe two section curves.

The type 1 inlet is, again, a designation internal to theLAPIN code indicating an inlet with a translating cen-terbody.

7. Should the decision process reach this point, the onlyoption (currently) left is that of a LAPIN type 1 in-let with a two-dimensional (the alternative to axisym-metric) assumption. Cowl and centerbody geometryis generated from the two section curves. Duct widthgeometry is computed to result in cross-sectional ar-eas matching those obtained from the geometric itemparameter object. (The computation of cross-sectionalarea is another service of the PacParaGeoAsmb andPacParaGeoBdry classes.)

The interplay of parameter with consumer is illustrated inthe above process. The sectioning of boundaries and thecomputation of cross-sectional areas are both tasks that areconsidered to be relevant and common across a wide vari-ety of consumers of objects of the PacParaGeoAsmb andPacParaGeoBdry classes. Thus, once the LAPIN propa-gation code identifies an object of that class, it is assurednot only of the kind of information available, but of theservices available for the useful transformation of that in-formation.

11.4 Testbed GUI

Although a GUI is not considered to be a product of theoverall project, such a tool is nevertheless necessary fortesting purposes. Indeed, a GUI is the most expedient wayto see that the concepts described above do, in fact, work.

The first demonstration of the architecture is shown in Fig-ure 11.1. This is a screen capture of the application se-lection dialog box implemented by the GUI. The dialog al-lows the user to select one of the available application typesthrough a mutually-exclusive radio button interaction.

Figure 11.1: GUI Opening Application Query

The remarkable thing about the application selection dialogis that it is generated on-the-fly by the GUI, rather than by astatic coding of the dialog. At the time of dialog initializa-tion, a scan is done of all PIA classes, isolating those thatare derived from the type PacAppl. (The class PacAppl it-self is excluded from this set.) A radio button is generatedfor each such identified application class, drawing the nametext from the supporting class information. Thus, the figureshows that, at the time this dialog was captured, two appli-cations were supported: the HSR Inlet Unstart (HiuAppl)application and the LAPIN (LapAppl) application.

In all of the GUI, there is only one spot in whichapplication-specific coding exists: in the implementation ofthe document class a series of include statements transmitcomments to the linker that cause it to incorporate the classcode of the various PIA library components, even thoughthere is no reference to those classes and, thus, no need ap-parent to the linker for that supporting code. It is expectedthat once the migration of the architecture to the distributedobject environment of CORBA is complete, the need toforcibly include code beyond the generic, well-known li-brary levels will cease to exist, allowing new applicationsto be introduced to the system without the necessity of re-compiling every consuming tool.

Figure 11.2 illustrates nearly all the rest of the featuresof the architecture as exercised by the testbed GUI. Thewindow labeled PacAppl1:1 views a LAPIN applicationchoosen from an application selection dialog in the courseof GUI startup. The window labeled PacAppl1:2 views asecond application, in this case an HIU application, that hasbeen created as a successor to the LAPIN application in theapplication graph.

A window viewing an application lists from top to bottom

1. The parameter identification tree (which is not ex-panded in either window of the figure for reasons ofspace),

2. The parameter configuration graph,

NASA/TM—2005-213611 18

Figure 11.2: Display of Two Independent Applications Connected in a Graph

NASA/TM—2005-213611 19

3. The operation tree,

4. The application graph predecessor list (except in thecase of the PacAppl1:1 window which views the ini-tial node of the graph which, by definition, has no pre-decessors), and

5. The application graph successor list.

Comparing the differences between the two windows, inparticular the different operations lists, shows the self-revealing nature of applications within the architecture.The PacAppl1:1 window lists the various LAPIN opera-tions; the creation of LAPIN parameters, the loading ofLAPIN parameters from traditional Fortran namelist input,the running of LAPIN, and the validation of the parame-ter set as input to a potential LAPIN run. Meanwhile, thePacAppl1:2 HIU window lists an entirely different set ofoperations; the conversion of a parameter configuration to aplace holder and several different data-loading operations,all as previously discussed. These differences are all asa direct result of the GUI inquiring of the application asto the application’s content and generating an appropriateviewing window in response.

The two viewing windows also reveal the connection be-tween the two applications as participants in an applicationgraph. The PacAppl1:1 window views the initial node ofthe application graph, as witnessed by the absense of a Pre-decessor Applications element in its view. (An applicationis made an initial node of an application graph as an im-plicit part of the OnNewDocument process.) The Succes-sor Applications list of that view shows the HIU applica-tion viewed by the PacAppl1:2 window as its successor.The HIU application, in turn, lists the LAPIN applicationof the PacAppl1:1 window as its predecessor. The appli-cation graph can be, of course, expanded to the practicallimits of the host machine; it is only for reasons of space inthe figure that just two applications in a direct parent childrelationship are shown.

The operation of the information propagation processthroughout the application graph is also illustrated by Fig-ure 11.2. The parameter configuration graph of the LAPINapplication viewed through the PacAppl1:1 window hasbeen expanded beyond is default single-patriarch form toinclude two child configurations and a grandchild config-uration attached to the second child. By the act of in-formation propagation citing the root parameter configu-ration of the LAPIN application (effected by first select-ing the root parameter configuration of that application andthen double-clicking the application element of the view-ing window), that parameter configuration graph is repli-cated in the successor HIU application. This is further

confirmed by the fact that the default parameter configu-ration object names generated in the LAPIN applicationas the configuration graph was expanded (for example,LapCfg:00F939D0) are, in fact, replicated in the config-uration graph of the HIU application. This is precisely asexpected by the act of information propagation as a resultof its effort to keep parameter configuration synchronizedbetween cooperating applications.

12 Future Directions

At this point, the road ahead for the PIA project seems rel-atively clear. The key technology of self-revelation and itsability to enable common tools, information propagationthroughout an application graph, and the like can be con-sidered well demonstrated. Further work now must centeron two areas: making the application architecture practica-ble by moving it to a distributed object environment, andfilling in the many semantic gaps so as to have a fully pop-ulated set of information forms.

12.1 Distributed Object Implementation

As noted in the discussion of the HIU application, the de-mands of real applications easily overwhelm the capacitiesof a single virtual address space implementation of the ap-plication architecture. There is no possibility of accommo-dating multiple applications in a cooperative graph wheneven a single application is beyond the range of reason.

For this reason of practicality alone, it is necessary to mi-grate the application architecture to a distributed, served-object architecture. This work has already begun uti-lizing the Common Object Request Broker Architecture(CORBA) technology standardized by the Object Manage-ment Group (OMG, http://www.omg.org).

12.1.1 Distributed Object Fundamentals

The basic idea of the distributed object is to convince clientcode that it is using an object within its own operationalspace while, in fact, the actual object exists somewhere re-mote from the client. Frequently, the idea of remote meansthat the object exists on another machine accessed across anetwork, not uncommonly that network being the Internet.

To understand the underlying mechanisms of distributedobjects as implemented by the CORBA standard, considerthe conceptual diagram presented in Figure 12.1. Con-suming code at the upper left has pointers or referencesto what are, in fact, client stubs of the distributed objects

NASA/TM—2005-213611 20

Consuming Code

Client stub Client stub

BrokerRequestObject

BrokerRequestObject

Object Adapter

Skeleton Skeleton

Implementation Implementation

Routing/Transport Layer

Argument Marshaling Argument Marshaling

Figure 12.1: CORBA Distributed Object Technology

it believes it is working with. When a method is invokedon a client stub, instead of performing the requested op-eration, the method invokation along with its argumentsare passed through to the Object Request Broker (ORB)resident in the consuming code which marshals the infor-mation into a transportable message. The message is thenrouted, frequently over the Internet, to a serving ORB. ThatORB cooperates with a object adapter (in earlier formula-tions a Basic Object Adapter or BOA and, more recently,a Portable Object Adapter or POA) to demarshal the mes-sage and transmit the method invokation to an implemen-tation skeleton object, which in many cases, simply passesthe invokation on to a final, implementing object.

When the remote method operation is complete, theprocess is simply reversed. The results of the opera-tion are passed back through the skeleton object to the[BOA/POA]/ORB combination, which marshals them intoa responding message and routes that message back to theORB serving the client. The response is demarshaled andpassed back through the client stub objects to the waitingconsumer code. Except for the generally longer responsetimes, the consuming code is unaware that the operationdid not occur within its locally held object.

12.1.2 Distributed Object Advantages

This distributed object technology brings with it a numberof key advances.

1. The CORBA standard offers a particularly relevantfeature called object service activation. Simply put,a served object need not actively exist at all times, butmay instead reside in a dormant (or etherealized inCORBA terminology) state on some secondary stor-age device. Should a method invokation come in forsuch an object, a protocol exists which allows theserver to first re-create (or incarnate) that object fromits dormant form before method delivery occurs. Atsome later time, should the served object become in-active, it may be placed back in its dormant state.

The key contribution here is that not all the objects of agiven application need to be active within the addressspace of a server at any given time. An applicationsuch as HIU may well have terabytes of data, but onlythat data actively in use at any given moment needs tobe served by such a server.

2. Distributed object technology allows PIA applicationsto be served to consuming tools (and other applica-tions) by multiple serving machines. Thus, it is notnecessary to get all of the data and implementing code

NASA/TM—2005-213611 21

of all the wrapped applications onto one physical ma-chine.

This ability to serve different wrapped applicationsfrom different machines allows those machines to belocated with the groups supporting the applications.For example, experimental data applications can beserved from machines supported by the data acquisi-tion group while a consuming analysis application canbe served by a machine provided by the group generat-ing and supporting that application. Furthermore, bothsuch applications can be used by a consuming clientwidely separated from both distributed object servers.

3. Distributed object technology separates the issues offunctionality from implementation. Thus, the ser-vices of a PIA-wrapped application may be suppliedthrough distributed objects without exposing the im-plementation of those services.

This feature is of particular interest to commercialproviders of applications who may wish to sell theservices of a particular application without revealingthe proprietary methods by which those services areachieved. The PIA technology further facilitates thisby allowing general-purpose tools of potentially wideavailability to interact with such provided services,thus eliminating the need for a custom access toolkitfor every such offered product.

12.1.3 Distributed Object Difficulties

The migration to a distributed object environment, whilenecessary and advantageous overall, does bring with it cer-tain difficulties.

1. Distributed objects, being exposed upon the net bywell-known services, are accessible by, literally, theentire community of the net. Mechanisms must beimplemented to limit the accessibility of distributedobjects to those that should have access.

2. Having presumably eliminated those who should notaccess distributed objects of a PIA implementation,it must still be recognized that the remaining acces-sor set has more than one element. It is, thus, stillnecessary to arrange mechanisms to assure the in-tegrity of PIA structural components even when quasi-simultaneously accessed by members of that consum-ing set [8].

12.1.4 Distributed Object Persistence

In the CORBA standard, the connection between client andobject does not define the period of existence of the object.

An object may exist prior to a client connecting to it and itmay exist after the client has fulfilled its desires and exited.Indeed, the CORBA standard provides no specification foreither the beginning or ending of a served object. The stan-dard leaves such issues to the discretion of the application.

The PIA project provides answers for the question of thebeginning and ending of objects. The class (or, in theCORBA nomenclature, the interface) information supportsystem provides a CreateInstance method which creates anew instance of the supported class. To end such a createdobject, every class implemented by the PIA project inheritsfrom the base class a SetDefunct method which declaresthe termination of the presenting instance.

Between beginning and ending, the CORBA objects of thePIA implementation exist without regard to the comingsand goings of either clients or servers. As indicated pre-viously, when such an object appears to be idle, the serverprogram arranges to remove the object from active serviceand saves its content to persistent storage through the se-rialization mechanisms originated in the C++ implementa-tion work. When a method invokation on such an object ar-rives at some later time, the object is re-created and its con-tents restored by a deserialization operation before methoddelivery proceeds.

12.2 Populating the Semantic Set

The mechanism of self-revelation of kind depends uponexacting definition of the semantic nature of a particularobject. In the work to date this has been relatively easysince the definitions involved structural components; appli-cations in a generic sense, parameter identifications, con-figurations, and the like. Even the geometric parameterkinds were defined with comparitive ease since the issueof geometry is relatively well settled.

The usability of the PIA technology is closely related tothe supply of ‘building blocks’ available to the applicationwrapper, particularly to the supply of semantically definedparameter classes from which to choose. While the cod-ing of parameters is often quite trivial, the need for expertsin the various disciplines who can formulate clear, broadlyapplicable definitions of particular parameter forms cannotbe overemphasized.

13 Summary

An abstract, highly flexible, object-oriented applicationarchitecture has been defined. The architecture has beenimplemented in C++ and real applications have been

NASA/TM—2005-213611 22

wrapped according to that architecture. Applicationswrapped in this manner have been connected into directedapplication graphs and the automatic propagation of in-formation from source application to consumer has beendemonstrated.

References

[1] James Douglas Stegeman, Richard A. Blech,Theresa Louise Benyo, and William Henry Jones. Inte-grated CFD and Experiments (ICE): Project Summary.Technical memorandum NASA/TM-2001-210610,National Aeronautics and Space Administration,Lewis Research Center, 21000 Brookpark Road,Cleveland, OH 44135, December 2001.

[2] The American Society of Mechanical Engineers. In-tegrated CFD and Experiments Real-Time Data Ac-quisition Development, number ASME 93-GT-97, 345E. 47th St., New York, N.Y. 10017, May 1993. Pre-sented at the International Gas Turbine and AeroengineCongress and Exposition; Cincinnati, Ohio.

[3] William Henry Jones. Project Integration Architec-ture: Formulation of Semantic Parameters. Techni-cal memorandum NASA/TM–2005-213614, NationalAeronautics and Space Administration, Glenn Re-search Center, 21000 Brookpark Road, Cleveland,OH 44135, March 2005. Available electronically athttp://gltrs.grc.nasa.gov.

[4] William Henry Jones. Project Integration Architec-ture: Formulation of Dimensionality in Semantic Pa-rameters. Technical memorandum NASA/TM–2005-213615, National Aeronautics and Space Administra-tion, Glenn Research Center, 21000 Brookpark Road,Cleveland, OH 44135, March 2005. Available elec-tronically at http://gltrs.grc.nasa.gov.

[5] William Henry Jones. Project Integration Architecture:Inter-Application Propagation of Information. Techni-cal memorandum NASA/TM–2005-213613, NationalAeronautics and Space Administration, Glenn Re-search Center, 21000 Brookpark Road, Cleveland,OH 44135, March 2005. Available electronically athttp://gltrs.grc.nasa.gov.

[6] American Institue of Aeronautics and Astronatics.Project Integration Architecture (PIA) and Computa-tional Analysis Programming Interface (CAPRI) forAccessing Geometry Data from CAD Files, number2002-0750, 1801 Alexander Bell Drive, Suite 500, Re-ston, VA 20191-4344, January 2002. Aerospace Sci-ences Meeting and Exhibit, Reno, NV.

[7] William Henry Jones. Project Integration Architecture:Wrapping of the Large Perturbation Inlet (LAPIN)Analysis Code. Draft paper available on central PIAweb site, March 2001.

[8] William Henry Jones. Project Integration Architecture:Distributed Lock Management, Deadlock Detection,and Set Iteration. Technical memorandum NASA/TM–2005-213612, National Aeronautics and Space Admin-istration, Glenn Research Center, 21000 BrookparkRoad, Cleveland, OH 44135, March 2005. Availableelectronically at http://gltrs.grc.nasa.gov.

NASA/TM—2005-213611 23

This publication is available from the NASA Center for AeroSpace Information, 301–621–0390.

REPORT DOCUMENTATION PAGE

2. REPORT DATE

19. SECURITY CLASSIFICATION OF ABSTRACT

18. SECURITY CLASSIFICATION OF THIS PAGE

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources,gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of thiscollection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 JeffersonDavis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.

NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)Prescribed by ANSI Std. Z39-18298-102

Form ApprovedOMB No. 0704-0188

12b. DISTRIBUTION CODE

8. PERFORMING ORGANIZATION REPORT NUMBER

5. FUNDING NUMBERS

3. REPORT TYPE AND DATES COVERED

4. TITLE AND SUBTITLE

6. AUTHOR(S)

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

11. SUPPLEMENTARY NOTES

12a. DISTRIBUTION/AVAILABILITY STATEMENT

13. ABSTRACT (Maximum 200 words)

14. SUBJECT TERMS

17. SECURITY CLASSIFICATION OF REPORT

16. PRICE CODE

15. NUMBER OF PAGES

20. LIMITATION OF ABSTRACT

Unclassified Unclassified

Technical Memorandum

Unclassified

National Aeronautics and Space AdministrationJohn H. Glenn Research Center at Lewis FieldCleveland, Ohio 44135–3191

1. AGENCY USE ONLY (Leave blank)

10. SPONSORING/MONITORING AGENCY REPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space AdministrationWashington, DC 20546–0001

Available electronically at http://gltrs.grc.nasa.gov

March 2005

NASA TM—2005-213611

E–15072

WBS–22–617–91–40

29

Project Integration Architecture: Application Architecture

William Henry Jones

Simulation; Data management; Semantics; Information retrieval; Computer aided design; C++ (programminglanguage); Graphical user interface; Information systems; Encapsulating; Parameter identification; Object-oriented programming; Data structures; Computational fluid dynamics

Unclassified -UnlimitedSubject Category: 63

Responsible person, William Henry Jones, organization code RTS, e-mail: [email protected], 216–433–5862.

The Project Integration Architecture (PIA) implements a flexible, object-oriented, wrapping architecture whichencapsulates all of the information associated with engineering applications. The architecture allows the progress of aproject to be tracked and documented in its entirety. Additionally, by bringing all of the information sources and sinksof a project into a single architectural space, the ability to transport information between those applications is enabled.

Project Integration Architecture: Application … Integration Architecture: ... Project Integration...

Documents

Transcript of Project Integration Architecture: Application … Integration Architecture: ... Project Integration...