Operator Support Concepts for Tomahawk Strike

Management

Mark D . LoPresto, Ann F. Pollack, John Florence, Robert C. Ferguson, and Ian E. Feldberg

M Odeling and simulation play important roles in the exploration of future

system capabilities. Plans for the next generation of Tomahawk include a strike
management capability (the ability to control missiles after launch). The Laboratory
has developed strike management conceptual and functional prototypes that have
helped to refine system concepts and requirements, stimulate user feedback, and
provide an environment for early algorithm development. The functional prototype has
become a valuable tool for examining broader issues of weapon employment and has
been incorporated into a distributed interactive simulation environment to help refine
real-time control of precision strike weapons as system-level challenges grow in
complexity.

INTRODUCTION
As the technical direction agent for Tomahawk, challenge routes of attack. Timely awareness of strike
APL is helping the Navy to shape the direction of the effectiveness and the ability to control how strike
cruise missile program. One example of this effort is the operations unfold are therefore important objectives.
Battle Group Strike Warfare Coordination (BG STC) These objectives are prompting a change from the cur-
initiative, which is intended to improve overall strike rent fire-and-forget employment mode for Tomahawk.
effectiveness through better coordination of strike The Tomahawk Baseline Improvement Program
warfare systems. Tomahawk, which constitutes the (TBIP) is developing capabilities for the next genera-
u.S. Navy's long-range cruise missile arsenal, is the tion of Tomahawk to improve system response time and
in itial focus of this undertaking. enhance employment flexibility. The upgrade, sched-
Originally conceived as a strategic system for deliv- uled to reach operation by the turn of the century, will
ering nuclear warheads, Tomahawk is now a conven- include two-way communications between missiles in
tional weapon system appropriate for tactical environ- flight and command and control nodes, as shown in
ments. Tactical environments necessitate greater Fig. 1. Communications from the missiles will provide
responsiveness and adaptability to the dynamics of real-time health and status reports and battle damage
strike warfare, since target priorities are likely to change indications. Return communications will allow an op-
as battle damage accumulates and objectives shift. The erator to divert, or flex, missiles to alternate targets
opposing force's defenses, once alerted, may be moved, based on the effectiveness of previous missiles. It will
and new threats to the strike force may emerge to be possible to judge aimpoint damage using single-

148 JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 16, NUMBER 2 (1995)
 Status reports
and battle damage
~ indications

1l ....... - ...

I '\

.---\
Unitary

Disperse

~
..
I \.

Figure 1. Tomahawk Weapon System Baseline IV concept of operations. (GPS = Global Position ing System.)

frame video images from a missile's terminal-imaging use the prototypes to obtain comments and suggestions
infrared seeker. (The term aimpoint in this article is from prospective operators on interface design, usabil-
synonymous with aiming point.) ity, and essential features. In addition, the computer
The two-way communications capability permits environment provides a context for algorithm formu -
real-time monitoring and control by a Tomahawk lation. T o demonstrate system-level implications of
Strike Coordinator (TSC) or a delegated representa- advanced strike and cruise missile concepts and capa-
tive. 1 If necessary, the TSC will be able to reallocate bilities, the Laboratory is integrating the products of
resources by diverting missiles to alternate targets using this task into broader simulation environments.
an en route flex command to maintain coverage of
DESIGNING PROTOTYPES
critical targets, conserve missiles, and permit recovery
from missile casualties. Such functions have been In software engineering, prototypes are especially
termed strike management. useful for solidifying requirements (by the procuring
Recognizing that proper utilization of such capabil- agent), understanding design trade-offs (among the
ities is critical to their success, the Program Executive technical community), and influencing system design
Office for Cruise Missiles and Unmanned Aerial Vehi- (by the eventual customer; in this case, the Fleet) .
cles (PEO[CU]) began to define operator support con- Prototypes provide an avenue for uncovering and solv-
cepts through the BO STC initiative. A fundamental ing problems before schedule and cost become the main
objective was to demonstrate that the new capabilities determinants of development. Prototypes can be
could be made manageable for operators. In response, evolved in four basic stages leading toward an opera-
the Laboratory created a computer environment for tional system as follows:
visualizing strike management through prototypes that 1. Conceptual prototypes, which focus mainly on the
present the look and feel of potential capabilities. We human-computer interface, show the look and feel of

JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 16, NUMBER 2 (1995) 149
M. D. Lo PRESTO ET A L.

