battle labs: tools and scope · battle lab demonstrations; and, b) experiments with evolving...

51

Battle Labs

BATTLE LABS:TOOLS AND SCOPE

Julian Cothran

The Battle Lab is a tool for the rapid insertion of new technology into weap-ons systems and for the early evaluation of potential military componentsand experimental systems. It can yield cost savings to project managers andsystem users. It is multi-faceted, meeting such diverse requirements of theacquisition process as the engineering test beds used by the project man-ager and the simulations used by commanders, planners and others forwargaming. This paper describes the desired integration of battle labs withtest beds, and how test beds produce: a) the required fidelity of input forBattle Lab demonstrations; and, b) experiments with evolving technologicaladvancements.

OPINION

with the simulations (Roos andFranks, 1992).

This can be accomplished by �net-working simulators that offer a safe,cost effective environment augmentinglive field exercises; one in which we canafford to exercise all the componentsof today�s combined arms teams,� ac-cording to George T. Singley, III(Singley, 1993). Singley adds:

(M)aterial developers will shortenacquisition time while reducingboth costs and development risksby employing Distributed Interac-tive Simulation (DIS) during con-cept definition, concept explora-tion, design, MANPRINT assess-

ccording to General FredrickM. Franks, Jr., former com-mander of the U.S. Army

Training and Doctrine Command(TRADOC):

(W)hat we wanted to do inTRADOC was provide ourselvesa means�given resource con-straints�to take emerging ideasfrom recent battlefield experi-ences such as Just Cause andDesert Storm and continue to ex-periment with those ideas and withtechnology insertions that couldbe applied to furthering our war-fighting capabilities using simula-tions as well as some actual proto-type (hardware) systems tied in

Report Documentation Page Form ApprovedOMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering andmaintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, ArlingtonVA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if itdoes not display a currently valid OMB control number.

1. REPORT DATE 1996 2. REPORT TYPE

3. DATES COVERED 00-00-1996 to 00-00-1996

4. TITLE AND SUBTITLE Battle Labs: Tools and Scope

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Army Missile Command,Forward Area Air Defense Project Office,Hunstville,AL,35808

8. PERFORMING ORGANIZATIONREPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited

13. SUPPLEMENTARY NOTES Acquisition Review Quarterly-Winter 1996

14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT Same as

Report (SAR)

18. NUMBEROF PAGES

12

19a. NAME OFRESPONSIBLE PERSON

a. REPORT unclassified

b. ABSTRACT unclassified

c. THIS PAGE unclassified

Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18

52

Acquisition Review Quarterly � Winter 1996

ments and prototyping.

Simulation also allows for quicker,more effective trade-off studies. Theresult is clearer requirements in lesstime and at lower cost (Franks andRoss, 1993; Slear, 1992).

Gen. Franks and General Jimmy D.Ross, former commander of the ArmyMateriel Command (AMC), agreedthat:

Battle Labs� requirements for rapidinsertion of new technologies into sys-tems via components and experimen-tal systems will be tested iteratively,demonstrated and evaluated for mili-tary value. To a much greater degreethan in the past, this process is basedon simulation of both the physical sys-tem and its battlefield performance.Battle Labs provide a means for theArmy�s systematical examination ofwar-fighting ideas and evaluation of theoptions offered by new technical capa-bilities (Franks and Ross, 1993).

They went on to say that,

(T)he objective of each Battle Labis to determine the potential mili-tary value offered by a new capa-bility as early as possible. Productsof these efforts typically are soft-ware models or early stage �aus-

tere prototypes� such as �bread-boards� or �brassboards� withoutthe full functionality of completefieldable systems or components.Testing is likely informal and mayinvolve an iterative model-fix-model or test-fix-test cycle.

This means of virtual prototyping notonly facilitates concurrent engineeringbut also encourages continuous, com-prehensive evaluation by the combatdevelopment, material development,and test and evaluation communities atthe beginning of the acquisition pro-cess�when the weapon system is be-ing designed to reduce the time andcost of the acquisition cycle (Ross,1993; Singley, 1993).

