BSR/ANSI/AIAA

S-XXX-200X

American National Standard

Guidelines for the Preparation of AIAA Standards Documents

Sponsored by

American Institute of Aeronautics and Astronautics

Approved XX Month 200X

American National Standards Institute

Abstract

This is a standard for the interchange of simulation modeling data
between facilities. As illustrated in Figure 1, the initial objective is
to allow a person with a simulation of a certain type of vehicle or
aircraft at facility A to transfer the simulation to facility B in an
easy, straightforward manner.

Figure 1. A Standard Format for Exchanging Simulation Modeling Data
Between Simulation Facilities

Given a standard format for the exchange of simulation modeling data,
the user community investment required to use the standard is minimal.
Each facility internal standards and conventions may still be used. The
only work required to commit to the standard is to write "translation"
programs to import and export data from/to the DAVE-ML standard. This
one time investment would then allow any model to be exchanged easily
and with good confidence that the "rehosting" of the model would require
minimal effort. Again, the user need not change anything inside his
facility or software to use the model.

**[LIBRARY OF CONGRESS CATALOGING DATA WILL BE ADDED HERE BY AIAA
STAFF]{.mark}**

> Published by
>
> **American Institute of Aeronautics and Astronautics**
>
> **1801 Alexander Bell Drive, Reston, VA 20191**
>
> Copyright © 200X American Institute of Aeronautics and Astronautics
>
> All rights reserved
>
> No part of this publication may be reproduced in any form, in an
> electronic retrieval system or otherwise, without prior written
> permission of the publisher.
>
> Printed in the United States of America

Contents