the eventual system; such prototypes may be auto- allowed rapid modifications on the basis of sponsor and
mated. user feedback.
2. Functional prototypes provide the internal organiza- Object-oriented techniques were used to implement
tion (data structures and architecture) and incorpo- a flexible system that could readily be adapted and
rate candidate algorithms and processing behind the expanded to represent new ideas and concepts. Object-
interface to give the system limited functionality. oriented techniques model the problem domain as a set
3. Fieldable prototypes provide the major functions of of objects and the relationships among them. Objects
the eventual system reliably enough to insert the are abstractions of things in the problem domain that
prototype into an exercise or operational environ- relate to the system's responsibilities. A class is a set of
ment for initial evaluation. Some operational benefit objects that have a common structure and behavior. In
is also obtained. general, classes are static, and objects are particular
4. Operational prototypes provide virtually all func- instances of classes.
tions in a robust and reliable system that is often an The first advantage of object-oriented development
interim capability introduced in anticipation of fu- is design stability. Although specific requirements may
ture delivery through a formal program. change, any Tomahawk strike management system will
have objects for representing missiles, shooters, mis-
Prototypes supply useful information throughout sions, and others. Object-oriented development also
their multistage development. They facilitate defini- permits data encapsulation, since each object has an
tion of technical characteristics through hands-on eval- associated set of attributes and actions. In this manner,
uation and permit user feedback before an investment data are packaged or encapsulated with particular ob-
is made in full-scale development. Customers can val- jects, thus helping to manage system complexity.
idate system requirements and usability by interacting Object complexity evolves with the prototype. Ini-
with prototypes that approximate the look and feel of tially, the prototype represented objects at a very high
the eventual system. Questions arising from this process level with few details, which provided an overall per-
help to refine system concepts further. A mature pro- spective useful for refining capabilities and identifying
totype can serve as an interim solution that does not new requirements. As the prototype unfolded, the ob-
require a lengthy acquisition process to remedy short- jects afforded a framework for continued development,
falls in fielded capabilities. since they could easily be added, deleted, or modified.
This article describes the application of conceptual In addition to employing object-oriented tech-
and functional prototypes to Tomahawk strike manage- niques, the development philosophy stressed code re-
ment. The conceptual prototype models the look of use, which was particularly important in the interface
operator support by simulating the content and presen- development. A commercial product (Symantec Think
tation format of key information on a typical strike C) was used to provide the basic user interface objects
management display. The functional prototype conveys on the Macintosh, such as windows, menus, and dia-
the feel of operator support by enabling options for the logue panels. Drawing on this existing code enabled the
functional support layer behind displays (including data team to concentrate on implementing Tomahawk
structures, functional flow, algorithms, decision support strike management objects. Code reuse allowed rapid
features, and controls for governing flow and applying progress on the specific problem domain within a ge-
decisions) to be explored. neric interface framework.
The aim of the architectural philosophy was to
achieve the flexibility and growth potential emphasized
DEVELOPMENT PHILOSOPHY in the software development philosophy through a
Early prototypes have helped to mature Tomahawk modular approach. Thus, the logical functions of the
strike management concepts through a spiral develop- prototype were separated into two elements: the strike
ment cycle. Top-level requirements were written in a management display and the simulation driver. The
system-level specification for the Tomahawk Weapon strike management display approximated the system
System Baseline IV. We began designing the prototypes to be deployed, and the simulation driver provided
by storyboarding ideas for strike management to pro- the inputs and responses for stimulating the human-
duce a series of sample displays illustrating possible computer interface. In an operational system, real-
operator support concepts. After review, the ideas were world inputs would replace the driver. To mirror this
transformed into an automated prototype that was discrete functionality in the prototype architecture,
initially implemented and evolved on the Macintosh separate processors were used for the two elements (Fig.
and then progressed to the current 486-based system. 2). Interaction between the elements was through mes-
Throughout development, the team concentrated on sages across a network. This architecture was designed
designing a flexible, easily extendable system. This to enhance modularity and set the groundwork for de-
philosophy accommodated changing requirements and veloping an operational system.

150 JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 16, NUMBER 2 (1995)
 TOMAHAWK STRIKE MANAGEMENT

prototype displays were firm

enough to permit work to begin on
the computer implementation of
the functional prototype.
The displays in the conceptual
prototype are simple and intuitive.
Tomahawk strike management
Graphics are used to convey infor-
mation on a gross scale, and text
Operator support prototypes Simulation driver
and tables are employed to orga-
nize and present fine details. The
geographic display presents the
top-level information required to
monitor the strike, allowing the
operator to retrieve more detailed
• "Look" and "feel" of human-computer interface • Scenario definition and control
• Demonstration of tactical support concepts • Missile capabilities from launch to impact information if needed. A consis-
• Interaction with simulation driver • Simulation/stimulation to exercise concepts
of operation
tent color scheme is used to
present essential strike informa-
Figure 2. Top-level hardware and functional architecture of the operating support environ-
ment. tion. Green is used as a positive
indication (e.g., receipt of a missile
status message) and blue denotes
CONCEPTUAL PROTOTYPE completion (i.e., the missile has reached the target).
Nonstandard conditions are presented in red and yel-
The initial conceptual prototype consisted of a series low, depending on the degree of urgency or effect on
of computer screen viewgraphs illustrating operator dis- the overall strike plan.
plays for each of the anticipated strike management The conceptual prototype illustrates a hands-off
functions. Figure 3 presents a sample display. Concept strike management style. As long as the strike proceeds
refinement occurred through weekly meetings with the nominally, results are presented on the display in green
Navy sponsor. After only a few such meetings, the and blue. The TSC monitors progress but is not

