Exercise Registration and Initialization Using

Simulation Management PDUs

Authors

Scott Reinhart and Yilmaz Cengeloglu

Lockheed Martin Missiles & Space

Advanced Technology Center

KEYWORDS

Exercise Management, Feedback, Planning, After Action Review, Protocol Data Unit

Abstract

The Distributed Interactive Simulation specification states that a Simulation Manager (SM) creates and initializes an entity using type and characteristic data established off-line and prior to the creation. There are problems associated with this prior knowledge approach. It assumes there is a simulation capable of supporting an entity and that the available entity information is accurate. There is also no provision for supporting unknown entity types. These prior knowledge problems make achieving effective exercise collaboration difficult. The current approach lacks the ability for the SM to register potential exercise participants and query them for their type and characteristic data.

This paper discusses a paradigm whereby the SM uses existing simulation management PDUs to register entities on the network and then interactively selects and initializes only those entities required for an exercise. Each entity supplies its profile information to the SM as an HTML form and receives its setup data as HTML responses. Since the SM no longer requires prior knowledge about an entity, it is able to manage any type of entity. This interactive exercise initialization allows a SM to gather the available exercise resources, select the required entities from these resources and initialize each entity regardless of its type.

Background

Setting up a DIS exercise involves the interaction of a SM and one or more simulations, which in turn generate one or more entities for the exercise. There are several methods available to do this. One involves creating and initializing the entities on the simulation. The SM then starts the exercise with a Start/Resume PDU and the simulations start broadcasting their Entity State PDUs. Another method is to create the entities from the SM using the Create Entity PDU and initialize the entities using Set Data PDUs. This method, however, only works if the SM has accurate information about the simulation and its entities.[1] If the information is lacking is some respect, the creation and/or initialization will fail. In addition, this method does not take into account new simulations that may be on-line but not in the SM database.

An alternative method, which is presented here, is to register all available entities with the SM and allow the SM to select which entities to add to an exercise. The SM also queries the entity to supply its own setup data in HTML format, which is modified by the SM and returned to the entity. With this method, the SM requires no prior knowledge about simulations or entities. Everything required to set up an exercise is supplied to the SM by the entities. It is interesting to note that the idea of remotely managed entities could be extended to stealths and mission planner systems, allowing them to be controlled from a SM as well. Figure 1 shows the flow of an exercise initialization.

Figure 1 : SM steps used to setup an Entity to participate in an exercise

Exercise Registration

The first task in setting up an exercise is to register all the entities with the SM. It is proposed that this is accomplished using a Create Entity PDU with the three fields of the Receiving Entity ID set to binary ones. This broadcasts the Create Entity PDU to all simulation applications on the network. The Standards Draft[2] specifies that an Entity field containing the maximum number minus one (2¹⁶-2) indicates that a simulation is to assign a number to the requested entity. Setting the Entity field to the maximum number (2¹⁶-1) would be interpreted by a simulation that it is to create all of its available entities, assign numbers to them and respond with an Acknowledge PDU for each one. Using the current Create Entity PDU with all Receiving Entity ID fields set to binary ones turns it into a Create All Entity PDU without requiring a new PDU type. From here on, this type of Create Entity PDU will be referred to as a Create All Entity PDU.

A simulation only responds to the Create All Entity PDU with entities that are capable of supporting remote setup. This prevents a SM from attempting to initialize an entity that does not support this feature. Simulations that support remote setup entities would only create entities that are not currently initialized. This means a simulation would respond to multiple Create All Entity PDUs with uninitialized entity Acknowledge PDUs.

To indicate that an Acknowledge PDU is a response from a Create All Entity PDU, it is proposed that the Acknowledge PDU contain a new enumeration value for the Acknowledge Flag. Note that a single Create All Entity PDU could generate multiple Acknowledge PDUs from a simulation if that simulation supports more than one entity. Figure 2 illustrates the entity creation and registration process.

Figure 2 : Registering all Entities in an Exercise with a Create (All) PDU

Multiple Simulation Managers

In an exercise with multiple SMs, each SM would receive an Acknowledge PDU for all entities that respond to the Create All Entity PDU. There are several ways to handle which SM controls which entities.

One method is the first SM to request setup data from an entity is granted access to the resource. Requests from other SMs for the entity are refused at this point. So even though several SMs may know of the existence of an entity, only one controls it. This allows several SMs to acquire and manage the entities of most interest without knowing about the other SMs in the exercise.

Another method is for only one SM to generate the Create All Entity PDU. Other SMs on the network respond with an Acknowledge PDU like an entity but with a simulation manager type. The master SM would assign entities to a slave SM. The slave SM would then request the resource for itself. This scenario allows several SMs to control different parts of an exercise while the master SM allocates resources and, presumably, controls the exercise execution.

Exercise Reset

To reset an exercise and start over, it is necessary to remove and reinitialize all entities in the exercise. To perform this task , it is proposed that the Remove Entity PDU with the three fields of the Receiving Entity ID set to binary ones specifies to all simulations they are to remove all of their entities. From here on, this type of Remove Entity PDU will be referred to as a Remove All Entity PDU. Figure 3 shows how the Remove All Entity PDU operates.

Figure 3 : Removing all Entities in an Exercise with a Remove (All) PDU

