INAUGURATION Day is fast approaching, and the Secret Service is planning the protection of the President. He will be taking the oath of office, speaking before a huge crowd, and walking or riding down wide streets lined with people. Planning such an event has always been a major undertaking, but it is complicated today by the growth of terrorist activities. The Secret Service must make many decisions--how large a security force to use, where individuals should be located, where temporary fences or other barricades should be constructed, the likeliest sources of sniper fire and other attacks, and to which nearby buildings should access be restricted.
In April 1996, the Secret Service contacted Lawrence Livermore National Laboratory's Conflict Simulation Laboratory asking to use their JTS (Joint Tactical Simulation) system for inaugural planning. By portraying various scenarios using JTS, the Secret Service can watch each scenario unfold on-screen and quickly analyze security tactics and options, rehearse the event so that there will be few surprises, and train its officers and other leaders to conduct the operation effectively.
JTS and other computerized conflict simulation systems were originally designed for the military for battlefield exercises. After these programs became popular, organizations responsible for site security, disaster relief, and hostage rescues recognized their usefulness. More recently, state and local governments have become interested in using simulations to plan police raids, drug interdictions, fire fighting, crowd control, and prison riot control.





LLNL's Pioneering Work
Well into the 1970s, the principal tool for simulating battle and conducting "what-if" scenarios was the "sand table." This was a large surface dotted with tiny trees, rivers, and towns where model tanks, soldiers, and other accoutrements of battle could be deployed and moved about to simulate military maneuvers. Sand was often used to form the terrain, hence the term. But sand tables were an imperfect way to portray war games because they were an open system--both sides could see each other. Lines of sight were determined by running a piece of string between two points, and decisions about the outcome of a conflict were decided by tossing dice.
Livermore's involvement in combat simulation was born in 1973 when Laboratory scientists began studying the battlefield utility of recently developed tactical nuclear weapons. They needed something better than a sand table to graphically portray potential uses of these weapons and the ramifications of their use. Out of this need came Janus, a two-sided, interactive, conflict simulation program named for the Roman god of portals who had two faces to look in two directions at once. Written in FORTRAN and running on 16-bit computers, Janus was one of the first simulation programs to feature player input and output using an interactive graphical user interface. Scientists and battle planners finally had a realistic, digitized battlefield map with movable, changeable icons. (For reference, Janus was developed at about the time that "Pong," the first interactive computer game, became popular.)





An early version of Janus was transferred to the Army in 1983 while Livermore continued to refine it. In the mid-1980s, 32-bit microprocessors were adopted and the design was modified to support asynchronous operations, a more flexible programming system that allows a program to be interrupted and/or extended. Incorporating high-resolution graphics, distributed processing, and real-time play, Janus could be used for combat and tactical processes from the squad to brigade level. In 1991, the Army took over full responsibility for Janus.
On December 20, 1989, 20,000 U.S. troops invaded Panama and overthrew the dictatorship of General Manuel Noriega. Prior to the invasion, the U.S. Army used Janus as an operational planning tool. During a full day of simulations, it became clear that the planned placement of one platoon prior to the outbreak of hostilities caused a delay in arriving at a company's fire support position, so the platoon's position was changed. A later poll of battalion and company leaders revealed that the war games may have saved lives during the invasion and ensuing battle--a significant accomplishment for the first known use of a computerized, interactive, force-on-force war game prior to an actual battle.1

Why Use a Simulation?
The experience with the Panama invasion makes clear the benefit of conflict simulations prior to a battle. But multisided, interactive simulations allow fast, cost-effective planning, evaluation, and training for almost any endeavor that involves multiple persons or agencies working together for a common goal. Simulations can assist with resource allocation and scheduling, coordination in and between agencies, management decision-making, procurement planning, and tactics. Simulations of a conflict are also valuable tools for apprising staff and others of the current situation while the event is under way. Simulations of what actually occurred are also frequently used for after-the-fact analysis of an event.
For military training, simulations are particularly useful now because military organizations can afford fewer training hours and smaller expenditures during field exercises. As the military moves into nontraditional missions such as large-scale evacuations, peacekeeping, and famine relief, simulations help to train military leaders without a large investment.
These simulation programs are not intended to train individual soldiers or other participants in a conflict; rather, they train the mission leaders. By participating in different scenarios, leaders learn how to respond to a wide variety of situations.






