An Interactive Design, Visualization, and Analysis Tool ... · An Interactive Design, Visualization, and Analysis Tool for Information Flow ... (FBCB2) SEPTEMBER-OCTOBER ... tem under

228 SIMULATION FEBRUARY 2001

TECHNICAL ARTICLE

An Interactive Design, Visualization, andAnalysis Tool for Information Flow

Over a Tactical Data Network

SIMULATION 76:4, 222-232©2001, Simulation Councils Inc.ISSN 0037-5497/01Printed in the United States of America

John M. D. Hill, John R. Surdu and Curtis A. Carver, Jr.Department of Electrical Engineering and Computer Science

United States Military AcademyWest Point, NY 10996

{dj0165 |dj6106 | dc8177}@usma.edu

James A. Vaglia and Udo W. PoochDepartment of Computer Science

Texas A&M UniversityCollege Station, TX 77843

{jvaglia | pooch}@cs.tamu.edu

The United States Army is embracing the use of newinformation technologies to achieve tactical advantageover potential adversaries. Existing and future informa-tion systems place a significant load on the tactical datanetwork, resulting in a bandwidth management crisis, yetthere is no prioritization, allocation, planning, or manage-ment tool available to simulate information flows overtime for different communications configurations underdifferent operational conditions. The development of sucha tool requires the implementation of a communicationnetwork model and the supporting discrete-event simula-tion system. Models for the information systems thatinduce flows, the command posts using the informationsystems, and the influence of operational conditions on theinformation flows are also required, as is a graphical userinterface that allows the tactical planner to configure thesystem and set up data capture. The visual developmenttechniques used in this tool make it easy for the planner todesign and build communication networks to supportoperations, then interactively reconfigure the network,run "what-if" scenarios, and visualize the effects. Thesystem can be used for training, design of experimentalnetworks, and to support rapid decision-making.

Keywords: Tactical communications, visual-ization, decision aids, information flow, dis-crete event simulation

1. IntroductionThe United States Army wants to improve the use ofinformation systems to achieve tactical advantageover its adversaries. Various systems are already de-ployed, and as the Army modernizes its forces andupdates its doctrine, new uses for these existing sys-tems will be developed. Simultaneously, the Army isinvestigating applications of new information tech-nologies in the tactical arena. These new capabilitiesand new systems place increasing and uncoordinateddemands on the tactical data network, resulting in abandwidth management crisis. Unfortunately, there isno mechanism for prioritizing the information flowsor for determining the best allocation of availablecommunication system resources to support particu-lar operational conditions. There is also no ability toexamine the impact of new capabilities or new infor-mation systems on the information flows.

The Information Flow Design and Evaluation Toolwas developed to support communication planners inan Army division and to enable experimentation.During tactical operations the communication net-work and the information flows traveling over itchange significantly. The planners need a tool that al-lows them to consider different scenarios and developthe most effective configurations, improving commu-

SEPTEMBER-OCTOBER 2001 SIMULATION 229

nications capabilities and increasing combat effective-ness. They also need a tool to examine the potentialeffects of current and future battlefield informationsystems. This tool must be able to simulate the flowson the data network over time for different communi-cations configurations under different operationalconditions. The major design components of the toolare the supporting discrete event simulation mecha-nism, the communications network, the Army BattleCommand Systems, the Command Posts, and the con-ditions they operate under.

Two major goals for the system are to provide a vi-sual development environment and to display the re-sults in an easy to understand visualization. Drag anddrop methodologies and other visual techniques suchas right-click functionality and pop-up menus areused for placement of tactical entities and establish-ment of radio links. The loads placed on the systemand the bandwidth utilization are visually repre-sented for easy interpretation by the user. The systemenables planners to rapidly determine viable configu-rations based on actual mission requirements and cur-rent systems availability that make more effective uti-lization of the available bandwidth.

2. The Tactical Information EnvironmentWhen an Army Division deploys in the field it buildsa complex information infrastructure. The specificcomposition of that infrastructure depends on severalfactors. Different types of operations, their subordi-nate phases, and the specific missions of the Com-mand Posts create different information processingand generation demands on the Army Battle Com-mand System and the supporting communicationsnetwork. Figure 1 depicts the interaction of all ofthese factors and how they will be modeled.