Show

STRIKE CLOCK

00987

Aimpoint Name Allocated Required MID Term Video

71 AA Amal Abo 2 None

00G51

Figure 3. Strike management display for the conceptual prototype. (MID = missile identification.)

JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 16, NUMBER 2 (1995) 151
M. O. Lo PRESTO ET AL

required to take action. Intervention is required only providing the appearance of operator interfaces without
when there is a deviation from the plan, causing a the feel. With the driver, the functional prototype
yellow or red display warning to appear. Such anom- offers an environment that stimulates realistic response
alous conditions invoke system recommendations that from the operator support prototype.
prompt action from the TSC. Suggested actions are Early driver development was based on the Toma-
limited to a few well understood choices. This strike hawk Object-oriented Trade-off Evaluation Model
management style reinforces a goal of the prototype (TOTEM), which APL created as a tool for exploring
development effort: to demonstrate a straightforward advanced Tomahawk concepts. It included a graphical
user interface. user interface (GUI) that permitted parameters to be
modified easily for defining a scenario and analyzing
different options. With a GUI, the operator controls
FUNCTIONAL PROTOTYPE the computer by manipulating icons on the computer
screen rather than entering text instructions on a com-
The modular architecture of the prototype design
mand line. Such directly manipulatable, user-friendly
environment allows the functional components to
interfaces are familiar and intuitive for Macintosh,
be developed in parallel with conceptual prototypes.
DOS Windows, and X Windows users. Figure 4 illus-
This modularity promotes rapid prototype develop-
trates a TOTEM scenario development screen. The
ment. The functional prototype consists of the strike
object-oriented domain model allowed the program to
management user interface for monitoring and control-
be adjusted easily for exploring potential new capabil-
ling missiles and a simulation driver for generating
ities. Because of this inherent flexibility, TOTEM was
missile messages and responding to strike management
a logical starting point for the simulation driver and
commands.
served as the basic domain framework and interface to
build upon.
The Simulation Driver The primary functions of the simulation driver are
The simulation driver is an important component in to stimulate the strike management system with repre-
the functional prototype. Without the driver, the util- sentative missile messages and to mimic the response
ity of the functional prototype would be limited to of missiles to strike management commands. Although

File Edit Objects Options Simulation Tue 11:12 AM

Untitled 1 G!i

Figure 4. Scenario development screen for the Tomahawk Object-oriented Trade-off Evaluation Model (TOTEM).

152 JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 16, NUMBER 2 (1995)
 TOMAHAWK STRIKE MANAGEMENT