In summary, the PM must developtest bed tools and integrate his effortswith the Battle Labs if he is to demon-strate system capabilities that are notonly measurable, but also result in thehigh fidelity simulations that willstreamline the acquisition process.Battle Labs, the Louisiana Maneuvers(LAM), and the methodology of DIScombine nicely to point the way, but theproof is in the implementation. Prob-lems encountered in implementing theconcept and methodologies of simula-tion frequently involve the mispercep-tions of decision makers. Among theseis the widely shared misperception that

Julian Cothran was the Chief Engineer, Forward Area Air Defense Project Office, U.S.Army Missile Command, Redstone Arsenal, Alabama, from 1986 through March 1995. Heis a graduate of PMC 94-1, Defense Systems Management College (DSMC).

53

Battle Labs

testing must deliver sensational, �crashand burn� results to be deemed effec-tive by the public. This erroneous ex-pectation must give way to a desire forthe in-depth, structured testing andanalyses performed in a test bed andBattle Lab environment. That new en-vironment truly provides the qualitativeand quantitative data about a weaponsystem�s added value that will supportprogram and system decisions.

Another misperception lies withinthe systems engineering process. Al-though the steps in the process aregood, how and when these steps areexecuted is not unalterable, and theperception that they are is mistaken.This is pivotal to the success of BattleLabs.

To implement simulation properlyrequires a teaming of the user (or com-bat developer) and the Project Man-ager (or material developer). The aimof their combined efforts reflects a con-current engineering philosophy thatprovides direct feedback into theweapon system development cycle. Thegoal is to use modeling and simulationto test, evaluate, and further amplifyany number of factors in that cycle.Among these: Operational Require-ment Document (ORD) requirements,smart technology insertion, comparisonof alternative evolutionary concepts,predictions of the system�s functionaland operational performance, designand development of new devices andalgorithms, system integration, systemsoftware support, command and con-trol, best doctrinal way to fight the sys-tem, and MANPRINT issues. These as-sessment and development needs arenot new; however, that they are ob-

tained as a joint team effort is new.The Battle Labs concept, with speci-

fied centers controlled by the combatdeveloper, is well-understood. Unfor-tunately, the contribution of the testbed to the Project Manager�s team isless visible, as is the interplay of test beddata used bycombat devel-opers and ma-terial develop-ers. Neverthe-less, a fusion ofthe test bedsand battle labs, providing end-to-endsimulations and simulators, would fos-ter rapid prototyping through �hard-ware-in-the-loop� (HWIL). It wouldalso combine, in a DIS synthetic envi-ronment, the domains of research, de-velopment and acquisition (RD&A),military operations, and training (seeFigure 1).

Project managers own the detailedsimulations (or test beds) that provideaccurate weapon system performancedata to wargaming models. These com-plex test beds place soldiers in detailedsimulations of hardware prototypes andnew system software to assess theweapon�s warfighting �value added.�Through DIS, test beds enable a newweapon system, or a new configurationof an old weapon system, to interact ina war game in real time. The combatdeveloper is given access to the simu-lation at his home station. This is theBattle Lab concept enabled through ateaming of users, PMs, contractors, anddevelopers.

Whether test beds support the re-quired evaluation areas and address thewidest scope of issues (while remain-

...the widely-sharedmisperception thattesting must deliversensational, �crash andburn� results...

54


A Time and Space Coherent Representation of a Battlefield EnvironmentMeasured in Terms of Human Perception and Behavior

of Those Interacting in the Environment

Figure 1. DIS Synthetic Environment

ing flexible and comparatively inexpen-sive) should be asked in determiningexactly what types and combinations ofsimulations, test beds, and tests areneeded. This evaluation is illustrated inFigures 2 and 3.

EVALUATION AREAS

The next step is to assess whether thedetail and scope of the evaluation meth-odology will support technical require-ments generation and evaluation, op-erational requirements, and overall re-quirements (e.g., force modernization).The assessment of these applications is

shown in Figure 4, as applied to theSTINGER/AVENGER, the ForwardArea Air Defense (FAAD) Project Of-fice, and the Weapon System Manage-ment Directorate (WSMD). Next weassess the scope and detail of the tools[missile simulation (HWIL); weaponsystem fire unit simulation (HWIL);Software in the Loop, (or SWIL); andMan in the Loop, (or MIL), and thebattlefield models], and how these toolsinteract with each other within the DISvirtual network. This is illustrated inFigure 5 as an integrated evaluationand Test Evaluation Master Plan(TEMP) asset.

55