The type of operation has a major impact. An Armydivision can conduct a wide variety of operations,each of which places different information require-ments on the communications infrastructure. Typi-cally, operations are divided into phases. Changingfrom one phase to another often results in new unitpositions, activities, and information flows, necessitat-ing a complete reconfiguration of the communicationsnetwork.

The subordinate units have assigned missions andperform tactical tasks, and they both consume andproduce information that must pass through theirCommand Posts (CPs). CPs are the nerve center forunits, ranging from small battalion CPs to the very

Figure 1. The Tactical Information Environment and the layers of the system design

230 SIMULATION SEPTEMBER-OCTOBER 2001

large division CPs. Every CP has different responsi-bilities and information processing requirements. Ad-ditionally, when the CPs have to move as part of theirmission, or are attached to a different higher head-quarters, reconfiguration of the ABCS systems and thecommunications network are required.

Within the CPs, the demands for tactical band-width come from the information systems that formthe Army Battle Command System (ABCS) [1]. ABCSis a family of several distributed computing systems,seven of which are identified in Table 1. Each Com-mand Post has a different configuration of ABCS sys-tems, and may have multiple systems of any giventype.

All of the information flow travels over the tacticaldata network, known collectively as the Mobile Sub-scriber Equipment (MSE) system. MSE “provides bothvoice and data communications on an automatic, dis-crete addressed, fixed-directory basis using floodsearch routing [2].” The MSE system uses routerscalled Node Centers (NCs) to form the backbone ofthe communications network. Small Extension Node(SEN) and Large Extension Nodes (LEN) routers areassociated with CPs and connect to the NC backbonewith either a wire or radio link. There are significantrestrictions on how many SENs can be connected to asingle NC and on the total bandwidth. Consequently,tactical bandwidth is a crucial and very limited re-source that must be carefully managed to support tac-tical operations.

3. The Information Flow ChallengeThe challenge for division communication plannerslies in designing and setting up the communicationsinfrastructure to support information flows for cur-rent and future operations. It is prohibitively expen-sive to deploy the Division communications structure,Command Posts, and information systems to the fieldevery time an experiment is desired. Even if it wasnot, it would be very difficult to stimulate the actualsystems without conducting full-blown division op-erations, including the participation of an adversaryforce.

The planners need an automated tool for designingthe tactical data network to meet the expected databandwidth requirements of the battlefield informa-

tion systems. This tool must be able to simulate theflows on the data network over time for differentcommunications configurations and different opera-tional conditions. The tool must have a good model ofthe information flows to be able to predict networkperformance. Ultimately, the tool will allow the plan-ner to define “what if” scenarios, such as the loss of amajor communications node or significant change inoperational conditions.

4. Related WorkPrevious research related to this work has focused onthe lower level communications architecture, includ-ing protocols, switching, and devices. The MSE Sys-tem Control Center, Version 2 (SCC-2) has a NetworkPlanning Tool (NPT) built into it [2]. The NPT oper-ates at the level of asset placement, terrain analysisprofiling, frequency assignment management, andradio/antenna system engineering. The Tactical Inter-net Modeling and Simulations (TIMS) system focusesat the level of switching, protocols, and routing algo-rithms [3]. The Operational Planning and Simulation(OPSIM) system allows planners to build large-scalemilitary networks while still being able to modify andobserve the effects at the device level [4]. The InterimDivision Design Tool allows for new equipment andprotocols to be modeled and tested [5]. None of thesesystems consider the information flows driven at thehighest level by tactical entities under specified opera-tional conditions.

5. A Design and Evaluation ToolThe Design and Evaluation Tool must provide theplanners with several capabilities. Breslau et al., iden-tify several requirements for network simulations,among which are scenario generation, visualization,and extensibility [6]. They also state the requirementsfor network simulation scenarios as “network topolo-gies that define links and their characteristics, trafficmodels that specify sender and receiver locations anddemands, and network dynamics that include nodeand link failures.” An additional requirement, ofcourse, is the ability to capture relevant data foranalysis.

The division Information Flow Design and Evalua-tion Tool was developed with the idea of getting the

Table 1. Components of the Army Battle Command System

