"My dear Watson, try a little analysis yourself,"

said he, with a touch of impatience.

"You know my methods. Apply them,

and it will be instructive to compare results."

-- Arthur Conan Doyle, The Sign of the Four

Appendix C

Joint Precision Strike Demonstration

We demonstrate how designers can employ UNIFY and Object Model Template (OMT) to achieve effective Multi-Representation Modelling (MRM). We incorporate UNIFY in Joint Precision Strike Demonstration (JPSD) [JPSD97], a military model that is part of the Department of Defence's High Level Architecture (HLA). JPSD is specified using OMT [OMT98]. From the JPSD specifications, we construct an MRE and show how to maintain consistency within this MRE when concurrent interactions occur.

We construct a Platoon-Tanks Multiple Representation Entity (MRE) from the JPSD specifications. We assume that the jointly-executing models in JPSD are a Platoon model and a Tank model. For brevity, we assume that a Platoon consists of only two Tanks, as shown in Figure 69. From the OMT tables in the JPSD specification, we determine the attributes in the representations of the Platoon and Tank models. Next, we capture the relationships among attributes using an Attribute Dependency Graph (ADG) and select mapping functions to maintain consistency in a Platoon-Tanks MRE. Finally, we select policies for resolving the effects of concurrent interactions.

In §C.1, we present the tables in OMT. In §C.2, we list steps for incorporating UNIFY in JPSD. We demonstrate each step in subsequent sections. In §C.3, we construct an MRE. In §C.4 and §C.5, we construct an ADG and select mapping functions for attribute dependencies in the MRE. In §C.6 and §C.7, we determine and resolve the effects of concurrent interactions. In §C.8, we construct a CE and IR for the MRE.

C.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.

C.2 Steps

The steps for incorporating UNIFY in JPSD 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

C.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. We modify the OCST for JPSD to make Aggregate a derived class of Entity so that an Aggregate entity can send and receive other interactions in addition to requests to aggregate and disaggregate. Also, we do not show specific instances of derived classes, such as Tank or Aggregate. From the modified OCST for JPSD (shown in Table 22), we derive a Platoon from Aggregate. Our Platoon-Tanks MRE consists of the representations of a Platoon and two Tanks, Tank1 and Tank2.

Object Class Structure Table for JPSD

Base Class

1st Subclass

2nd Subclass

3rd Subclass

Entity

Aggregate

 

 

Platform

Land

Tank

ArmoredFightingVehicle

SelfPropelledArtillery

SmallWheeledUtilityVehicle

Air

AttackHelicopter

ElectronicWarfare

UAV

Munition

AntiArmor

Guided

BattlefieldSupport

 

System

TacticalSystem

 

 

Strike

 

 

BattalionCommander

 

 

ModSafCommander

 

 

From the APT, we determine the attributes that are part of the concurrent representations within our Platoon-Tanks MREs. For brevity, Table 23 shows only part of the APT for JPSD. 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 .

Attribute/Parameter Table for JPSD

Object/Interaction

Attribute/Parameter

Datatype

Cardinality

Units

Resolution

Accuracy

Accuracy Condition

Update Type

Update Condition

T/A

U/R

Entity

Entity_ID_site

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_ID_application

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_ID_entity

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Force_ID

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Kind

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Domain

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Country

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Category

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Subcategory

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Specific

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Location_X

double

 

meters

1

10%

DR1

conditional

time-out2

TA

UR

Location_Y

double

 

meters

1

10%

DR

conditional

time-out

TA

UR

Location_Z

double

 

meters

1

10%

DR

conditional

time-out

TA

UR

Velocity_X

double

 

meters/sec

 

10%

DR

conditional

time-out

TA

UR

Velocity_Y

double

 

meters/sec

 

10%

DR

conditional

time-out

TA

UR

Velocity_Z

double

 

meters/sec

 

10%

DR

conditional

time-out

TA

UR

Orientation_Psi

double

 

radians

 

