3dof Model

8/10/2019 3dof Model

1/14

JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 2010 71

INTRODUCTION

The DoD definitions1of the terms model and simula-tion are as follows:

Model: A physical, mathematical, or otherwise logi-cal representation of a system, entity, phenomenon,or process.

Simulation: A method for implementing a modelover time.

Models and simulations are further classified by theDoD into four levels: campaign, mission, engagement,and engineering. These four levels are shown anddefined in Fig. 1. A campaign-level simulation includessuch a large number of model elements that using engi-neering-level models on a single computer would prob-ably take years of execution time. Typically for guidance,

navigation, and control (GNC) analysis, the number

of assets is more limited, and the simulation is at the

engineering levelalthough the level of sophistication

of the models used varies with the system questions to

be answered.

This article discusses the engineering questions,model implementations, and simulation architectures

used in a GNC simulation. We start with a brief his-

torical review of GNC simulations and their uses, and

then we examine the requirements of a digital simula-

tion independent of the models and outline current

simulation designs. Finally, we characterize the essential

models for a GNC simulation and the different levels of

detail for these models. Additionally, we consider some

his article presents a brief history of missile simulations and a discussion of

the programming languages and paradigms used for developing them. Evolv-

ing language and programming paradigms elicit requirements for new

simulation architectures. Within this execution framework, engineering-level guidance,

navigation, and control simulations must include certain functional modules to capture

the performance characteristics of the missile system. The level of model sophistication

required depends on the particular engineering question to be answered. Six-degree-of-

freedom simulations are effective tools for cost and risk reduction during the develop-ment and deployment of missile systems.

Six-Degree-of-Freedom Digital Simulations forMissile Guidance, Navigation, and Control

Patricia A. Hawley and Ross A. Blauwkamp


2/14

JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 201072

P. A. HAWLEY AND R. A. BLAUWKAMP

engineering questions that the simulation may answerbased on the level of model fidelity.

HISTORY

Orville and Wilbur Wright did not simulate air-frames; they prototyped them. As pilots, they acted asthe guidance and navigation subsystems, and they solvedany unstable control systems problems with the airframeduring flight testing by improvising attitude commandsand after landing by modifying the control surfaces toachieve, after an iterative process, safe and stable per-formance. Their successes triggered the development ofairplanes around the world, but their methodology wascostly both in terms of material and in the health and

safety of the pilot. It also was impractical for unmannedairframes such as missiles.The first missiles were the Greek and Roman ballis-

tae, whose motion gave us the term ballistic trajectory.Their designers and users determined the performancecharacteristics of these weapons empirically and incre-mentally modified and improved them over the years. Itwasnt until Sir Isaac Newton supplied the mathematicaland physical language to describe this motion that engi-neers could more accurately predict the performance of

Engineering

Engagement

Mission

Campaign

Figure 1. These four levels of simulation reflect the level of detail

in the simulations and the scope of the questions being asked.

Starting at the most detailed level, an engineering simulation

models a missile systems components and their interactions

to the highest fidelity possible. Next, an engagement simula-

tion omits some of the detail of the engineering simulation but

includes models for launch platforms and threats so that the sys-

tems effectiveness at neutralizing the threat can be ascertained. A

mission-level simulation omits more details and aims to address

the tactical effectiveness of the missile system to perform a spe-

cific mission (e.g., air defense). Finally, a campaign-level simulation

seeks to determine the best capability mix of blue forces against

red forces by focusing on order of battle and probability of kill.

Ideally, all available engineering details would be included at all

levels of simulation, but this is generally not feasible.

ballistic missiles. During World War II, German engi-neers improved on the launch mechanism of their bal-listae by adding rocket propulsion and a simple azimuthcontrol for rudimentary guidance. The performance ofthese first guided missiles was poor, but it was sufficientto inspire an entire segment of todays defense industry.

The first simulation of a missile consisted of a rocketengine burn time and the ballistic equation of motion

to determine the missiles achievable range, as well asa heading to determine its approximate impact point.2Current missile systems are described by nonlinear dif-ferential equations, partial differential equations, and/or discrete-time equations. These models may encom-pass high-fidelity aerodynamics involving tables ofwind tunnel measurements,3 time-varying propulsioncharacteristics, digital autopilots, one or more homingsensors, inertial sensors, communication links, and oneor more guidance laws. The complexity of these mis-siles is reflected in the costs and the capabilities of suchsystems. Instead of simply hitting a target as large as aLondon neighborhood (the goal of the German missiles

of World War II), current interceptors are expected toimpact within centimeters of the aimpoint. Given theexpense of testing such complex systems, and the dif-ficulty in fully evaluating all components to their fullrange of capability, simulations are an effective means ofcost and risk reduction.

PROGRAMMING LANGUAGES AND PARADIGMS

The first digital programs were written in assemblylanguage, and the combination of hardware and lan-guage limited their scope. Fortunately high-level pro-gramming languages provided engineers with moresophisticated tools for building programs. One of thefirst high-level programming languages was FORTRAN,the IBM Mathematical FORmula TRANslation System.FORTRAN allowed engineers to write mathematicallysophisticated equations to model missile systems. Thechallenge then was to write equations that were suc-cinct enough to execute on the slow memory-limitedearly digital computerswithout any particular softwarearchitecture. To achieve real-time performance withhardware in the loop, engineers used analog comput-ers rather than slower digital ones. An analog computeruses the voltages and currents of electrical components

as surrogates for the state variables in differential equa-tions and, therefore, could represent the operating con-dition for a missile during testing of subsystems such astail actuators or seeker heads. Because analog comput-ers require special-purpose hardware and configurationsand are limited by noise, nonlinearities, and parasiticeffects, they have been replaced by digital computers asthe speed and memory capacity of the digital computershave improved.4Invariably, with each increase in hard-ware performance, engineers increase the complexity of