ABCS SystemsGlobal Command and Control System-Army (GCCS-A)Maneuver Control System (MCS)Advanced Field Artillery Tactical Data System (AFATDS)Air and Missile Defense Planning and Control System (AMDPCS)All Source Analysis System (ASAS)Combat Service Support Control System (CSSCS)Force XXI Battle Command Brigade and Below (FBCB2)


maximum benefit from visual development and visu-alization of the results. With that in mind, the specificrequirements for the tool are stated below.

• Scenario Generation. The communication plannersshould be able to interactively place and configure theCommand Posts (and their associated ABCS informa-tion systems), the communications network compo-nents, and the links between them. The tool shouldprovide a drag-and-drop mechanism that makesbuilding the scenario a simple, rapid process.• Defined Links and Characteristics. The constraints ofthe components must be built into the visual objectsthat represent them. For instance, the number of con-nections between nodes and their bandwidth alloca-tions should be automatically set up when the usermakes the connection with the visual drag-and-dropmechanism.• Traffic Models. This tool must be able to simulate theflows on the data network over time for differentcommunications configurations and different opera-tional conditions. This requires the system to generaterealistic information flows from each information sys-tem under particular operational conditions.• Data Capture. The system must be able to capturedata about saturation and identify offending informa-tion systems or bottlenecks in the communicationsnetwork.• Visualization. The system should visually displaybandwidth saturation on links and bottlenecks at MSENodes in a manner that makes is easy for the plannerto understand at the aggregate level what is going onin the communications network. The planners canthen “drill-down” to the specific statistical data theyare interested in.• Network Dynamics. The planners must have the abil-ity to apply abrupt modifications to the communica-tions network, such as the loss of a node or the elimi-nation of a CP along with its ABCS informationsystems. These dynamic changes must be handled bythe simulation system in the same manner as the realcommunications network. The changes must also beapparent in the visualization presented to the plan-ners.• Extensibility. If new components, protocols, or in-formation systems are produced, or new informationabout information flows under particular operationalconditions is available, incorporation into the systemshould be as simple as “plug and play.”

6. Visual Development and VisualizaitonThe graphical user interface (GUI) enables interactivedesign of the MSE communications network, place-ment of the CPs and their associated ABCS boxes,configuration of the operational conditions, executionof the simulation, and visualization of the results.The planner can use the GUI to change the communi-

cation system setup, the operational conditions, andthe CP locations interactively. This is also the visual-ization mechanism for observing the effects of thetraffic-flow over the communication architecture frommessages generated by the ABCS boxes under givenoperational conditions.

The system is designed to be as visually interactiveas possible, providing for visual placement of entitiesthrough drag and drop, visual connection of radiolinks by dragging, and visual representation of loadsand bandwidth utilization. The screen capture in Fig-ure 2 shows a demonstration setup on a piece of FortHood, Texas, terrain. Although the CPs and MSEnodes are placed artificially close for clarity, the im-age depicts the interaction mechanism and the visual-ization of the results.

6.1. Placement of EntitiesThe first step in designing the communications sys-tem is to load a map as a visual reference in placingthe CPs and MSE nodes. The map is contained in ascrollable view port, allowing the planner to panacross the entire area of operations. The system inter-face includes two palettes. The first palette containsicons representing the three types of MSE Node—SEN, LEN, and NC. The second palette contains iconsfor each type of CP normally found in the divisionarea of operations. Since there are many differenttypes of CPs, this palette is scrollable, allowing theplanner to rapidly find the desired icon. The plannertypically begins by placing the CPs on the map in ac-cordance with the operational plan by using a “dragand drop” gesture with the mouse that places a newinstantiation of the icon on the map display. The sametechnique is used to place MSE Nodes. Once on themap display, both MSE Nodes and CPs can be freelyrepositioned with a drag gesture. All entities retaintheir position on the map when it is scrolled.

6.2. Establishment of LinksThe system uses a “rubber-band line” mechanism forestablishing the radio links between entities. That is,the user clicks on an entity and drags the mouse toanother entity while a visual link is constantly main-tained between the source entity and the point of themouse. When the mouse is over the target entity, theplanner releases the mouse and the system attemptsto establish the link. To distinguish this drag gesturefrom an entity movement gesture, the right mousebutton is used. It is at this point that the rules formaking links are enforced. If there is not an availableradio port of the correct type on both ends, the link isdenied, otherwise it is established. If it is a high-speedlink, a thicker line is used to represent the higherbandwidth. If it is the second or third low-speed linkbetween a Small Extension Node (SEN) and a NodeCenter (NC), then the width of the line is increased.


