> 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


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 
aerodynamic interference effects - though I think with some thought and code we 
could do

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 ---

<?xml version="1.0"?>
<?xml-stylesheet href="JSBSim.xsl" type="application/xml"?>
<fdm_config name="F-16" version="2.0" release="BETA">

        <author> Erik Hofman </author>
        <filecreationdate> 2003 </filecreationdate>
        <description> F-16 from Stevens and Lewis </description>
        <version> 0.8 </version>

    <child name="MK-82" file="mk82" mode="MATED" carriage="EXTERNAL">

        <wingarea unit="FT2"> 300 </wingarea>
        <wingspan unit="FT"> 30 </wingspan>
        <chord unit="FT"> 11.32 </chord>
        <htailarea unit="FT2"> 63.7 </htailarea>
        <htailarm unit="FT"> 16.46 </htailarm>
        <vtailarea unit="FT2"> 54.75 </vtailarea>
        <vtailarm unit="FT"> 0 </vtailarm>

--- end ---

In this way we can define a store in one place and include it multiple times in 

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 
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.


Reply via email to