3/14


6DOF DIGITAL SIMULATIONS FOR MISSILE GNC

the models that they describe in computer code. Logi-

cally, there should be a corollary to Moores Law (whichstates that the power of digital hardware doubles approxi-

mately every 2 years) to indicate that the models codedon these rapidly advancing computing platforms double

in complexity every 2 years.

FORTRAN is a high-level procedural programminglanguage with high-quality mathematical libraries for

numerical computations, but initially there were fewdata structuresonly scalars, arrays, and COMMON

blocksand few control constructsIF, GOTO, and

DO; so, as the size of the code blocks and the size ofthe code development teams increased, the maintenance

and reliability of the programs became problematic.5, 6Spaghetti code proliferated and undermined the effec-

tiveness of engineering models for testing the perfor-

mance of increasingly sophisticated missile systems. Thefirst attempt to address this problem was the develop-

ment of structured programming: a top-down software-

development methodology that imposed a disciplinedbreakdown of the data flow in a simulation. Operations

on the data were partitioned into modules or proceduresand executed sequentially, and the system states often

were represented by an appropriate set of data structures.

This methodology exposed the control flows that pro-duce spaghetti code, namely the infamous GOTO state-

ment and the equally nefarious FORTRAN COMMONblock, but did not eliminate the problems associated with

global scoping of variables in a simulation. Data flowing

through a simulation built by using structured program-ming may suffer unintended consequences as a result of

a small change in the internal workings of a particularcode module,7and the engineer maintaining the simu-

lation may have a difficult time finding the source of

the problem if the change was made by another teammember. Despite these drawbacks, there are millions of

MidcourseGuidance

TerminalGuidance

BoostGuidance

BoostAutopilot

Autopilot

ShipSensor

ShipMotionLauncher

Missile

SystemRoot

Ship

ThreatObjects

FlightController

INS

Propulsion

TVC

Dynamics

FinActuators

IMU

Gyros

Gyros

Accelerometers

Fuze

Servos

RFSensor

IRSensor

ReentryVehicle

BoosterDecoy

HomingSensors

WarheadSectionSeeker

Airframe

InertialSensors

Figure 2. This tree shows a hierarchical model tree for a missile system. The SystemRoot in cyan connects the tree to the simulation

executive. The top nodesMissile, ThreatObjects, and Ship (in blue)correspond to the top-level functional descriptions of objects that

would appear in a mission or engagement simulation. The pink nodes are higher-level models composed of the more detailed models

that are the leaves of the tree (in green). These leaves correspond to the engineering models that would appear in a 6-degree-of-freedom(6DOF) simulation.


4/14



11

1

111

0..* 0..*

ModelObject

Dynamics

Propulsion

TVCFinActuator

Airframe

actuators: vectortvc: TVC

dynamics: Dynamicspropulsion: Propulsion

+jettisonTVCEvent()

states: StateVectorderivatives: DerivateVectortimeStamp: TimeStampmutex: Lockcondition: Condition

+initialize()+activate()+propagateStates()+updateStates()+computeOutputs()

+reset()#waitForStates (in time : TimeStamp )#waitForOutputs( in time: TimeStamp)+connectToData(in object: ModelObject)

mass: doublethrust: vectorcgLocation: vectorfuelMass: doublemomentsOfInertia: matrix

+getMass(in time: TimeStamp): double+getCGLocation(in time: TimeStamp): vector+getInertia(in time: TimeStamp): matrix+getThrust(in time: TimeStamp): vector

deflectionLimit: doublerateLimit: doubledeflection: doubledeflectionRate: double

+getDeflection(in time: TimeStamp): double

deflectionLimit: vectorrateLimits: vectordeflections: vectordeflectionRates: vector

+getDeflections(in time: TimeStamp): vector

Cn: AerodynamicsTablesCm: AerodynamicsTablesCl: AerodynamicsTablesCN: AerodynamicsTablesCA: AerodynamicsTablesCY: AerodynamicsTablesforcesTotal: vectorMomentsTotal: vectorposition: vectorvelocity: vectoracceleration: vectorquaternion: vectorangularRate: vectorangularAcceleration: vector

+getPosition(in time: TimeStamp): vector+getVelocity(in time: TimeStamp): vector

+getAcceleration(in time: TimeStamp): vector+getDCM(in time: matrix): matrix+getBodyRates(in time: TimeStamp): vector+getAngularAccelerations(in time: TimeStamp): vector

Figure 3. This class diagram shows that the Airframe is composed

of a vector of zero or more FinActuator objects, a Propulsion object,

a Dynamics object, and zero or more thrust-vector control (TVC)

objects. The Airframe constructs these models when it is instan-

tiated, and it destroys them when it is destructed. Each of these

classes inherits methods from the ModelObject that encapsulate the

functionality required by the simulation executive. The get functions (in green) allow other models to access the outputs of these objects.

A model can generate an event as indicated by the jettisonTVCEvent method in the Airframe model. The variables in blue are the private

data of the models. Notice that the ModelObject does not maintain a list of subscribers for the Observer pattern because the objects do

not push data to their subscribers. Instead, the objects pull data from publishing objects with the correct time stamps and may wait for

the data to be ready. The connectToData method finds the object supplying the required data by searching the model tree. These objects

do not propagate time, but they do depend on it.

lines of structured-programming FORTRAN code still

in use. Existing FORTRAN numerical libraries often

are linked into the C++ programs to supply efficientmathematical utilities, and it is possible to wrap legacy