3 degrees

DR

conditional

time-out

TA

UR

Orientation_Theta

double

 

radians

 

3 degrees

DR

conditional

time-out

TA

UR

Orientation_Phi

double

 

radians

 

3 degrees

DR

conditional

time-out

TA

UR

marking_text

string

 

 

 

perfect

always

static

 

 

UR

Aggregate

Aggregate_ID_site

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Aggregate_ID_application

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Aggregate_ID_entity

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Kind

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Domain

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Country

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Category

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Subcategory

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Entity_Type_Specific

short

 

enumeration

discrete

perfect

always

static

 

 

UR

Location_X

double

 

meters

1

10%

DR

periodic

0.033333333

TA

UR

Location_Y

double

 

meters

1

10%

DR

periodic

0.033333333

TA

UR

Location_Z

double

 

meters

1

10%

DR

periodic

0.033333333

TA

UR

Velocity_X

double

 

meters/sec

 

10%

DR

periodic

0.033333333

TA

UR

Velocity_Y

double

 

meters/sec

 

10%

DR

periodic

0.033333333

TA

UR

Velocity_Z

double

 

meters/sec

 

10%

DR

periodic

0.033333333

TA

UR

Orientation_Psi

double

 

radians

 

3 degrees

DR

periodic

0.033333333

TA

UR

Orientation_Theta

double

 

radians

 

3 degrees

DR

periodic

0.033333333

TA

UR

Orientation_Phi

double

 

radians

 

3 degrees

DR

periodic

0.033333333

TA

UR

marking_text

string

 

 

 

perfect

always

static

 

 

UR

Shape

short

 

enumeration

discrete

perfect

always

conditional

if tasking changes set shape

 

UR

Num_Entities_in_Aggregate

short

 

enumeration

discrete

perfect

always

delta

 

 

UR

DisaggPermitted

boolean

 

 

discrete

perfect

always

static

 

 

UR

AggregateState

short

 

enumeration

discrete

perfect

always

delta

 

 

UR

SubordinateList

sequence

 

 

discrete

perfect

always

delta

 

 

UR

Platform

Appearance_Paint_Scheme

short

 

enumeration

discrete

perfect

always

delta

 

 

UR

Appearance_Smoking

short

 

enumeration

discrete

perfect

always

delta

 

 

UR

Appearance_Flaming

short

 

enumeration

discrete

perfect

always

delta

 

 

UR

Appearance_Trailing

short

 

enumeration

discrete

perfect

always

delta

 

 

UR

Appearance_Lights

short

 

enumeration

discrete

perfect

always

delta

 

 

UR

Appearance_Hatch

short

 

enumeration

discrete

perfect

always

delta

 

 

UR

Damage_State_Appearance

short

 

enumeration

discrete

perfect

always

delta

 

 

UR

Damage_State_Mobility

short

 

enumeration

discrete

perfect

always

delta

 

 

UR

Damage_State_Fire_Power

short

 

enumeration

discrete

perfect

always

delta

 

 

UR

Tank

GunElevation

 

double

 

radians

 

0.1

DR

delta

 

TA

UR

From the OCST (Table 22) and APT (Table 23), we derive the attributes of a Tank and a Platoon. Table 24 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 Location_X, Location_Y, and Location_Z into an attribute called Location. Likewise, we combine Entity_ID_site, Entity_ID_application, Entity_ID_entity, Entity_Type_Kind, Entity_Type_Domain, Entity_Type_Country, Entity_Type_Category, Entity_Type_Subcategory, Entity_Type_Specific and marking_text 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.

Attributes of Platoon, Tank1 and Tank2 (JPSD)

Entity

Original Attributes

Derived From

New Attributes

Platoon

Aggregate_ID_site

Aggregate

Initial_Parameters

Aggregate_ID_application

Aggregate_ID_entity

Entity_Type_Kind

Entity_Type_Domain

Entity_Type_Country

Entity_Type_Category

