> As Geoff Brian has outlined previously, DSTO is in the
> process of developing aircraft datasets, including aircraft
> configuration properties, aerodynamics, propulsion and mass
> properties in DAVE-ML for use with their simulation codes.
> We are also developing a C++ library, named Janus, to
> interface with these datasets.
>
> In undertaking this work, we have started looking at
> encapsulating stores load-out information in an XML format.
> This information includes the mass properties of the stores
> (i.e. external fuel tanks etc), as well as details of the
> external stores stations on which particular stores may be
> carried and the required carriage equipment (i.e. pylons and
> racks). This information is a more specific application than
> the DAVE-ML format was developed for, and may require its own
> syntax and markup.
>
> We are interested to know if anyone else has looked at this
> problem?
>
> Kind Regards,
> Hilary Keating
Greetings:
I have looked into something very similar - at least for the same purpose. For
the JSBSim
project we decided we would like to have the ability to load stores. We
expanded this idea
to allow for any parent/child or host/parasite relationship. In our case, we
would then be
able to carry any number of stores, but at this time we do not have a way to
model
aerodynamic interference effects - though I think with some thought and code we
could do
that.
I don't know if you have seen our JSBSim config file format. We are currently
making the
first major modification to the format in its six years of existence in order to
(hopefully) make it easier to work with DAVE-ML, as well as to provide for new
capabilities. We also describe aircraft physical characteristics, ground
reactions, flight
control, propulsion, and aero, etc. in an XML config file.
What we decided to do for the case of stores is to create a configuration file
for the
store itself, then include it from the main ("parent") file, for example:
--- start ---
Erik Hofman
2003
F-16 from Stevens and Lewis
0.8
600.0
100.0
-40.0
0
0
0
300
30
11.32
63.7
16.46
54.75
0
...
etc.
--- end ---
In this way we can define a store in one place and include it multiple times in
specified
locations.
We have some infrastructure in place and can read the stores and create
"spawned" and
complete flight models for each child store, but we do not yet execute the
flight model
for a store. The store is kept as part of the parent vehicle, and contributes
mass
properties and forces and moments to the parent, but once the mode is changed
from MATED
to FREE, integration begins for the store flight model and it is no longer
contributing to
the parent vehicle flight model.
Jon