the driver simulates missile actions from launch times using data passed with the message. In addition,
to impact, the emphasis is on message exchange and the object may send out its own message or pass the
processing. All communication between the driver and original message farther along a hierarchical message-
the strike management module is through message passing structure to be handled by the program or the
passing. In the Macintosh-based prototype, messages operating system.
were passed over a network utilizing the Apple Pro- Strike management interface development started
gram-to-Program Communications Toolbox, Apple with the set of viewgraphs that constituted the concep-
Events, and the Apple Event Manager. Apple Events tual prototype. The basic display was a geographic view
uses Apple's message-passing protocol for program-to- of the area of interest that served as the default window
program communications. Apple Events provided a when the program was started. This display inspired
built-in mechanism for exchanging data between the new and expanded features, such as pop-up information
strike management module and the driver, simulating windows that remained open while the user clicked on
the transmission of messages between the Tomahawk an object, pull-down menus for setting up and tailoring
Strike Manager and missiles in flight. In the NEXT- the display, and special keyboard equivalents for com-
STEP version of the functional prototype, message mon user actions.
passing was achieved using Unix remote procedure The initial interface development phase, although
calls in a client-server architecture. short, was probably the most productive. The features
The driver is an event-stepped simulation with a of SuperCard made it easy to dispense with mundane
variable execution rate. Simulation events are inserted but potentially time-consuming tasks such as imple-
into an event list in sequence of execution order. menting window management services and handling
Events are removed from the top of the event list at mouse tracking and clicks. Instead, developers concen-
the user-specified execution rate unless constrained by trated on introducing features relevant to Tomahawk
the performance of the computing platform. The driver strike management. Attention focused on how strike
manages event processing alongside user input han- management would work, not just how it would look.
dling and display processing within the application, Four top-level strike management functions (strike
allowing the user to alter the execution rate before or preview, strike monitoring, strike control, and strike
during simulation. assessment) were drawn from the Tomahawk Weapons
Simulation events include missile events, threat System Baseline IV System Specification, the docu-
events, target events, and Global Positioning System ment specifying the next generation of Tomahawk.
(GPS) events. Each missile is initialized with a launch How these functions could be performed became ap-
event. After the missile begins flight, a booster separa- parent through using the rudimentary strike manage-
tion event is scheduled, and so on, through each se- ment display. The geographic display was well suited
quential mission event. Anomalous missile events can to strike preview (simulating the strike before execu-
be generated at random, under user control, or based tion) and strike monitoring (viewing strike progress
on proximity and state of threats. These events allow during execution). The information necessary to sup-
the strike management operator support prototype to port strike control (diverting missiles in flight) and
handle difficult scenarios. strike assessment (gauging strike success from reported
results), however, was not clearly presented on a geo-
graphic display. Early attempts at performing these
Strike Management Operator Support functions with the preliminary prototype led to addi-
The strike management user interface for the func- tional displays to support these functions.
tional prototype was developed using Apple's Hyper- In the initial implementation, the strike control
card application program, which was then replaced by function was triggered by a reported missile failure.
SuperCard (from Silicon Beach). Hypercard and Su- Strike plans require a specific number of missiles to be
perCard, both of which support Apple Events, are in- allocated to each aimpoint. If a missile failure results
novative applications for programming on the Macin- in the quantity of missiles allocated to an aimpoint
tosh. They supported the rapid growth cycle of the falling below the number required, a set of actions is
prototypes with their graphical user interface develop- needed to recover from the failure. Recovery is accom-
ment and message-passing capabilities. plished by diverting missiles or launching backup mis-
Hypercard and SuperCard work similarly, using siles, or by doing both, to restore complete aimpoint
Macintosh's HyperTalk interpreted programming lan- coverage.
guage. The SuperCard environment was selected be- In the Macintosh version, the recovery from a mis-
cause of its color display support. Graphical entities on sile failure was scripted; the system response was hard
the screen represent objects in the program that inter- coded and only made sense if a certain missile failed
act through the exchange of messages. When an object before a certain point in the strike. The failure man-
receives a message, it may perform some service, some- ifested itself on the display through changes in the

JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 16, NUMBER 2 (1995) 153
 M. D. Lo PRESTO IT Ai.

colors of key objects (e.g., the missile icon turned from to this aimpoint view of the strike. For example, aim-
green to red) and audible alerts. The failure appeared point location on the geographic display does not
to cause the system to calculate and rank possible re- necessarily convey aimpoint priority. Consequently, in
covery options. addition to the geographic display, the prototype pro-
It was difficult, however, to show recovery options vides an aimpoint summary window that draws the
on the same geographic display that was indicating the attention of the TSC to aimpoint coverage. The aim-
current state of the strike. A key concern was that the point summary consists of a table of prioritized aim-
TSC would confuse recommended actions with the points (as determined from the strike plan). For each
actual state. In tead, separate dialogue panels and alert aimpoint, the table shows the missiles (by missile iden-
boxes were used to present recovery options unambig- tification number) heading to that aimpoint, the quan-
uously to the TSC, as shown in Fig. 5. In the Strike tity of missiles required, and the number of currently
Preview mode, the TSC can fai l a missile at will to allocated missiles. The table also provides access to
practice recovery procedures. When an actual strike is terminal imagery when it arrives at the strike manage-
being monitored, the failure has to be initiated at the ment module.
simulation driver and passed to the strike management
module via Apple Events.
The TSC performs strike assessment by interpreting Improving the Functional Prototype
the missile status messages and viewing terminal imag- The functional prototype, consisting of the integrat-
ery (when available) for any battle damage indications. ed simulation driver and strike management user
Throughout the interface development, but in partic- interface, was demonstrated to the sponsor in July and
ular when considering strike as essment, it became August 1993, just 4 months after the effort began.
apparent that the real focus of the TSC should be On the basis of sponsor feedback, APL set out to build
aimpoint coverage rather than individual missile health a more robust prototype for demonstrating TBIP capa-
and progress. The geographic display is not well suited bilities to Navy operation al personnel. We developed

~1IQ2l!U ~ !lm:.lt fil..!.25< !:§!. ~

2 1 0 Hone
7!AB A.a! Abo 3 0 Hone

70AR Airport 3 3 0
0 Hone:

6 0 Hone
72RC noD 0
60RB Latka 8 Ae. t

