Joint Task Force Prototype

B.1 OMT Tables

OMT consists of a number of tables for specifying parts of a model. They are:

1. 1. Object Class Structure Table (OCST): Shows the class hierarchy along with publishable/subscribable information for each class.
2. 2. Attribute/Parameter Table (APT): Lists object attributes and interaction parameters along their data type, cardinality, units, resolution, accuracy, accuracy condition, update type and update condition.
3. 3. Object Interaction Table (OIT): Lists each possible interaction and associated information, such as its sender, its receiver and the attributes it affects.
4. 4. Enumerated Data Table (EDT): Lists the values of all enumerations.
5. 5. Complex Data Table (CDT): Lists the definitions of all structured data types.
6. 6. Object Class Definitions (OCD): Describes the role of each entity.
7. 7. Object Interaction Definitions (OID): Describes each interaction.
8. 8. Attribute/Parameter Definitions (APD): Describes each object attribute and interaction parameter.

We augment the OIT with the class of each interaction. Also, we add two tables to OMT to capture attribute relationships and specify policies for concurrent interactions.

1. 9. Attribute Relationships Table (ART): Lists each attribute dependency, its type, its mapping function and requirements and properties of the mapping function.
2. 10. Concurrent Interactions Table (CIT): Lists policies for resolving classes and instances of concurrent interactions.

B.2 Steps

The steps for incorporating UNIFY in JTFp are:

1. 1. Construct an MRE from the OCST and the APT
2. 2. Construct an ADG from the APT and the ART
3. 3. Select Mapping Functions for Dependencies in the ART
4. 4. Determine the Effects of Interactions from the OIT
5. 5. Resolve the Effects of Concurrent Interactions from the CIT
6. 6. Construct a Consistency Enforcer and an Interaction Resolver

B.3 Construct an MRE from the OCST and the APT

We construct a Platoon-Tanks MRE to execute a Platoon model and a Tank model jointly. Using the OCST for JTFp (shown in Table 14), we derive a Platoon from AggregateGroundPlayer, and a Tank from MobileGroundPlayer. Our Platoon-Tanks MRE consists of the representations of a Platoon and two Tanks, Tank1 and Tank2. The PS (publishable/subscribable) information associated with each class in Table 14 is used to manage data transfer within the HLA. UNIFY does not require this information.

From the APT, we determine the attributes that are part of the concurrent representations within our Platoon-Tanks MREs. For brevity, Table 15 shows only part of the APT for JTFp. The table lists attributes only for classes or base classes of Platoon and Tank. For each attribute, the designer may specify information such as its data type, units, resolution, accuracy, condition under which the specified accuracy is required and update type. The T/A and U/R information is not used in UNIFY .

From the OCST (Table 14) and APT (Table 15), we derive the attributes of a Tank and a Platoon. Table 16 lists the attributes of Platoon, Tank1 and Tank2. For brevity, we combine a number of attributes derived from the OCST and APT (second column) into one attribute (fourth column). We combine attributes that are logically similar and that have identical accuracy condition, update type and update condition. For example, we combine the attributes radar_detectable, elint_detectable, comint_detectable, ir_detectable and photint_detectable into an attribute called detectable. Likewise, we combine entity_name, federate_id, affiliation, motion_type, voice_nets, jtids_nets, trap_tre and commander_type into an attribute called initial_parameters. We combine such attributes so that we can present a simple MRE, for which an ADG will be presentable and specifying mapping functions will be manageable. Combining similar attributes is consistent with our discussion about assigning nodes of an ADG (§6.1.1). A node can be assigned to any subset of a representation for which a designer can specify how the effects of interactions must be applied. In practice, we expect designers to assign nodes to individual attributes rather than combined attributes.

B.4 Construct an ADG from the APT and the ART

We construct an ADG for the Platoon-Tanks MRE from the APT and the ART for JTFp. Since OMT does not support specifying relationships, we construct an example ART for our MRE (Table 17). In practice, we expect a designer to construct an ART specific to the models executed jointly. The specification of the relationship may be accomplished formally; in Table 17, we present informal specifications in the last column.

We construct an ADG for the Platoon-Tanks MRE. From Table 16, which was derived from the APT, we determine the nodes in the ADG. From the ART in Table 17, we determine the arcs in the ADG. The ADG is shown in Figure 67. The interaction dependencies to each attribute exist because interactions with other entities or internal actions of the MRE may change any attribute.

Dynamic semantics of attribute relationships may be captured by weighting dependencies. Dependency classes capture static semantics, whereas weights capture dynamic semantics. For our Platoon-Tanks MRE, we assign a weight of one to each cumulative dependency, and equal weights to distributive dependencies that have the same independent attribute. We select these weights in order to keep our subsequent discussion of mapping functions simple. Other weights for these dependencies are possible.