JTS Is State of the Art
Livermore's Conflict Simulation Laboratory (CSL) was established in 1974 to develop simulation programs such as Janus. After Janus attracted the attention of the Army, the CSL was asked by several other organizations to expand upon Janus's capabilities.
For the Department of Energy, the CSL developed a system to evaluate the effectiveness of site security and to train security personnel. Over the next several years, various iterations of this system, for the U.S. Air Force Security Police Agency, the Berlin Brigade, and U.S. Army Europe, were created and ultimately merged in the single system known today as the Joint Tactical Simulation (JTS) model, which is being used by the Secret Service for inaugural planning. JTS simulates conflict in both urban and suburban environments and in building interiors.
JTS is constantly being updated to incorporate new features, and new versions of the system are released about every six months. The latest release was delivered in September 1996.
JTS can be applied to a battalion-level battle as well as to the defense of an individual building or site--in other words, JTS can be used to plan a large engagement or the rescue of a single hostage. The design is compatible with modern conflict simulation standards, including the Distributed Interactive Simulation protocol, that allow interaction with other simulations, human instrumentation systems, and a variety of vehicle and aircraft simulators.
JTS is used today by military and DOE organizations for security assessments of U.S. and NATO military bases and DOE sites. It is also used by the Army in Europe for large-scale combat modeling and leadership training. In advance of U.S. involvement in Somalia, the Army used JTS to analyze terrain at the Mogadishu airport in order to select appropriate guard tower heights, identify the least vulnerable areas for civilian shelters, optimize sniper placement, and find the safest take-off and landing paths at the airport. In 1995, prior to our present involvement in Bosnia, the Army used JTS to run "what-if" scenarios for sending troops overland to Sarajevo from the sea. They identified bottlenecks in the mountainous terrain and simulated probable ambush locations.
JTS is an entity-level simulation, which means that it explicitly models an individual howitzer, plane, ship, or soldier. It can handle force sizes from 2 entities to 2,000.
JTS is one of the few programs to simulate night and adverse weather operations, with area lights and spotlights that can be turned on and off as needs require. Terrain features such as buildings, roads, rivers, fences, and vegetation can be modeled down to the nearest 10 centimeters. Underwater obstacles and river currents can also be modeled.
JTS is also rare in that it addresses direct-fire fratricide, the killing of friendly forces by directly firing on them, usually with small weapons. (This contrasts with indirect-fire fratricide, which occurs when large-weapons fire is aimed at an area about which the shooter has minimal information. Many simulation models address indirect-fire fratricide.) Even with the best of information about where enemy and friendly forces are located, direct-fire fratricide does happen in the confusion of battle. But it has traditionally been difficult to model because of its sensitivity and lack of available data. With JTS, the user may establish how and where direct-fire fratricide might occur through a simulation.

Using JTS
A JTS simulation session might involve as few as 2 terminals or as many as 40, each viewing a different part of a battlefield. There can be as many as ten sides represented in the conflict simulation, each represented by a set of workstations networked together. A conflict is usually thought of as having two sides, but civilians and other players may be treated as one or more neutral sides.
The JTS system database stores extremely detailed information on every facet of a conflict--weapons, munitions, sensors, groups of soldiers, types of missions, observers, vehicles, security systems, and others. For example, the database stores approximately 150 pieces of data on a typical engineering squad, including the time it takes the squad to get into and out of trucks, the types and numbers of weapons available to the squad, and the time it takes the squad to dig foxholes, penetrate wire barriers and rubble, and perform other engineering tasks. User organizations construct this huge database, and they may add and modify information as needed.






For a particular simulation, its planners select appropriate people, weapons, vehicles, etc., from this database. For analysis of security at an embassy, the numbers selected might be relatively small. Operational planning before the Panama invasion would have required the database to include thousands of soldiers in various configurations, as well as large numbers and many types of weapons, munitions, vehicles, tanks, helicopters, planes, and the like.
Before the start of a battle scenario, planners decide the parameters: they decide the location, the weather, the local civilian situation, when and how the battle will begin, and the makeup of the various sides; they select initial routes and speeds for vehicles and people; they determine where, when, and what kind of reinforcements will be dropped off. An almost infinite number of variations are possible. Later, when the scenario is being played out, these variables may be changed as requirements demand.
JTS allows for a simulation area as large as 6 degrees of latitude and longitude, the equivalent of 660 by 660 kilometers. Any user may view the entire playing field during a scenario, although each player can only view forces that have been acquired by the assets he or she controls. A high-level mission leader may choose to view the entire playing field, while a lower level player responsible for maneuvering specific forces will likely zoom in for a more detailed view of a smaller area.
The workstation screens show such features as topography, vegetation, built-up areas, roads, rivers, ocean depths, building floor plans. Vegetation appears on the screen in various colors, differentiated not by type but by penetrability, visibility, and ease of movement, which are what matter to a person or vehicle trying to move around on the ground or to a plane flying overhead trying to see those people and vehicles.
Lines of sight are constantly being determined as soldiers and vehicles move on and over the terrain. As an aircraft or other vehicle moves over long distances or comes into the area of another friendly player's forces, its tactical control may be transferred from one terminal to another. Intelligence reports pass back and forth between terminals by telephone or other real-world communications media as users report that an enemy tank unit has appeared or that a company in their area is being fired upon.
In a small-scale simulation (of a hostage rescue, for example), the locale might be a city with low-rise and high-rise areas; an airport; a river; many narrow, winding streets; and numerous bridges, in addition to an unfriendly civilian population. During the scenario, a user might zoom in on a multistory building and see individual soldiers and civilians moving around inside it.