Entity_Type_Subcategory

Entity_Type_Specific

marking_text

Location_X

Location

Location_Y

Location_Z

Velocity_X

Velocity

Velocity_Y

Velocity_Z

Orientation_Psi

Orientation

Orientation_Theta

Orientation_Phi

Shape

Composition

Num_Entities_in_Aggregate

DisaggPermitted

AggregateState

SubordinateList

Tank1

Entity_ID_site

Entity

Initial_Parameters1

Entity_ID_application

Entity_ID_entity

Force_ID

Entity_Type_Kind

Entity_Type_Domain

Entity_Type_Country

Entity_Type_Category

Entity_Type_Subcategory

Entity_Type_Specific

marking_text

Location_X

Location1

Location_Y

Location_Z

Velocity_X

Velocity1

Velocity_Y

Velocity_Z

Orientation_Psi

Orientation1

Orientation_Theta

Orientation_Phi

Appearance_Paint_Scheme

Platform

Appearance1

Appearance_Smoking

Appearance_Flaming

Appearance_Trailing

Appearance_Lights

Appearance_Hatch

Damage_State_Appearance

Damage_State1

Damage_State_Mobility

Damage_State_Fire_Power

GunElevation

Tank

GunElevation1

Tank2

Entity_ID_site

Entity

Initial_Parameters2

Entity_ID_application

Entity_ID_entity

Force_ID

Entity_Type_Kind

Entity_Type_Domain

Entity_Type_Country

Entity_Type_Category

Entity_Type_Subcategory

Entity_Type_Specific

marking_text

Location_X

Location2

Location_Y

Location_Z

Velocity_X

Velocity2

Velocity_Y

Velocity_Z

Orientation_Psi

Orientation2

Orientation_Theta

Orientation_Phi

Appearance_Paint_Scheme

Platform

Appearance2

Appearance_Smoking

Appearance_Flaming

Appearance_Trailing

Appearance_Lights

Appearance_Hatch

Damage_State_Appearance

Damage_State2

Damage_State_Mobility

Damage_State_Fire_Power

GunElevation

Tank

GunElevation2

C.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 JPSD. Since OMT does not support specifying relationships, we construct an example ART for our MRE (Table 25). 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 25, we present informal specifications in the last column.

Attribute Relationship Table for Platoon-Tanks MRE in JPSD

Dependency

Type

Specification

Location1 → Location

Cumulative

The location of the platoon is the centroid of the location of its tanks.

Location2 → Location

Cumulative

Location → Location1

Distributive

Location → Location2

Distributive

Velocity1 → Velocity

Cumulative

The velocity of the platoon is the average of the velocity of its tanks.

Velocity2 → Velocity

Cumulative

Velocity → Velocity1

Distributive

Velocity → Velocity2

Distributive

Orientation1 → Orientation

Cumulative

The orientation of the platoon is the average of the orientations of its tanks.

Orientation2 → Orientation

Cumulative

Orientation → Orientation1

Distributive

Orientation → Orientation2

Distributive

Damage_State1 → Composition

Cumulative

If a tank is fatally damaged, Composition reduces by one, and vice versa .

Damage_State2 → Composition

Cumulative

Composition → Damage_State1

Distributive

Composition → Damage_State2

Distributive

Appearance1 → Composition

Cumulative

The appearance of each tank determines the appearance of the platoon.

Appearance2 → Composition

Cumulative

Composition → Appearance1

Distributive

Composition → Appearance2

Distributive

Velocity → Location

Modelling

The location of a platoon or a tank depends on its velocity.

Velocity1 → Location1

Modelling

Velocity2 → Location2

Modelling

We construct an ADG for the Platoon-Tanks MRE. From Table 24, which was derived from the APT, we determine the nodes in the ADG. From the ART in Table 25, we determine the arcs in the ADG. The ADG is shown in Figure 70. 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.