B.5 Select Mapping Functions for Dependencies in the ART

We select mapping functions to translate attributes among concurrent representations within the Platoon-Tanks MRE. Recall from Chapter 6 that mapping functions must translate values or changes in values of attributes from one to another. Additionally, it is desirable that mapping functions complete their translations in a time-bound manner, and that they be composable and reversible.

We show mapping functions for some dependencies in Table 18. The mapping functions are presented as pseudo-code. Error-checking has been omitted for brevity. Pseudo-code in the second column of Table 18 implements specifications in the last column of Table 17. If any Tank is detectable, Platoon is detectable. Likewise, if Platoon is detectable, all Tanks are detectable. Platoon is not detectable only if both Tanks are not detectable. If any Tank is engageable, Platoon is engageable. If Platoon is engageable, at least one Tank is engageable. Platoon is not engageable only if both Tanks are not engageable. If the damage_state of any Tank becomes 100%, the composition of the Platoon is reduced by one. The damage_state of the Tank is changed to ∞ to ensure that composition is not reduced further subsequently. Likewise, if composition is reduced by one (δcomposition = −1), a Tank whose damage_state was less than 100% previously is selected and its damage_state changed to 100%. Similarly, mapping functions for other dependencies can be constructed. For the last_cse_change attribute, a designer may employ different functions for the different parts, such as lat_at_last_cse_change, time_at_last_cse_change and hspd_at_last_cse_change. For example, the Platoon-level position, consisting of lat_at_last_cse_change, lng_at_last_cse_change and alt_at_last_cse_change may be defined as the centroid of the Tank-level positions. However, the Platoon-level time, time_at_last_cse_change, may be defined as the latest of the Tank-level times. Mapping functions such as those shown in Table 18 translate values or changes in values of attributes.

The mapping functions shown in Table 18 are composable and reversible. Moreover, since they are simple in construction, we expect that they will complete in a time-bound manner, thus ensuring that the Platoon-Tanks MRE is consistent at all observation times. When an interaction changes the value of any attribute, mapping functions propagate the change in the attribute to dependent attributes. For example, if an interaction changes the Tank-level attribute, detectable1, the mapping function fd changes the dependent Platoon-level attribute, detectable. Subsequently, the mapping function gd changes the Tank-level attribute, detectable2. Since fd and gd are composable, the change to detectable1 eventually propagates to detectable2. Since fd and gd are reversible, detectable1 does not change again as a result of the same interaction.

When an interaction occurs, traversing the ADG in Figure 67 and applying the mapping functions in Table 18 ensures that the Platoon-Tanks MRE is consistent at all observation times. Next, we determine and resolve the effects of concurrent interactions.

B.6 Determine the Effects of Interactions from the OIT

We determine the effects of interactions on the Platoon-Tanks MRE from the OIT. We show an augmented OIT in Table 19. The first column lists the name of the interaction. The next four columns list the class and affected attributes for the sender and receiver of the interaction. We augment each interaction in the OIT with its type (see Chapter 7): Type 0 (certain responses), Type 1 (uncertain responses), Type 2 (certain requests), and Type 3 (uncertain requests). We do not utilise the ISR (Init/Sense/React) information and the parameters of an interaction in UNIFY .

The OIT lists interactions among entities, but not internal actions of an entity. For example, the OIT does not list any interaction corresponding to our Platoon-Tanks MRE changing its course, because such an interaction is internal to the MRE. In UNIFY , internal actions are interactions. We add an internal action called ChangeCourse to the interactions in the OIT (see last row in Table 19) to show that UNIFY addresses internal actions as well as interactions with other entities. This interaction initiates a change in the course of an entity. The sender and receiver of ChangeCourse is the same entity. The class of that entity is Player. The interaction affects the attribute last_cse_change.

The last column in Table 19 lists the type of an interaction. Assigning a type requires information about the semantics of an interaction. In OMT, this information is available from the OID. For example, the OID lists the semantics of GetSeaState as a request that will be satisfied by an Environment entity. Hence GetSeaState is a Type 2 interaction. ReturnSeaState is the response to a GetSeaState. ReturnSeaState could be Type 0 or Type 1, but we assigned it to Type 1 because an entity may discard an update about the state of the sea. For the ChangeCourse interaction, we assumed that a change in the course of an entity is a request whose outcome is uncertain.