Although it is possible to use Remove Entity PDUs for this task, a Remove All Entity PDU is processed by all the systems in the exercise. In particular, an exercise with multiple SMs allows one SM to reset the entire exercise, including all of the other SMs. Using individual Remove Entity PDUs does not give this flexibility since there is no guarantee that any one SM knows about all the entities or SMs in the exercise.

HTML Setup Data Format

It is necessary for the SMs and entities to agree on a common setup data format. It is proposed that the Hyper Text Markup Language (HTML) be selected as this format. Although there is insufficient room here to fully address the issue of HTML as the data format, the rationale for selecting HTML is worth discussing here.

HTML has grown in popularity due to the rapid expansion of the World Wide Web on the Internet. HTML is a language that describes the layout of a screen page using tags enclosed by angle brackets. HTML specifies various types of entry fields using the <FORM> tag. Multiple "form" pages are handled by reference tags in the HTML page description. Submitting an HTML form returns the data as a response string. This response string consists of a reference label and a series of attributes and values. Figure 4 illustrates how HTML pages and responses would flow between a SM and multiple entities during the set up of an exercise.

Figure 4 : How a SM sets up Entities using the HTML Form concept

These features means HTML contains all the ingredients necessary for setting up an entity for an exercise. The page layout description allows the entity to supply its data as a form without the SM knowing in advance what is contained in the form. The SM merely displays the form page on the screen and allows the operator to enter data. More than one form may be displayed at a time since HTML supports reference links to additional pages.

When the operator completes the form, they return the data to the entity as a series of response strings. Again, the SM does not need to know what data is in the response strings. The entity then parses the returned response strings to extract the data.

Figure 5 is a screen shot of an F18 fighter form displayed on the ExMan simulation manager program from Lockheed Martin Missiles & Space. The data in this form is greatly simplified for inclusion in this paper. The real form would contain all the information required by the F18 to participate in an exercise.

Figure 5 : Entity HTML Form displayed on the ExMan simulation manager

This approach for exercise setup takes the view that a SM does not need to know what is contained in the entity setup data, it only needs to know how to present the data to the SM operator. Using HTML as the data format allows a SM to set up any type of entity. All the information required by the SM exists in the form as HTML tags. In fact, any exercise participant could use HTML as its setup format, even other SMs. Due to its popularity, there are a myriad of books available on HTML.[3] Another benefit of HTML is the appearance of web authoring tools that use an interactive interface to create the HTML code for a web page or, in this case, an entity form.

Entity Setup Data Transfer

Once the SM registers an entity, it requests the entity to supply the setup data. This is done using the existing Data Query PDU, Set Data PDU and Data PDU. There are two types of setup data that a entity may support; Behavior data for the exercise and After-Action Review data to collect during an exercise.

The Behavior data contains the information the entity requires to participate in the exercise. This includes but is not limited to items such as initial starting location, movement path, armament, target locations, radar parameters, etc. After the SM modifies the data, it is returned to the simulation.

The Behavior data is the current state of the entity and not necessarily the initial state of the entity. After a Remove Entity PDU or Remove All Entity PDU, the Behavior data is the initial state. If the request comes during a pause in an exercise, however, the Behavior data represents the current state of the entity. This way, a SM can pause an exercise and request the Behavior data from all the entities. The SM saves this Behavior data, which it uses later to restore an exercise to a previous state. This allows the SM to implement an exercise save and restore mechanism using the existing simulation management PDUs.

The After-Action Review data includes a list of the data types the entity could save during an exercise. Since this data can be quite extensive, it is impractical to send it over the network during an exercise. The SM selects the data it wishes saved and returns the selections to the entity. During the actual exercise, the simulation saves the data locally so it may be retrieved later. This data is not required during the exercise but is valuable for analyzing the exercise after the action. For an F18 fighter, this might include information such as target lockon, missile release switch and launch times, trigger switch and bomb drop events, etc. An Entity would normally allow modification of its After-Action Review data before and not during an exercise.

Requesting Setup Data

Requesting a simulation to supply its setup data is done using the Data Query PDU as per the Standards Draft.[4] It proposed that two new enumeration values be added to the Request ID field of the Data Query PDU. These enumerations specify whether the requested data is the Behavior data or After-Action Review data.

The entity responds with a Data PDU that contains the requested data. Since the data may be too large to place in a single Data PDU, it is proposed that the Response Status field contain a new enumeration value that specifies the enclosed data is not complete. The SM would check this field and if the data is not complete, it would issue another Data Query PDU to the entity. The entity would continue to respond with partial data until it completes transfer of the entire data set.

Using multiple Data Query PDUs and Data PDUs to transfer a large data set requires the SM and entity agree on the data format specified in the Request ID field. For the case of setup data, HTML page descriptions are an ideal format since they consists entirely of text. It is simple to partition text data into smaller sets for multiple PDU transfer.

The entity would partition the data into sets small enough to fit in a single Data PDU. As the entity receives Data Query PDU, it places the next set into a Data PDU and sends it to the SM. A single Variable Datum is the most efficient way to place text data in a Data PDU. For its part, the SM retrieves each Data PDU and reassembles the complete data set from the Variable Datum. Figure 6 shows the steps necessary to request and retrieve setup data from an entity.