C.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 26. The mapping functions are presented as pseudo-code. Error-checking has been omitted for brevity. Pseudo-code in the second column of Table 26 implements specifications in the last column of Table 25. The location, velocity and orientation of Platoon are averages of the location, velocity and orientation of Tank1 and Tank2. Similarly, mapping functions for other dependencies can be constructed. Mapping functions such as those shown in Table 26 translate values or changes in values of attributes.

Mapping Functions for JPSD Platoon-Tanks MRE

Dependency

Mapping Function

Location1 → Location

Location ← fd (Location1, Location2)

fl : Location_X ← (Location1_X + Location2_X) / 2

Location_Y ← (Location1_Y + Location2_Y) / 2

Location_Z ← (Location1_Z + Location2_Z) / 2

Location2 → Location

Location → Location1

(Location1, Location2) ← gd (Location)

gl : δLocation1_X ← δLocation2_X ← δLocation_X

δLocation1_Y ← δLocation2_Y ← δLocation_Y

δLocation1_Z ← δLocation2_Z ← δLocation_Z

Location → Location2

Velocity1 → Velocity

Velocity ← fd (Velocity1, Velocity2)

fv : Velocity_X ← (Velocity1_X + Velocity2_X) / 2

Velocity_Y ← (Velocity1_Y + Velocity2_Y) / 2

Velocity_Z ← (Velocity1_Z + Velocity2_Z) / 2

Velocity2 → Velocity

Velocity → Velocity1

(Velocity1, Velocity2) ← gd (Velocity)

gv : δVelocity1_X ← δVelocity2_X ← δVelocity_X

δVelocity1_Y ← δVelocity2_Y ← δVelocity_Y

δVelocity1_Z ← δVelocity2_Z ← δVelocity_Z

Velocity → Velocity2

Orientation1 → Orientation

Orientation ← fd (Orientation1, Orientation2)

fo : Orientation_Psi ←
(Orientation1_Psi + Orientation2_Psi) / 2

Orientation_Theta ←
(Orientation1_Theta + Orientation2_Theta) / 2

Orientation_Phi ←
(Orientation1_Phi + Orientation2_Phi) / 2

Orientation2 → Orientation

Orientation → Orientation1

(Orientation1, Orientation2) ← gd (Orientation)

go : δOrientation1_Psi ← δOrientation2_Psi ← δOrientation_Psi

δOrientation1_Theta ← δOrientation2_Theta ← δOrientation_Theta

δOrientation1_Phi ← δOrientation2_Phi ← δOrientation_Phi

Orientation → Orientation2

...

The mapping functions shown in Table 26 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, Orientation1, the mapping function fo changes the dependent Platoon-level attribute, Orientation. Subsequently, the mapping function go changes the Tank-level attribute, Orientation2. Since fo and go are composable, the change to Orientation1 eventually propagates to Orientation2. Since fo and go are reversible, Orientation1 does not change again as a result of the same interaction.

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

C.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 27. 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 27) 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 Entity. The interaction affects the attributes Location, Velocity and Orientation.

The last column in Table 27 lists the type of an interaction. Assigning a type requires information about the semantics of an interaction. For example, the semantics of Collision are that it is generated in response to a modelling event in which two entities collide. Since the collision has occurred already and its effects on the sender and receiver are certain, Collision is a Type 0 interaction. ArtyRadioMessage is a request by a commanding officer to perform a task. Since an entity may discard the request, ArtyRadioMessage is a Type 3 interaction. For the ChangeCourse interaction, we assumed that a change in the course of an entity is a request whose outcome is uncertain.

Object Interaction Table for JPSD

Interaction

Sender Class

Sender Attributes

Receiver

Receiver Attributes

Interaction Parameters

ISR

Type

Collision

Entity

Location, Velocity, Orientation, Appearance, Damage_State

Entity

Location, Velocity, Orientation, Appearance, Damage_State

Issuing_ID, Colliding_ID, Mass, Relative_Location, Event_ID, Velocity

ISR

0

Detonation

