K/DSRD/OL-1670

USING CONSTRUCTIVE SIMULATIONS AND ALSP FOR TRAINING IN UFL 92

Dean S. Hartley III

Data Systems Research & Development
Oak Ridge K-25 Site
Oak Ridge, TN 37830

                                ABSTRACT


The Aggregate Level Simulation Protocol (ALSP) is now a
proven success in connecting the logic and timing of
constructive simulations.  In 1991 and early 1992, when we
were planning the major annual Korean military exercise,
Ulchi Focus Lens 92 (UFL 92), ALSP was unproven technology. 
This paper sketches the situation then and the impact of
ALSP on UFL 92.  It should be noted that, while ALSP
provides the possibility of better exercises, it is not a
panacea.  Planning and executing an exercise of the
magnitude of UFL requires much more than a model or a set of
models.  This aspect is included in the paper, lest we
forget that the point of such exercises is training for war,
not technology for its own sake.


                            1.  INTRODUCTION


The Republic of Korea (ROK) and North Korea are still at war
with each other.  The Korean War ended with a truce, not a
final conclusion.  The level of combat is currently low
(occasional raids and fomentation of civil unrest by North
Korea); however, a major conflict is possible at any time. 
Both Korean and U.S. troops are trained in individual and
group skills by various means; however, training the
commanders and their staffs is a particularly difficult
problem.  Commanders and staffs at the theater level are
concerned with coordinating vast quantities of men, material
and information.  The command is supposed to formulate plans
that drive a conflict in satisfactory directions and to
react to an uncooperative foe.  In Korea, this problem is
exacerbated by language differences and constant turnover of
U.S. personnel.

The only solution is practice.  At the top level, this means
an annual exercise called Ulchi Focus Lens.  This exercise
involves a majority of the ROK forces, all of the U.S.
forces in Korea and a large number of U.S. forces located
outside of Korea, such as Japan and the continental U.S.
(CONUS).  Actually moving all of these forces and employing
them in a wargame each year would be prohibitively
expensive.  The alternative is to use a constructive
simulation or simulations to generate the problems (caused
both by the enemy and poorly coordinated friendly forces)
that the generals need to solve.

Prior to UFL 92, this exercise was driven by a set of models
and extensive manual scripting and communication between
models (e.g., "the enemy air just sank that ship [in the air
model], so quit using it [told to the naval model
controllers]").  This worked, but not as well as desired. 
The U.S. Forces Korea (USFK) wanted something better.  A
single model covering the entire domain of training for war
(at the desired level of detail) would have been preferable.

Three dimensions of training are clearly specified in USFK
documents.  One dimension is scope or command level, ranging
from brigade-and-below training through theater level
training.  The second dimension is the combat area or type
of activity, including ground, air, naval, amphibious,
intelligence, special operations, electronic warfare, and
deployment and logistics.  The third dimension is spectrum
of conflict or combat intensity, ranging from low intensity
conflict through nuclear warfare.

A fourth dimension of training is not clearly specified, but
may be inferred from the named training exercises.  This
dimension may be described as one of training purpose or
goals.  For example, one theater level exercise might
involve the mobilization of great numbers of troops, with
training goals including coordination skills at the higher
command levels and unit skills at the troop levels.  Another
exercise at the theater level might consist of command post
personnel only, emphasizing command and control skills.  A
third theater level exercise might consist only of theater
level staff to train planning skills.  Figure 1 illustrates
the simulation dimensions.


Figure 1. Simulation Coverage