FORTRAN code in a C-style interface for use in a C++

simulation.

To foster greater maintainability of programs, a more

effective separation of concerns was needed. The next

paradigm for high-level programming was object-ori-

ented (OO) programming. In an OO design, data and

actions are bound together in objects to separate one

models functionality from another models functional-

ity and to separate time and other simulation services(e.g., random numbers and I/O) from the models. This

methodology specifically addressed the scoping8of data

and/or state variables in the simulation; namely, a model

has state variables, and these states are private9data of

the class. An instance of a class is called an object, and

other objects cannot directly affect the states of the

model; they can only request access to publicly available


5/14



information provided by the model. Multiple instances

of a class can be present in a simulation, but because thestates are encapsulated,10 these instances are indepen-dent. A particular missile subsystem may be composed

of multiple modules forming a hierarchical tree of nestedmodels. To simplify code development and reuse, classesmay inherit11 states and/or behaviors from base classes;

for example, a digital autopilot model class would inheritfrom the DiscreteModel base class. Inheritance supports

the concept of polymorphism,12 wherein a model canbe treated as a plug-and-play component in the simu-lationa higher-fidelity seeker model can be swapped

into the simulation for the terminal homing phase afterdynamically removing a lower-fidelity seeker model usedfor the midcourse phase. These programming concepts

require a high-level language such as Smalltalk, C++,or Java. Often, C++ is chosen because it is backward-

compatible with the C programming language used forlow-level hardware coding and provides OO classes withinheritance and templates for generic programming.

C++ is statically typed and allows for user-created types

with operator overloading; i.e., the programmer may

create a type (a class) and explicitly overload the binary+ operator to perform a syntactically appropriate combi-nation of two objects of that type. Attempting to use the

overloaded operator with another type generates a com-piler error. Catching usage errors at compile time versusrun time typically improves simulation execution times

by eliminating conditional tests from the final code.Grouping data or state variables into objects that

dictate the operations that may be performed on thesestates illuminated the various ways that engineers usedata and operations while writing code. The authors ofDesign Patterns: Elements of Reusable Object-Oriented

Software13catalogued many of the most commonly seenpairings of data and operations and grouped them into

categories: creational, structural, and behavioral. Apattern describes a programming idiom, i.e., the parti-

tioning of functions and responsibilities into particularclasses or objects to achieve a given task or algorithm.An engineer equipped with a set of design patterns or

idioms is equipped with a set of tools for producing effec-

t

0

0 2 4 6 8

4

3 6 9

8

10

0

0

0

k

k

k

t

dt= 2

T= 2

T= 4

T= 3

dt= 1 dt= 1 dt= 2 dt= 2 dt= 1 dt= 1

dt= 2 dt= 1 dt= 1 dt= 2 dt= 2 dt= 1 dt= 1

Model E quations InterconnectionsPropagation of Time

Continuous Model 1

Continuous Model 2

Discrete Model 1

Discrete Model 2

Discrete Model 3

uy

y

y

y

0 1 0 113

4

5

2

=

R

T

SSSSS

6

V

X

WWWWW

@( , ,

( , , )

)x f x

x u t

u t

y g

1 1 1 1

1 1 11

=

=

o

uy

yy

y

01 0 02

1

3

4

5

=

R

T

SS

SSS

6

V

X

WW

WWW

@( ) ( ( ), ( )

( ( ), ( ))

)

( )

x k f x k k

x k u k

u

y k g

12 2 2 2

2 2 2 2

+ =

=

( ) ( ( ), ( )

( ( ), ( ))

)

( )

x k f x k k

x k u k

u

y k g

13 3 3 3

3 3 3 3

+ =

=u

y

y

y

y

00 1 03

1

2

4

5

=

R

T

SSSSS

6

V

X

WWWWW

@

( ) ( ( ), ( )

( ( ), ( ))

)

( )

x k f x k k

x k u k

u

y k g

14 4 4 4

4 4 4 4

+ =

=u

y

y

y

y

1 0 1 04

1

2

3

5

=

R

T

SSSSS

6

V

X

WWWWW

@

( , ,

( , , )

)x f x

x u t

u t

y g5 5 5 5

5 5 5 5

=

=o u

yy

y

y

0 0 105

1

2

3

4

=

R

T

SSSSS

6

V

X

WWWWW

@

Figure 4. The blocks highlighted in yellow are the model equations that correspond to the leaves in a hierarchical tree that are either

discrete or continuous. The equations to the right (green) indicate how the blocks are interconnected. The time axes on the left (blue)

indicate each models expected update times independent of the other models; however, to be mathematically correct, the differential

equations must be propagated such that whole time steps (n*dt) align with the update times for the discrete models that provide inputs

to the continuous models. This requirement forces the time steps for the numerical integration to change to smaller values if necessary to

align with the discrete time propagation as shown by the variability of dton the axes. These three behaviors separate into three compo-

nents in the 6DOF simulation architecture: time propagation, model equations, and model interconnections/communication.


6/14



Trapezoidal

RungeKutta4