Munition

Appearance, Damage_State

Entity

Velocity, Appearance, Damage_State

Munition_ID, Location, Velocity, Firing_ID, Target_ID ,Event_ID, Detonation_Result, Burst_Descriptor

ISR

0

Weapon_Launch

Platform

none

Munition

none

Launch_Platform_ID, Weapon_ID

ISR

3

DisaggregateRequest

Aggregate

none

Aggregate

AggregateState, Subordinates

entity_ID, aggregate_ID, detection_range, aggregate_state

ISR

3

ArtyRadioMessage

ModSafCommander

none

Land

Location, Orientation, Velocity

message_type, command, gun_ID, full_message

ISR

3

ChangeCourse

Entity

Location, Velocity, Orientation

Entity

Location, Velocity, Orientation

New_Location, New_Velocity, New_Orientation

IR

3

We determine the interactions that our Platoon-Tanks MRE can send and receive. In Table 28, 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 Collision can be sent by an entity of class Entity. Since Entity is a base class of Platoon, Tank1 and Tank2, we distinguish the interaction Collision sent by these three entities as Collision-P, Collision-T1 and Collision-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 70. Finally, we indicate the type of the interaction. Since in UNIFY we do not aggregate or disaggregate, we do not expect the DisaggregateRequest interaction to occur.

Effects of Interactions for JPSD Platoon-Tanks MRE

Interaction

S/R

affects

affects +

Type

Collision-P

S

Location,
Velocity,
Orientation, Composition

Location1, Location2,
Velocity1, Velocity2,
Orientation1, Orientation2,
Appearance1, Appearance2,
Damage_State1, Damage_State2, Location,
Velocity, Orientation, Composition

0

Collision-T1

S

Location1,
Velocity1,
Orientation1, Appearance1, Damage_State1

Location, Velocity,
Orientation, Composition, Location2, Velocity2,
Orientation2, Appearance2,
Damage_State2, Location1,
Velocity1, Orientation1, Appearance1, Damage_State1

0

Collision-T2

S

Location2,
Velocity2,
Orientation2,
Appearance2,
Damage_State2

Location, Velocity, Orientation, Composition, Location1, Velocity1,
Orientation1, Appearance1, Damage_State1, Location2,
Velocity2, Orientation2,
Appearance2, Damage_State2

0

Weapon_Launch-T1

S

 

 

3

Weapon_Launch-T2

S

 

 

3

DisaggregateRequest-P

S

 

 

3

ChangeCourse-P

S

Location, Velocity,
Orientation

Location1, Location2, Velocity1, Velocity2, Orientation1, Orientation2, Location, Velocity, Orientation

3

ChangeCourse-T1

S

Location1, Velocity1,
Orientation1

Location, Velocity,
Orientation, Location2,
Velocity2, Orientation2, Location1, Velocity1,
Orientation1

3

ChangeCourse-T2

S

Location2, Velocity2,
Orientation2

Location, Velocity,
Orientation, Location1,
Velocity1, Orientation1, Location2, Velocity2,
Orientation2

3

Collision-P

R

Location,
Velocity,
Orientation, Composition

Location1, Location2,
Velocity1, Velocity2,
Orientation1, Orientation2,
Appearance1, Appearance2,
Damage_State1, Damage_State2, Location,
Velocity, Orientation, Composition

0

Collision-T1

R

Location1,
Velocity1,
Orientation1, Appearance1, Damage_State1

Location, Velocity,
Orientation, Composition, Location2, Velocity2,
Orientation2, Appearance2,
Damage_State2, Location1,
Velocity1, Orientation1, Appearance1, Damage_State1

0

Collision-T2

R

Location2,
Velocity2,
Orientation2,
Appearance2,
Damage_State2

Location, Velocity,
Orientation, Composition, Location1, Velocity1,
Orientation1, Appearance1, Damage_State1, Location2,
Velocity2, Orientation2,
Appearance2, Damage_State2

0