USFK's multi-dimensional training requirements might conceivably be satisfied with a single training product; however, the available tools and techniques made this a practical impossibility. The technical problem resulted because there was no single combat model that simulated all areas. In addition to there being no single model that satisfied all of the requirements, there were several individual areas for which there was no functioning, credible model. The staff at the Oak Ridge Department of Energy facilities were asked to help solve the problem. We put together a team of over 50 people, most located in Korea, to identify a technically feasible solution and implement a prototype Battle Simulation Center (BSC) to manage the exercises. ALSP is now a proven success in connecting the logic and timing of constructive simulations. In 1991 and early 1992, when we were planning UFL 92, ALSP was unproven technology. This paper sketches the situation then and the impact of ALSP on UFL 92. It should be noted that, while ALSP provides the possibility of better exercises, it is not a panacea. Planning and executing an exercise of the magnitude of UFL requires much more than a model or a set of models. This aspect is included in the paper, lest we forget that the point of such exercises is training for war, not technology for its own sake. 2. TRAINING PROGRAM The Korean BSC training program is composed of three core elements; the training audience, training materials/methods, and the training personnel. 2.1 TRAINING AUDIENCE The exercise training audience consists of military personnel (players) operating from a Tactical Operations Center. The player prepares plans and issues orders to the personnel (gamers) who input the requirements into the BSC computer workstation. Inherent in effective BSC exercise planning is a thorough understanding of the training audience to include its organization, training requirements, and desired training results. This understanding is necessary in order to develop the proper exercise database and select the correct simulation models and training materials. As the echelon of the training audience increases, so do the exercise support requirements. Any exercise supporting a division or above training audience will always necessitate augmentation from outside the trained unit. 2.2 TRAINING MATERIALS/METHODS Training materials and methods must be tailored to meet the needs of the training audience. The detail and focus of instruction will vary between gamers, scripters, and controllers. In addition to the mix of trainees, the Korean BSC incorporates a variety of models to accomplish the command training objectives. Each model requires unique training materials, certified instructors, and instructional methods. Although most model developers provide user documentation, it is generally very basic and must be extracted from and expanded to create a suitable program of instruction. When training gamers, scripters, or controllers it appears that the most effective instruction methodology is one that minimizes lecture and maximizes hands-on training time. Models used by the Korean BSC utilize a combination of menu- driven orders and interactive displays. Instilling confidence in the trainee that the simulation is efficacious can only be accomplished through intense practical exercises at the workstation. 2.3 TRAINING PERSONNEL The Simulation Control Plan should specify the requirements for gamers, scripters, and controllers. The ability to meet the objectives of the training audience is, in part, attributed to the scope and detail found in the Plan. The Korean BSC has the added demand of supporting numerous combined training audiences which mandate additional personnel to satisfy both U.S. and Korean training objectives. Many students enter the training wary of a computer model's ability to simulate realistic battlefield conditions. The instructor has the difficult task of instilling confidence in the students that they can use the simulation to provide timely and practical output to the players. When selecting individuals for instructor positions, functional expertise should be a primary consideration. Without it an instructor may be able to teach the mechanics of the simulation model, but he will not fully understand the player unit organization, mission and capabilities - information that is critical when assisting gamers as they translate player orders into appropriate computer commands and computer output into realistic tactical reports. Opposing forces (OPFOR) gamers, scripters, and controllers have training requirements which differ from their friendly counterparts. The instructor must work closely with the OPFOR Operations Officer to ensure that the training is focused on the systems, tactics, and capabilities of the OPFOR. There are two competing views of OPFOR activities: 1 During the OPFOR gamer and controller training, the instructor must emphasize that the OPFOR's role is not to win the war but to support the Blue Force training audience. On occasions during an exercise, the OPFOR may be required to deploy personnel and equipment in a manner that is uncharacteristic or doctrinally incorrect in order to support emerging, Exercise Director mandated training objectives. 2 The OPFOR gamer and controller training focus is on ensuring that the training audience objectives are realized through the realistic portrayal of OPFOR doctrine, tactics and capabilities. The OPFOR must play to win, even when constrained by scenario input designed to allow attainment of the exercise goals or objectives. It is the job of the Exercise Director to reconcile these two views. The USFK BSC relies upon extensive, combined ROK/US augmentation to perform the required OPFOR player and controller functions. The BSC OPFOR cadre staff is a small number of permanently assigned personnel and is heavily involved in planning, coordinating and training for the numerous scheduled exercises. Because of the large number of relatively inexperienced personnel brought in for each exercise, the cadre must teach new procedures, organization and equipment authorizations, command and support relationships, as well as new or different tactical employment concepts and procedures prior to each exercise. This is in addition to the basic controller functions required to input tactical orders into the system. The augmentation OPFOR players perform command and staff functions comparable to that performed by the training audience player commanders and staffs. A significant difference is that the training audience players are performing familiar tasks while the OPFOR players are often performing in a new or unfamiliar operational environment. The augmentation controllers, sometimes referred to as gamers (because they perform both functions), actually interface with the model through workstations. They translate OPFOR augmentation player or Red operational orders into commands which are entered into the model. They then translate model generated output into operational reports to be provided back to the players in accordance with OPFOR unit procedures. 3. MODELS The desired UFL 92 confederation included the Corps Battle Simulation (CBS) as the basic ground combat model, the Air Warfare Simulation (AWSIM) as the basic air combat model, the Research and Evaluation Systems Analysis (RESA) model as the basic naval model, and the Theater Transition and Sustainment Model (TTSM) as the basic logistics model. Because there was overlap among these models, the detailed choices for which code would be used for each event depended on close analyses. Two smaller models (of subroutine size compared to the major models) performed specialized functions: the Joint Electronic Combat/Electronic Warfare Simulation (JECEWSI) performed electronic warfare functions, and the Combat Base Assessment Model (CBAM) assessed damage to air bases. The Tactical Simulation (TACSIM) was used in the exercise as an intelligence driver; however, its classification prohibited full electronic linkage to the other models. Its connection to the confederation was maintained by manual interface. 3.1 ALSP AS A MEANS FOR JOINING MODELS ALSP was a Defense Advanced Research Projects Agency (DARPA) sponsored effort, being developed by the MITRE Corporation. The goal was to develop a protocol for interfacing multiple combat simulations. The description of ALSP might lead one to conclude that it is a simple protocol for allowing multiple (similar or dissimilar) combat models to communicate with each other. This is analogous to a Local Area Network (LAN) connecting PCs. A little bit of software and hardware is added to each PC, allowing each to communicate. Similarly, a little code is inserted into each model and external code modules are added, allowing each model to communicate. However, the changes go deeper than implied by the analogy: the models are REQUIRED to communicate. The implementation of this philosophy in ALSP requires profound changes to the operation of models that run under it.