JCATS Innovations
The Conflict Simulation Laboratory is currently developing for the Joint Chiefs of Staff a new, more broadly useful simulation system known as the Joint Conflict and Tactical Simulation (JCATS). More detailed than JTS, JCATS increases the number of entities that can be handled in a simulation from 2,000 to 60,000. The first version of JCATS is due to be released in 1997.
JCATS will incorporate a unique experimental feature that allows a user to "aggregate" entities into a group to be moved, viewed, and controlled as one icon and then "deaggregate" the group back to the entity level for detailed operations. A user will thus be able to manage a large number of entities on the battlefield and play a very detailed, high-resolution game in specific areas without high-end computers or large numbers of players.
This aggregation/deaggregation feature will help to control the cost of training exercises, but it is requiring the CSL to meet a major challenge. When a unit has been aggregated to include a variety of unlike entities such as riflemen, scouts, tanks, trucks, and other vehicles, how does the unit behave? The aggregated unit "inherits" some behaviors from its component parts, but other behaviors change when individuals become part of a group. For example, the group moves at the speed of the slowest individual, and there is little truly independent behavior in a group. These and other changes in behavior are being considered when defining aggregated unit behavior.
JCATS simulations include more realistic graphics, especially for visualizing activity inside a multistory building or on complex terrain. Users will get a three-dimensional look at activity inside a building without significantly slowing down computer processing.
JCATS will be the only entity-level model to show detailed, high-resolution amphibious operations and other aspects of sea-coast warfare, a particularly useful feature for the U.S. Marine Corps and the Navy.
Another unique feature will be the establishment of a "matrix of relationships" among the various players in a simulation. In a multisided conflict, there can be friends, enemies, and neutral players. A group of "friends" may form a coalition and function as a single "side." But at some point during a simulation, the coalition may break down, causing a former friend to become a neutral player or even an enemy. There may also be guerrilla troops who are on one side during part of the scenario and then defect to another side. JCATS will be able to accommodate these fluid relationships.
Military personnel will be able to use JCATS as a training tool while working at their own real-world equipment rather than at a computer terminal. For example, simulation data will be fed into shipboard equipment, and sailors and officers will respond to it as though it were the real thing. While JTS and other programs have been used in conjunction with vehicle and flight simulators, this use of a simulation program with real equipment will be a first.





Future Work for the CSL
Livermore's Conflict Simulation Laboratory now has over 20 years of experience in developing and deploying systems such as JTS and JCATS, working closely with the relevant branches of the military during all phases of each project. Upon its release next year, JCATS will be the cornerstone of the Joint Chiefs of Staff's battalion, brigade, and lower-level training programs until the Joint Chiefs bring the Joint Simulation System (JSIMS) on line in 2003. Lawrence Livermore will likely be a technical advisor for the development of JSIMS.
The CSL has already begun working on additions to JCATS that will appear in later versions of the model. In particular, the CSL aims to fill a major gap in modern conflict models, which is that none accurately models the impacts of information warfare. The capability to handle information warfare attacks is a significant challenge because communications and control systems are currently implicit in simulation programs and assumed to be perfect. This new modeling capability will include an interface with operational command, control, computers, communications, and intelligence (C4I) systems. Other changes will include increasing the size of simulated scenarios and adding an ability to develop a software architecture in the future to take advantage of new computer networking and computing technologies as they arise.
After its release, JCATS will be used as a test bed for JSIMS concepts and will be integrated into the JSIMS architecture. Through these activities, the CSL staff will continue to stay in the forefront of conflict simulation technology.

Key Words: conflict simulation, Janus, Joint Conflict and Tactical Simulation (JCATS), Joint Tactical Simulation (JTS).

Reference
1. Evaluating the Use of Janus as an Operational Planning Tool in Operation Just Cause, The Titan Corporation, Olympia, Washington, June 1991. (Subcontract B098749).

For further information contact Diana Sackett (510) 422-1671 ( dsackett@llnl.gov).


DIANA E. SACKETT joined the Laboratory as a computer scientist in 1975 after having received a B.S. in mathematics from Occidental College in 1974 and an M.S. in mathematics from Stanford in 1975. She has worked on a variety of scientific and engineering computing projects since coming to Lawrence Livermore. She is currently the Associate Division Leader for Modeling and Simulation in D Division and is head of the Conflict Simulation Laboratory.






Back to November 1996