The Tactical Tomahawk Weapons Control System:
Interface Design Project
Student Team: Julie Besselman, Meredith Logsdon, Brian Whisnant, Timothy Yewcic
Faculty Advisor: Dr. Stephanie Guerlain, Department of Systems and Information Engineering
Graduate Student Advisor: Robert Willis, M.S. Student, Department of Systems and Information Engineering
Client Advisors: Bruce Copeland, Wayne Harman, Bob Athay, and Alan Thomas
Naval Surface Warfare Center
Dahlgren, VA
KEYWORDS: Cruise missile, interface design, situational awareness, cognitive task analysis, and usability testing.
ABSTRACT
Scheduled for deployment in 2003, the Tactical Tomahawk cruise missile represents a qualitative leap forward in long-range ‘smart’ weapon technology. The weapons control officer will be able to retarget these missiles during flight by directing the missiles to strike time-critical, emergent targets within minutes of their appearance. Other new capabilities include battle damage assessment and the capacity to plan missions onboard the launching ship or submarine, further increasing the flexibility of this new weapons system.
The objective of our Capstone team was to design a prototype of the computer interface that an operator of such a system would use to monitor and control the cruise missiles. We conducted extensive research into situational awareness and interface design techniques as we formulated our list of functional requirements and developed our interface. Based on our design, we created an interactive computer program that we used to conduct usability testing on 20 subjects from a systems engineering graduate class. The program simulates a battle situation, and the subjects interacted with the interface to gather information about what was happening and to make decisions based on that information. We modified several variables during each hour-long test, including changing the total number of missiles and targets on the screen at once as well as turning on and off a feature that graphically displayed the range of each missile.
Though the focus of our project was the development of the interface and the design of our usability test, we were able to draw some valuable conclusions from our test data. Our work is intended to be a firstiteration, andthe test results should be used to make improvements to both the interface and the testing method itself.
INTRODUCTION
The goal of this Capstone project was to develop and test an interactive prototype of a weapon control system interface for the new Tactical Tomahawk cruise missile. Unlike the current missiles, which operators program before launch, the next generation Tactical Tomahawk will have retargeting capability, giving it the ability to loiter in enemy territory and then quickly strike an emergent target wherever it may appear.
The implementation of this tactical retargeting feature will not be complete until the interface for operating its control system has been established, designed, and built. The Navy has contracted Lockheed Martin to build the software applications that will connect the missiles to the control system guidance system, and other subsystems (Willis, 2000). As a separate venture, the task of this Capstone team was to determine how to best design a weapons control system interface for the Tactical Tomahawk cruise missile.
The goals of this project were to:
Design, develop and test interface concepts for the US Navy’s Tactical Tomahawk cruise missile operator interface.
Provide specific display recommendations to the Naval Surface Warfare Center – Dahlgren Division (the client) for use in future contracted TTWCS user-interface development.
Recommend the appropriate level of automation to minimize mission execution time while maximizing operator situational awareness
BACKGROUND
The Tomahawk cruise missile saw action for the first time in 1991 in Operation Desert Storm. It immediately proved itself as an effective tool for precise, deep strike missions and has since seen action in regional conflicts in Afghanistan, Sudan, and Serbia (Sanders, 2000; “U.S. Navy,” 2000).
Current Tomahawk missiles are programmed and launched with a predetermined flight path and target. The missile can be launched from either a ship or a submarine and has a range of over 800 nautical miles (“U.S. Navy,” 2000). Once over land, its guidance system computer compares the surrounding terrain with the maps in its memory to keep the missile on the correct course (See Fig. 1). After launch, the operator cannot control the missile and only receives information via the Tomahawk In-flight Position Reporting System (ORD, 1998).
The new Tactical Tomahawk Weapons Control System (TTWCS), which is not yet operational, will improve upon this successful design by adding some powerful capabilities. The new missile will have the ability to be retargeted while in flight, making it capable of striking an emergent target of opportunity that may not even appear until the missile is actually airborne. The operator will be able to keep missiles in ‘loiter’ patterns over enemy territory until emergent targets appear, giving the Navy the power to strike an emergent target within minutes of its initial appearance. It will be possible for the operator to plan missions from the launch platform. Presently, mission plans are created at headquarters in Norfolk, VA or Pearl Harbor, HI, and then transmitted to the ship or submarine. In addition, the new missile will periodically relay missile status details to the weapons systems operator, giving him or her the information required to effectively control the missiles in real time (Sanders, 2000).
With its increased capabilities, the proposed system places much greater responsibility on the weapons systems officer controlling the missiles. The system must provide the operator with a wide range of information, including information on the position, range, and warhead of each missile as well as current and projected positions for the different types of targets. These will all be factors needed to decide which missile should be assigned to which target and when. The system creates the need for a weapons control interface that will allow the weapons officer to comprehend the complex arena of combat and make decisions quickly and effectively.
The existing hardware, a workstation with a keyboard, trackball, and two 19” monitors will be used with the new missile, and we have designed our interface accordingly. Our Capstone team has done the necessary research, design, and testing to develop an interactive interface prototype that answers the question: how can a single interface be created that allows the weapons control officer to operate these missiles effectively?
RELEVANT THEORY
Although no standard guideline exists for interface design, methodologies for human-computer interface design are often based on principles from several fields of study including situational awareness and cognitive science. These general principles are helpful for understanding the basis of many of the TTWCS interface design decisions.
Situational Awareness
Situational awareness (SA) is a term originally used only by the aircraft community to represent a pilot’s ability to correctly perceive the state of his environment while utilizing flight automation tools. However, SA has become a field of study that pertains to many different systems with varying levels of automation. Situational awareness is defined as “the perception of elements in a [dynamic environment], the comprehension of their meaning, and the projection of their status in the near future”(Endsley, 1995). This is of particular concern to automated, dynamic systems because the removal of operators from physical contact with the process may diminish the accuracy of their perceived system-state [Moray in Endsley article]. In other words, as the system automates or internalizes some of the operator’s tasks, the operator loses touch with what is happening within the system.
Endsley believes that “at a minimum, the [interface] design process should include steps to ensure that needed information is always present regarding the state of automation and the state of the parameters being monitored in a clear, easily interpreted format.” It is important to note that the automation of some tasks can benefit system performance by decreasing the mental workload on the human operator. The key issue (as it pertains to interface design) is to make sensible choices regarding the allocation of functions between the human operator and computer automation.
Cognitive Task Analysis
Cognitive Task Analysis is a relatively new branch of applied psychology that has recently been utilized in the development of expert systems, system training, expert decision-making, and policymaking (Chipman, 2000). It is a broad area of study consisting of tools and techniques for describing the knowledge and strategies required for task performance. This is extremely pertinent to the design of this interface because new TTWCS operators will have to perform tasks (involving knowledge and strategy) not familiar to the old system. While the system must provide the functionality for performing these new tasks, it must also support/aid the cognitive or mental work that the operator will undertake while interacting with the system. The field of Cognitive Task Analysis focuses on issues such as identifying and supporting these responsibilities.
APPROACH
Our approach to this project had four distinct phases (see Figure 2).
The first phase was a Domain Analysis of three primary domains: interface design principles, the TTWCS system properties, and the larger context of air campaign command and control. Second, potential scenarios were developed to identify functional requirements. Next, interface components were developed and synthesized into a prototype. Finally, Subject Testing and Analysis were conducted.
Domain Analysis
There are three basic types of Tactical Tomahawk missions. The class of the target to which the missile is assigned defines the missions. Target classes (and thus mission types) include default, flex, and emergent (or d-, f-, and e-targets). A missile is launched along a path initially toward its d-target. While en-route, the operator can command the missile to abort its default mission, and execute one of several preprogrammed flex missions. The operator can also respond to the appearance of an e-target by rapidly programming and transmitting a completely new route and aimpoint.
As a retargetable system, TTWCS brings the cruise missile into the realm of on-call weapons available to an air campaign or ground commander for destruction of time-critical targets (Scott, 2000). In the context of the doctrinal Decide, Detect, Deliver targeting process, the TTWCS display development must therefore consider from whom a call for a fire or attack order is received, and in what format. A central assumption for this project is that an attack order from a targeting center specifies the “what, where, when”, while the TTWCS operator and/or system decides “how” (with what missile(s)). There must be a two-way communication link to provide feedback to the targeting center specifying any targets that were given up as an opportunity cost for servicing an unplanned emergent target. Further, the development of the displays also addresses the likelihood of the targeting cell “asking” if a vessel could accomplish a certain mission. The displays must therefore facilitate rapid analysis of “what-if” scenarios to determine the acceptance/rejection of a possible time-critical mission.
Initial products from the Domain Analysis phase include a formal list of objects, properties, and values that are inherent in the system. Objects and properties include Targets, Missiles, Airspace Constraints and Threats, Vessels, Missions, Campaigns, and BattleGroup.
Scenario Development
Following the object definition, a description of seven possible scenarios led to the development of a formal set of interface functional requirements. The scenarios also facilitated the identification of operator information requirements. A sample scenario was:
“Three inflight missiles are along separate routes prior to the branch points for a common flex target. The operator receives the command to service the flex target as well as a new emergent target that is within range of two missiles. Priorities of all targets are known, and the expected move time of the e-target is given. Select the best course of action.”
Other scenarios included interaction with no-fly zones, targets requiring multiple missiles, multiple simultaneous emergent targets, and targets closer to a vessel than an in-flight missile.
Interface Design and Prototype Development
A systems approach as described in Gibson (1991) was applied to the development of several levels of prototypes. The system was first reduced to its components, and then was built up iteratively into system prototypes of increasing fidelity. Static, non-interactive Power Point slides were used for cognitive walkthrough purposes (Kellmeyer & Osga, 2000). The rapid prototyping iterative process progressed through scripted “movies”, and into static yet interactive slides to demonstrate basic system display functions. A design document was submitted to several professional graphic designers and multimedia producers, and Creative Perspectives (Charlottesville, Virginia) was selected to code a dynamic and interactive Version 1 prototype suitable for subject testing in the near-term, as well as a Version 2 incorporating subject testing results and a more deliberate graphic design effort. Macromedia Director 8 was selected as the prototyping software.
Components
The previously defined objects and functional requirements were combined to create component prototypes. Initially, prototype concepts were developed that addressed component processes of the total system. The most basic types of components are the symbols used to represent the individual missiles and targets. To the greatest extent possible, the symbol development is in accordance with Department of Defense common interface symbology (Mil Std-2525B, 1999). Examples of several target and missile symbols are shown in Figure 3.
Requirements for subsequent components were made clear in the analysis of other scenarios and their functional requirements. For example, the previously described scenario requires an interpretation of the missiles with respect to time, and requires the operator to rapidly evaluate the problem, reduce and compare options, and make a decision. The missile-time component prototype shown in Figure 4 maps object properties into a graphical feature for a missile assigned to an emergent target. This missile-time component would be multiplied for each candidate missile. (See Figure 4)
Coverage Zones are a third key component in the prototype. Coverage zones are missile-time-space representations that simply show a radius of action on the map for each missile in a specified time factor. The time factor is selected by the operator, and can vary at 30, 20, and 10 minutes, as well as any specified numerical value. Other interface components include missile routes, missile-target assignments, airspace control measures, and threats.
System Prototype
While the design document describes a two-monitor interface consisting of a predominantly text data display separate from a predominantly graphical situation display, the Version 1 Director prototype which was complete for our usability test consists of one monitor with a small message window, as shown in Figure 5. The prototype architecture enables the programming of new scenarios (number of missiles & targets, waypoints, messages, etc.), and continuously updates all the geometric, trigonometric, and physics expressions inherent in the system, with the exception of missile altitude and dive angle.
USABILITY TESTING
The final phase of the project was to conduct usability testing of the interface design. The subjects were systems engineering graduate students, and received two 75-minute training sessions to familiarize themselves with the system. During testing, the subjects monitored and redirected the airborne missiles, responding to message requests and changes in the tactical environment. We varied two major aspects of the scenario with different subjects: the number of objects on the screen at once (missiles and targets) and the presence or absence of ‘coverage zones’ (a circle that was attached to the onscreen missile as it flew, representing the area that it could cover in a given period of time). When an emergent target appeared, we also varied the number of missiles that were candidates for attacking the new target. Each scenario had either 10 or 20 objects, and only half included the coverage zone feature. A spilt plot experimental design was followed, such that different combinations of these variables were assembled and given to each subject in such a way that statistical conclusions could be drawn from the results. The hypotheses for the tests were that response time and accuracy would suffer when more objects were present, and situational awareness would increase with the presence of the coverage zones due to the utility of the function.
There were eight different possible test scenarios, each incorporating a different combination of the experimental variables. There was a separate Multimedia Director ‘movie’ for each scenario, and each subject ran through three of these movies. A testing block was approximately one hour long, including a 10-minute review period, three 12-minute scenarios (the first one was practice, though the subject did not know this) and a 15-minute post-test survey. A total of 20 subjects were tested over three days, and a test administrator and assistant were present to record answers and response times.