Figure 2. CBS under ALSP

Figure 2 illustrates the effect of ALSP on the CBS model. The CBS model is shown residing on a computer and connected to several distribution computers, each connected to CBS workstations. The ALSP Common Module (ACM) is shown residing on a workstation (avoiding an overload on the CBS computer), with a link to the CBS computer. The ACM provides the protocol connection to other models in the confederation and is virtually identical to the ACMs for the other models. The ALSP Translator is shown sitting on and rooted in the CBS model. The Translator converts messages from other models to the format understood by CBS. The root-like extensions shown in the figure are changes to CBS that cause CBS both to react to these messages and send its own messages to other models. Several immediate concerns about using ALSP to solve the interface problem for USFK were readily apparent. USFK would require confederations of large numbers of models. Would the message traffic become excessive? How extensive and expensive would the model modifications be? Many of the models are subject to configuration control by their owners. How receptive would the owners be to the modifications? Differing requirements might require differing confederations with corresponding differences of attribute ownership. How difficult would it be to modify the models to accommodate this? How extensive and expensive would the aggregation/disaggregation problems be and how many versions would be required based on multiple confederation sets? 3.2 USFK DECISION The core solution for USFK was to use the ALSP methodology. This methodology was the most promising technologically and it enjoyed external funding support. This external funding was critical to USFK because the model interface task was too large for USFK to fund alone. However, the ALSP choice did not solve the USFK problem immediately. Only two models, CBS and AWSIM, were to have been modified to use ALSP by the end of Fiscal Year (FY) 92. Additional models could be modified subsequent to that time; however, no more than one to two major models were likely to be modified in a given year. The implication for USFK was that a complete confederation of five or six major models and two smaller models, interfaced through ALSP, might not be available until FY 96. Clearly hybrid solutions would be required to meet the USFK requirements for operations from FY 92 until the complete confederation is available. Human interfacing was the only immediately available supplemental option. Although DARPA was funding the initial modifications to AWSIM and CBS, DARPA was to step out of the picture, leaving other agencies to fund the modifications to other models (and further modifications to AWSIM and CBS required to communicate with new models). Despite the risks, USFK chose to use ALSP for UFL 92. The confederation is shown in Figure 3. ALSP was used to connect AWSIM in Europe at the Warrior Preparation Center (WPC) and CBS in Korea at the BSC. CBS terminals were remoted to I Corps at Fort Lewis, WA in the U.S. JECEWSI and RESA were connected to AWSIM with the WPC point-to-point connections. Similarly, TACSIM was connected (with a one- way link) to CBS in Korea. The resulting confederation was not perfect, but was an improvement over all manual links.