U.
Launch Plotfor.
NeHt
4 71M 7 71M 3 15 00651
7 721£ 5 71M 4
Reject

[ Reject All I

Figure 5. Sample strike management display using SuperCard with a Macintosh. (Alloc =allocated , MSL =missile, Remt =Remote, DTED =Digital
Terrain Elevation Database , 10 = identification.)

154 JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 16, NUMBER 2 (1995)
 TOMAHAWK STRIKE MANAGEMENT

the new prototype using an IBM-

compatible PC. The NEXTSTEP oper-
ating system was selected because it
provides an object-oriented graphical
user interface and supports develop-
ment of object-oriented applications.
The support structure includes sophis-
ticated tools for building graphical user
interfaces to programs incorporating
Objective C , which, like C++, is an
object-oriented programming language
that can execute standard C source
code.
The transition to NEXTSTEP was LCC20
-.
relatively straightforward. Although
SuperCard is not an object-oriented de-
velopment environment, it exhibits
several characteristics of an object-
oriented system, such as encapsulation,
modularity, and message passing. Much
of the application structure developed
for SuperCard remained valid in the
NEXTSTEP version. The behavior of
key objects and their interactions with Req Moe A'n/j tskPd estPIt l

other objects in the application were z

well known. In short, the analysis and
, z, 64 0.70 0.&0
10.75
0.50
3 3 ~ D.86 0.88
much of the existing design directly , , 3 0.50

carried over to NEXTSTEP; most of

, , , 0.&0
0.30 0.50 JI

the revamping effort concentrated on

programming the interface. Figure 6
shows an example of the current strike [.
_arm_
,ll"Ir ~!I ! I f:'

--· -
management user interface based on f'II9'eSS
~UD
the IBM PC.
TIf1I8UD RIIq Moe MSUD expPd Image 0416 0430 0446 0600 06
[] I"M I -~~ I· I· Ilt41 J.". 11ISII7I1 JAMI ~~.
....~

--··
I I
1__ I
1· I 113.. I 11ISII7I· 1-
The NEXTSTEP revision offered I"AD I· I.... I··.. ISlIm. 1- ... .... .. ..
.
the opportunity to incorporate a grow- 171M "~ Akport 11744 Ion
I' I'
17"
Sllml
I-'j-
_
'"....
I I I I 1·_ I 1- IAPI .. ...
B
ing list of enhancements and alterna-
tive displays. Suggestions for improve-
ments, extensions, and new capabilities
InAC I_
t Jl'- T·
I· I ·~~
.::r.
eeA8
12S47 I·... I~ IMO.
T X4I -r.... __-rDOOl' j HV' --l

-
Figure 6. Sample strike management display using NEXTSTEP with an IBM PC. (AimptlD
frequently emerged from demonstra- = aimpoint identification, MSLlD = missile identification, exp Pd = expected probability of
tions. Alternative (i.e., nongeographic) damage, RAP = reporting action point, Req = required, Alloc = allocated, Avail = available,
displays for tracking missile progress tskPd = task probability of damage, estPd = estimated probability of damage.)
and the ability to fail any missile at any
point in the strike were two suggestions
high on the list of frequently requested capabilities. dards when implementing the three decision aids intro-
These and other desired capabilities required develop- duced into the prototype. These were developed using
ing decision aids for integration into the prototype. a Macintosh Quadra 800 and subsequently ported to
Incorporating working decision aids into the proto- the IBM PC for integration with the rest of the system.
type offers several advantages, such as prompt feedback The first decision aid, aimpoint coverage, computes
to help refine complicated heuristics, information for actions necessary to reallocate missiles to assure proper
use in determining data structure design (operator de- coverage of all aimpoints. The algorithm is triggered
cisions are quite complex and can require intricate data when the quantity of missiles designated for an aim-
structures), and the possibility of translating lessons point is less than the number required. This situation
learned from early algorithm implementation directly can arise from a missile failure, a previous reallocation,
into the final product. In addition to lessons learned, or an increase in required missiles based on an opera-
the software itself can be incorporated in the final tor's assessment of previous damage. Each of these sit-
system. The Laboratory adhered to strict ANSI C stan- uations requires the system to consider different factors.

JOHNS HOPKINS APL TECHNICAL DIGEST , VOLUME 16, NUMBER 2 (1995) 155
M. D. Lo PRESTO ET AL.

In responding to a failure, the system must consider if The Laboratory is investigating other methods, such as
a backup missile should be launched or whether one of genetic algorithms* and fuzzy logic, t for the next gen-
the missiles en route can be redirected to cover the eration of aimpoint coverage algorithms.
failed missile's aimpoint. Clearly, a recovery solution The second decision aid, strike effectiveness, allows
that conserves resources is desirable (i.e., a solution an operator to monitor the progress of a strike using the
using the minimum number of backup missiles). If an probability of target damage as a measure of overall
aimpoint is not sufficiently damaged, missiles headed strike effectiveness. By monitoring the strike progress,
toward lower-priority aimpoints may need to be redi- corrective actions can be made to compensate for those
rected, depending on timing constraints. This action areas of the strike that are not meeting objectives. For
can deprive other aimpoints of coverage and set a example, if the current probability of damage to a given
cascade of missile redirections in motion. Eventually, target is below the specified level (perhaps owing to
backup missiles may need to be launched to cover an failures or diverted missiles) , the user can divert anoth-
aimpoint, including the original underdamaged aim- er missile from a lower-priority aimpoint to compen-
point. sate. The conditional probability of damage to an aim-
The aimpoint coverage algorithm assists the opera- point is calculated on the basis of the expected level
tor in reaching a decision by enumerating all of the of damage to an aimpoint from a single missile and the
appropriate responses to the given situation. Each re- number of missiles going to a given aimpoint. The
sponse is ranked using a series of heuristics and present- expected level of damage from a single missile is mission
ed to the operator for consideration. The implemented dependent and is calculated before strike execution.
heuristics are simple but effective in ranking solutions The strike effectiveness algorithm dynamically com-
and include the following: putes the conditional probability of damage for each
aimpoint as the strike progresses. For example, if a
1. A failure recovery solution in which no backup mis-
missile fails, the algorithm updates the conditional
siles are launched is better than a solution in which
probability of damage values for all aimpoints. The
backup launches are required (conserve resources).
updated values are presented to the operator for eval-
2. A failure recovery solution requiring few missile
uation using the now familiar color scheme. Values that
diversions is better than a solution requiring many
meet or exceed tasking are shown in green, nonzero
diversions (minimize the req uired number of realloca-
values below the specified damage level are shown in
tion moves).
yellow, and null values are shown in red. A null value
3. A failure recovery solution requiring that a missile be
will occur when no missiles are headed to an aimpoint.
diverted from a low-priority aimpoint is better than a
This decision aid allows the operator to evaluate a
solution in which a missile is diverted from a higher-
strike's effectiveness quickly during execution.
priority aimpoint (divert missiles from low-priority
The third decision aid, hit probability, computes the
aimpoints) .
probability that a Tomahawk will hit designated struc-
The aimpoint coverage algorithm is being expanded tures in the target area. It is designed for both collateral
to reallocate missiles in response to positive damage damage evaluation and target hit maximization. The
assessments. In this case, to maximize the probability algorithm accepts as input a series of disjoint, simple
of meeting strike objectives, the system will seek to polygons specified by their vertices. These polygons
redirect missiles still flying to the destroyed aimpoint, represent buildings and other structures in the target
which will eliminate the need to consider launching area as viewed from above. The algorithm also accepts
backup missiles. A key issue is how to redistribute the as input the parameters of a bivariate normal probabil-
extra missiles. Some possibilities are to divert all extra ity distribution, which denote a missile's most likely
missiles to the highest-priority aimpoint available, to termination point and containment ellipses in two di-
distribute missiles evenly across all remaining available mensions. To compute the probability of hit, the algo-
aimpoints, or to redistribute missiles based on a weight- rithm approximates the integral of the distribution
ed priority of remaining available aimpoints (e.g., di- function over the series of input polygons. The distri-
vert two missiles to the highest-remaining-priority aim- bution function will generally be highly dependent on
point and one to the remaining second-highest-priority a missile's run-in heading and dive angle. Using the
aimpoint). probabilities computed by the algorithm, an operator
Although the aimpoint coverage algorithm works can determine the best run-in heading and dive angle
well for the limited scenario used to demonstrate the
prototype, the number of missiles and diversion and * G enetic algorithms are heuristic search algorithms based on mecha-
backup options in an operational system can be several nisms of evolution and natural selection. For further information,
orders of magnitude greater. In an operational environ- see the article by Best and Sanders on genetic algorithms in this
issue.
ment, any practical algorithm may need to be able t Fuzzy logic is a mathematical approach for simulating human-like
to generate and rank many possible solutions. reasoning and control. Consult Ref. 2 for further information.

156 JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 16, NUMBER 2 (1995)
 TOM AHA WK STRIKE MANAGEMENT

for a missile going to a specified aimpoint to minimize w(i) is a weighting factor based on the priority of
the probability of collateral damage and maximize the aimpoint i, and
probability of hitting the desired target. The Laboratory
E is the expectation operator.
is developing a general algorithm for computing the hit
probability that uses more sophisticated parallelepi-
The same method of control would not have to
peds, instead of polygons, to model the target area.
govern all scenarios. A strike control doctrine could
The three decision aids developed for the functional
invoke various methods of control for different situa-
prototype provide the operator with vital assistance in
tions. For example, control by negation might apply to
controlling and monitoring strike progress. Both the
recovery from missile failure, whereas positive control
aimpoint coverage and strike effectiveness aids have
would apply to all other situations. Reallocation situ-
been integrated with the prototype. An independent
ations, other than missile failure, might arise through
program implements the hit probability algorithm.
assessments by the TSC. The operator might decide to
Eventually the hit probability decision aid will be in-
flex all missiles away from an aimpoint on the basis of
corporated into the functional prototype and may con-
damage seen in missile imagery. The prototype would
tinue to be developed as a stand-alone system for use
compute flex actions to redistribute missiles to remain-
with the current Tomahawk arsenal.
ing aimpoints. Under positive control, the TSC would
These decision aids set the foundation for additional
then select the option to execute.
refinements that will allow a deeper exploration of
Both the Macintosh and NEXTSTEP strike manage-
operator support concepts. For example, we expanded
ment prototypes process a limited scenario incorporat-
the degree of operator control over the flex capability
ing relatively few TBIP missiles, launch platforms, and
to permit examination of the level of control appropri-
targets. The three decision aids were developed to
ate across a range of operational conditions. The initial
support this limited scenario. Nonetheless, these algo-
control method for the aimpoint coverage decision aid
rithms, as noted earlier, may provide a basis for devising
used positive control in which the functional prototype
and implementing expanded capabilities that will ac-
computed and recommended actions but did not exe-
count for the full range of operational functions and
cute without explicit operator approval. A manual
considerations (e.g., a modified aimpoint coverage al-
control capability to allow the TSC to divert any
gorithm will need to account for large strikes consisting
missile to any alternate mission available to that missile
of a mix of current generation missiles and advanced
has been added (see the middle window in Fig. 6).
TBIP missiles).
Under manual control, the system does not provide any
The expansion of strike control capabilities in the
recommendations; it merely issues missile commands
prototype will enable our sponsors to address other
according to the direction of the operator.
challenges facing future Tomahawk employment. Com-
Progressively more automatic control modes will
ponents of the functional prototype are being integrated
also be introduced. In passive control, the prototype
into a demonstration of Tomahawk satellite communi-
will compute and recommend strike actions and then
cations to be conducted at the Laboratory during 1995.
automatically carry out the highest-ranking action
The demonstration will show two-way communications
unless overruled by the operator. This level of control
between strike management and missiles represented by
might be appropriate for recovery options to high-
the simulation driver. An important objective of this
priority aimpoints or when the missile is close to the
demonstration is to define techniques for dynamically
branch point between two missions.
assigning missile communication schedules that are
The final level of control is automatic control. In
fully coordinated with the strike management's percep-
this mode, the strike management prototype will con-
tions. Also, through Independent Research and Devel-
tinuously evaluate and execute strike actions to opti-
opment funding, APL has developed Phase I of the
mize some measure of effectiveness without any oper-
Precision Integrated Strike Concept Evaluation Suite
ator intervention. One such optimization might be to
(PISCES) to connect various Tomahawk-related simu-
minimize the mean square error between tasked and
lations resident at the Laboratory into a distributed
expected probability of damage, weighted by aimpoint
simulation capability. Although currently internal to
priority (i.e., for each aimpoint i), as follows:
APL, PISCES adheres to Distributed Interactive Simu-
min E{w(i) [PDE(i) - PDT(i)FJ , lation standards and protocols to allow future examina-
where tion of strike management in more complex operations.
The Laboratory is also preparing the strike management
PDE(i) is the probability of damage expected at prototype for a more operationally representative assess-
aimpoint i, ment of usability and operational utility. Prospective
PDT(i) is the probability of damage tasked at operators will employ the prototype to manage more
aimpoint i, realistic and complex strike scenarios to confirm useful

JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 16, NUMBER 2 (1995) 157
M. D. Lo PRESTO ET AL.

support concepts, suggest enhancements, and identify prospective operators have verified the potential ben-
missing capabilities. efits of the proposed new Tomahawk strike manage-
Some aspects of the functional prototype may also ment functions and helped to identify and prioritize
benefit current Tomahawk employment. The strike additional capabilities. Several features, such as the
summary window at the bottom of Fig. 6 includes a hit probability algorithm and the missile progress dis-
timeline to compare planned missile time of flight with play, that could be of use in the current Tomahawk
reported progress. The timeline begins at the planned system have been identified during these demonstra-
time of launch and ends at the projected time the tions. The development of prototypes as part of the BG
missile will reach the target. Such a display will help STC initiative has assisted the PEO(CU) not only in
decision makers evaluate coordination of launches and solidifying the strike management concept but also in
arrivals. This display could be extended to provide a adapting it for near-term initiatives such as the Tom-
strike planning tool for developing launch sequence ahawk In-Flight Position Reporting System, a tracking
plans. system to be installed in some operational Tomahawk
missiles.

CONCLUSION REFERENCES
The prototype development effort has shown that 1T omahawk Land Atu.u:k Missile (TLAM CID) Employment Manual, Naval
Warfare Publication 3-03.1, Naval Doctrine Command, Norfolk, VA (1994).
strike management can be straightforward if operators 2Quaranta, T. F., "Fuzzy Systems for Simulating Human-Like Reasoning and
are provided with the proper tools. Demonstrations to Control," Johns Hopkins APL T ech. Dig. 16(1), 43-58 (1995) .

THE AUTHORS

MARK D. LoPRESTO received a B.S. degree in systems engineering from

the U.S. Naval Academy in 1982 and an M.S. in electrical engineering from
The Johns Hopkins University in 1989. He joined APL in 1987 after 5 years
as a Surface Warfare Officer in the Navy and is a Senior Staff engineer in
the Surface and Strike Warfare Systems Engineering Group of the Fleet
Systems Department. In 1991, Mr. LoPresto assumed his current position as
technical lead for the Battle Group Strike Warfare Coordination initiative

,
of the Navy's Tomahawk program. His recent efforts have involved
developing functional prototypes, including Tomahawk Strike Management,
for use in the Tomahawk Baseline Improvement Program. In addition, he
/ has been supporting an Independent Research and Development project to
provide a distributed simulation capability for evaluating advanced precision
strike concepts. His e-mail address is [email protected].

ANN F. POLLACK received a B.E.s. in electrical engineering and an

M.S.E. in computer science from The Johns Hopkins University in 1988.
She joined APL in 1988 and is a Senior Staff engineer in the Surface and
Strike Warfare Systems Engineering Group. Ms. Pollack has worked
primarily in the Tomahawk program, performing a variety of systems
engineering tasks. Most recently she has served as the lead engineer for
Tomahawk deconfliction (eliminating conflict between Tomahawk missiles
in flight). She has continued her education, earning an M.S. in electrical
engineering from The Johns Hopkins University in 1991, and is currently
pursuing a Ph.D. in computer science from the University of Maryland,
Baltimore County. Her e-mail address is [email protected].

158 JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 16, NUMBER 2 (1995)
 TOMAHAWK STRIKE MANAGEMENT

JOHN FLORENCE received a B.S. in mathematics from West Chester State

University of Pennsylvania in 1966, an M.S. in operations research from
George Washington University in 1972, and an M.S. in computer science
from The Johns Hopkins University in 1987. Before coming to the
Laboratory, Mr. Florence developed simulation models for the U.S. Army
and numerous private businesses. He joined APL in 1985 and is a Senior
Staff mathematician in the Surface and Strike Warfare Systems Engineering
Group who has specialized in software engineering, simulation, modeling,
and analysis. His current efforts include developing object-oriented simula-
tions to support prototype development and distributed simulation capabili-
ties at APL. His e-mail address is [email protected].

ROBERT C. FERGUSON received a B.S. in electrical engineering from

Cornell University in 1984 and an M.S. in electrical engineering from
Purdue University in 1985. He joined APL in 1986 as a member of the
Strategic Systems Department, where he contributed to Trident II missile
accuracy analysis. In 1989, he became a member of the Fleet Systems
Department and contributed to the Aegis and Tomahawk programs by
developing correlator/tracker algorithms for the Aegis Anti-Air Warfare
Correlator/Tracker and performing system analysis for the Tomahawk
Baseline Improvement Program. Currently, Mr. Ferguson is participating in
Tomahawk deconfliction analysis and data fusion efforts for the E-2C
program. His e-mail address is [email protected].

IAN E. FELDBERG received a B.S. in electrical engineering and computer

science and an M.S. in computer science from The Johns Hopkins
University in 1984 and 1987, respectively. Mr. Feldberg joined APL in 1984
and is a Senior Staff engineer in the Surface and Strike Warfare Systems
Engineering Group. He has contributed to a variety of software projects,
including computer animation for simulation, machine vision and machine
learning research, and biomedical research. He became a member of the
Fleet Systems Department in 1993, primarily in support of the Tomahawk
program, and has served as the principal software engineer for the
Tomahawk Terminal Fratricide Visualization. Mr. Feldberg is the principal
software engineer for Tomahawk strike management proto typing efforts as
well as technical consultant for the Synthetic Environment Workstation, an
Independent Research and Development project coordinated through the
Research Center. Mr. Feldberg is pursuing a doctorate in computer science
with specialization in machine learning and synthetic environments. His
e-mail address is [email protected].

JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 16, NUMBER 2 (1995) 159