The visual representation of the links retain their“rubber-band” properties so that if an entity at oneend is moved by the planner, all of the visual linksfollow the entity. Each visual link has a line-proximitymethod for determining how close a mouse-click is tothe link. If the planner right-clicks within three pixels(configurable) of the line, a pop-up-menu appears of-fering options for that link, such as deletion.

6.3. Execution Under Particular Operational ConditionsOnce the CP and MSE Nodes have been placed andthe links established, the planner sets the OperationalCondition (OC). The system uses a much finer granu-larity in describing the OC than the operations andphases normally associated with plans. For example,the operation could be an Area Defense, the phasecould be counter-attack, and the operational conditionwould be specific to the artillery fires and helicopterstrikes that are part of that phase. The OCs mark aclear distinction in the types of information flows be-tween particular ABCS systems.

Now that everything is in place and the OC hasbeen specified, the planner starts and controls thesimulation with the Simulation Toolbar (in Figure 2,the panel that contains the time display and the Stop,

Pause, and Go buttons). VCR-like controls are usedsince they are more familiar to most people thansimulation instructions. In fact, the planners do noteven have to be aware that there is a simulation run-ning in the background.

6.4. Load and Bandwidth VisualizationAs the simulation runs, the planner can observe theeffect of the information flows on bandwidth utiliza-tion. The color of the MSE Nodes represents the load,or backlog, of information flows trying to passthrough the node. The color of the links represents thebandwidth utilization over a (configurable) time win-dow. The color-coding itself is configurable, but gen-erally follows the convention shown in Table 2 (forclarity in grayscale, the name of each color is also pro-vided).

The screenshot in Figure 2 provides several inter-esting examples. The bandwidth utilization is veryhigh on the links between the TAC CP and the MAINCP on the northern links. An alternate route existsthrough the NCs to the south, but the green coloringindicates they are underutilized. Within the NC back-bone, there is a completely un-utilized (black) high-speed link from the upper-left NC to the lower-middle NC. The planner could consider moving this

Figure 2. Prototype system


link between the two center NCs to help relieve theflows between the TAC CP and the MAIN CP. Thelow-speed link from the SEN for the Brigade CP in thesouthwest corner is saturated (red) to the southwestNC, but the high-speed link carrying the traffic north-east to the north-center NC is only lightly saturated.The planner could consider adding additional low-speed links out of the SEN to increase the flow.

6.5. InteractionThe planner can interact with the system while it isrunning to observe the effects of changes in the sys-tem. For instance, the planner can remove a compo-nent by right-clicking it and selecting “Delete” fromthe drop-down menu. When an MSE Node is re-moved, all links to it are automatically dropped also.The system detects the loss and reroutes the informa-tion flow. The same is true if a planner removes a link.MSE Nodes can be dragged back into the display andhave new links established. When information flowsare congested (information is being dropped), the sys-tem will look for better routes and find the newly in-stalled links. The planner also has the ability to freezethe action to capture visualization and data at a spe-cific point, or stop the simulation and start over.

7. Design and ImplementationOne of the most important parts of the design of thistool is the separation of functionality that provides forflexibility and ease of analysis. This section expandson the discussion of the methodology presented byHill et al. [7]. The key to the model is the relationshipbetween operational conditions, the tactical entities,and the information flows over the communicationnetwork. In this design, Operational Conditions areseparated as a factor that affects all other componentsand distinct layers are used for the tactical entities, theABCS boxes, the MSE communications network, andthe discrete event simulation mechanism. See Figure 1

for a depiction of the layers. This layered design al-lows for flexibility in construction and analysis, andmakes the addition of new components or protocolsvery simple.

7.1. Operational ConditionsAn Operational Condition is any distinguishable por-tion of the operation (or phase of an operation) thatcauses a significant alteration in the behavior of thetactical entities, the configuration of the communica-tions network, or the distribution or utilization of theABCS information systems. Associated with each OC,is a set of message patterns for each type of ABCS sys-tem at each type of command post and at each ech-elon. OCs can be chained in order to produce phases,and therefore the entire operation. When the systemtransitions from one OC to the next, Flow Generators(see Section 7.3) are used to produce the message pat-terns appropriate to the new OC.