Figure 3. Model Connections for UFL 92

4. PHYSICAL FACILITIES Running the models and especially running the exercise required physical facilities. The practical matter of the availability of facilities and funding to modify what is available placed restrictions on what could be done, requiring an iterative design process. The overall communications architecture for simulation support to UFL 92 is illustrated in Figure 4. This figure illustrates a worldwide distributed architecture that includes communications networks with sites in Korea, the CONUS, and Germany. This linkage supported voice, data, and limited video interface between the simulation centers, the USS Blue Ridge, TACSIM user sites, and the Yongsan simulation technical control facilities in Buildings 2386, 2552, and 2555.


Figure 4. Communications Architecture

Eleven simulations and support software were employed in support of UFL 92. A wide variety of computer hardware was used for the simulations and supporting communications and networking. The ACM was loaded and executed on the VAX 6520 in Building 2386. A total of 30 AWSIM workstations were provided to exercise participants in Korea. A total of 88 CBS workstations were provided to exercise participants in Korea, plus another 36 for participants at the I Corps Gaming Center. JECEWSI has no unique requirements, and was run on AWSIM workstations. The Joint Intelligence Model (JIM) was run on dedicated CBS type workstations in the Intelligence and Scripting cells. The Joint Military After Action Reporting System (JMAARS) was run on CBS workstations (Amiga-based only) in the After Action Review cell. The Joint Strategic Target Acquisition and Reporting System (JSTARS) was run on a VAX Station 4000 provided by PM JSTARS. A total of 16 RESA workstations was provided to naval gamers and controllers in Korea. A total of 8 TACSIM workstations was provided to exercise participants in Korea. Some exercise participants did not have workstations, but were provided remote printers for TACSIM reports. In addition to quantity lists, it is necessary to have an appreciation of the physical size and configuration requirements for the workstations for each of the models. Figure 5 illustrates CBS workstations that were used in Korea.


Figure 5. CBS Workstation Alternatives

Site layouts depend on equipment configurations. In addition to the space requirements, space availability must be considered and compromises arrived at. An example site layout is illustrated in Figure 6.


Figure 6. Osan Layout

