Aviator "Under the Hood"

Purpose

This article responds to several frequently asked questions about STK's Aviator capability.

Preliminary concept(s)

Before answering any specific questions, there are some fundamental aspects of Aviator that are very germane to the answers, and as you will see, most of the answers depend on how extensively you want to take advantage of Aviator.

Aviator is inherently a fully extensible framework of plugin objects. In computer science terms, there is a large set of interfaces (900+) that define the relationships between objects. AGI has built a large set of objects (700+) that implement these interfaces in many ways. The manner in which Aviator functions inside of STK is just one possible way that you can wire these objects together to do things. Most of Aviator's API can function outside of STK, although there are some objects that can only exist within an STK scenario.

Aviator was designed to use COM interfaces, so you can build objects using C++, any .NET language, or any other language capable of creating COM objects that implement multiple interfaces. The ability to develop objects that plug in to Aviator is an advanced topic; AGI does not offer standard documentation on this for customers to use independently. AGI wants to work closely with customers to ensure they are using best practices when developing their own functionality.

Many customers want to use their existing high-fidelity, mission-critical models inside of STK and then take advantage of Aviator and other STK features on top of those models. For example, if you are designing and building a high-end aircraft, you will certainly have invested heavily in high-fidelity models of the aerodynamics and propulsion systems of the aircraft. There are many ways that you can model the aircraft in Aviator with full fidelity in terms of speeds, altitudes, climb rates, attitude angles, etc. First, you can employ the native Aviator file formats for aerodynamics and propulsion to read in ASCII data and then apply the native "piloting techniques" that are modeled as part of Aviator's high-end performance modeling (e.g., climb at speed resulting in minimum time to altitude). A second method is to wrap up your own high-fidelity models with a user interface to control the parameters that drive the models, and then employ Aviator's existing set of 20+ procedure types and advanced maneuvers to flexibly simulate the aircraft's flight. Finally, you can also create wrappers around Aviator's existing procedures that are aware of the "special capabilities" of your aircraft. The ability to reuse specific bits and pieces in any combination is what we call “selective reuse.”

As you can see, the Aviator interface framework is not fixed but rather is completely open to extend with entirely new types of aircraft performance models, new types of procedures, and other tools that know how to make use of extended capabilities.

Frequently asked questions

Methods of Calculation

1. How does Aviator calculate aircraft performance such as flight time, fuel consumption, distance traveled, etc.?

Aviator represents the trajectory of an aircraft via a set of performance models that capture the capabilities of an aircraft along with a sequence of procedures that refer to those capabilities to generate the actual trajectory. There are different types of performance models for the functions of takeoff, climb, cruise, descent, and landing, plus specialized models for terrain following and VTOL flight. The acceleration performance model defines the aircraft's ability to maneuver. You can define other types of performance models, but you will need to develop other procedures or tools to make use of new performance capabilities.

The performance models of a given type must implement the standard interface specified by the type. A climb interface, for example, has several methods. One method returns a profile when given a ground track and starting state. Another method returns “steady state” values for a requested altitude and weight. Procedures that climb will make use of this interface to generate the motion. AGI has developed many different representations of the different performance model types. Some are simplistic in the extreme, others are much more realistic and involve more complexity. 

The help topic Designing Missions explains the "building blocks" of an aircraft's trajectory in Aviator: phases and procedures.

There are two general categories of procedures in Aviator: ground track and basic maneuver.

Quite a few procedures are based on a defined ground track and then use the performance models to determine the altitude and speed profile to fly along that ground track. These procedures can be sensitive to excessive wind speed, as too much wind will make it impossible to hold a specified ground track. You will be presented with a graceful failure when that happens. Examples of this type of procedure are takeoff, landing, point-to-point, holding, arcs, and terrain follow. These ground track procedures all function in a flat earth coordinate system that is “wrapped around” the mean-sea-level surface of the earth. These procedures have not been built to work with dynamics. The assumption that is built into performance modeling is the aircraft is always “in trim.” You can define new performance models that understand dynamics and the procedures will then reflect that aspect. 

The basic maneuver procedure makes use of navigation and vertical plane strategies as well as full 3D strategies to fly a variety of maneuvers, from simple turns to highly involved intercept guidance maneuvers. Some strategies operate purely in the wind frame while other strategies understand how to operate in the Earth frame; it depends on the purpose of the strategy. The strategies control how the aircraft's motion is propagated. The basic maneuver procedure is fundamentally capable of accepting flat earth accelerations in separate horizontal planes or vertical planes, doing quaternion integration or doing full, 6DOF integration, but the strategy determines which method to employ. Strategies may define their own integration states so that it is possible to build a strategy that does full, 6DOF simulation with dynamics. There are several MATLAB guidance and control strategies that can define their own integration states, providing a rough equivalent capability to Simulink within Aviator.
 

