six-degree-of-freedom digital simulation for missile guidance, navgation and control
TRANSCRIPT
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
1/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010) 71
INTRODUCTION
The DoD denitions1 of 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 classied by theDoD into four levels: campaign, mission, engagement,and engineering. These four levels are shown anddened 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
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
2/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010)72
P. A. HAWLEY and R. A. BLAUWKAMP
engineering questions that the simulation may answerbased on the level of model delity.
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 ight 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 rst 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 modied 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 reect 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 delity 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 eectiveness at neutralizing the threat can be ascertained. A
mission-level simulation omits more details and aims to address
the tactical eectiveness of the missile system to perform a spe-
cic 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 rst guided missiles was poor, but it was sufcientto inspire an entire segment of todays defense industry.
The rst 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-delity 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 reected 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-culty in fully evaluating all components to their fullrange of capability, simulations are an effective means ofcost and risk reduction.
PROGRAMMING LANGUAGES AND PARADIGMS
The rst 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 therst 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 congurationsand are limited by noise, nonlinearities, and parasiticeffects, they have been replaced by digital computers asthe speed and memory capacity of the digital computershave improved.4 Invariably, with each increase in hard-ware performance, engineers increase the complexity of
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
3/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010) 73
6DOF DIGITAL SIMULATIONS FOR MISSILE GNC
the models that they describe in computer code. Logi-cally, there should be a corollary to Moores Law (which
states 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 programming
language with high-quality mathematical libraries for
numerical computations, but initially there were fewdata structuresonly scalars, arrays, and COMMON
blocksand few control constructsIF, GOTO, andDO; so, as the size of the code blocks and the size of
the 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. The
rst attempt to address this problem was the develop-
ment of structured programming: a top-down software-development methodology that imposed a disciplined
breakdown of the data ow 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 ows 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 owingthrough 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,7 and the engineer maintaining the simu-
lation may have a difcult time nding the source ofthe problem if the change was made by another team
member. 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.
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
4/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010)74
P. A. HAWLEY and R. A. BLAUWKAMP
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 nds 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 oftenare linked into the C++ programs to supply efcient
mathematical 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 specically addressed the scoping8 of data
and/or state variables in the simulation; namely, a model
has state variables, and these states are private9 data 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
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
5/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010) 75
6DOF DIGITAL SIMULATIONS FOR MISSILE GNC
information provided by the model. Multiple instancesof a class can be present in a simulation, but because the
states 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 supportsthe concept ofpolymorphism,12 wherein a model can
be treated as a plug-and-play component in the simu-lationa higher-delity seeker model can be swapped
into the simulation for the terminal homing phase afterdynamically removing a lower-delity 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 for
low-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 maycreate 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 nal code.Grouping data or state variables into objects that
dictate the operations that may be performed on these
states illuminated the various ways that engineers usedata and operations while writing code. The authors of
Design Patterns: Elements of Reusable Object-OrientedSoftware13 catalogued 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 particular
classes 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 dierential
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 ofdton the axes. These three behaviors separate into three compo-
nents in the 6DOF simulation architecture: time propagation, model equations, and model interconnections/communication.
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
6/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010)76
P. A. HAWLEY and R. A. BLAUWKAMP
Trapezoidal
RungeKutta4
+createWorkVectors(in numberOfStates: int): void+integrate(in timeStamp, in dt: double, inout s tates: vector, in derivatives: vector
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
7/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010) 77
6DOF DIGITAL SIMULATIONS FOR MISSILE GNC
Functional
Executive
Truth
1
1
1
1
1
1
1
Executive LayerNumerical integrationClockRandom processes
External I/O
Model LayerHierarchical 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-specic
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 delity. 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 conguration of the executive and model
parameters at run time
8. Transparent logging of outputs (usually by creatinga hierarchical le 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 tdt
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 tdt
xdt
k2 2n n2 1
/= + +o state derivatives at midpoint of interval using states advanced to the midpoint using Eulersmethod and k1 as the slope
( , )k x tdt
x
dt
k2 2n n3 2 /= + +o
state derivatives at midpoint of interval using k2 as the slope
( , * )k x t dt x dt kn n4 3 /= + +o state derivatives at endpoint of interval using k3 as 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 dt4 rather than by dt, as it does in a rst-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/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
8/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010)78
P. A. HAWLEY and R. A. BLAUWKAMP
The rst three requirements are necessary for math-ematical correctness. The fourth requirement refersto statistically valid Monte Carlo results that requireindependent random processes, and the fth 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 ofight could be explored in more detail without runningfrom t = 0. The seventh and eighth requirements addressinputs to and outputs from the simulation for con-guration and post-processing, respectively. The nextthree requirements may or may not be part of the nalspecication 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 conguration managementso that a team can efciently 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 nds 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-delity, 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 Specica-
tion (OASIS): OASIS is a specication for 6DOF simulationdevelopment 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 rst 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 sufcient 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
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
9/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010) 79
6DOF DIGITAL SIMULATIONS FOR MISSILE GNC
law18 produces 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 specic 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 delity is shown in the models ofFigs. 79. Figure 7 shows the tennis court model foran axisymmetric airframe linearized about a ight 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 selectedight condition. This level of modeling can be useful forinvestigating observed instabilities during a test ight 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 specications 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 ighttests to exercise various missile subsystems at particu-lar operating conditions. Similarly, after ight 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 modications to the missile orto assess its performance against a new threat. For anoperational system, a simulation identies 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 specications, if necessary,for future deployments. Finally, it can be used to gen-erate operational guidelines for deployment and ringprotocols.
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
deection, Q is the dynamic pressure, S is the reference area, d is
the reference diameter, I is the moment of inertia, m is the mass,
a is the angle of attack, is the acceleration, g is the ight-path
angle, and is the Euler angle. The partial derivatives are the aero-
dynamic coecients linearized at a selected ight 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 ight
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.
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
10/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010)80
P. A. HAWLEY and R. A. BLAUWKAMP
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 aect the missiles operation: gravity, atmospheric pressure, weather,
multipath, etc. Target includes the targets 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 exible bending modes, a center-of-mass oset 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 Model19 and appear inFigs. 1012. A missile is a phys-ical entity whose motion andorientation are controlled tointercept a target entity witha specied 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 ight 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 aredened as those attributes thatdene missile translationaland rotational motion: typi-cally, they are the Cartesianposition, velocity, the quater-nion (for orientation), and theangular velocity. The airframereceives steering commandsfrom the ight controller thatthen are realized as forces andmoments by the actuators.The airframe model has sev-eral components: dynamics,airframe mass, aerodynamics,propulsion, and ight 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.,
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
11/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010) 81
6DOF DIGITAL SIMULATIONS FOR MISSILE GNC
AutopilotNavigationprocessor
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 ight 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 lters and guidance laws with mode logic for various
stages in ight and a high-delity autopilot or wrapped ight 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, a angleof attack, aerodynamic rollangle, and d control surfacedeections.
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 deections. For an endo-atmospheric system, the controlsurfaces typically are tails, aile-rons, or canards, but other ightcontrol 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 ightcontroller.
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 ight 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 delitymay be employed in the sensor models used in a GNCsimulation, but nal performance predictions usually aremade with high-delity models, particularly for the ter-minal mode of the engagement.
The ight 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 lter(s).The guidance lter 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
/ / /
v
v
v
=
=
= = + +
=
= = + +
/
/
Usually, the moments act about the center of massof the rigid body so there is no gravity moment (in auniform gravitational eld). 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 ight conditions and control surfacedeections, 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
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
12/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010)82
P. A. HAWLEY and R. A. BLAUWKAMP
states to produce steering commands. Note that theremay be a dif ferent guidance law and lter for each phaseof ight. 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 ight. 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 ight 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 lters) 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.20 This more exactingdesign regime requires greater model delity 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 modelspecications. If the proposed models do not achieve thedesign objectives, the specications may be revised orthe concept may be scrapped altogetherwithout thehigh cost of hardware prototyping and ight testing. Fora system under development, a 6DOF simulation veriesexpected performance given the design specications,provides an operational platform during hardware pro-totyping, and is validated during ight testing. It is anessential tool for designing operational ight 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 x is the state vector, u is input vector, and y isthe 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 dened 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 B K 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 x and the eigenvaluesfor e are independent with Kinuencing x and L inu-encing e. These conditions fail for nonlinear control
laws and observers.
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
13/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010) 83
6DOF DIGITAL SIMULATIONS FOR MISSILE GNC
the information that is available for the systemnewconcepts may not have any information besides gen-eral specicationsand 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 multithreadedight code becomes a requirement, transitioning to
a 6DOF implementation makes sense. Aerodynamictables can be wrapped in a mex le 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 conguration orrun in a federation with other system simulations (forexample, high-delity radar or threat simulations); atthis time, Matlab and Simulink do not have these capa-bilities. This control of the model equation propagationand information ow 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 Ofce, 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-iable everywhere in the program. Local scope means that the vari-able is visible and modiable 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 (itspublic operations) are separated from itsimplementation (itsprivate data andprivate operations). 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 specied 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,dened 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).
-
8/2/2019 Six-Degree-Of-Freedom Digital Simulation for Missile Guidance, Navgation And Control
14/14
JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 29, NUMBER 1 (2010)84
P. A. HAWLEY and R. A. BLAUWKAMP
Patricia A. Hawley is 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. Blauwkamp received 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.