7.2. Command PostsCommand Posts, which contain the ABCS boxes, canbe placed in different locations, removed from play(taking their ABCS boxes with them), or be given adifferent mission (affecting the nature of their infor-mation flow patterns). In this case, the effect on infor-mation flows and on the communications networkcan be observed. The CPs are modeled so that theycan generate varying flows through the informationsystems onto the communication system. CPs con-tains some number of each type of ABCS system, andeach system produces messages according to a user-configurable distribution (for each particular OC).Currently, information flows generated by multipleABCS boxes of the same type (MCS boxes, for ex-ample) within a tactical entity are aggregated. Futureiterations of the tool may decompose the elementswithin the tactical entity and address management ofinternal communications.

7.3. Army Battle Command System (ABCS)The ABCS systems are modeled and considered ascomponents within the appropriate CP. The OCscause the ABCS systems to generate different types ofinformation flows. ABCS systems are in a separatelayer so that generation of information flows is a dis-tinct element that causes traffic (message/packetlevel) over the MSE communications network. In thisway, message patterns between individual ABCSboxes can be altered and the effect on the communica-tions network components and on the CPs can be ob-served.

Because the purpose of this simulation was to mea-sure the network traffic between and not within head-quarters, each ABCS system type (e.g., MCS, ASAS,AFATDS, etc.) within a CP is represented as a singleentity. In addition, communications between ABCS

Table 2. Color Representation of Loads and BandwidthUtilization


boxes in the same CP are not modeled, and competi-tion for access to the associated MSE Node is incorpo-rated into the aggregation of ABCS systems within thetactical entities.

In order to measure the load on the various linksand node centers, the simulation needed a method ofgenerating loads (in the form of messages). For pur-poses of this model, messages are not broken into thevarious protocol packets; rather, they are treated assingle messages. It is not important for this simulationto know that a message has been broken down intofour TCP/IP packets of 1500 bytes each. It is impor-tant, however, to know that the message is 6000 byteslong. Length of packet headers and time to disas-semble and reassemble messages is ignored. Messagesare generated from distributions defined by the userto replicate actual message generation under particu-lar operational conditions.

Each ABCS entity within a CP has Flow Generatorsattached to it. The number and types of Flow Genera-tors depends on several factors, including the type ofheadquarters, the particular operational condition,and the messages that normally pass between the CPs[1]. Messages have two dimensions—frequency andlength. Frequency indicates how often the message isgenerated, and length indicates the number of bytesin the message. Both dimensions of the messages canbe represented as either table lookups or probabilitydistributions. During research and development ofthis system, it became clear that some messages mightbe best represented by probability distributions andothers might be best represented as a table lookup.

Since the exponential distribution is often used torepresent inter-arrival times of customers and mes-sages, this distribution is supported in the prototypesystem [8]. In addition, the normal distribution is sup-ported. The current implementation only supportsthese two distributions, but a wide variety of distribu-

tions can be allowed with minimal effort, includingWeibull, gamma, uniform, log-normal, variousPearson distributions, and triangular.

When CPs are instantiated, so are their associatedABCS systems. Each ABCS system instantiates a FlowGenerator, which builds the initial set of Message Cre-ators (MCs), then monitors the current OC so that itcan delete and add appropriate Message Creators.When a Flow Generator for an ABCS system is cre-ated, it reads a configuration file that indicates whichMCs are needed based on the ABCS system’s head-quarters type, echelon, and the indicated operationalcondition. An extract of the information contained inthis configuration file is shown in Figure 3.

When an MC is instantiated it is given the messagefrequency and message length information by itsowning Flow Generator, as specified in the tablelookup or probability distribution. When the simula-tion is initialized, each MC determines the time of itsfirst message and schedules a message arrival event inthe simulation event queue. It also determines whenits next message should be created and schedules afuture message creation event. As the simulationprogresses and a message creation event is removedfrom the event queue, the associated MC executes theevent, creating a new message and scheduling a mes-sage arrival event at its associated ABCS system.