2. Does Aviator solve flight dynamics equations within its simulation?
3. Is it possible to implement external constraints on the flight performance simulation such as aircraft body=angles limiters, velocity limitations, height limitations that are waypoint dependent, etc.?

The Aircraft performance models define those limitations.
 

4. Is it possible to implement flight control loops? Via connection to MATLAB Simulink, for example.

The MATLAB basic maneuver guidance and control strategies enable an equivalent capability to Simulink. The strategies provide both flat earth and ECF coordinate representations to the MATLAB function. You can specify your own integration state and can use AGI’s aeroToolbox functionality to perform coordinate transformations and attitude rotations and other helper functions.
 

5. Does Aviator offer 3DOF simulation of 6DOF simulation of aircraft dynamics?

Aviator does not intrinsically model dynamics, but the extensibility model does not preclude you from incorporating your own models that employ dynamics.
 

6. What numerical computational methods are implemented inside of Aviator?

The basic maneuver procedure uses adaptive Runge-Kutta 4/5 integration, and there are a vast number of other specialized, often proprietary methods used throughout Aviator for various purposes.
 

7. Are there any validations or calibrations made to Aviator calculations by comparing to experimental flight tests of a specific aircraft?

Test data for several aircraft have been run through Aviator with very favorable results. Customers have had great success importing their own data for their purposes.
 

Performance Database:

1. What options are there to create an aircraft performance model inside of Aviator?

AGI provides several different representations of performance models. The advance fixed-wing capability provided on the “User Aircraft Model” (which is the standard representation) enables you to specify separate methods for aerodynamics and propulsion — from textbook relationships to external file imported data. The result is performance that varies as a function of weight, altitude, speed, and non-standard atmospheric effects.

There are different representations of climb, cruise, and descent performance models, from simplistic, one-parameter models to more realistic or data-driven models that are more complex.

The Aviator capability also provides a simplified missile model as well as an advanced rotorcraft model.

You can use the Aviator extensibility system to wrap your models or data in any way necessary to generate performance models.
 

2. What types of aircraft performance databases can be imported into STK to define an aircraft model? For example, aerodynamic data such as lift and drag polars and engine deck.

Aviator offers ASCII format aerodynamic and propulsion file formats. The advance fixed-wing interface has a feature to generate AERO and PROP files from the selected models, which you can examine and use to build your own files.
 

3. Is it possible to integrate an aircraft performance database in the following formats?:
   1. Interpolation tables for the aircraft aerodynamics:
      1. Cd versus Cl as a function of height, velocity, and stability margin
      2. Cl versus AOA as a function of height, velocity, and stability margin
      3. Drag corrections due to change of height/Reynolds number

At a minimum, AERO files specify Cd and AoA as a function of Mach number and Cl. Optionally, you can specify an altitude dependence and can also specify detailed aerodynamic coefficients using a parabolic model for lift and drag. Stability margin is not modeled in the built-in AGI models. The aircraft configuration specifies a drag count, which will supplement the Cd0 value you specify in your AERO file.
 

2. Interpolation tables for engine performance (engine deck):
   1. Engine power and fuel flow as a function of throttle position, engine RPM, height, velocity, and external temperature
   2. Engine power losses due to installment, friction, etc.
   3. Propeller modeling:
      1. Propeller maps – propeller efficiency, thrust coefficient, and power coefficient as a function of advance ratio
      2. Propeller diameter
      3. Transmission ratio – propeller to engine RPM ratio.

The PROP file provides tuples (of thrust and fuel flow) over a set of throttle settings as a function of Mach number and altitude. The built-in external propulsion model does not model propellers.

You can use the Aviator extensibility system to wrap customer models or data in any way necessary to generate aerodynamic or propulsion models. You can extend the advanced fixed-wing representation, the standard default acceleration performance model, and the missile model to capture your specific aerodynamic and propulsion modeling requirements.
 

Connectivity:

1. Is it possible for Aviator to connect to an external program, service, API, or physical module in order to show its data on the Aviator map environment and GUI?

Refer to the Preliminaries section of this article for information on this question.
 

2. Is it possible to exchange Aviator’s aircraft performance calculation module for a user-provided calculation module?

If you decide that the methodology describe in the Preliminaries section is inapplicable, you are free to generate external ephemeris and attitude files by whatever means you have at their disposal. While this is a fundamentally simple process, you won’t have an interactive environment to work in and you will essentially not be using the features provided by Aviator.