Battle Labs

Figure 3. Evaluation Areas

Figure 2. System Evaluation Methodology Trade-Off

LEGEND: SYS - SYSTEM PA - PERFORMANCE SIM - SIMULATIONARCH - ARCHITECTURE EX - EXAMPLE DEM - DEMONSTRATIONEVAL - EVALUATION MSL - MISSILE VAL - VALUATIONINTEG - INTEGRATION DOF - DEGREE OF FREEDOM

56


Figure 5. Scope, Detail, and Interaction

Figure 4. FAADS Simulation Test Bed,System Evaluation Methodologies/Applications

57

Battle Labs

After determining the detail andscope required of the test bed, simula-tions and models, an ordering by typeand function needs to be performed toproduce a simulation hierarchy. This

type of hierarchy is shown in Figure 6for the FAAD PM and WSMD. Thenext assessment determines how andwhen the various tools will be needed,and how they should connect (see Fig-

Figure 6. Simulation Hierarchy (PM�s Tool Kit)

LEGEND

SIMNET = SIMULATION NETWORKBDS-D = BATTLEFIELD DISTRIBUTED SIMULATION DEVELOPMENTVIC = VECTOR IN COMMANDBEWSS = BATTLEFIELD ENVIRONMENT WEAPON SYSTEM SIMULATIONCASTFOREM = COMBINED ARMS TASK FORCE ENGAGEMENT MODEL6 DOF = SIX DEGREES OF FREEDOM SIMULATIONCORBAN = CORPS BATTLE ANALYZERIFS = INTEGRATED FAADS SIMULATIONEO/IR/MMW = ELECTRO-OPTICAL/INFRARED/MILLIMETER WAVEECM/ECCM = ELECTROMAGNETIC COUNTER/COUNTER MEASURES

58


ure 7). Within this evolution, the simu-lated weapon system prototypes areevaluated by soldiers. This process ofvirtual prototyping produces the ben-efits seen in Figure 8.

The Air Defense Program ExecutiveOfficer (PEO) completed an initial re-view of the library of battlefield mod-els in 1989. He concluded that no ex-isting model could provide all of thefeatures needed and desired for analy-ses of Forward Area Air Defense(FAAD) systems. Instead, it would benecessary to use several models in sup-port of system performance assess-ments, tactics, and doctrine analyses.The survey identified minimum re-quirements for models and defined cri-teria for evaluating and comparing

models. A subsequent evaluation ofeach model�s applicability and utility foranalyzing FAAD issues was also con-ducted. This revealed that the modelswould have to be capable of support-ing battalion-sized or larger units in anasymmetric play of forces (e.g., Bluetactics by Blue, Red tactics by Red).The models would also have to be inuse at present in the simulation com-munity.

The CASTFOREM, JANUS(T),and VIC models were chosen; together,the three models satisfied the battle-field integration issues. Many of thedetailed outputs from the interactiveJANUS(T) could be fed intoCASTFOREM. Similarly, some of thebattalion and brigade-level results from

Figure 7. Simulation Evolution/Life Cycle

59

Battle Labs

CASTFOREM could be used as inputfor the corps and division-level VICsimulation (Air Defense PEO, 1989).Yet all three had major drawbacks:They assumed perfect identification offriend or foe (IFF); they modeled com-mand and control logic through deci-sion tables only, thus not allowing forassessment of a C3I capability on thebattlefield; they lacked detail in the playof fixed-wing aircraft; they excludedfratricide; they allowed no explicit elec-tronic warfare play; and they used un-changing weather parameters. In addi-tion, JANUS(T) provided only a verycoarse level of modeling for a fire unit

by assuming perfect targeting by thethreat (Red) aircraft, an �a priori� know-ledge of Blue�s location by Red aircraft,and visual identification ranges for Blueforces applicable to tanks rather thanthe detection, recognition, and identi-fication ranges common to sensors inAir Defense units. Nevertheless, theselimitations of the models make a testbed attractive since their outputs, wheninserted into the VIC battle, can easilyprovide the correct inputs for aCASTFOREM or VIC model, or anyupgrade of these with higher resolutionand fidelity.

Figure 8. Virtual Prototype Simulation - Life Cycle

60


THE UTILITY OF IMPLEMENTATION