Detonation-P

R

Velocity,
Composition

Velocity1, Velocity2,
Appearance1, Appearance2,
Damage_State1, Damage_State2, Location,
Velocity, Composition, Location1, Location2

0

Detonation-T1

R

Velocity1,
Appearance1, Damage_State1

Velocity, Composition, Location1, Velocity2, Velocity1, Appearance2, Appearance1,Damage_State2, Damage_State1, Location, Location2

0

Detonation-T2

R

Velocity2,
Appearance2,
Damage_State2

Velocity, Composition, Location2, Velocity1,
Velocity2, Appearance1, Appearance2,Damage_State1, Damage_State2, Location, Location1

0

DisaggregateRequest-P

R

 

 

3

ArtyRadioMessage-P

R

Location,
Velocity,
Orientation

Location1, Location2, Velocity1, Velocity2, Orientation1, Orientation2, Location, Velocity, Orientation, Composition

3

ArtyRadioMessage-T1

R

Location1,
Velocity1,
Orientation1

Location, Velocity, Orientation, Location2, Velocity2, Orientation2, Location1, Velocity1, Orientation1

3

ArtyRadioMessage-T2

R

Location2,
Velocity2,
Orientation2

Location, Velocity, Orientation, Location1, Velocity1, Orientation1, Location2, Velocity2, Orientation2

3

ChangeCourse-P

R

Location, Velocity,
Orientation

Location1, Location2, Velocity1, Velocity2, Orientation1, Orientation2, Location, Velocity, Orientation

3

ChangeCourse-T1

R

Location1, Velocity1,
Orientation1

Location, Velocity, Orientation, Location2, Velocity2, Orientation2, Location1, Velocity1, Orientation1

3

ChangeCourse-T2

R

Location2, Velocity2,
Orientation2

Location, Velocity, Orientation, Location1, Velocity1, Orientation1, Location2, Velocity2, Orientation2

3

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

C.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 29.

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 29) or for instances of interactions (e.g., all the other rows in Table 29). 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.

Concurrent Interactions Table for JPSD Platoon-Tanks MRE

Concurrent Interactions

Condition

Policy

Any combination of (Detonation-P, Detonation-T1, Detonation-T2), any combination of (Collision-P, Collision-T1, Collision-T2)

Always

Damage to Tanks less than sum of damages but greater than minimum of damages; add compensatory interaction to reduce damage

DisaggregateRequest-P

Always

Ignore

ArtyRadioMessage-P, any combination of (ArtyRadioMessage-T1, ArtyRadioMessage-T2)

Received, commands conflicting

Ignore all except InitiateStrikeCommand-P

ArtyRadioMessage-P, any combination of (ArtyRadioMessage-T1, ArtyRadioMessage-T2)

Received, commands non- conflicting

Delay all except InitiateStrikeCommand-P by one time-step

Any combination of (ArtyRadioMessage-P, ArtyRadioMessage-T1, ArtyRadioMessage-T2), any combination of (ChangeCourse-P, ChangeCourse-T1, ChangeCourse-T2)

All received

Ignore ChangeCourse-P, ChangeCourse-T1, ChangeCourse-T2; Resolve ArtyRadioMessage-P, ArtyRadioMessage-T1, ArtyRadioMessage-T2) as above

ChangeCourse-P, any combination of (ChangeCourse-T1, ChangeCourse-T2)

All received

Ignore all except ChangeCourse-P

Type 0, Type 1

All received

Ignore Type 1

Type 2, Type 3

All received

Ignore Type 3

Any Interaction

Ignored or Delayed

Ignored or Delayed entirely, i.e., no partial effects permitted

C.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 71 shows a JPSD 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 70 and mapping functions in Table 26. 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 29. 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.


1. DR refers to a dead-reckoning algorithm, listed in the JPSD APT as DR(F, P, W).

2. time-out refers to the JPSD APT condition: if (!accurate) or (value has changed and 5 second update interval passed)