The Joint Theater Level Simulation (JTLS) is a NASA equivalent Class C system, developed on a short schedule as a proof of concept system for the support of Thea- ter Level Command Post Exercises (CPX) and Field Training Exercises (FTX).
JTLS supplemented the FTX with realistic data supplements to aid in the training of Theater and Army staffs in the performance of their staff duty assignments in time of war. Additionally, it was designed to permit the Theater and Army staffs to gain insight into strategic realities and operational trends in a fluid combat envir- onment, both as a learning tool and as a planning tool.
Software Development Standard: None used. The system was the first of its kind, and the sponsoring organizations had no one who understood DOD-STD- 2167A at that time.
Documentation: Nonstandard. Little time was available to field the system, with the immediate involvement of numerous ‘‘stakeholders.’’ All architectural design documents were discarded because of the lack of customer familiarity with compu- ters (a typical problem with armed forces personnel at the time). We designed a Functional Design Document (FDD) and a User Analyst Guide (AG), done by Dr. Joseph P. Fearey. The system was a proof of concept where the tactical and tech- nical expertise was at JPL. The documentation totaled approximately 5,000 pages.
System Size: Approximately 120,000 source lines of code, 180,000 total lines of commented code.
Languages: SIMSCRIPT II.5, the C programming language, and INGRES.
Total Cost: $7,800,000.
Cost/Line of Code: $43.35 per commented line of code.
System Description: JTLS was a ‘‘first of its kind’’ attempt to use computers to transliterate realistic combat events at the war theater level into useful and under- standable information, for the use of staff officers and commanders. This was done as a proof of concept. It started on a DEC VAX 11-780 and 8600 running VMS 4.1, and used VT-100 and VT-220 text terminals and Graphover 9500 graphics display terminals.
Note: As in all first of the kind prototypes, neither Dr. Joe Fearey nor I had the foggiest idea of how many ‘‘stakeholders’’ and nonperforming government agen- cies (well-funded agencies, without producing a product) there were in the ‘‘theater of operations’’ we had entered. These descended on us like a squadron of dive-bom- bers from the carrierKagaon the Yorktown at Midway. We had to work at a rate fast enough to deliver before they sank us for the same simple philosophical reason and phenomenon that Napoleon used so often: ‘‘A glutton will defend his dinner like a hero!’’
In the end, with the help of great contractors, JPLers, and consultants like Col.
Trevor Dupuy of treasured memory, we delivered. The system is, as far as I’m aware, still in use by the Pentagon, but not for its intended purpose. It was designed for theater warfare, as a staff exercise tool in support of the FTX, and not to detail combat events at corps or division.
However, it served its purpose in proving that combat operations, planning, and execution can be modeled effectively, and if well used can save lives and money.
This of course takes the human at his best. When people don’t use tools as intended, then it produces the wrong results.
The Joint Theater Level Simulation1was something that I had wanted to design and implement from the time I was serving in Vietnam. The concept (orBegriff,as the Kantian definition is more precise) started to take on substance while serving on the war planning staff at CINCLANT. It then took on the final object architecture in my mind during my three years at SHAPE. However, it was my experience on the Voyager Project at JPL that rounded out the concept of a war game. In particular, it was the way we used simulations like the command simulator (COMSIM) and sequence generation (SEQGEN) that synthesized with my experience at SHAPE and enriched the vision into a doable concept. I envisioned it as a driver for our large and very important Command Post Exercises of WINTEX and Able Archer.2
1The Joint Theater Level Simulation. JPL Highlights 1985. Jet Propulsion Laboratory, California Institute of Technology. Page 56 by S. Mike de Gyurky.
2WINTEX and Able Archer were the two major Tactical and Strategic Field Training Exercises (FTX), and Command Post Exercises (CPX) of NATO’s operations plan for the defense of Western (Allied) Europe against the Soviet Union and the Warsaw Pact. They were held annually and cost huge resources in the displacement of personnel and the preparation of manually generated exercise scenarios. These two FTX/CPX included countless military units from all NATO countries except France. They included all of the military headquarters from Supreme Headquarters Allied Command Europe (SHAPE) down to divisional levels, spanning from CINCLANT (Commander in Chief Atlantic) in Norfolk, VA, to CINCMED (Commander in Chief, Mediterranean Sea) in Naples, Italy, to Eastern Anatolia, and the North Cape. The preparation for and the execution of such a large military exercise cost huge resources in time and money. At the time I was assigned as Staff Officer for Command and Control Systems, to Colonel Joseph Bullers USAF (1976–1979), I had the additional duty of conducting the situation briefings to the SACEUR (Supreme Allied Commander Europe) and the NATO Secretary General.
In doing the requirements for and the design of the Allied Command Europe (ACE) Command, Control and Information System Architecture, I became very familiar with the physical system (manually used), the information handling, the data contents, and their use. I started to think about it, and developed in my head a concept for building a computer simulation to drive the FTX and CPX automatically and provide the participating staffs with realistic information and environment.
CASE STUDY ONE: THE JOINT THEATER LEVEL SIMULATION (JTLS) 203
My initial vision, or as Kant and Schopenhauer term it,Anschauung, was substantially different from what it finally turned out to be. There were several reasons for this.
I was too new to JPL to have a sufficiently large ‘‘wheelbase’’ (political pull, coercive power, authority) to exercise the kind of control I needed; later on I would have the approach to the detailed design, the development process, and the methodology for building the system. But this lack of authority also had a posi- tive side, because there was a most important object lesson for me to learn that otherwise would have eluded me. It was one of the most important lessons for me in my three decades of designing and building software-intensive systems.
This lesson became the most important driving force toward developing the common software services (CSS) layer. The lesson was learned on JTLS and imple- mented for the first time with GDSS, which immediately followed the completion of JTLS. The lesson learned was brought to its full sophistication much later on the Jason 1 Satellite Telemetry, Command, and Communications Subsystem in 2001.
This most important design lesson that I learned is the importance of modularity and layering of the software architecture. The technical term for this software is Common Software Services.
14.1.1 The Beginnings of JTLS
After completing my assignment as Team Chief of the Voyager General Science Data Team on the Voyager project in 1982, Dr. Joe Fearey and I wrote up a concept of operations (CONOPS) for a military exercise support system. We found a sup- porter of this concept here at JPL at the Assistant Laboratory Directorate level. At the time, we at JPL liked to do work on military programs. One reason was that JPL had started its existence as an Army ordnance laboratory before NASA came into being. Second, we experiment, develop, learn, and integrate many new technologies on defense programs, which we later use on flight projects. After a technology proved effective on a class B subsystem,3it was then adopted into our flight projects as proven technology. We also have an opportunity to push the technical envelope to the limit, which we cannot do freely on a flight project, because of the risk factor involved.
Once we complete a DOD project, and deliver the product, we do not maintain it. Upon delivery of the system to the customer, the customer turns it over to a con- tractor of their preference and we at JPL move on to other, one of a kind projects.
I traveled around with Dr. Fearey, looking for someone interested in developing a war gaming system. We found a sponsor at U.S. Readiness Command (now CENTCOM) at MacDill AFB in Florida. After completion, it was very well received and adopted by the Joint Analysis Directorate (JAD) of the Office of the Joint Chiefs of
3Class A systems are segments, the loss of which will have catastrophic consequences or result in the loss of a spacecraft.
Class B systems are segments, the loss of which will not have tragic consequences to a project or result in the loss of a spacecraft.
Class C systems are those systems that can be recovered and corrected, and then reset or placed back into duty.
Staff (OJCS) as the standard gaming system for joint and specified commands for the analysis of theater-level plans. JTLS was the first major piece of gaming software to become a part of the OJCS’s Modern Aids to Planning Program (MAPP).
Insightandunderstanding are not only philosophical terms, they are key con- cepts to event-driven interactive systems. Through the use of such systems as JTLS, a military staff can get a better understanding of the soundness of a military plan. Using a spacecraft and operations simulator, we can gain a better understand- ing of the status of new software before we uplink it to the spacecraft during cruise, prior to a planetary encounter.
Architecturally, JTLS was designed to provide its users with an environmental realism (user interface) similar to those encountered at the theater-level battle staffs of that period, where few, if any, staff officers of the combat arms were computer- literate.4 JTLS requires a minimum of three players: a Game Controller, a Red Team Commander, and a Blue Team Commander. The only computer users were located at workstation terminals, VT100s, at the Controller’s Team; these we called Systems Terminals. The messages to the Red and Blue teams to and from the com- bat forces simulated by the computer were provided through the Controller. Since the workload was very heavy, due to the message traffic from ground and air units, and could overwhelm players at high game speed, a limit of 26 players could be added as part of the Red and Blue Commander staffs. See Figure 9.
JTLS’s initial configuration was developed, coded, tested, and delivered to the U.S. Readiness Command, MacDill AFB, Florida, in approximately 16 months.
The final version, JTLS 1.5, a significant enhancement over the baseline version, was delivered to JAD with the acceptance testing accomplished at the Naval Post Graduate School in Monterey, California, on October 1, 1985.
14.1.2 Estimating the Cost of War
Preparation for the execution of a game was a time-consuming task. Digitized ter- rain, still in its infancy at JPL, was prepared by the JPL Image Processing Labora- tory from maps provided with 1:1,200,000 resolution. The user prepared the air- ground-naval database that included all organizations, units, weapons systems, attrition coefficients, movement rates, weapons performance factors, and the con- sumption rates for critical items like rations, fuel, and ammunition through the Sce- nario Preparation Program (SPP). For a theater such as Central Europe, game preparations required the effort of two engineers covering an average period of six work months. Prior to running JTLS, the scenario database was passed through the Scenario Verification Program (SVP) to validate its correctness and integrity.
4The JTLS User Interface environment provided the using Theater or Field Army Command Post with manually posted displays and verbal input to the ‘‘Game Controller’’ who received the game truth from the Model Interface Program (MIP), and input the orders from the Red Commander and Blue Commander through the MIP into the Combat Events Program. In this way, the Battle Staff of participating units could be located in tents, in trucks (as was the practice), or in bunkers. This provided field realism and permitted noncomputer-literate officers to perform their duties in the same manner as they were trained to do.
CASE STUDY ONE: THE JOINT THEATER LEVEL SIMULATION (JTLS) 205
Figure9.JTLS—examplesofanoperatingsystem-dependent
206
The JTLS graphics capability freed users from manually updating the situation maps, and provided a clearer view of the overall tactical situation. Users were pro- vided with terrain detail, unit identification, combat strength and location, and indicated their direction of movement via arrows.
The JTLS Post Processor (PP) recorded the data generated during the Command Post Exercise and the execution of the game, providing the users the capability to analyze the exercise results. By the way, to my mind the original idea was that even if nobody cared about the issues of fighting a war, if I could provide a CPX suppor- tive game that would enable the JCS to calculate the cost in dollars and cents, maybe they would present the Congress with an estimated cost,a priori. Perhaps after looking at the bill before starting, they would say, ‘‘Nah, we can’t afford this war. Forget it.’’ Anyway, the user may identify the most effective weapons system through air-to-air combat, the type of weapon producing the greatest number of tank losses (figuring into the equation, it is hoped, the loss of tank crews, five soldiers per tank), and the amount of fuel and rations used during a period of time at $1.50 per gallon of JP-4 and diesel.
What had started all this thinking about the cost of a war was the decision pro- cess of President Eisenhower in not going to the aid of the French at Dien Bien Phu, when the entire Joint Chiefs of Staff wanted to, and the Cabinet as well. He flatly asked the Secretary of the Treasury what it would do to the National Budget; to be specific, would we go into the red?
At the following cabinet meeting, the Secretary of Treasury informed President Eisenhower that sending in troops and materiel to get the French out of their colo- nial jam (which most Americans didn’t sympathize with anyway) would put our finances in the red. President Eisenhower then replied that we couldn’t afford to go to war. Well, to me that was the best answer I have ever heard about a war. I loved this attitude of President Eisenhower’s, that we won’t go to war, because it will put our national budget into the red! I figured that if I could build a war game that permitted even a ballpark figure of the cost of a war to be contemplated by our president, he could ask for a simulation run, and get the dollar cost. Based on this, the president then could tell the Cabinet, ‘‘Okay, let’s do it. We can afford it, so let’s proceed.’’ Or conversely, he could say, ‘‘No, we can’t go to war. We don’t have the money in our budget!’’
All of this is for cases, of course, where we have not been attacked or have declared war. Needless to say, I was naı¨ve. Since I was only a Green Beret major, I had no idea that people simply liked to go to war, for too many reasons to go into here.
What it did provide was the relief to the budget required for the funding of the CPX and FTX to the Army and Air Force during the Cold War. What had been a time-consuming and manpower-intensive process had been greatly simplified through the advances in technology, particularly in modeling techniques, computer simulation languages (such as the advances from GPSS to Simscript), and computer platforms and operating systems, particularly the leap from the PDP-11 to the VAX 11-780 and VMS.
JTLS, in its final configuration at the time of delivery, comprised 120,000 source lines of code, with about 60,000 lines of comments. It ran on the DEC VAX 11-780
CASE STUDY ONE: THE JOINT THEATER LEVEL SIMULATION (JTLS) 207
and VAX 8600 platforms using DEC’s great VMS 4.1 operating system. The major technologies that enabled us to build it, in addition to the truly outstanding talents, were Simscript II.5, the C programming language, INGRES (a relational database management system), and the system workstations (including VT100 terminals).
Each graphics workstation was composed of a Sony video monitor, a digitizer pad, a Graphover 9500, and a Sony videodisc player, which contained the terrain map representation.
14.1.3 Starting up the Effort
Nothing is ever easy! After many failed attempts at finding a sponsor, we ran into some imaginative Air Force officers who wanted to get going at once. No sooner had the word leaked out that we were going to build a war game, the ‘‘stake- holders’’ got into the act. We, Dr. Joe Fearey and I, certainly hadn’t the foggiest idea that there were so many stakeholders in the business of war gaming. With all of the heavy funding that the DOD had invested in war gaming, no one had any- thing worth mentioning to show for the money. But they had powerful lobbies.
There was one functionally good product called the McClintic Theater Model, which had been built by some very talented individuals.5 It was the automation of a military board game like the ‘‘Eastern Front’’ or ‘‘Gettysburg’’ games. One of the stakeholders immediately forced us to build on this system and enhance its capabilities with improved movement and attrition algorithms. This game was written in 12,000 lines of Fortran and ran on a PDP-11 (then my favorite machine).
But this was a great inhibitor to us, because it shunted aside my modular and global architecture, and forced us to use an old system, which was dated. There were several reasons for this, the first being control over development. Government agencies rarely if ever yield to the troops in the field. US STRIKECOM at McDill was a ‘‘field’’ organization, and not a Defense stem-winder establishment. The old Napoleonic dictum, ‘‘A glutton will defend his dinner like a hero,’’ was making itself felt. I, being thoroughly naı¨ve, and not understanding politics, just defied them and went about my business trying to build on the McClintic model, while ignoring the stakeholders as much as I could.
The thing that was paramount to the few brave visionary officers at McDill AFB was that we simply had to swallow our pride and prove by any means possible that an interactive, event-driven, computer simulation was not only doable, but that it was far superior to anything the stem-winders at DOD had. We were proved correct.
With all the problems we had to solve, we also had things going for us. The DEC VAX 11-780 and VMS 4.1 had just come out and had great compilers for C and for Simscript II. I knew only GPSS, but this was far better. I had to yield on the issue of my large, elaborate modular hardware and software architecture called MEDUSA to something simple, just to get the system built and prove my hypothesis on war gaming. It was politically a very unsavory experience. When Army guys finally got involved at the War College and in the Pentagon, it was like going from Air Force
5Ray Macedonia, Fred McClintic, and James F. Dunnigan.