The NASA Meatball Logo
Optimal Trajectories by Implicit Simulation
NASA Glenn Research Center
Cleveland, OH


Introduction to OTIS

The Optimal Trajectories by Implicit Simulation program (OTIS) is a general-purpose program, which is used to perform trajectory performance studies. A user can simulate a wide variety of vehicles such as aircraft, missiles, re-entry vehicles, hypervelocity vehicles, satellites, and interplanetary vehicles. The vehicle models used in OTIS are defined by user inputs; there are no embedded, vehicle specific aerodynamic or propulsion models. OTIS is primarily a point mass, three-degree of freedom (3DOF) simulation program for single vehicles. Options allow six-degree of freedom (6DOF) simulations and several types of limited multiple vehicle problems. The program name is derived from one of the program's methods used to solve differential equations, which was distinctive at the time of OTIS' origin. Trajectory integration can be specified as implicit, explicit or analytic. Flight paths can be generated with respect to any of the major bodies in the solar system. Trajectory generation, trajectory targeting and trajectory optimization can all be accomplished using this program.

For the OTIS developers, trajectory analysis consists of simulating and optimizing vehicle trajectories. Programs, such as OTIS, are used to predict how a vehicle will perform or to determine how to best fly a given vehicle. The resulting data allow a variety of studies to be accomplished including vehicle & sub-system design trades, guidance studies, error analyses and mission planning.

A typical problem, which can be solved using OTIS, is shown as Figure 1. The problem is to find the trajectory that takes a vehicle from a set of initial conditions (a point on a runway) to a set of final conditions (injection into low Earth orbit).

A typical single stage to orbit (SSTO) trajectory optimization problem with three phases.
Figure 1: Example Trajectory Optimization Problem

OTIS' highly generalized modeling capabilities allow the development of a progressively more detailed simulation as the vehicle and mission design advance without abandoning the basic simulation framework. The simplified models used in the preliminary design can be replaced by more faithful representations of the vehicle design. More realistic constraints can be added and design options easily traded off to obtain insight into the final design.

How OTIS Works

OTIS provides two general modes of operation: explicit trajectory integration (or propagation) and optimization using either explicit or implicit integration methods. OTIS provides a number of implicit integration schemes including Gauss-Labatto methods and pseudo-spectral methods. However, it can optimize with explicit integration and parameterized sub-optimal controls. It is implicit integration that provides the OTIS user with rapid, robust, and accurate solutions to trajectory optimization problems

In OTIS, a trajectory represents the time varying solution to a vehicle's dynamical, kinematic and constraint equations. To accommodate general trajectory modeling problems, a trajectory is divided into sub arcs called phases. The times at which the phases are joined are called events. Within a phase, the number of states, controls, path constraints and definition of the vehicle models (aerodynamics and propulsion) remain unchanged. All targeting is specified at the events. Time, control and some state variable discontinuities can occur at the events. State transformations, including discontinuities that have dependencies on previous phase(s) are handled by specific transformation phases. There are seven phase types in OTIS:

The first four types (A, E, I & P) are propagation phases, which provide mechanisms for generating a portion of a trajectory, and in general, take place over a finite length of time. The other three phase types (J, S & T) are transformation phases. The transformation phases have zero time lengths and are used to make changes in the simulation or to introduce discontinuities

While many problems can be simulated with a single phase, more interesting problems employ multiple, linked phases. The linking is accomplished through either linear or nonlinear constraints and need not be a simple sequence. An example linking of a six-phase trajectory is illustrated in Figure 2 Trajectory Description by Phase

Example phase-layout of an OTIS problem
Figure 2: Trajectory Description by Phase

Phases 1 and 2 are separate vehicles. Phase 2 separates into 2 distinct branches (e.g., a booster drops the first stage and the upper stage continues). Phases 4 and 6 then describe the stages after the separation.

OTIS Features

OTIS was designed to be flexible in terms of models and available mathematical procedures. The major OTIS features are:

OTIS Source Code

OTIS is a Fortran program. The authors have successfully compiled and executed OTIS with many different Fortran 95 compilers and computer systems including g95, a free Fortran95 compiler. The size of the working arrays in OTIS governs the program size. As distributed, OTIS requires about 9 Mbytes of storage space when compiled with the lowest level of optimization and without debugging enabled. Key parameters determine the size of the working arrays. Making these parameters smaller will reduce the program size substantially, but at the loss of some capability in the number of controls, nodes, phases and/or other key features of OTIS.

OTIS, as distributed, is not just a program, but also a program whose use is augmented by a number of supporting programs. OTIS installation and execution is streamlined through the use of Python and Perl shell scripts that run on most commonly available computer operating systems including Windows and Linux/UNIX/OS X systems.

The basic OTIS organization is shown on Figure 3. The primary inputs to OTIS are a NAMELIST file and an optional file containing tabular data. The NAMELIST file contains the trajectory modeling, vehicle modeling, definition of numerical methods and output instructions for running a given trajectory problem. Creating a NAMELIST file is usually accomplished with a text editor, with an existing file serving as a template.

The optional tabular data file contains all input tabular data. The information for the aerodynamics, propulsion and other user-defined tabular functions are normally contained in the tabular data file. The tabular data is broken into elements called data sets.

The principal outputs of OTIS are a tabular listing of the trajectory problem being solved and a set of plot files. One of the outputs and also a possible input to OTIS is the restart file. This file contains the trajectory and control time history values and allows an optimization case to be solved in a sequence of runs.

OTIS accepts a namelist input, data files, and a restart file (optionally) as input, and outputs a restart file, a trajectory summary, and tab-delimited data files.
Figure 3: OTIS System Operation

The performance of OTIS in solving trajectory optimization/simulation problems varies depending on the computer type, compiler and compiler options, as well as the user and the problem being solved. Typical contemporary run times for an OTIS solution range from a few CPU seconds to several hundred CPU seconds. A minimum time climb solution for a supersonic fighter that employs a single phase and about 10 segments runs in 1 to 3 seconds on a typical Linux/UNIX server. The longest known run time to date is over 31 days for a single stage to orbit problem on a MicroVAX and was run in the late 1980's.

As mentioned earlier, OTIS uses an internal data dictionary to organize the values stored in its ABLOCK common block. The source file of ABLOCK Fortran common block is used to form the data dictionary. The dictionary is used to form a set of indices that map the elements of ABLOCK and the names of the elements. How it is made available to OTIS is computer operating system dependent. OTIS is distributed with a procedure that makes this happen in a fashion that is largely 'transparent' to the user. Most of the arrays in ABLOCK are dimensioned by parameters that are located in one file and can be changed before compiling the code.

Responsible NASA Official: Maria Babula
Web Curator Rob Falck
NASA Privacy Statement
Date of Last Site Update: May 2008