The system needs to be able to capture the specificdata about the impact of information flow at any par-ticular point in the system. The planner is allowed toattach statistics modules to any desired MSE Node orLink to capture saturation or other data. For example,the captured data can include the sending ABCS sys-tem, the receiving ABCS system, the specific message,and the links over which that message passed. Al-though the planner will “attach” the modules to iconsrepresenting elements of the communications net-work, the actual statistics collection occurs within the

Figure 3. Extract from a Flow Generator Configuration File


Simulation Executive, since it is aware of every eventand every entity. The statistics mechanism also servesas the repository for information required for “play-back” visualizations of the loads on the communica-tion network.

7.4. Communication NetworkThe elements of the Mobile Subscriber Equipment(MSE) communication network architecture are mod-eled by the number, type, and bandwidth of their con-nections, as well as rules for how those connectionsare made. See Figure 4 for a depiction of the Link,Port, and MSE Node objects used in the model.

The Link object is a separate entity so that it can betagged individually for statistics capture, analysis,and visualization. The link is able to execute a “startmessage” event at the scheduled time. It responds toqueries from the ports at either end of the link aboutthe next available start time. It answers the query bydetermining how fast the sending port can send themessage and how fast the receiving port can receiveit, then determining the elapsed time for the size ofthe message. The slowest data rate of the two Portsdetermines the elapsed time for the message, and thetime at which the next message between the two portscan begin. The message elapsed time is what con-sumes time when the system is run on the simulator,

and what causes backlogs at the Nodes and saturationof the Links. Since multiple messages may pile up oneither port, the Link has to keep a “request queue” inorder to remember what start time has been prom-ised.

The Port object is the mechanism for connectingLinks to MSE Node objects (defined below). The Portmaintains specifics about maximum bandwidth, cur-rent bandwidth capability, and an output queue tohold outgoing messages until the Link is ready forthem in turn. This also helps track statistics, such asthe length of the output queue, the delta between ar-rival and departure time, etc. TheSmallExtensionNode, the LargeExtensionNode, andthe NodeCenter objects are subclasses of the MSENode object. Every instantiation of an MSE Node hassome number of high-speed and low-speed ports de-pending on its type.

The MSE Node performs several steps when it ex-ecutes a message arrival event. First, it checks to see ifthe destination ABCS system is attached to this MSENode (SEN and LEN only). If so, the message is sentto the ABCS system. If not, it is processed for furtherdelivery. Second, if the routing table contains an entryfor the appropriate port for the destination ABCS box,then it queries the Link on that Port about the nextavailable start time. The MSE Node then schedules a

Figure 4. MSE Components


start time for that message with the Link. Since anMSE Node can have more than one Port and the Linksmay be occupied, processed messages are effectivelyadded to the tail of the appropriate Port outputqueue. For the purposes of the simulation, the move-ment of arrived messages to queues within a node isinstantaneous.

It is important to note that the MSE Node alsoschedules a timeout event in case no acknowledgmentis ultimately received for the sent message. This en-sures that the message can be re-sent, and when ap-propriate, a search can be initiated to determine thenew best path to the destination ABCS system. Theremay not be a new path, due to destruction of all nodesproviding a path or the destruction of the CP contain-ing the destination ABCS system.

The search to find a new path to a destinationABCS system is a standard flood search of existingLinks, but any algorithm could be tried (and ana-lyzed). The searching MSE Node inserts a floodsearch message into the appropriate Ports’ messagequeues (schedules them with the simulation). It alsoschedules a timeout event for the flood search. TheMSE Node maintains a status of the replies, and whenthey are all back (or the timeout has occurred), theMSE Node determines the correct path and then in-serts the message(s) into the queue of the appropriatePort (reschedules them).

7.5. Discrete-Event Simulation MechanismAt the lowest level, there is a discrete-event simula-tion (DES) mechanism that enables the representationand analysis of the communications system underparticular operating conditions. Hill et al., providemore detailed information about the methodology be-hind the simulation [9]. The supporting simulation isa Java implementation of common DES techniques,defining a simulation executive, simulation partici-pants, and a simulation event queue.

