Here's an amazing fact:

Did you know: each NASA Center (and DoD lab, and aerospace industrial partner) have incompatible simulation software architecture?

This is the result of the historical 'stovepipe' environment in which each of these facilities were developed.

As a result, the current state-of-the-art in simulation modeling requires extensive manual effort to whenever we need to share (or 'rehost') a perfectly valid flight simulation from, say, Bell-Boeing, to NASA Ames or Langley, with each transfer of simulation code. Such 'rehosting' can take months to perform and verify, and has to be repeated each time a component of the vehicle model is updated (new aero, FCS, etc.)

This is an astonishing impediment to efficiency, considering how much we rely on simulations for research & development, not to mention procurement, of new aerospace projects. In the NASA High-Speed Research (HSR) program we typically required four to six months to implement, at three different simulation facilities (Langley, Ames, and CALSPAN), each new release of the Ref H simulation package from Boeing/McAir.

It is not a problem limited to subsonics, or the tactical aircraft community, or even civilian or military aerodynamics - the CEV/Orion project currently has (at last count) seven separate, incompatible implementations of the abort vehicle's aerodynamics: JSC uses 'Trick,' MSFC uses 'MAVERIC', Dryden (for the pad abort flight test) has ported the sim to both POST3D and 'DrydenSim', the launch abort systems subcontractor uses an internal framework, and Langley has two: POST and Matlab®/Simulink®. Each new release of the CEV aero database requires tedious effort to install and verify. These legitimate analysis tools are all appropriate choice; it's just that they can't share the original model that causes inefficiency.

The AIAA Modeling & Simulation TC has proposed the development of standards for encoding flight vehicle dynamic models. The idea is simple: agree on a way to describe the aerodynamic and other subsystem models (propulsion, landing gear, flight control, etc.) of a flight vehicle. This description should be facility-agnostic, that is, the encoding means should not show a preference for Fortran over C++, or piloted simulation vs. design/analysis (non-real-time) simulations. An agreed model description language will go a long way to making simulations 'portable' between centers.

We've taken a big step towards this goal, by developing and demonstrating an XML (eXtensible Markup Language)-based grammar to describe the aerodynamic model of an R&D/engineering simulation. The resulting model is a human- and machine-readable text file that contains the complete set of aerodynamic coefficient tables, the build-up equations, a brief history of the source or provenance of the model, any uncertainty parameters for the data, and verification checkcases. Models described in this Dynamic Aerospace Vehicle Exchange Markup Language (DAVE-ML) can be easily ported from one simulation facility to another, or into an analysis code, in a matter of minutes, not months, after a required set of import ("translation") scripts are developed and tested.

Currently, Langley, Ames and Pax River have developed and demonstrated compatibility with DAVE-ML aero models, and we can also import these models into Matlab/Simulink for control design studies. The Australian DSTO agency has adopted DAVE-ML as their standard format for friendly/foe aircraft modeling for both training simulations and N-vs-N ACM studies.

I hope you will lend support to setting up a cross-cutting technology project to further this useful technology for the U.S. aerospace industry.

More information about DAVE-ML is available from http://daveml.nasa.gov.