The design of the communications connections begins with the models' logical data flows. The logical data flows are realized as communications lines with named and sized circuits. In addition to model circuits, supporting communications lines must be added, such as video teleconferencing circuits to permit high data-rate personal interactions for solving problems quickly. All of the communications circuits are brought together to produce a set of overall circuit diagrams. Naturally, system security procedures also had to be addressed and solved. 5. DATABASE Although each model comes with a database for test purposes, those databases do not describe Korea, any Korean scenario, or even the weapons likely to be employed in Korea. Databases for the exercise needed to be constructed. Each of the models has its own database design and set of tools for handling the database. The CBS database is used as an example because CBS is the model with which the project team worked most intimately. The development of the OPFOR database for a model represents a special case and its description provides a more detailed view of the kinds of activities required for developing a usable database. In addition to the simulation specific requirements for databases, the confederation of simulations imposes a requirement that the databases need to be logically consistent across the simulations. This does not mean that a similarly named data element should have the same value in each simulation, but rather that the values (based on the specific process models within the simulations) generate comparable results. 5.1 THE CBS DATABASE A typical CBS database holds around 4 megabytes of data. The most visible data are the unit data. Unit data will include the specific unit's name (4th Battalion, 3rd Brigade, 4th Division), its size and type (battalion, infantry) and its make up (400 troops, 2 tanks, 1 flame- thrower, 3 anti-tank missiles, 10 jeeps). This is the data which is of most obvious and direct relevance to the players and they spend inordinate amounts of time ensuring that it is exactly the way they want it. These data will typically change significantly for each exercise. New weapons are particularly troublesome. The database manager only has limited capability to make the model adapt to new weapons. It is possible to make changes in a weapon's name so that the players may think they have a new weapon; but in fact, it will have all the characteristics of the previous weapon. Every time that the Jet Propulsion Laboratory (JPL) releases a new version of CBS, the database is upgraded as well. A typical upgrade may take several days of intensive work to complete a single database. Once this is done all other existing databases have to be converted before they can be used. When the model reads incorrectly formatted data, it will either crash then, or worse, wait until you are in the middle of the exercise and then crash! Further, some or all of the utilities which the database manager depends upon may need to be upgraded with a version change. Finally, it should be pointed out that with every upgrade, hidden anomalies in the model tend to surface. 5.2 THE CBS OPFOR DATABASE The USFK BSC initially started with an unclassified generic Soviet type database. The organizations portrayed were made to look like the USFK threat forces by changing their names. Initially, little was done to modify the composition of the units to more accurately reflect the real world threat forces other than to refrain from using certain units which were dramatically different. For example, if an air defense brigade in the database was not extant in real life, it was not used or was moved far out of the competitive playbox. This type of solution was not totally satisfactory. The unit would still shoot at Blue air assets and print the reports associated with acquiring the tracks and the subsequent firing as well as any observable results of that weapons firing. The units not being used, regardless of where they were positioned or located, were still subject to normal attrition, which resulted in automatic resupply actions being generated by the model. Realism of the information contained in the database quickly became an issue when the generic Soviet type units displayed greater capabilities than the real world threat being played. For example, the theater specific (real) threat transportation assets were neither organized down to the same level or as capable as those configured in the database. The greater capacity and large number of trucks and fuel tankers distributed throughout the database organizations significantly improved the OPFOR capability over that which could be realistically supported. To address the issues about the validity of the generic database, revisions were planned which would allow the threat force organization and composition to be more accurately portrayed as the actual threat force. Because of the volume of changes contemplated, as well as a desire to make it as accurate as possible, new database information was entered into a PC spreadsheet which could be easily sorted, copied and rearranged as required. Threat TO&E data recorded on spreadsheet programs used by the OPFOR operations element were subsequently input as text files into the mainframe after modifications were approved by the command's intelligence staff. Exercise starting locations are determined from initial map study in sufficient detail to allow controllers to initiate play at the start of the exercise (STARTEX) without major moves. Coordination with Blue during scenario development must specify the starting line of contact and care must be taken to ensure a one hex buffer is maintained between OPFOR and Blue units so that units are not in the same hex or in conflict when the game starts. Locations for all units must be provided, not just the ones planned for the competitive box, even units in the database which are not planned for use during the exercise. Scripted units must be located as well as units in the database which are not going to be played. These latter units should be located at a single coordinate well out of the play area and given a time after the end of the exercise (ENDEX) for introduction into the game. This ensures they do not appear on any sensors or detract from exercise objectives. After Tech Support enters the locations into the database, they check to ensure that no units were placed in a water hex or in contact with Blue forces. They then make corrections as necessary to resolve any problems. For exercise scenarios starting at some point in the hostilities after H-Hour, units must be manually decremented to reflect the STARTEX scenario combat power/strength. Assignment of units to workstations is based on geographical constraints as well as scenario role. For example, a front line unit/division and its follow-on force could be assigned to the same workstation based on geographic considerations. However, care must be exercised to ensure that the number of unit icons and requirements for control of those units remain within workstation capability. As a rule of thumb, a workstation can effectively manage about 35 unit icons actively. However, if the majority of units assigned are follow-on forces not immediately engaged in combat, considerably more units can be assigned. 5.3 INTERACTING WITH OTHER MODELS (SUCH AS AWSIM) CBS is moving rapidly to be able to integrate with multiple models. Database coordination is still required when two models are expected to cooperate. Units sizes need to match or at least be interpretable by the interface. Weapons names have to match and expected results need to be compared. Agreements have to be reached on operational areas. When there simply is no match between weapons, "work-arounds" need to be devised. A good example of this is the Marine's requirement for off-shore naval gunfire support. CBS didn't allow for such an implementation. To get around this, CBS does have the ability to make "on the fly" islands in the ocean wherever a senior controller might desire. CBS can also move units "magically" to islands. Therefore, a naval gunfire work-around is to create islands at the spot where ships should be and then move artillery pieces to those islands. The database manager must put into the force structure artillery units with no other purpose than to be moved to these "magical" islands in the sea. Furthermore, the units should have weapons characteristics which closely match naval weapons. 6. EXERCISE OPERATIONS Exercise support and battlefield simulation is a fast paced environment and extremely mobile. Commanders prefer the simulation hardware and technical control to be close to the command posts it supports. In certain ways, this makes sense but there are good reasons to isolate the technical support activity from the bustle and chaos of the exercise site. Although commanders like the ability to walk into the Technical Control cell to receive status on simulation operation and stoppages, excessive interruptions impede the ability of Tech Control to respond to and resolve operational problems. Furthermore, many of the types of questions brought to the Tech Control staff actually pertain to the functional aspects of the simulation model and are better directed to Senior Control staff. The main argument for location of Technical Control at the exercise site stems from the legitimate need for close communication between Technical Control and Senior Control. Proper planning for adequate telephone lines and well formulated policy articulated in a standard operating procedure may alleviate the need to collocate Senior and Technical Control. 6.1 PRE-EXERCISE ACTIVITIES Pre-exercise activities begin when the decision is made to support an exercise and continue until STARTEX. The key document prepared to plan the pre-exercise activities and forecast operational support of the exercise is the Technical Support Plan. The primary reference for its formulation is the Exercise Support Plan, the formal statement of the functional requirement to conduct the exercise. The Technical Support Plan must embody this functional requirement while describing the details of the areas required to technically support the Exercise Control Plan. A quality site-survey will greatly facilitate all subsequent exercise activities. The exercise facility can range anywhere from a fully equipped permanent building to a temporary collection of tents with mobile generator power. Additional activities include an exercise plan review, configuration planning, and equipment inventory and packing. 6.2 EXERCISE DEPLOYMENT ACTIVITIES Exercise deployment activities take the approved Exercise Plan and Technical Support Plan and execute the steps necessary to station equipment and personnel at the remote exercise sites. Activities include determining staffing requirements, insuring equipment delivery and accountability, installing the equipment, configuration testing, and operational support during the exercise. These activities must begin early enough to ensure readiness to perform the Communication and Simulation Test on the designated dates. 6.3 EXERCISE OPERATIONS The training audience (players) consists of commanders and staffs of real units using go-to-war communications systems and existing unit standing operating procedures (SOP). Habitual unit relationships, an existing chain of command, and personnel performing normally assigned duties enables the training audience to concentrate on tactical planning and employment and attainment of specific training objectives. USFK OPFOR players do not have this luxury. The USFK BSC relies upon combined ROK/US augmentation to perform the required OPFOR player, acting as the enemy commanders. The gamers actually interface with the models through workstations. They translate player operational orders into commands which are entered into the model. They then translate model generated output into operational reports to be provided back to the players. For example, an order is given for a unit to attack to seize an objective and destroy enemy forces in sector. If an ATTACK ORDER is entered by the gamer at the maneuver workstation, the computer replicates the unit deploying into an attack formation and advancing, slowly, in the direction given. If the attacking unit is several kilometers behind the line of contact, it will take a long time to actually make contact with an enemy force. The preferred method would be to initially move the unit forward with a ground move order, such as MOVE TO CONTACT or MOVE UNDER FIRE. Once contact is made the unit is then ordered to ATTACK to a point beyond and through the contacted enemy unit. Simultaneously, fire support assets must be employed. Other tactical and doctrinal issues that must be considered are; attack formations, specifically where are the engineer assets; when to split units; and controlling several unit's movement in a relatively small and congested area. Executing and reporting results of this attack order is difficult at best but almost impossible without considerable training and practice. During an exercise the Analysis Section conducts an intensive data collection effort in preparation for the exercise After Action Reviews (AARs). 7. CONCLUSIONS Technology improvements in computers made the first simulation centers possible by producing computers with sufficient capacity to handle significant sized battle simulations for use in military training. Further improvements have driven the costs down sufficiently for all major commands to consider the advantages of having their own BSCs. Budget constraints are forcing reductions in fully manned and equipped training exercises, shifting the emphasis in the direction of simulation based training exercises. Unfortunately, simulation training requires a substantial overhead in support manpower: that is, personnel who are not part of the training audience. These support personnel operate the computers and convert actions by the training audience into inputs for the simulations and convert simulation activity into stimuli for the training audience. Major commands can afford the personnel to support division level training, which occurs frequently during the year. However, the personnel requirement for the once or twice a year theater exercises is not sustainable. New technology such as ALSP is enabling distributed simulation support, in which one or more simulation centers provide support to a simulation center undergoing a major exercise. They would, in turn, receive support during their major exercises. Actual use of constructive simulations for training requires careful consideration of a series of factors. The training needs specify the model requirements and the physical requirements. The model inventory specifies the input space, logical links, and computer hardware requirements. The locations, input space, logical links, and computers specify the electronic links. The locations, input space, and electronic links specify the facility design. Any (and there are bound to be some) restrictions on model inventory, input space, computers, or facilities will specify physical BSC connections. The BSC connections will modify the implementations of the designs. Despite the complexities of designing and employing a confederation of simulations for training, there is a significant reward. Training can be more meaningful and thorough and can engage a larger proportion of the command and staff functions required in a real war. A better trained command structure produces better results in war and a more credible deterrence to potential adversaries. REFERENCES Bell, Richard E., et al. "Battle Simulation Center Technical Support Plan," K/DSRD-1300, August 1992. Bell, Richard E. "OPFOR Exercise Staff SOP (Draft)," December, 1992. Hartley, D. S., III, Kara L. Kruse, Helena C. Martellaro, A. John Martellaro, Stephen L. Packard, and Joseph P. Trien. "A Structure for Combat Model Integration for US Forces Korea," K/DSRD-886, May 1992. Hartley, D. S., et al. "Design of a Prototype Battle Simulation Center," K/DSRD-1638, January 1994. Jackson, Lynn H. and Stephen L. Packard. "Recommended Organization and Work Breakdown Structure (WBS) for the United States Forces Korea (USFK) and Combined Forces Korea (CFC) Battle Simulation Center (BSC)," K/DSRD-1136, April 1992. Weatherly, Richard, David Seidel, and Jon Weissman. "Aggregate Level Simulation Protocol." Presented to 1991 Summer Computer Simulation Conference, July 1991, Baltimore, MD. MITRE Informal Report, McLean, VA. Wood, Wayne and Maxon E. Boling. "Battle Simulation Center Local Area Network (LAN): As Built Design, Phase One Operational Capability," K/DSRD-1087, May 1992. * Work sponsored by U.S. Forces Korea under DOE Project Number 1947-E096-A1 with the U.S. Department of Energy and performed by Martin Marietta Energy Systems, Inc. This manuscript has been authored by a contractor of the U.S. Government under contract DE-AC05-84OR21400. Accordingly, the U.S. Government retains a nonexclusive, royalty-free license to publish or reproduce the published form of this contribution, or allow others to do so, for U.S. Government Purposes.