Within the constraints of the preced-ing section, the test bed is an analysistool emulating the weapon system andused to conduct experiments, studiesand analyses to support: a) predictionsof the system�s functional and opera-tional performance; b) comparison ofalternative evolutionary concepts; c)design and development of new con-cepts, devices and algorithms; d) sys-tem integration; and e) maintenanceand support of system software(AVENGER Project Office, 1992) (seeFigure 9).

A wide variety of concept and con-figuration trades-offs are necessary inany system�s evolutionary development.

This use of test beds is manifested atseveral levels. At one level, the test bedallows investigation into alternativestructures for weapon systems or rela-tionships between system components(e.g., the effects of system mod-ularization, element intercommunica-tion, and centralization of decisionmaking). Another level of test bed useis the selection of alternative weaponsystem elements (i.e., technology inser-tion) based on comparisons of their ef-fectiveness. A third level of test bedutility lies in measuring variations in asignificant component�s characteristicsand how they impact the effectivenessof the full system. These three levels ofanalyses provide the basis for informeddecisions on trade-offs.

Figure 9. Test Bed Applications

61

Battle Labs

Test beds also support componentdesign and development. The test bedis used to shake down preliminary de-signs (i.e., analytical models), evaluat-ing them in the context of weapon sys-tem objects and functions. This enablesthe subsystem to be studied in a con-trolled but realistic operational envi-ronment for which the design variablesserve as study parameters. It also allowsother elements of the system to influ-ence modification and evaluation of thedesign, as well as permitting observa-tion of the effects of design parameterson system performance.

Design and development of compo-nents and subsystems are brought to-gether in system integration. The testbed has tremendous utility for reduc-ing the high risk in this area. Systemintegration issues explored on the testbed include functional or operationalcoordination, completeness, and integ-rity; system interface validation; datafusion; and the cooperative operationof system elements. The test bed mayalso serve to identify and quantify anyproblems in functional or data interfaceand to investigate alternative solutionsfor such problems, and also serve tosupport experiments or demonstrationsof system integration concepts.

Performance assessment of a weaponsystem is another use of the test bed,as is validation of engagement simula-tions or wargaming models. The testbed can generate data invaluable in

validating engagement models by dem-onstrating the system�s fully integratedoperational functions under full en-gagement scenarios. Using the test bedto predict the results of a weaponsystem�s field and firing tests supportspre-test planning and post-test analy-ses, reduces the amount of real worldtesting required, saves time and money,and provides results that are more con-structive and defensible.

In today�s software driven weaponsystems, the test bed is a necessarycomplement to the normal softwaredevelopment environment. The testbed provides the complex and realisticstimuli and operational states necessaryto determine the adequacy of theweapon system�s operational, imbed-ded software.

SUMMARY

The Test Bed and Tools for DIS areready and functional. Integration andconsolidation of efforts to utilize thesetools must be continued. Many re-sources and simulations are untappedthat can help the Project Managers andthe user. The Program Executive Of-ficer and TRADOC User communitiesneed to synchronize their efforts to cre-ate cost effective weapons systems andsystem improvements through robustsimulations.

62


REFERENCES

Air Defense Program Executive Officer(PEO). (1989). Appendix A: Simula-tion Model Survey. Forward Area AirDefense System Simulation Plan, (Re-port MA89-PEO-AD-0001), Feb. 17.Author.

AVENGER Project Office. (1992). Sys-tem Specification for the AVENGERSimulation Test Bed (Draft), July. Au-thor.

Franks, Gen. F.M., Jr. and Ross, Gen. J.D.(1993). How To Do Business With BattleLabs - A Guide For Industry. Washing-ton: Army Materiel Command.

Ross, Gen. J.D. (1993). Legacy for �90sin Louisiana Maneuvers. Army, June.

Roos, J.G. (1992). An Exclusive AFJIInterview With: General Frederick M.Franks, Jr., USA, Commanding Gen-eral, US Army Training & DoctrineCommand (TRADOC). Armed ForcesJournal International, October.

Singley III, G.T. (1993). Distributed In-teractive Simulation-A Preview. ArmyResearch, Development and AcquisitionBulletin, March-April.

Slear, T. (1992). Battle Labs: Maintain-ing the Edge. National Defense, Novem-ber.

battle labs: tools and scope · battle lab demonstrations; and, b) experiments with evolving...

Documents