Foreword [**Error! Bookmark not
defined.**](#__RefHeading___Toc511719077)

Introduction [vi](#__RefHeading___Toc511719078)

Trademarks [vii](#__RefHeading___Toc511719079)

1 Scope [8](#__RefHeading___Toc511719080)

2 Tailoring [8](#__RefHeading___Toc511719081)

3 Applicable Documents [8](#__RefHeading___Toc511719082)

4 Vocabulary [8](#refheading___toc511719083)

4.1 Acronyms and Abbreviated Terms [9](#__RefHeading___Toc511719084)

4.2 Terms and Definitions [9](#__RefHeading___Toc511719085)

5 Clause [**Error! Bookmark not
defined.**](#__RefHeading___Toc511719086)

5.1 Subclause (level 1) [**Error! Bookmark not
defined.**](#__RefHeading___Toc511719087)

5.1.1 Subclause (level 2) [**Error! Bookmark not
defined.**](#__RefHeading___Toc511719088)

5.1.2 Subclause (level 2) [**Error! Bookmark not
defined.**](#__RefHeading___Toc511719089)

5.2 Subclause (level 1) [**Error! Bookmark not
defined.**](#__RefHeading___Toc511719090)

Annex A Annex Title (Informative) [14](#__RefHeading___Toc511719091)

A.1 General [1](#__RefHeading___Toc511719092)

A.2 Clause [1](#__RefHeading___Toc511719093)

A.2.1 Subclause (level 1) [1](#__RefHeading___Toc511719094)

A.2.2 Sublcause (level 1) [1](#__RefHeading___Toc511719095)

Figures

Figure 1 --- Figure title [**Error! Bookmark not
defined.**](#__RefHeading___Toc501443506)

Tables

Table 1 --- Table title [**Error! Bookmark not
defined.**](#__RefHeading___Toc501443538)

Foreward

This standard has been sponsored and developed by the AIAA Modelling and
Simulation Technical Committee. Mr. Bruce Jackson of NASA Langley
conceived DAVE-ML. DAVE-ML is the embodiment of the standard in XML. It
is the data type descriptions for the XML implementation.
(annex\_\_\_\_\_\_\_)

This implementation was then tested by trial exchange of simulation
models between NASA Langley Research Center (Mr. Bruce Jackson), NASA
Ames Research Center (Mr. Thomas Alderete and Mr. Bill Cleveland), and
the Naval Air Systems Command (Mr. William McNamara and Mr. Brent York).
Numerous improvements to the standard resulted from this "testing".

At the time of approval, the members of the AIAA **NAME CONSESNSUS
BODY** were:

> Bruce Hildreth, Chair Science Applications International Corporation
> (SAIC)
>
> Bruce Jackson NASA Langley Research Center
>
> Geoff Brian Defense Science Technical Organization (DSTO)
> Geoff.Brian@dsto.defence.gov.au
>
> Corrine Ilvedson corinne.ilvedson@insitugroup.com
>
> Jacco Hoekstra hoekstra@nlr.nl
>
> Robert Seltzer
>
> Richard "Pat" Anderson
> <http://www.erau.edu/faculty/RichardAnderson.html>

The above consensus body approved this document in Month 200X.

The AIAA Standards Executive Council (VP-Standards Name, Chairman)
accepted the document for publication in Month 200X.

The AIAA Standards Procedures dictates that all approved Standards,
Recommended Practices, and Guides are advisory only. Their use by anyone
engaged in industry or trade is entirely voluntary. There is no
agreement to adhere to any AIAA standards publication and no commitment
to conform to or be guided by standards reports. In formulating,
revising, and approving standards publications, the committees on
standards will not consider patents that may apply to the subject
matter. Prospective users of the publications are responsible for
protecting themselves against liability for infringement of patents or
copyright or both.

[]{#__RefHeading___Toc511719078 .anchor}Introduction

The purpose of this standard is to clearly define the information
required and format to exchange air vehicle simulation models between
simulation facilities. This portion of the standard is implemented in
XML and called DAVE-ML.

The Exchange Standard (DAVE-ML) Includes:

-   Standard variable name definitions -- the purpose of this is to
    facilitate the transfer of information by using these standard
    variables as a "common language". Of course, the DAVE-ML standard
    can be used without using standard variable names. It will just be
    more difficult because the person exporting the model will have to
    explicitly define all the variables instead of just a subset unique
    to the particular model.

-   Standard function table definition - this allows easy transfer of
    non-linear function tables of n dimensions.

-   Standard axis system definitions - this is used by the variable
    names and function tables to clearly define the information being
    exchanged.

-   Standard static math equation representation - for definition of
    aero model (or other static models) equations. This is implemented
    using Math-ML.

XML provides a format for the exchange of this information, so each
organization only has to make import/export tools to the standard one
time, instead of each time they import from, or export to, a new or
changed facility.

The resultants of the use of this standard will be substantially reduced
the cost and time to exchange aerospace simulations and model
information. Test cases have shown use of the standard results in an
order of magnitude reduction in effort to exchange simple models. Even
greater benefits should be attained for large or complicated models.

[]{#__RefHeading___Toc511719079 .anchor}Trademarks

The following commercial products that require trademark designation are
mentioned in this document. This information is given for the
convenience of users of this document and does not constitute an
endorsement. Equivalent products may be used if they can be shown to
lead to the same results.

MATLAB

Simulink

XML

Math-ML

1.  []{#__RefHeading___Toc511719080 .anchor}Scope

This standard establishes the **definition of the information** and
**format** used to exchange air vehicle simulations and validation data
between disparate simulation facilities. This standard is not meant to
require facilities to change their internal formats or standards. With
the concept of an exchange standard, facilities are free to retain their
well-known and trusted simulation hardware and software infrastructures.
The model is exchanged through the standard, so each facility only needs
to create import/export tools to the standard once. Then they can use
these tools to exchange models with any facility at minimal effort,
instead of making unique import/export tools for every facility that
they exchange with.

The standard includes **definition of the information** in order to
clarify the information exchanged. Such clarification includes axis
systems referenced, units, and sign conventions used. XML is used as the
mechanism to facilitate automation of the exchange of the information.
Using the definitions in the standard, a **list of simulation variable
names and axis system** is included. This list of standard variables
names further simplifies the exchange of information, but is not
required.

2.  []{#__RefHeading___Toc511719081 .anchor}Tailoring

The standard variable names and axis system definitions are part of the
standard to facilitate communication. They provide a "common language"
for the exchange. For example, it is not enough to exchange the lift
coefficient function. As a [minimum]{.underline} the independent
variables used to define the function and their units, sign convention,
and reference axis system must be defined. This is facilitated by having
some standard variable names and axis systems. Of course, new variable
names, definitions, and other convenient axis systems may be used to
exchange models between simulation facilities. However, in such cases,
the exporters and importers must be very careful to carefully define
these variables and axes, otherwise, the exchanged model may not produce
the desired results. Use of standard variable names and axis systems
facilitates the exchange.

The standard includes a methodology for creating new standard variables.
Its use is encouraged.

3.  []{#__RefHeading___Toc511719082 .anchor}Applicable Documents

The following documents contain provisions which, through reference in
this text, constitute provisions of this standard. For dated references,
subsequent amendments to, or revisions of, any of these publications do
not apply. However, parties to agreements based on this standard are
encouraged to investigate the possibility of applying the most recent
editions of the normative documents indicated below. For undated
references, the latest edition of the normative document referred to
applies.

Tools which will help the user use the standard have been provided by:

Bruce Jackson, NASA Langley, Virginia: a Java package for manipulating
DAVE-ML and tools to generated Simulink models from DAVE-ML.
(annex\_\_\_\_\_\_)

Geoff Brian, Defense Science Technical Organization (DSTO), Australia:
JANUS, a C++ application programmer's interface (API) for the
manipulation of DAVE-ML models. (annex \_\_\_\_\_\_\_)

Bill Cleveland, NASA Ames Research Center, California: Fortran tools to
import and export NASA Ames function tables from/to the DAVE-ML
standard. (annex \_\_\_\_)

4.  []{#refheading___toc511719083 .anchor}Vocabulary

    1.  []{#__RefHeading___Toc511719084 .anchor}Acronyms and Abbreviated
        Terms

  ----------------- -----------------------------------------------------
  AIAA              American Institute of Aeronautics and Astronautics

  ASME              American Society of Mechanical Engineers

  ASTM              American Society of Testing and Materials

                    
  ----------------- -----------------------------------------------------

The **Acronyms and Abbreviated Terms** section is an optional element
giving a list of the acronyms and abbreviated terms necessary for the
understanding of the standard.

Unless there is a need to present acronyms in a specific order to
reflect technical criteria, all acronyms should be listed in
alphabetical order in the following sequence:

--- upper case Latin letter followed by lower case Latin letter (*A*,
*a*, *B*, *b*, etc.);

--- letters without indices preceding letters with indices, and with
letter indices preceding numerical ones (*B*, *b*, *C*, *C*m, *C*2, *c*,
*d*, *d*ext, *d*int, *d*1, etc.);

--- Greek letters following Latin letters (*Z*, *z*, *Α*, *α*, *Β*, *β*
... *Λ*, *λ*, etc.);

--- any other special acronyms.

2.  []{#__RefHeading___Toc511719085 .anchor}Terms and Definitions

For the purposes of this document, the following terms and definitions
apply.

> Breakpoint - The value of the independent variable of a given
> dependent variable, or the X coordinate (or abscissa of) a one
> dimensional table, for example.
>
> Confidence Interval - An estimate of the computed or perceived
> accuracy of the data.
>
> Dependent Variable - The output of the function table is the dependent
> variable For example: C~L~(α,β). C~L~ is the dependent variables. Also
> called the output.
>
> Independent Variable - The variable or variables of which the
> independent variable is a function. For example: C~L~(α,β). α and β
> are independent variables.
>
> One Dimensional Table - A table where there is only one independent
> variable. For example, C~L~(α).
>
> Two Dimensional Table - A table where there are two independent
> variables. For example, C~L~(α,β).
>
> Static Equation -- An equation where the output (left hand side) does
> not have direct dependence (right hand side) on a simulation state.
>
> Simulation State -- In the formulation of a simulation model shown as
> :
>
> x=Ax + Bu [note needs x-dot]{.mark}
>
> y=Cx + Du
>
> x represents a vector of the simulation states.
>
> State Derivative - In the representation shown above in the simulation
> states, x is a vector of the time derivative of x. x is the state
> derivative(s). [note needs x-dot]{.mark}
>
> Function Table -- The numeral set of data points used to represent
> non-linear relationships between an independent variable based on (as
> a function of) one or more independent variables. Example C~L~(α,β) is
> represented by a function table.
>
> Gridded Table- A multi-dimensional function table where the
> independent variable breakpoints points do not change for different
> values of other independent variables. This is sometimes called an
> orthogonal table.
>
> All one-dimensional tables are a "gridded table".
>
> Ungridded Table - A multi-dimensional function table where the
> independent variable breakpoints points do change for different values
> of other independent variables. This is sometimes called a
> non-orthogonal table.

**4 STANDARD SIMULATION VARIABLES**

**4.1.1 Background / Philosophy**

[The Rationale for Having Standard Variable Name and Naming
Conventions]{.underline}

The standard variable names and axis system definitions are part of the
standard to facilitate communication. They provide a "common language"
for the exchange. For example, it is not enough to exchange the lift
coefficient function. As a [minimum]{.underline} the independent
variables used to define the function and their units, sign convention,
and reference axis system must be defined. This is facilitated by having
some standard variable names and axis systems.

Therefore, if you exchange models using the standard variables, you
don't have to define a variable that is part of the standard, just refer
to the standard. Additionally, the naming convention is presented to
allow the list of standard variables to grow as needed by the user
community. Hopefully the convention will keep some consistency in the
variable names and make them easier for users to interpret.

[States and State Derivatives]{.underline}

Long term software maintenance of simulation software used to model the
flight dynamics of an airplane is predicated upon identification of the
states and controls in the simulation. The importance of this cannot be
overstated. States and inputs (controls) are determined by the physics
of the problem. Since the physics are immutable (although we have all
seen software where they\'re not) the identification of these variables
is crucial in software maintenance.

Again, according to physics, all outputs which we use in simulation are
derived from states and inputs.

By definition, anything in a simulation we are interested in is an
output. To create an output, for example indicated airspeed, we must be
able to identify the states and inputs. Therefore, if we know the
appropriate law of physics, we may correctly compute indicated airspeed.
Too often in simulation modeling we forget these fundamental immutable
concepts. We \"fudge\" things and create outputs from other outputs.
Practically speaking, this is done because we can\'t determine what the
states in the simulation are. That is, what is computed from what since,
it is an iterative process, it becomes very cloudy as to what variable
is dependent upon what other variable.

This is why we must go back to the physics and realize everything is
computed from states and inputs in the mathematical and physical sense.

Now the question becomes which state, that is, state at what time?
Again, this becomes clear if we go back to the physics. Outputs at any
time T are a function of the states and inputs at time T. Integration of
the state derivatives at time T results in states at time T plus delta
T. State derivatives at time T are functions of the states and inputs at
time T. It is crucial that we do not mix variables at time T with
variables at time T plus delta T.

Practically speaking, for simulation standards, what this means is that
all integrations must be done in a centralized location in each
simulation loop, otherwise we mix variables at time T with variables at
time T plus delta T. The simulation industry has violated this
mathematical principle for many years in the use of \"in-line\"
difference equations for simulation filters and actuators, etc. This
often works \"OK\" and \"no harm is done\". However, what is missed is
that software maintenance becomes much more difficult when those states
cannot be located because they are embedded---they are strung throughout
the code. Therefore, the outputs cannot be properly created.
Furthermore, when a modification comes to add a capability or to fix a
bug, the key variables required to modify a simulation (again what would
the states, state derivatives, and inputs) are impossible to find or
inaccessible. Therefore, the fix made to the simulation is less than
optimum and possibly creates more headaches down the road for the next
fix, etc., etc., ad infinitum.

Therefore this AIAA Simulation Variable standard identifies states and
state derivatives as part of the naming convention. Identification of
inputs or controls, while a good idea, is very difficult because so many
variables are controls and the controls change as a mode of operation of
the simulation. Therefore it is left out of the standard.

**4.1.2 Variable Naming Convention**

This paragraph will discuss the convention and philosophy used for
naming of simulation variables. The purpose of this is so when other
variables are added to the list they will follow the same general
convention.

Both the C and Ada language conventions are supported. The only
\"oddity\" is that in the C convention we us an underscore to separate
the prefix and suffix from the body of the variable name.
Conventionally, C does not use underscores in variable names at all.

General rules for naming variables:

> Variables shall have meaningful names. Mnemonics will not be used.
> Standard abbreviations are allowed.
>
> (C language) The first word in the variable name (not including the
> prefix, if any) starts with a lower case. Distinct words thereafter in
> variable names shall be separated by capitalization of the separate
> words (example\" bodyXAcceleration\").
>
> (Ada language) Distinct words in variable names shall be separated by
> underscores between the separate words (example\"
> body_X_acceleration\").
>
> Varaible names shall not exceed 60 characters in length. Brief, but
> complete names are most effective.
>
> Abbreviations are generally all capitals. Units should be all lower
> case. This reduces ambiguity.

**Methodolgy for Creating New Names**

The suggested method of creating the name is as follows.

> Each name up to six components. All components are not required to be
> used because in many cases they do not apply. These components are:

(prefix)\_(variable source domain)\_( axis or reference
system)\_(specific axis or reference)\_(core name)\_(units)

As will be seen, very rarely, if ever, are all 6 components of a name
used.

[Prefix]{.underline}

The prefix is used to identify the most important dynamic variables in
the simulation, the states and the state derivatives.

The prefix is always separated from the body of the variable by an
underscore or as a separate component of a structure.

[Identification of States]{.underline} The states and state derivatives
are those variables which make the simulation dynamic and are
essentially the key variables in a real time flight simulation.
Basically, anything that is integrated (mathematically) is a state
derivative. The result of the integration is the state (integration of
the state derivative results in the state). This is true for any
integration in a simulation. Obviously then, if the user controls all
the states, he controls the motion of the simulation. Also, these along
with the inputs are the key variables for validation. All outputs are
computed directly or indirectly from states and inputs.

Clearly, the formulation of the equations of motion and the model itself
determines what variables are states. This naming convention is not
meant to standardize on any variable as a state, just for the simulation
engineer to explicitly name them, making it easier to document and
exchange the models.

Examples:

s_bodyXVelocity_fs-1 s\_ prefix indicates that this variable is a state

sd_bodyXAcceleration_fs-2 sd\_ prefix indicates that this variable is a
state derivative

[Variable Source Domain]{.underline}

This is the object domain in which the variable is used. In object
oriented design, it would logically be the object. The source domain is
normally not included if it (or the object) is the vehicle or aircraft
being simulated, for example, airspeed.

Some domain examples:

> Aero or Aerodynamic
>
> Engine or Thrust
>
> Controls
>
> Wheel
>
> Landing Gear
>
> Hydraulic
>
> Electrical
>
> Users may (should) add as many domains as needed to clearly identify
> the variable.

Variable name examples:

> aeroBodyXForceCoefficient
>
> aeroBodyXForce_lbf
>
> thrustBodyYForce_lbf

[Axis or Reference System]{.underline}

This is the axis or reference system to which the variable is
referenced. Standard axis system abbreviations are used. If no axis
system pertains to the variable or the core variable name needs no
reference system to be unambiguous (ex. airspeed) then this part of the
variable name may be omitted.

The following are some axis system examples which corrospond to the
standard axis systems discussed below.

> GEaxis Geocentric Earth Fixed-Axis System.
>
> Body Body axis system
>
> FEaxis Flat earth inertial axis system

Variable name examples:

BodyXVelocity_fs-1

S_GEaxisZVelocity_fs-1

[Specific Axis or Reference]{.underline}

This is the specific axis or reference used within the axis system. If
the axis or reference system component of the name is included in the
name, then the specific axis or reference should also be included.

[Alternatively]{.underline}

The specific axis or reference can logically be a vector or an array.

For example:

X, Y, or Z for linear motion

Pitch, Roll, or Yaw for angular motion

Variable name examples:

s_bodyRollRate_rs-1

bodyXTurbulenceVelocity_fs-1

Examples as a vector:

s_bodyAngularRate_rs-1(3)

> Where element 1 would be about the X axis (pitch), element 2 would be
> about the Y axis ( roll) and element 3 would be about the Z axis
> (yaw). When vectors are used, a right handed triad in order (x, y, z)
> must be used to avoid confusion.

[Core Variable Name]{.underline}

This is the most specific (hence core) name for the variable. All
variable names must include this component of the name.

Core variable name examples:

rate

forceCoefficient

turbulenceVelocity

velocity

angleOfAttack

angleOfSideslip

cosineOfAngleOfSideslip

thrust

torque

aileronDeflection (aileron could be considered a domain)

Variable name examples:

s_bodyRollRate_rs-1

bodyXTurbulenceVelocity_fs-1

GEaxisZVelocity_fs-1

angleOfAttack

angleOfSideslip

cosineOfAngleOfSideslip

Some additional discussion:

Very rarely if ever are all 6 components of a name used. In the case of
"rate", 5 components were used (prefix \[s\], axis or reference system
\[body\], specific axis or reference \[Roll\], core name \[Rate\], and
units \[rs-1\]). In this case "variable source domain" was omitted
because "s_bodyRollRate_rs-1" is a variable defined by the laws of
physics and there cannot be a body rate from aerodynamics and a body
rate from the moments produced by the engine. If however, the user
wanted to have a multi-body simulation, logically the "variable source
domain" could be used to discriminate between different elements of the
body, or, perhaps more logically, an array or structure would be used to
define different elements in a multi-body or flexible structure problem.

The *whole point here is to help provide clear communication when
exchanging models*, *not force variable names*. "s_bodyRollRate_rs-1" is
the shortest unambiguous version of the variable name.

[Suffix]{.underline}

The suffix is used to describe the units of the variable.

The convention for the suffix is simple and is followed for all
variables. This will allow the user, the programmer, and the reader of
the code to check for homogeneity of the units and is obviously
self-documenting in this respect. Therefore, the units will be put on
all variables except variables that are non-dimensional (which therefore
have no units). This also has the other significant advantage of making
this standard consistent and acceptable in countries with the
international system of units. For example, airspeed is just as
acceptable as a standard both for the American system of units and the
International system of units.

The standard for exponential expression is used. So feet per second is
fs-1 and feet per second squared is fs-2. Every term in the denominator
has an exponent. For example:

(r/s^2^ )/(f\*lbf) would be expressed as rs-2f-llbf-1.

Some more examples:

trueAirspeed_fs-1 for feet per second (f/s)

and in the other case

trueAirspeed_ms-1 for meters per second (m/s)

or

trueAirspeed_nmih-1 for knots (nautical miles per hour)

The standard defines what the variable name for airspeed is, the user
defines what units they are using.

The suffix is always separated from the body of the variable name by an
underscore.

The standard unit notations are given below. The seven *Système
Internationale d\'Unites* (SI) units and standard abbreviations are
included.

> time
>
> hours h
>
> seconds s (SI Standard)
>
> minutes min
>
> milliseconds ms (milli prefix m)
>
> length
>
> feet f
>
> meter m (SI Standard)
>
> nautical miles nmi
>
> statute miles smi
>
> kilometers km (kilo prefix k)
>
> centimeters cm
>
> millimeter mm (milli prefix m)
>
> Force
>
> pound force lbf
>
> Newton N
>
> kilogram force kgf
>
> Mass
>
> gram g
>
> kilogram kg (SI Standard)
>
> pound mass lbm
>
> slug slug
>
> Plane Angle
>
> degrees (angular) d
>
> radians r
>
> revolution rev
>
> Temperature
>
> degrees Rankine R
>
> degrees Centigrade C
>
> degrees Kelvin K (SI Standard)
>
> Power, energy, work, heat
>
> British thermal unit btu
>
> erg erg
>
> calorie cal
>
> joule jou
>
> horsepower hp
>
> Electrical
>
> volt direct current vdc
>
> volt alternating current vac
>
> ampere A (SI Standard)
>
> cycles cyc
>
> watt watt
>
> henry hy
>
> farad fd
>
> ohm ohm
>
> Other
>
> candela (luminous intensity) cd (SI Standard)
>
> mole (amt. of substance) mol (SI Standard)

[Discarded Conventions and Reasons]{.underline}

We have considered having a prefix for simulation inputs and outputs as
well as states but at the present time this has been discarded due to
the fact that the inputs and outputs required vary so widely, and there
are typically an extremely large number of outputs.

We considered eliminating the suffix when the units were one of the
\"standards\", but discarded this concept due to the fact that always
having the units attached to the variable will help the
programmer/engineer have consistent units when they are programming and
reduce programming errors due to mixing of the units improperly.

Another naming convention that was considered and discarded was the use
of prefixes and or suffixes or other naming structures to designate
software organization. This was discarded based on the philosophical
fact that variable names should not designate software organization. If
the AIAA standard develops to the point in the future where there is
standard software, architecture or structure, these variable names could
be used in that software but will not be changed.

3.  Summary

While it is strongly recommended that this naming convention be followed
for all future variables, the real key to a \"**standard variable
name**\" is not the name, but the definition of the name. To exchange
information between two or more organizations, the most important factor
is not whether a variable is named \"airspeed\" or \"as\", but what is
the precise, unambiguous definition of the variable (true airspeed,
indicated airspeed, calibrated airspeed?, etc.), including units and
axis system.

Using the "standard variable name" simply provides a common language and
set of definitions within which to transfer the model.

4.  Standard Variable Names

Using the conventions discussed above, a set of standard variable names
has been created. These are presented in Annex [A]{.underline}. An
excerpt of Annex [A]{.underline} is given below for illustrative
purposes.

Interpretation of the standard variable name annex is best given by
example. Item 1 in the table below is standard variable defining the
Roll Euler Angle, its axis system and positive sign convention (t = RWD,
or right wing down). Four name examples are provided:

-   The short name, PHI

-   Two full names using the standard convention**,** one with degrees
    as units and one with radians.

In addition this example also illustrates the pitch and yaw euler
angles.

Since roll, pitch and yaw may also conveniently be expressed as a
vector, the shaded area is the standard definition of the Euler angle
vector. Again, eulerAngle_r(3) would be the standard vector using
radians as the units and is fully compliant with the standard.

The standard allows use of any of the standard set of units.

<table>
<colgroup>
<col style="width: 4%" />
<col style="width: 6%" />
<col style="width: 8%" />
<col style="width: 21%" />
<col style="width: 23%" />
<col style="width: 8%" />
<col style="width: 6%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 4%" />
<col style="width: 5%" />
</colgroup>
<thead>
<tr class="header">
<th></th>
<th><strong>Symbol</strong></th>
<th><strong>Short Name</strong></th>
<th><strong>Full Variable Name</strong></th>
<th><strong>Description</strong></th>
<th><strong>Sign Convention</strong></th>
<th><strong>Intial Value</strong></th>
<th><strong>Min Value</strong></th>
<th><strong>Max Value</strong></th>
<th><strong>Note</strong></th>
<th><strong>Date Changed</strong></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td><p><mark>eulerAngle_d(3)</mark></p>
<p><mark>eulerAngle_r(3)</mark></p>
<p><mark>(euler_angle_d(3))</mark></p></td>
<td><mark>Vector of the roll, pitch, and yaw Euler angles defined
below</mark></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>1</td>
<td>Φ</td>
<td>PHI</td>
<td><p>rollEulerAngle_d</p>
<p>rollEulerAngle_r</p>
<p>(roll_euler_angle_d)</p></td>
<td>Roll Euler Angle, FE (flat earth or local) Frame</td>
<td>RWD</td>
<td></td>
<td>-180</td>
<td>180</td>
<td>2</td>
<td></td>
</tr>
<tr class="odd">
<td>2</td>
<td>θ</td>
<td>THET</td>
<td><p>pitchEulerAngle_d</p>
<p>pitchEulerAngle_r</p></td>
<td>Pitch Euler Angle, FE (flat earth or local) Frame</td>
<td>ANU</td>
<td></td>
<td>-90</td>
<td>90</td>
<td>2</td>
<td></td>
</tr>
<tr class="even">
<td>3</td>
<td>ς</td>
<td>PSI</td>
<td><p>yawEulerAngle_d</p>
<p>yawEulerAngle_r</p></td>
<td>Yaw Euler Angle, FE (flat earth or local) Frame</td>
<td>ANR</td>
<td></td>
<td>-180</td>
<td>180</td>
<td>2</td>
<td></td>
</tr>
</tbody>
</table>

**4.1.5 References**

None

**5.2 STANDARD SIMULATION AXIS SYSTEMS**

**5.2.1 Background / Philosophy**

The axis system definitions discussed herein were taken from existing
standards, the the *ANSI/AIAA Recommended Practice for Atmospheric and
Space Flight Vehicle Coordinate Systems* (ANSI/AIAA R-004-1992)
\[Reference 3.1\]and the *Distributed Interactive Simulation* (DIS
Application Protocols, Version 2, IST-CR-90-50, March 1994) \[Reference
3.2\]. Reference 3.1 standard is based on ISO Standard 1151-1 of 1988
and 1151-3 of 1972.

Axis system standards also are reflected in the variable naming
convention. When applicable, the axis system is included in the variable
name.

**5.2.2 Axis System Conventions**

In general, ANSI/AIAA R-004-1992 \[Reference 3.1\] should be referred to
as the normative reference on axis system definitions. However, it is
important to emphasize the correlation of reference \[3.1\] and \[3.2\]
axis systems.

[Geocentric Earth Fixed-Axis System]{.underline}

The Geocentric Earth Fixed-Axis System (Axis System 1.1.3 of Reference
3.1) is identical to the DIS \"Geocentric Cartesian Coordinate System\"
(also referred to \"World Coordinate System\" of Reference 3.2).

It is a system with both the origin and axis fixed relative to, and
rotating with, the earth. The origin is at the center of the earth, the
xG axis being the continuation of the line from the center of the earth
through the intersection of the Greenwich Meridian and the Equator, the
zG axis being the mean spin axis of the earth, positive the north, and
the yG axis completing the right hand triad.

All variables in the simulation referenced to this axis system refer to
the \"GEaxis\" for the Geocentric Earth Fixed-Axis System.

This system is fixed to and rotating with the earth.

[Body Axis Coordinate System]{.underline}

The next standard axis system is the Body Axis System (axis system
number 1.1.7 in Reference 3.2). This is identical to the DIS \"Entity
Coordinates System\" in Reference 3.2.

It is a system fixed in the vehicle with the origin at the center of
mass consisting of the following axis orientation. The x axis is in the
reference plane of the vehicle, or if the origin is outside that plane,
is in that plane through the origin that is parallel to the reference
plane, and positive forward. The reference plane is the plane of
symmetry or clearly specified alternative. The y axis is normal to the
reference plane and positive to the right. The z axis lies in or is
parallel to the reference plane and completes the orthogonal right hand
triad.

The body axis system is referred to in the variable names as \"Body\".

[Flat Earth Axis System]{.underline}

The third axis system is defined only for convenience on creating
validation data. It is a fixed, non-rotating, flat earth with no mapping
to a round earth coordinate system, therefore, latitude and longitude
are meaningless. The purpose of this coordinate system is to allow, if
desired, vehicle checkout simulation to be performed in this axis
system. This simplifies the use of this standard by the simulation
facilities which do not normally use a round or oblate spheroid,
rotating earth model.

The Flat Earth reference system is situated on the earth\'s surface
directly under the cf of the vehicle at the initialization of the
simulation. The x axis on the local frame points northwards and the y
axis points eastward, with the z axis down. The x and y axis are
parallel to the plane of the flat earth.

The flat earth axis systems is referred to in the variable names as
\"FEaxis\".

[Discarded Conventions and Reasons]{.underline}

There are many other possible axis systems, several more are in referece
3.1. However other axis systems may be easily transformed to these and
these axis systems will satisfy the needs of the vast majority of the
users.

[Summary]{.underline}

It is strongly recommended that this axis system convention, and those
in Reference 3.1, be followed for all future equations of motion. If it
is not a satisfactory system, the convention should be modified and all
the defined axis systems modified according to the new convention.

**5.2.3 References**

**3.1** *ANSI/AIAA Recommended Practice for Atmospheric and Space Flight
Vehicle Coordinate Systems* (ANSI/AIAA R-004-1992).

**3.2** *Distributed Interactive Simulation* (DIS Application Protocols,
Version 2, IST-CR-90-50, March 1994).

**[CLAUSE]{.underline}**

**5.3 STANDARD SIMULATION Function table DATA FORMAt and xml
Implementation of the Standard**

## 5.1 PURPOSE:

The purpose of this section is to explain the data requirements for
which a Standard Function Table Format must be able to satisfy. This
discusses the content of the information contained in the table and
configuration management of the data in the table. As you will see the
format of the table includes data for all these components.

This document also discusses conceptually how the data table should be
looked up in an executable program.

The standard is implemented in XML as specified by DAVE-ML, Annex
\_\_\_\_\_. Annex \_\_\_ provides example programs for loading and
looking up data in the XML standard.

**5.3.1 Philosophy**

Probably the most immediate benefit of the standard to the simulation
discipline is one that defines formats for the interchange of tabular
data. Tabular data is used almost universally for non-linear function
generation of aerodynamic, engine, atmospheric, and many other
parameters. The easy interchange of such data can greatly improve
efficiency in the simulation community.

Most simulation developers and users have addressed this issue locally.
In many simulation communities, a family of tools has been built around
existing local function table standards. Thus, the intent of this
standard is not to obsolete these local standards, but rather to define
a format for communication which will allow each site to develop a
single format converter to and from their local format. **This is an
exchange standard.** It is hoped that this standard will eventually be
adopted for local use as well, but that is not required for the standard
to succeed.

## DESIGN OBJECTIVE

The design objectives of the Standard Data Table Format were first and
foremost to make a data format that would include all the information
about real multi-dimensional data, not just the data values. This
notably is the fact that, in the general case of the independent
variables for a multi-dimensional table, the independent variables have
different number of breakpoints, different breakpoints, and different
valid ranges. An equally important design objective was to allow the
table to contain information on where the data points come from
(provenance, via reference), and a confidence interval for the data.
Confidence Intervals can be used for Monte Carlo simulations and to
mathematically combine two different estimates at the same parameter at
the same point. Therefore, confidence statistics are extremely valuable
when attempting to update a data set (however the user must be careful
as not all confidence intervals are equivalent, or even meaningful).
Additionally, the table has to be easy to read by the computer and the
human being, and be self-documenting as much as possible.

## 

**[5.4]{.mark} *Standard Function Table Data-An Illustrative Example***

Figure A presents a fairly standard three-dimensional set of data as is
typical of aerodynamic data from flight test or from a wind tunnel. In
the example given, lift coefficient is a function of angle-of-attack,
Mach number, and a control position. More generally stated, a function
output (dependent variable), CLALFA is dependent on three inputs
(independent variables), alfa, Mach, and delta_s.

Close examination of the example data given will reveal the following
characteristics:

1.  The number of breakpoints of the independent variables varies for
    each independent variable. Not only are there a different number of
    angle-of-attack (alfa) breakpoints, but also a different number of
    Mach number (Mach) and control position (delta_s) breakpoints. We
    have defined this as an "Un-gridded Table".

2.  The values (breakpoints) of the independent variables are different.
    Again, an "Un-gridded Table".

3.  The valid ranges of the independent variables are different.
    ("Un-gridded Table")

4.  The above three differences are not consistent for all the data. For
    example, in the example table the alfa, breakpoints for Mach = 0.6
    and Mach = 0.7 for delta S = -5 are identical.

![](media/image1.wmf)

Figure 5.4 -1 An Illustration of a 3 Dimensional Function Table, CLALFA
(alfa, Mach, delta_s)

For function data there is other information that is of significant
importance to the user, without which the data is not very useful. In
general this information is:

-   where did the data come from? For example what report?

-   how is it defined? For example, is this at a specific altitude? What
    configuration is it for?

-   what are the engineering units of the output (the dependent
    variable) and the independent variables?

-   what is the sign convention of the independent and dependent
    variables? For example, is the control position positive trailing
    edge up or trailing edge down? Exactly which control surface is it?

-   who created the table? Not where the data came from, but what person
    decided that this was the correct data for this table?

-   how has it been modified and for what reason?

```{=html}
<!-- -->
```
-   how accurate is the data estimated to be? Or, mathematically what is
    the confidence interval of the data?

-   By what method is the data intended to be interpolated? For example,
    linear interpolation or bi- cubic spline interpolation?

-   By what method is the data intended to be extrapolated for data with
    different ranges?

The standard data format has data elements that contain all of the above
information. It has been implemented in XML as seven Major Elements and
is discussed in detail in Annex B. An introduction and overview will be
provided here.

Additionally, DAVE-ML also includes the ability to automate static
checks of the function data to allow spot checking of the function after
it has been exchanged.

**DAVE-ML Major Elements (reference Annex B)**

These major elements are provided in the same order as they must be in
the XML files. In general, most attributes and sub-elements are
optional. In fact, only the *fileHeader* and *variableDef* major
elements are required.

The logical flow of information is such that the lower major elements
refer upward to information previously defined, in general, so that
information (breakpoints, datapoints, provenance, etc.) that is re-used
in more than function does not need to be repeated.

1.  *fileHeader*- the fileHeader contains the file provenance (who
    created the file and how to contact that person or team), all
    references and overall description about all the functions in this
    particular file. The provenance of each particular function refers
    to the fileHeader.

2.  *variableDef* -- defines the signals used to generate the functions,
    at a minimum, the independent variable (inputs) and the dependent
    variables (outputs). Additionally, it includes the definition of any
    intermediate variables used to generate the functions, and defines
    any calculations that are to be performed (defined as MathML).

3.  *breakpointDef* - here, all the breakpoints, or independent variable
    datapoints, for gridded tables are defined. One set of breakpoints
    may be used by many functions. This section does not apply to
    ungridded tables. They contain their breakpoints within the
    *ungridedTableDef* major element. There may be a provenance for the
    breakpoints, which again may refer to the *fileHeader*.

4.  *griddedTableDef* - contains the datapoints of the function. These
    datapoints use the breakpoints defined in the breakpointDef major
    element. The provenance of each set of data points may be explicitly
    defined here, and may refer to documents defined in the
    *fileHeader*.

5.  *ungriddedTableDef* - contains the breakpoints and the datapoints of
    the ungridded tables. These are specified as sets of breakpoints and
    datapoints together and do not refer to the *breakPointDef* major
    element. As in *griddedTableDef*, the provenance of each set of data
    points may be explicitly defined here, and may refer to documents
    defined in the *fileHeader*.

6.  *function* -- combines the breakpoints with the datapoints, and
    defines which independent variables are used as inputs to the
    functions. This element also includes definition of how the function
    should be interpolated and extrapolated, and is the definitive
    element to include provenance on the particular function (where did
    the data for this function come, who decided this set of datapoints
    would be used for this function, etc.). The nonlinear function
    definition is complete at this point.

7.  *checkData -* contains a set of static check cases to verify the
    functions. It includes an optional tolerance on the outputs. If the
    checkData element is used, it must include check cases for all
    outputs in the file (it cannot check some functions and not others).

Annex B contains a detailed description and examples of the data element
definitions of the DAVE-ML function table standard. Appendix A of Annex
B provides detailed XML element references and descriptions.

**A Simple DAVE-ML Example**

The easiest way to understand the standard is through an example. Annex
B contains many more examples of the DAVE-ML implementation of the
standard.

Lets take a simple one dimensional aero table, in this case pitching
moment coefficient as a function of angle of attack, Table \_\_\_ and
Figure \_\_\_ below.

Table \_\_\_\_. A Simple Function

  ---------- ------- ------- ------- ------- ------- ------- ------- ------- -------
  alfa       0       18      19      20      22      23      25      27      90

  cm(alfa)   0.1     -0.1    -0.09   -0.08   -0.05   -0.05   -0.07   -0.15   -0.6
  ---------- ------- ------- ------- ------- ------- ------- ------- ------- -------

![](media/image2.wmf){width="5.997222222222222in"
height="3.9472222222222224in"}

Figure\_\_\_\_\_\_. The C~m~(α) Function- A simple one dimensional
gridded function.

The DAVE-ML for this function could be:

CmaExample.dml

\<xml version=\"1.0\" standalone=\"no\"?\>

\<!DOCTYPE DAVEfunc SYSTEM
\"/Users/bjax/Documents/Dev/DAVE/Schemas/trunk/validation_lab/DAVEfunc.dtd\"\>

\<DAVEfunc\>

\<!\-- ========================== \--\>

\<!\--============= File Header Components =============== \--\>

\<!\-- ========================== \--\>

\<fileHeader\>

\<!\-- This is an example of the file header components of the

derivative of Cm as a function of angle of attack. It must

remembered that all fileheader components of all functions

in the file must be grouped together into one file header

area.

Also note that there is not much information in this header,

Mainly because it is mean to be a simple example. In

reality, probably the most important information is the

author, the reference and the modification record, because

these data describe where the data came from and if it has

been changed (and how). See annex B for more complete

examples.

\--\>

\<author name=\"Bruce Hildreth\" org=\"SAIC\"
email=\"bruce.hildreth@saic.com\"/\>

\<fileCreationDate date=\"2006-03-18\"/\>

\<description\>

This is made up data to use as an example of a simple gridded function.

\</description\>

\<reference refID=\"BLHRpt1\" author=\"Joe Smith\"

title=\"A Generic Aircraft Simulation Model (does not really exist)\"

accession=\"ISBN 1-2345-678-9\" date=\"2004-01-01\"/\>

\<!\-- no modifications so far, so we don\'t need a modificationRecord
yet \--\>

\</fileHeader\>

\<!\-- ================================== \--\>

\<!\--============= Variable Definition Components =============== \--\>

\<!\-- ================================== \--\>

\<!\-- Input variable \--\>

\<variableDef name=\"Angle of attack\" varID=\"angleOfAttack_d\"
units=\"deg\" \>

\<isStdAIAA/\> \<!\-- Indicates that this variable is a standard

variable, which is why the author omitted

description and sign convention

and any other info. (it certainly could

be included here) \--\>

\</variableDef\>

\<!\-- Output (function value) \--\>

\<variableDef name=\"Pitching moment coefficient due to angle of
attack\"

varID=\"CmAlfa\" units=\"nondimensional\" sign=\"+ANU\"\>

\<description\>

The derivative of total pitching moment with respect to

angle of attack.

\</description\>

\</variableDef\>

\<!\-- ============================= \--\>

\<!\--============= Breakpoint Definition Set =============== \--\>

\<!\-- ============================= \--\>

\<breakpointDef bpID=\"angleOfAttack_d_bp1\"\>

\<!\--

Note that the bpID can be any name for the breakpoints. The

author here chose to use a name related to the independent

variable that is expected to be used to look up the function. In

fact, if this set of breakpoints were shared by many functions

and different independent variables would be used to look up the

function, then the bpID of \"angleOfAttack_d_BP1\" would be

misleading and a more generic name like \"AOA\" would probably be

better.

\--\>

\<description\>

Angle of attack breakpoint set for CmAlfa, CdAlfa, and ClAlfa

\</description\>

\<bpVals\> \<!\-- Always comma separated values \--\>

0, 18, 19, 20, 22, 23, 25, 27, 90

\</bpVals\>

\</breakpointDef\>

\<!\-- ============================= \--\>

\<!\--============= Gridded Table Definition =============== \--\>

\<!\-- ============================= \--\>

\<griddedTableDef gtID=\"CmAlfa_Table1\"\>

\<description\>

The derivate of Cm wrt fuselage AOA in degrees

\</description\>

\<provenance\>

\<author name=\"Jake Smith\" org=\"AlCorp\"/\>

\<functionCreationDate date=\"2006-12-31\"/\>

\<documentRef refID=\"BLHRpt1\" /\> \<!\-- This points back to the
Header,

which provides the information

about BLHRpt1. \--\>

\</provenance\>

\<breakpointRefs\>

\<bpRef bpID=\"angleOfAttack_d_bp1\" /\>

\</breakpointRefs\>

\<uncertainty effect=\"percentage\"\>

\<normalPDF numSigmas=\"3\"\>

\<bounds\>12\</bounds\>

\</normalPDF\>

\<!\-- This means that the 3 sigma confidence is +-12% on the Data.
\--\>

\</uncertainty\>

\<dataTable\> \<!\-- Always comma separated values \--\>

0.1,-0.1,-0.09, -.08, -0.05, -0.05, -0.07, -0.15, -0.6

\</dataTable\>

\</griddedTableDef\>

\<!\-- ======================== \--\>

\<!\--============= Function Definition =============== \--\>

\<!\-- ======================== \--\>

\<!\-- The function definition ties together input and output variables

to table definitions. This allows a level of abstraction such

that the table, with it\'s breakpoint definitions, can be reused

by several functions (such as left and right aileron or multiple

thruster effect tables).

\--\>

\<function name=\"Cm_alpha_func\"\>

\<description\>

Variation of pitching moment coefficient with angle of attack (example)

\</description\>

\<independentVarRef varID=\"angleOfAttack_d\"/\>

\<dependentVarRef varID=\"CmAlfa\"/\>

\<functionDefn\>

\<griddedTableRef gtID=\"CmAlfa_Table1\"/\>

\</functionDefn\>

\</function\>

\<!\-- ===================== \--\>

\<!\--============= Check Data Cases =============== \--\>

\<!\-- ===================== \--\>

\<!\-- Checkcase data provides automatic verification of the model by

specifying the tolerance in output values for a given set of

input values. One \'staticShot\' is required per input/output

mapping; in this case for a single input, single output model,

we have a single input signal and a single output signal in each

test point.

\--\>

\<checkData\>

\<staticShot name=\"case 1\"\>

\<checkInputs\>

\<signal\>

\<signalID\>angleOfAttack_d\</signalID\>

\<signalValue\> 0.\</signalValue\>

\</signal\>

\</checkInputs\>

\<checkOutputs\>

\<signal\>

\<signalID\>CmAlfa\</signalID\>

\<signalValue\>0.01\</signalValue\>

\<tol\>0.00001\</tol\>

\</signal\>

\</checkOutputs\>

\</staticShot\>

\<staticShot name=\"case 2\"\>

\<checkInputs\>

\<signal\>

\<signalID\>angleOfAttack_d\</signalID\>

\<signalValue\> 5.\</signalValue\>

\</signal\>

\</checkInputs\>

\<checkOutputs\>

\<signal\>

\<signalID\>CmAlfa\</signalID\>

\<signalValue\>0.04444\</signalValue\>

\<tol\>0.00001\</tol\>

\</signal\>

\</checkOutputs\>

\</staticShot\>

\<staticShot name=\"case 3\"\>

\<checkInputs\>

\<signal\>

\<signalID\>angleOfAttack_d\</signalID\>

\<signalValue\>10.\</signalValue\>

\</signal\>

\</checkInputs\>

\<checkOutputs\>

\<signal\>

\<signalID\>CmAlfa\</signalID\>

\<signalValue\>-0.01111\</signalValue\>

\<tol\>0.00001\</tol\>

\</signal\>

\</checkOutputs\>

\</staticShot\>

\<staticShot name=\"case 4\"\>

\<checkInputs\>

\<signal\>

\<signalID\>angleOfAttack_d\</signalID\>

\<signalValue\>15.\</signalValue\>

\</signal\>

\</checkInputs\>

\<checkOutputs\>

\<signal\>

\<signalID\>CmAlfa\</signalID\>

\<signalValue\>-0.06667\</signalValue\>

\<tol\>0.00001\</tol\>

\</signal\>

\</checkOutputs\>

\</staticShot\>

\<staticShot name=\"case 5\"\>

\<checkInputs\>

\<signal\>

\<signalID\>angleOfAttack_d\</signalID\>

\<signalValue\>20.\</signalValue\>

\</signal\>

\</checkInputs\>

\<checkOutputs\>

\<signal\>

\<signalID\>CmAlfa\</signalID\>

\<signalValue\>-0.08\</signalValue\>

\<tol\>0.00001\</tol\>

\</signal\>

\</checkOutputs\>

\</staticShot\>

\<staticShot name=\"case 6\"\>

\<checkInputs\>

\<signal\>

\<signalID\>angleOfAttack_d\</signalID\>

\<signalValue\>25.\</signalValue\>

\</signal\>

\</checkInputs\>

\<checkOutputs\>

\<signal\>

\<signalID\>CmAlfa\</signalID\>

\<signalValue\>-0.07\</signalValue\>

\<tol\>0.00001\</tol\>

\</signal\>

\</checkOutputs\>

\</staticShot\>

\<staticShot name=\"case 7\"\>

\<checkInputs\>

\<signal\>

\<signalID\>angleOfAttack_d\</signalID\>

\<signalValue\>50.\</signalValue\>

\</signal\>

\</checkInputs\>

\<checkOutputs\>

\<signal\>

\<signalID\>CmAlfa\</signalID\>

\<signalValue\>-0.31429\</signalValue\>

\<tol\>0.00001\</tol\>

\</signal\>

\</checkOutputs\>

\</staticShot\>

\</checkData\>

\</DAVEfunc\>

**Shorter version**

While the above seems incredibly long for a function with only 9 data
points, keep in mind it also includes many instructional comments and
optional, but very important information, such as units and where the
data came from (provenance). Also, a very large complex function would
only be expanded by the additional datapoints. The information included
with the function would probably not change much.

In the minimum, the same data can be represented as shown.

\<DAVEfunc\>

\<variableDef name=\"Angle of attack\" varID=\"angleOfAttack_d\"
\</variableDef\>

\<breakpointDef bpID=\"angleOfAttack_d_bp1\"\>

\<bpVals\>

0, 18, 19, 20, 22, 23, 25, 27, 90

\</bpVals\>

\</breakpointDef\>

\<griddedTableDef gtID=\"CmAlfa_Table1\"\>

\<breakpointRefs\>

\<bpRef bpID=\"angleOfAttack_d_bp1\" /\>

\</breakpointRefs\>

\<dataTable\>

0.1,-0.1,-0.09, -.08, -0.05, -0.05, -0.07, -0.15, -0.6

\</dataTable\>

\</griddedTableDef\>

\<function name=\"Cm_alpha_func\"\>

\<independentVarRef varID=\"angleOfAttack_d\"/\>

\<dependentVarRef varID=\"CmAlfa\"/\>

\<functionDefn\>

\<griddedTableRef gtID=\"CmAlfa_Table1\"/\>

\</functionDefn\>

\</function\>

\</DAVEfunc\>

1.  []{#__RefHeading___Toc511719092 .anchor}General

**Annexes** shall appear in the order in which they are cited in the
text. Each annex shall be designated by a heading comprising the word
"Annex" followed by a capital letter designating its serial order,
beginning with "A", e.g. "Annex A". The annex heading shall be followed
by the title and the indication "(normative)" or "(informative)" all on
a single line. Numbers given to the clauses, subclauses, tables, figures
and mathematical formulae of an annex shall be preceded by the letter
designating that annex followed by a full-stop. The numbering shall
start afresh with each annex. A single annex shall be designated
"Annex A".

**Normative annexes** are integral parts of the standard. Their presence
is optional. An annex's normative status (as opposed to informative)
shall be made clear by the way in which it is referred to in the text,
by a statement to this effect in the foreword and by an indication in
the table of contents and under the heading of the annex.

**Informative annexes** give additional information intended to assist
the understanding or use of the standard and shall not contain
provisions to which it is necessary to conform in order to be able to
claim compliance with the standard (requirements). Their presence is
optional. An annex's informative status (as opposed to normative) shall
be made clear by the way in which it is referred to in the text, by a
statement to this effect in the foreword and by an indication in the
table of contents and under the heading of the annex.

2.  []{#__RefHeading___Toc511719093 .anchor}Clause

    1.  []{#__RefHeading___Toc511719094 .anchor}Subclause (level 1)

        1.  Subclause (level 2)

Text

2.  Subclause (level 2)

Text

2.  []{#__RefHeading___Toc511719095 .anchor}Sublcause (level 1)

Text