A Simulation Executive (SimExec), implemented asthe DESimExecutive object, manages the event queueand maintains the simulation time. It accepts requestsfrom the simulation participants to schedule an eventthrough a call to its Schedule() member function. Aseach event is pulled from the queue, the Execute()method for the appropriate participant is called. Ev-ery object that participates in the simulation mustimplement the appropriate member functions for theJava interface DESimParticipant, such as the Regis-ter() member function that establishes communica-tions with the simulation executive.

The fundamental simulation event is theDESimEvent object. Instantiations of DESimEventsare constructed with a SimTime parameter and a pa-rameter for the participant that will execute the event.As each event is removed from the event queue, theExecute() method of the associated participant iscalled. New types of simulation events are created by

extending the DESimEvent object to include any addi-tional information or processing steps that are re-quired. This is particularly useful for the creation ofdata capture events.

8. ConclusionFuture work on this project will include more realisticrepresentation of operational conditions, particularlyas more refined information flow data is captured andanalyzed. The system will work at a higher fidelity,incorporating battalion and lower tactical entities, andperhaps interfacing the lower-level function toOpNet, NetCracker, or other device-level networksimulators. It will also incorporate improvements toMSE devices, and new generations of equipment thatthe Army is considering. As the system becomes moresophisticated, it will eventually include artificial intel-ligence tools to identify problems and propose solu-tions.

The visual development techniques used to meetthe requirements identified in section 5 for this toolmake it easy for the planner to design and build com-munication networks to support operations. In lessthan ten minutes the planners can create and config-ure a virtual communications network that wouldtake the division Signal Battalion an entire day tosetup. Once the network and conditions have beensetup, the planner can execute the simulation and vi-sualize the information flows being carried by thatnetwork. Armed with this understanding, the plannercan interactively reconfigure the network, run “what-if” scenarios, and observe the effects. Analysis of theresults can form the basis for establishing the actualnetwork to be used during the operation.

The system can be used in a variety of ways, in-cluding training of new planners, design of experi-mental networks or incorporation of experimentalcomponents, and support for rapid decision-making.The design and evaluation tool enables planners torapidly determine viable configurations based on ac-tual mission requirements and current systems avail-ability. This results in more effective utilization of theavailable bandwidth and assists in determiningprioritization of information flow in the future.

9. References [1] U.S. Army, Staff Leaders Guide for the Army Battle Command Sys-

tem, U.S. Government Printing Office, Washington, D.C.,1998.

[2] U.S. Army, Field Manual 11-55 Mobile Subscriber Equipment(MSE) Operations, U.S. Government Printing Office, Wash-ington, D.C., 1999.

[3] Robinson, C.A. “Warfighter Information Network HarnessesSimulation Validation,” Signal Magazine, Vol. 52, No. 5, pp27-31, 1998.

[4] Atamna, Y. “OPNET-Based Modeling and Simulation of C4Systems,” in Proceedings of the Advanced Simulation Technolo-gies Conference 1999 (ASTC '99), pp 109-116, San Diego, Cali-fornia, April 11-15, 1999.


[5] CTTI-Georgia, “Projects,” available at http://www.ga.erg.sri.com/projects.html, January 17th, 2000.

[6] Breslau, L., Estrin, D., Fall, K., et al., “Advances in NetworkSimulation,” IEEE Computer, Vol. 33, No. 5, pp 59-67, 2000.

[7] Hill, J.M.D., Carver, C.A., Jr., and Pooch, U.W., “A TacticalData Network Bandwidth Design and Simulation Tool,” inProceedings of the Advanced Simulation Technology Conference:Military, Government, and Aerospace Symposium 2000, pp 43-48, Washington, DC, April 16-20, 2000.

[8] Law, A.M. and Kelton, W.D., Simulation Modeling & Analysis,McGraw-Hill, Inc., New York, 1991.

[9] Hill, J.M.D., Carver, C.A., Jr., and Pooch, U.W., “InformationFlow: Tactical Network Design and Bandwidth Manage-ment,” in Proceedings of the Eighteenth IASTED InternationalConference on Applied Informatics (AI2000), Innsbruck, Aus-tria, February 14-17, 2000.

Documents

An Interactive Design, Visualization, and Analysis Tool ... · An Interactive Design, Visualization, and Analysis Tool for Information Flow ... (FBCB2) SEPTEMBER-OCTOBER ... tem under