We determine the interactions that our Platoon-Tanks MRE can send and receive. In Table 20, we list the interactions that Platoon, Tank1 and Tank2 can send and receive. In the first column, we list the name of an interaction as the name in the OIT along with a suffix that indicates whether Platoon, Tank1 or Tank2 sends or receives that interaction. For example, the interaction GetLOSVisibility can be sent by an entity of class Player. Since Player is a base class of Platoon, Tank1 and Tank2, we distinguish the interaction GetLOSVisibility sent by these three entities as GetLOSVisibility-P, GetLOSVisibility-T1 and GetLOSVisibility-T2 respectively. In the second column, we indicate whether the Platoon-Tanks MRE sends (S) or receives (R) the interaction. In the third column, we list the attributes affected by the interaction directly, i.e., we list the set affects for the interaction. These attributes are determined from the OIT. In the fourth column, we list the attributes affected by the interaction indirectly, i.e., we list the set affects + for the interaction. These attributes can be determined from the ADG in Figure 67. Finally, we indicate the type of the interaction.

Any subset of the interactions in Table 20 may occur concurrently. Next, we show how to resolve the effects of concurrent interactions.

B.7 Resolve the Effects of Concurrent Interactions from the CIT

The effects of concurrent interactions can be resolved by implementing polices from the CIT. In practice, a designer constructs a CIT specific to the application. Since a CIT is unavailable in OMT, we construct an example CIT, shown in Table 21.

A designer specifies policies in the CIT for resolving the effects of concurrent interactions. The CIT consists of sets of concurrent interactions with dependent effects, policies for resolving them and conditions under which the policies are applicable. Concurrent interactions that are independent of one another can be resolved by serialization and are not specified in the CIT. Some interactions may be independent because they affect disjoint sets of attributes. Other interactions may be independent because their effects are applied in different time-steps, for example, interactions sent and received by an entity. Yet other interactions are independent because they are request-response pairs. Policies must be specified in the CIT for only the remaining interactions. Policies may be specified for classes of interactions (e.g., the last two rows in Table 21) or for instances of interactions (e.g., all the other rows in Table 21). In JTFp, many interactions do not affect any attributes. Although such interactions can be assumed independent, we do not make such an assumption. It is likely that the interactions affect internal attributes in the models. Since OMT is meant to be an interface specification, internal attributes are not listed in the APT. For consistency maintenance, a designer must list internal attributes as well in the APT. Since internal attributes are not listed, we will not assume that interactions that affect disjoint sets of attributes are independent. For example, although InitiateStrikeCommand-P, InitiateStrikeCommand-T1 and InitiateStrikeCommand-T2 affect no attributes, hence affecting disjoint sets of attributes, we specify policies for resolving these interactions. An Interaction Resolver for the Platoon-Tanks MRE applies the policies in the CIT only if the effects of concurrent interactions conflict. If concurrent interactions do not conflict, they may be serialized.

B.8 Construct a Consistency Enforcer and an Interaction Resolver

A Consistency Enforcer (CE) and an Interaction Resolver (IR) for an MRE maintain consistency and resolve concurrent interactions respectively. A CE consists of an ADG and mapping functions, whereas an IR consists of policies for resolving concurrent interactions. Figure 68 shows a JTFp Platoon-Tanks MRE. The MRE can interact at multiple representation levels -- the Platoon and Tank levels -- concurrently. Moreover, the concurrent representations within the MRE are consistent at all observation times.

A CE consists of an ADG and application-specific mapping functions. For the Platoon-Tanks MRE, we presented an ADG in Figure 67 and mapping functions in Table 18. In Figure 34 (see Chapter 6), we presented an algorithm for implementing a CE. In §6.3, we discussed how to traverse an ADG and apply mapping functions in order to keep an MRE internally consistent.

An IR consists of application-specific policies for resolving the effects of concurrent interactions. For the Platoon-Tanks MRE, we presented policies for resolving concurrent interactions in Table 21. In Figure 47 (see Chapter 7), we presented an algorithm for implementing an IR. In §7.5, we presented a taxonomy for classifying interactions. Using this taxonomy, we presented policies for resolving the effects of concurrent interactions.

A CE and an IR ensure that an MRE is internally consistent when concurrent interactions occur. During a time-step, a number of concurrent interactions may occur. The IR determines the type of each interaction. Next, the IR applies the effect of each interaction as if the interaction occurred in isolation. In order to do so, the IR permits the interactions to take effect one at a time. When an interaction changes an attribute, the CE traverses an ADG and translates changes to dependent attributes by invoking the appropriate mapping functions. The CE maintains a list of changes for each attribute as a result of computing the effects of each interaction. Subsequently, the CE applies the effects of all the interactions on each attribute. The CE queries the IR about policies to resolve the effects of dependent concurrent interactions whenever the CE detects conflicts in the list of changes for an entity. If the IR contains a policy for resolving conflicting changes, the CE applies the changes accordingly; otherwise, the CE assumes the changes are independent and applies them in an arbitrary order. When the changes to all attributes have been applied, the MRE is internally consistent.