+createWorkVectors(in numberOfStates: int ): void+integrate(in timeStamp, in dt : double, inout states: vector, in derivatives: vector


7/14



Functional

Executive

Truth

1

1

1

1

1

1

1

Executive Layer Numerical integration Clock Random processes

External I/O

Model Layer Hierarchical model tree

TruthorEnvironmentLayer

Gravity

Weather

Signalpropagation

Truthdata

Node

0..*

Figure 6. This diagram illustrates the layers of a 6DOF simula-

tion where the time management, I/O, and random processes

are encapsulated in the Executive Layer; the models for grav-

ity, weather, and signal propagation are encapsulated in the

Environment Layer; and the hierarchical model tree is encapsu-

lated in the Application Layer (as in Fig. 2). Note that the nodes of

the hierarchical tree have interfaces for utilizing the Executive and

Truth Layers as well as the functional interfaces for the model ele-

ments. Often other layers are illustrated for a simulation architecture:

for example, the User Interface Layer, which often is a graphical user

interface (GUI), and the Operating System Layer for platform-specific

code. These layers are optional for a missile 6DOF and may be imple-

mented as part of the three layers shown.

is illustrated in Fig. 6 by the separation of the execu-tive utilities and environment from the models. Clearly,the executive elements do not depend on the models,but they do supply functionality that the models may

use. Second, the model-state equations (Fig. 4 center)often depend on other models states and/or outputs(Fig. 4 right), so communication between these modelsmust be not only transparent but also synchronous atinternal time steps in the numerical integration (Fig. 4left). Third, as model complexity rises and run-timeexecution slows, multithreading or distributed process-ing becomes a possible solution to the requirement forreal-time execution while maintaining model fidelity. Insummary, the architecture executive requirements are asfollows:

1. Synchronous evaluation of continuous state equa-

tions at time-step bounds for both major andminor time steps in the numerical integrationalgorithm

2. Synchronous evaluation of continuous and discreteequations at the time-step bounds for the discrete-time models

3. Asynchronous evaluation of aperiodic events (e.g.,separation of missile stages)

4. High-quality, random number generation for noiseprocesses

5. Reproducible results

6. Start and restart of simulation runs at an arbitrary

time7. Flexible configuration of the executive and model

parameters at run time

8. Transparent logging of outputs (usually by creatinga hierarchical file structure that mimics the modeltree structure)

9. Real-time execution for hardware-in-the-loopapplications

10. Multithreading to enhance run-time performance15

BOX 1. RUNGEKUTTA INTEGRATION FORMULA

( ) ( ) ( ),x t x t dt

k k k k6

2 2n n1 1 2 3 4= + + + ++ where tn+ 1 = tn+ dt

( , )k x t yn n1 /= o state derivatives at tn

( , )k x t dt

x dt

k2 2n n2 1

/= + +o state derivatives at midpoint of interval using states advanced to the midpoint using Eulersmethod and k1as the slope

( , )k x t dt

x

dt

k2 2n n3 2 /= + +o

state derivatives at midpoint of interval using k2as the slope

( , * )k x t dt x dt kn n4 3 /= + +o state derivatives at endpoint of interval using k3as the slope

The commonly used fourth-order RungeKutta integration algorithm breaks each major integration interval into fourminor integration steps. Each step involves the calculation of the derivatives with an updated state. Note that time does notstep uniformly through the minor steps. The advantage of using a higher-order algorithm, such as this one, is that the errorshrinks by dt4rather than by dt, as it does in a first-order algorithm, such as the Euler method.

11. Distributed processing to enhance run-time perfor-mance and/or operation in a High-Level Architec-ture (HLA) environment16

12. Portability and maintainability

13. Scalability


8/14



The first three requirements are necessary for math-ematical correctness. The fourth requirement refersto statistically valid Monte Carlo results that requireindependent random processes, and the fifth require-ment refers to reproducing a single run in the presenceof random processes by logging the seed(s) used in therandom number generator(s). The sixth requirementsimply allows a user to (re)run the simulation from an

arbitrary time so, for instance, the terminal phase offlight could be explored in more detail without runningfrom t = 0. The seventh and eighth requirements addressinputs to and outputs from the simulation for con-figuration and post-processing, respectively. The nextthree requirements may or may not be part of the finalspecification for the architecture, but they should beconsidered for future reuse of the code. Portability andmaintainability refer to executing the code on differenthardware and software platforms (e.g., PCs or worksta-tions running Windows or Linux) and adopting goodprogramming practices and configuration managementso that a team can efficiently develop code and transi-

tion that code to new users and developers. Scalabilityrefers to using this architecture with as many models asthe user chooses without degrading the performance.This last item would, of course, impact the run-timeperformance, but it should never affect the accuracy ofthe simulation results.

Another layer of the architecture handles the com-munication between models and the external world(gravity, signal propagation, weather, etc.). This layer ofutilities has the following requirements:

Loose coupling between models supports dynamiccreation and destruction of models during a simula-

tion run. Communication must be transparent between

models.

Models request data from a particular class, andthe communication mechanism finds the near-est matching object and connects the subscriberto the publisher (Observer pattern).

As models are created and/or deleted from thesimulation, the communication mechanismadjusts the subscriptions.

All of these requirements are independent of thesystem to be modeled and, therefore, the architecture

that matches these requirements promotes reusability.The following are some examples of current APL

simulations within the Air and Missile Defense Depart-ment that are using OO architectures with modelhierarchies:

OO Simulation Architecture (OSA):

Evolved Sea Sparrow Missile launch-to-intercept simulation is a high-fidelity, 6DOFimplementation.

C++ Single threaded Synchronous execution Composite pattern for model tree Mediator pattern for model communication

Java Event-Driven Implementation (JEDI):

SwarmSim is the Swarm Simulation for SmallBoat Defense.

MIDAS is the Missile Defense AnalysisSimulation.

Both are launch-to-intercept 6DOF simulationsfor ongoing system design and feasibility studies.

Java Multithreaded Synchronous execution (rendezvous

between threads) Composite pattern for model tree Observer pattern for model communication

Open Architecture Simulation Interface Specifica-

tion (OASIS): OASIS is a specification for 6DOF simulation

development in either C++ or Java.

The Multiple Kill Vehicle End-To-End Simula-tion is built with Simitar, an OASIS-compliantsimulation framework.

C++ (Simitar is the C++ implementation ofthe OASIS; it has had several engineeringreleases and is being actively developed.)

Single threaded for the first few releases Asynchronous execution Composite pattern for model tree

Observer pattern for model communication

THE COMMON MISSILE MODEL

Up to this point, the discussion of a missile simula-tion has indicated only that the subsystems comprisesmaller subsystems, etc., and thus are naturally repre-sented by a hierarchical tree (as in Fig. 2). What has notbeen discussed is what makes up a missile system. To acertain extent, the mathematical model chosen dependson the question to be answered.

As mentioned earlier, a minimal set of equations

for the V-2 rocket would treat the airframe as a pointmass without aerodynamics but with a thrust equationand just the ballistic equations of motion after motorburnout with an azimuth constraint. These equationsare sufficient to obtain rough estimates of the impactpoint. Variations in wind conditions and motor burnas well as heading and attitude control errors wouldaffect actual performance. Adding simple trim aero-dynamics17 with a transfer function representation ofthe autopilot and a proportional navigation guidance


9/14



law18produces a 3DOF simulation model that often isused to estimate a missiles operational footprint. Thisapproach is valid during the initial phases of a new mis-siles development or to model the general performanceof a system whose specific design details are not known(adversaries). A variation on this approach would beto successively modify the guidance law over some setof guidance law options to assess which law yields the

best performance in the scenario context. Again, theseresults would be optimistic because they ignore so manyother factors in the system, but the engineer can use thedemonstrated trends to direct the next phase of modeldevelopment.

Another level of fidelity is shown in the models ofFigs. 79. Figure 7 shows the tennis court model foran axisymmetric airframe linearized about a flight con-dition (e.g., the pitch channel of the airframe). Figure 8is the classic three-loop autopilot for the pitch chan-nel and a second-order transfer function model for anactuator with angle and rate limiting. Figure 9 illus-trates a simple inertial measurement unit (IMU) and

the proportional navigation guidance law. Assuming aroll-stabilized missile, the engineer can use these modelsto perform 5DOF analysis of the system at the selectedflight condition. This level of modeling can be useful forinvestigating observed instabilities during a test flight orcomputing values for a gain-scheduled autopilot duringinitial design studies (e.g., airframe control design andtrade studies).

Subsequently, a full 6DOF simulation coded fromthe proposed missile system specifications can be usedto verify the predicted performance of the system oncethe full aerodynamic characteristics, functional algo-rithms, and expected noise sources are included. A6DOF simulation can be used to design initial flighttests to exercise various missile subsystems at particu-lar operating conditions. Similarly, after flight testingof the system has begun, the 6DOF simulation param-eters can be validated against the measured telemetry.The interactions of the missile with supporting engage-ment systems, such as surface-based radar and weaponscontrol, can be explored and overall system performancecan be evaluated. The simulation can be used to assessthe risks associated with modifications to the missile orto assess its performance against a new threat. For anoperational system, a simulation identifies and illumi-

nates key sensitivities in the existing hardware. Theeffect on system responsiveness and lethality of poten-tial hardware or software changes can be characterized.Understanding this system behavior allows the engi-neer to revise the missile specifications, if necessary,for future deployments. Finally, it can be used to gen-erate operational guidelines for deployment and firingprotocols.

Although the degree of sophistication of the modelsvaries from the simplest 3DOF to the full-up 6DOF, in

dCN/d QS/m

dCm/d

dCN/d

1/s

1/s

cos/|Vm|

dCm/d dCm/d

QSd/I

+

+

+

+ +

+

+

.

.

.

..

Airframe

Figure 7. Aerodynamics airframe model where is the actuator

deflection, Qis the dynamic pressure, Sis the reference area, dis

the reference diameter, Iis the moment of inertia, mis the mass,

is the angle of attack, is the acceleration, is the flight-path

angle, and is the Euler angle. The partial derivatives are the aero-

dynamic coefficients linearized at a selected flight condition.

KI

KA

KGK 1/s +

+

+

+

+

m

m

c

.

Autopilot

c

c.

2 1/s 1/s + +

2

Actuator

Angle limit

Rate limit

Figure 8. A three-loop autopilot and simple transfer function

model for the actuator. The autopilot uses the acceleration com-

mand from the guidance law and the measured acceleration andbody rate (see Fig. 9) as inputs to obtain the actuator command.

The gains in the autopilot are scheduled as a function of flight

condition to achieve missile stability and command following. The

actuator command passes through a second-order transfer func-

tion with angle and rate limiters.

x

.

.

.

Guidancelaw

Inputs fromseeker

z1

c(k)

Vc(k)m

m

(k)

+

+

+

+

1 + az1

z1

1 + az1

IMU

w

v

Figure 9. The IMU adds noise to the truth values for the accel-

eration and body rate and passes the measurement through a

discrete transfer function. The noise includes nonlinearities, bias,

random-walk noise, and white noise. The guidance law is propor-

tional navigation where the navigation constant, , typically is set

to four, and the inputs are the line-of-sight rate and closing veloc-

ity to the target computed at discrete times.


10/14



Airframe

Flightcommands

Sensorcommands

Flightdata

Sensorcommands

Externalcommands

Worlddata

World data

Worlddata

Flightcontroller

Inertialsensors

Terminalsensors

Environment

Target

Targetdata

Sensedtarget data

Sensedbody data

Missile states and state rates

Weapons control system

Figure 10. Common missile model. The blocks shown illustrate the subsystems required for a

generic missile for GNC system studies. The subsystems outside the orange block are external

to the missile body, and the ones inside the orange block are onboard the missile. The inertialsensors include any IMU, inertial reference unit, and/or GPS unit that measure and/or estimate

the missiles states. Terminal sensors may include RF or IR seekers that may be strap-down

or gimbaled and measure the targets states for guidance. Environment encompasses any

physical processes that affect the missiles operation: gravity, atmospheric pressure, weather,

multipath, etc. Target includes the target s motion as well as any observables, e.g., radar cross-

section and irradiance. Weapons control system accounts for initial conditions at launch as

well as any uplinked information after launch.

Dynamics

Airframemass

Masscharacteristics

World data

Worlddata

Aerodynamics

Propulsion

Inertialsensor

Environment

Flightcontrol

actuators

Aerosteering

commands

Flightcontroller

Flightcommands

Aero forcesand moments

Hinge momentsand panel forces

Propulsive forcesand moments

Missilestateand

missilestaterates

Masschanges

Figure 11. Airframe model. The airframe model includes the subsystems that produce the

dynamic equations of motion. These subsystems can include missile staging, control surface

actuators, TVC vanes, and engine throttling as well as aerodynamics. The equations can be

simplea point mass with trim aerodynamics and perfect actuators and propulsionor

complexan extended body with flexible bending modes, a center-of-mass offset from the

center of control, thrust misalignments, and actuator models with hysteresis, friction, mis-

alignments, etc.

each case, the model tree hier-archy has some basic requiredcomponents. During theoriginal design of the OSAsimulation, separating out theexecutive portion from themodel portion produced a setof diagrams for the critical

elements of a generic missilesimulation. These elementswere dubbed the CommonMissile Model19and appear inFigs. 1012. A missile is a phys-ical entity whose motion andorientation are controlled tointercept a target entity witha specified accuracy. The basicelements of a missile includean airframe, inertial sensorsto stabilize the attitude andassist in guidance, one or more

terminal sensors and/or com-mand uplinks, a flight control-ler, and models external to themissile such as the launch plat-form, the threat, and any envi-ronmental models (weather,gravity, etc).

An airframe model com-putes missile states from forcesand moments. Missile states aredefined as those attributes thatdefine missile translationaland rotational motion: typi-cally, they are the Cartesianposition, velocity, the quater-nion (for orientation), and theangular velocity. The airframereceives steering commandsfrom the flight controller thatthen are realized as forces andmoments by the actuators.The airframe model has sev-eral components: dynamics,airframe mass, aerodynamics,propulsion, and flight control

actuators (see Fig. 11). Dynam-ics are the continuous-timemissile states (position, veloc-ity, orientation, and angularrates) and state derivatives(velocity, acceleration, angu-lar rates, and angular accel-erations) given the forces,moments, and mass character-istics, e.g.,


11/14



Autopilot Navigation

processor

Estimatedmissile

states andrates

Guidanceprocessor

Speedcontroller

Weapons control system

Body sensor data

Airframe

Flightcommands

Sensorcommands

Sensorcommands

Guidancecommands

Flightcommands

Guidancecommands

Guidancedata

Navigationdata

Controldata

Bodysensor

data

Targetsensordata

Externalcommands/

data

Externalcommands/

data

Externalcommands/

data

Terminalsensor

Inertialsensor

Figure 12. Flight controller. The flight controller encompasses the models for GNC. These

models may be simple conceptual equations with no noise, latency, or other error sources, orthey may be detailed models of Kalman filters and guidance laws with mode logic for various

stages in flight and a high-fidelity autopilot or wrapped flight code. A speed controller is shown

for the case when the propulsion may be throttled; for solid propellants, this model may be

omitted.

where Dynpsr dynamic pres-sure, S reference area, D reference diameter, angleof attack, aerodynamic rollangle, and control surfacedeflections.

Propulsion provides the mis-sile thrust forces, moments, and

mass variations. Flight controlactuators are those mechanismsthat physically realize the con-trol commands, e.g., controlsurface deflections. For an endo-atmospheric system, the controlsurfaces typically are tails, aile-rons, or canards, but other flightcontrol systems may includethrust-vector control vanes orpulse-width modulated thrust-ers. The airframe provides truthinformation to the inertial

sensors (typically, accelerom-eters and rate gyros) and inter-acts with the physical worldthrough environmental objectssuch as gravity and atmosphere(Mach, speed of sound, tem-

perature, wind, weather, etc.). The inertial sensors mea-sure the airframes motion and feed it back to the flightcontroller.

Terminal sensors are a collection of objects that pro-vide measurements of the target-relative states (e.g., posi-tion and velocity and/or line of sight and line-of-sightrate) to the flight controller. Two major types of terminalsensors are RF and IR receivers. These sensors interactwith an environmental object to account for variousphysical-world sources of measurement noise (thermalnoise, multipath, clutter, etc). Various levels of fidelitymay be employed in the sensor models used in a GNCsimulation, but final performance predictions usually aremade with high-fidelity models, particularly for the ter-minal mode of the engagement.

The flight controller consists of the navigation pro-cessor, the guidance processor, the autopilot, and thespeed controller (see Fig. 12). Typically, the navigationprocessor consists of an inertial navigation system (INS).

The INS provides estimates of the missile states to theguidance processor based on measurements obtainedfrom rate gyros and accelerometers (the inertial sensors)but may include processing of communication uplinksor possibly GPS measurements. The guidance processorconsists of the guidance law(s) and the guidance filter(s).The guidance filter processes the measurements fromthe terminal sensor(s) and inertial sensors to producewell-behaved estimates of the target states. The guid-ance law(s) combines these with the estimated missile

moment

where position and velocity

where acceleration

/ /

/

mwhere andmass force/ /

,

,

,

( , )

,

, ,

dtdR V R V

dtdV A A

mA F F F F

F

dtdQ f Q

dtd M M M M

Q Mwhere quaternion angular velocity and

gravity aerodynamics propulsion

gravity aerodynamics propulsion

/ / /

=

=

= = + +

=

= = + +

/

/

Usually, the moments act about the center of massof the rigid body so there is no gravity moment (in auniform gravitational field). Airframe mass calculatesthe missile characteristics (e.g., center of mass andmoment of inertia) as inputs to the dynamics. Aerody-namics computes the aerodynamic forces and momentsas functions of the flight conditions and control surfacedeflections, i.e., the forces and moments are obtained vialookups and interpolation in multidimensional tables:

( , , , , , )mach altitude

( , , , , )

( , , , , )

( , , , , )

,

( , , , , , )

( , , , , , )

,

F Dynpsr S

C mach altitude

C mach altitude

C mach altitude

M Dynpsr SD

C mach altitude

C

C mach altitude

A

Y

N

l

m

n

aerodynamics

aerodynamics

=

=

>>

HH


12/14



states to produce steering commands. Note that theremay be a dif ferent guidance law and filter for each phaseof flight. The autopilot transforms the steering com-mands to control surface commands for the airframe.In addition, the autopilot may have multiple controloptions based on the phase in flight. If the missile motoruses solid propellant, the speed controller is omitted;otherwise, it typically throttles the engine to achieve

the required speed. All of these flight control functionsare, of course, critical elements in a GNC simulation,but they cannot act alone, so the other subsystems andexternal models are implemented to simulate the actualsystems operation.

Many of these state equations are nonlinear andtime-varying. In the past, GNC designs have relied onlinearization techniques to simplify designs. Withinthe framework of linear state space systems, the sepa-ration principle states that the model observer (INSand guidance filters) does not affect the eigenvalues ofthe controller (airframe and autopilot), so the devel-opment and modeling of these subsystems could be

treated independently (see Box 2). However, to achievegreater performance, more modern designs use non-linear models and control design techniques, and theseparation principle breaks down.20This more exactingdesign regime requires greater model fidelity and stricterrequirements on the simulation execution, and this per-formance is provided by a well-designed 6DOF digitalsimulation.

CONCLUSIONS

A digital simulation may serve many purposes. For a

new concept, a 3DOF simulation explores system per-formance within the constraints of the proposed modelspecifications. If the proposed models do not achieve thedesign objectives, the specifications may be revised orthe concept may be scrapped altogetherwithout thehigh cost of hardware prototyping and flight testing. Fora system under development, a 6DOF simulation verifiesexpected performance given the design specifications,provides an operational platform during hardware pro-totyping, and is validated during flight testing. It is anessential tool for designing operational flight tests thatexercise the various subsystems at selected points in theperformance envelope. It also is essential for identifying

and illuminating key sensitivities in the existing hard-ware of an operational system.

Simulation architecture requirements do not varywith the level of model complexity. In all cases, thesimulation must provide synchronous propagation ofstate equations with support of asynchronous events andrepeatable random processes for correct mathematicalmodeling. For continued utility throughout the develop-ment process, the simulation architecture should addi-tionally support the following:

Real-time execution for hardware evaluation via

hardware-in-the-loop and/or computer-in-the-loop

Multithreaded execution to help achieve real-time

performance Distributed processing both to achieve real-time

performance and to operate in an HLA environ-

ment

Portability and maintainability

Scalability

For GNC studies, the missile 6DOF simulation

must implement the subsystems shown in Figs. 1012.

The sophistication of the models depends largely on

BOX 2. SEPARATION PRINCIPLE

Consider the linear system:

,

x Ax Bu

y Cx

= +

=

o

where xis the state vector, uis input vector, and y is

the output vector.

Then an observer for this system is of the form:

( ) ,

,

( ) ,

x Ax L y y Bu

y Cx

x A LC x Bu Ly

or

= + +

=

= + +

to t t

t t

to t

where xt is the estimated state. Because the feedbackcontrol will use the estimated state, then

.u Kx= t

If the error vector is defined such that

,e x x= t

then

and

( )

( ) .

e A LC e

u K x e

=

=

o

Finally, the system equations become

.

x

e

A BK BK

A LC

x

e0=

o

o; ; ;E E E

These equations illustrate the separation principle

of designing a controller and an observer independentlyfor linear systems. The last matrix equation is block-triangular so the eigenvalues for xand the eigenvaluesfor e are independent with Kinfluencing xand Linflu-

encing e. These conditions fail for nonlinear controllaws and observers.


13/14



the information that is available for the systemnewconcepts may not have any information besides gen-eral specificationsand the engineering question thatis being asked of the system. In some cases, a simpleMatlab or Simulink model may be an appropriate tool forinvestigating a concept; however, as more model infor-mation becomes available and/or hosting multithreadedflight code becomes a requirement, transitioning to

a 6DOF implementation makes sense. Aerodynamictables can be wrapped in a mex file for use in Matlaband Simulink, but the user does not have the controlover the synchronization at time-step boundaries thata 6DOF implementation provides. For run-time execu-tion, a 6DOF implementation can be refactored torun in a distributed or multithreaded configuration orrun in a federation with other system simulations (forexample, high-fidelity radar or threat simulations); atthis time, Matlab and Simulink do not have these capa-bilities. This control of the model equation propagationand information flow between models is particularlyimportant for the nonlinear, highly coupled designs

currently being developed. 6DOF performance predic-tions for these systems are a valuable tool for risk andcost reduction during missile system development anddeployment.

REFERENCES AND NOTES

1DoD Modeling and Simulation (M&S) Glossary, DoD 5000.59-M,Defense Modeling and Simulation Office, Washington, DC (15 Jan1998).

2Tsiolkovsky, K. E., The Exploration of Cosmic Space by Means ofReaction Device, Sci. Rev.(5), in Russian (1903).

3Etkin, B., Dynamics of Atmospheric Flight, Dover Publications, Mineola,NY (2005).

4Korn, G. A., Continuous-System Simulation and Analog Computers:From Op-Amp Design to Aerospace Applications,IEEE Control Syst.Mag.25(3), 4451 (June 2005).

5Hayes, B., The Post-OOP Paradigm, Am. Sci. 91(2), 106110(MarApr 2003).

6Subramaniam, G. V., and Byrne, E. J., Deriving an Object Modelfrom Legacy Fortran Code, Proc. 1996 Int. Conf. on Software Mainte-nance, Monterey, CA, pp. 312 (48 Nov 1996).

7Ross, J. M., and Zhang, H., Structured Programmers Learning Object-Oriented Programming, SIGCHI Bull.29(4), 9399 (Oct 1997).

8Scope is an enclosing context where values and expressions are associ-ated; for example, global scope implies the variable is visible and mod-ifiable everywhere in the program. Local scope means that the vari-able is visible and modifiable only in the local (subroutine) context.

9Private indicates that the data are hidden within the class and out ofscope outside that class, and it is a keyword in C++ and Java.

10Encapsulation refers to the principle of information hiding in whichthe interface of a class (itspublicoperations) are separated from itsimplementation (itsprivate data andprivateoperations). This tech-nique allows the code developer to change the implementation with-

out violating the contract with the user stated by the public interface.11Inheritance is a generalization of a base class implementation.

A derived class inherits data and behavior from its base class as itreuses and extends its operations. For instance, an Autopilot isaModelObject indicates that Autopilot should inherit from ModelOb-ject. Inheritance therefore produces a hierarchy between classes ofobjects.

12Polymorphism lets the user invoke the functions specified by the baseclass interface but achieve the derived class behavior. This bindingof behavior can be done at run time and yields plug-and-play swap-ping of ModelObjects. Another form of polymorphism, parametricpolymorphism, refers to the compile-time polymorphism achievedwith C++ templates or Java Generics.

13Gamma, E., Helm, R., Johnson, R., and Vlissides, J. M., Design Pat-terns: Elements of Reusable Object-Oriented Software, Addison-Wesley,Upper Saddle River, NJ (1995).

14The Common Object Request Broker Architecture, or CORBA,defined by the Object Management Group is a middleware standardfor the Broker pattern. Implementations of CORBA enable simula-tions on different platforms written in different programming lan-guages to execute together.

15A thread is a sequence of computer instructions executed by a CPUcore. A thread shares the address space with other threads in thesame process. A single CPU core time-slices the execution of mul-tiple threads, but multiple threads can run simultaneously on separateCPU cores.

16IEEE Computer Society, IEEE Standard for Modeling and Simula-tion (M&S) High Level Architecture (HLA)Framework and Rules,IEEE Standard 1516-2000, doi: 10.1109/IEEESTD.2000.92296(2000).

17Lansberry, J. E., Momentless Missile Dynamics Model with a Rotating

Earth, Technical Memorandum A1E(04)U-2-001, JHU/APL, Laurel,MD (9 Feb 2003).

18Murtaugh, S. A., and Criel, H. E., Fundamentals of ProportionalNavigation, IEEE Spectrum, 7585 (December 1966).

19Chiu, H. Y., A1E OO Working Group Presentation Viewgraphs, 26February 1997, Technical Memorandum A1E(97)-2-040, JHU/APL,Laurel, MD (5 Mar 1997).

20Palumbo, N. F., Reardon, B. E., and Blauwkamp, R. A., IntegratedGuidance and Control for Homing Missiles, Johns Hopkins APLTech. Dig.25(2), 121139 (2004).


14/14



Patricia A. Hawleyis a member of APLs Senior Professional Staff in the Guidance, Navigation, and Control (GNC)

Group of the Missile Systems Branch in the Air and Missile Defense Department. She holds a B.A. in astronomy and

physics, an M.S.E.E. from Purdue University, and an M.S. in applied physics from The Johns Hopkins University WhitingSchool of Engineering. Ms. Hawley has pursued additional graduate courses in electrical engineering and mathematics at

the University of New Hampshire. Her area of expertise is in 6-degree-of-freedom simulations of guidance, navigation, and

control systems. She is a member of the Institute of Electrical and Electronics Engineers and the American Institute of

Aeronautics and Astronautics. Ross A. Blauwkampreceived a B.S.E. degree from Calvin College in 1991, and an M.S.E.

degree from the University of Illinois in 1996; both degrees were in elec-

trical engineering. He continues to pursue a Ph.D. from the University of

Illinois. Mr. Blauwkamp joined APL in May 2000 and currently is the super-

visor of the Advanced Concepts and Simulation Techniques Section in the

GNC Group. His interests include dynamic games, nonlinear control, and

numerical methods for control. He is a member of the Institute of Electrical

and Electronics Engineers and the American Institute of Aeronautics and

Astronautics. For further information on the work reported here, contact

Patricia Hawley. Her e-mail address is [email protected].

The Authors

Patricia A. Hawley Ross A. Blauwkamp

TheJohns Hopkins APL Technical Digest can be accessed electronically at www.jhuapl.edu/techdigest.

Documents

3dof Model