What your actual solution is is unimportant as long as it has Quality.

-- Robert Pirsig, Zen and the Art of Motorcycle Maintenance

Appendix B

Joint Task Force Prototype

We demonstrate how designers can employ UNIFY and Object Model Template (OMT) to achieve effective Multi-Representation Modelling (MRM). We incorporate UNIFY in Joint Task Force prototype (JTFp) [JTFp97], a military model that is part of the Department of Defence's High Level Architecture (HLA). JTFp is specified using OMT [OMT98]. From the JTFp 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 JTFp specifications. We assume that the jointly-executing models in JTFp are a Platoon model and a Tank model. For brevity, we assume that a Platoon consists of only two Tanks, as shown in Figure 66. From the OMT tables in the JTFp 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 §B.1, we present the tables in OMT. In §B.2, we list steps for incorporating UNIFY in JTFp. We demonstrate each step in subsequent sections. In §B.3, we construct an MRE. In §B.4 and §B.5, we construct an ADG and select mapping functions for attribute dependencies in the MRE. In §B.6 and §B.7, we determine and resolve the effects of concurrent interactions. In §B.8, we construct a CE and IR for the MRE.

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.

Object Class Structure Table for JTFp

Base Class

1st Subclass

2nd Subclass

Player (S)

AirPlayer (S)

BallisticMissile (PS)

Aircraft (PS)

Flight (PS)

GroundPlayer (S)

FixedSite (PS)

MobileGroundPlayer (PS)

AggregateGroundPlayer (PS)

AfloatPlayer (PS)

 

Environment

Atmosphere (PS)

 

SurfaceCover (PS)

 

OpenWater (PS)

 

FederateStatus (PS)

 

 

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 .

Attribute/Parameter Table for JTFp

Object/Interaction

Attribute/Parameter

Datatype

Cardinality

Units

Resolution

Accuracy

Accuracy Condition

Update Type

Update Condition

T/A

U/R

Player

entity_name

string

1

 

 

perfect

always

static

 

N

UR

federate_id

enumeration

1

 

 

perfect

always

static

 

N

UR

affiliation

enumeration

1

 

 

perfect

always

static

 

N

UR

motion_type

enumeration

1

 

 

perfect

always

static

 

N

UR

voice_nets

boolean

maximum

 

TRUE, FALSE

perfect

always

static

 

N

UR

jtids_nets

boolean

maximum

 

TRUE, FALSE

perfect

always

static

 

N

UR

trap_tre

boolean

1

 

TRUE, FALSE

perfect

always

static

 

N

UR

commander_type

enumeration

1

 

 

perfect

always

static

 

N

UR

MobileGroundPlayer

radar_cross_section

float

1

meters

0.1 meters2

0.1 meters2

always

static

 

N

UR

radar_detectable

boolean

1

 

TRUE, FALSE

perfect

always

conditional

 

N

UR

elint_detectable

boolean

1

 

TRUE, FALSE

perfect

always

conditional

 

N

UR

comint_detectable

boolean

1

 

TRUE, FALSE

perfect

always

conditional

 

N

UR

ir_detectable

boolean

1

 

TRUE, FALSE

perfect

always

conditional

 

N

UR

photint_detectable

boolean

1

 

TRUE, FALSE

perfect

always

conditional

 

N

UR

air_to_air_engageable

boolean

1

 

TRUE, FALSE

perfect

always

static

 

N

UR

air_to_surf_engageable

boolean

1

 

TRUE, FALSE

perfect

always

static

 

N

UR

surf_to_air_engageable

boolean

1

 

TRUE, FALSE

perfect

always

static

 

N

UR

surf_to_surf_engageable

boolean

1

 

TRUE, FALSE

perfect

always

static

 

N

UR

damage_state

float

1

percent

0.01

0.01

always

conditional

 

N

UR

entity_type

enumeration

1

 

 

perfect

always

static

 

N

UR

time_at_last_cse_change

float

1

seconds

0.1 second

0.1 seconds

always

conditional

 

TA

UR

lat_at_last_cse_change

float

1

degrees

1 × 10-5 degrees

1 × 10-5 degrees

always

conditional

 

TA

UR

lng_at_last_cse_change

float

1

degrees

1 × 10-5 degrees

1 × 10-5 degrees

always

conditional

 

TA

UR

alt_at_last_cse_change

float

1

meters

1 meter

1 meter

always

conditional

 

TA

UR

cse_at_last_cse_change

float

1

degrees

1 × 10-5 degrees

1 × 10-5 degrees

always

conditional

 

TA

UR

hspd_at_last_cse_change

float

1

meters/second

1 meter/second

1 meter/second

always

conditional

 

TA

UR

vspd_at_last_cse_change

float

1

meters/second

1 meter/second

1 meter/second

always

conditional

 

TA

UR

role

enumeration

1

 

 

perfect

always

static

 

N

UR

AggregateGroundPlayer

radar_cross_section

float

unbounded

meters

0.1 meters2

0.1 meters2

always

static

 

N

UR

radar_detectable

boolean

unbounded

 

TRUE, FALSE

perfect

always

conditional

 

N

UR

elint_detectable

boolean

unbounded

 

TRUE, FALSE

perfect

always

conditional

 

N

UR

comint_detectable

boolean

unbounded

 

TRUE, FALSE

perfect

always

conditional

 

N

UR

ir_detectable

boolean

unbounded

 

TRUE, FALSE

perfect

always

conditional

 

N

UR

photint_detectable

boolean

unbounded

 

TRUE, FALSE

perfect

always

conditional

 

N

UR

air_to_air_engageable

boolean

unbounded

 

TRUE, FALSE

perfect

always

static

 

N

UR

air_to_surf_engageable

boolean

unbounded

 

TRUE, FALSE

perfect

always

static

 

N

UR

surf_to_air_engageable

boolean

unbounded

 

TRUE, FALSE

perfect

always

static

 

N

UR

surf_to_surf_engageable

boolean

unbounded

 

TRUE, FALSE

perfect

always

static

 

N

UR

composition

enumeration

unbounded

 

 

perfect

always

conditional

 

N

UR

time_at_last_cse_change

float

1

seconds

0.1 second

0.1 seconds

always

conditional

 

TA

UR

lat_at_last_cse_change

float

1

degrees

1 × 10-5 degrees

1 × 10-5 degrees

always

conditional

 

TA

UR

lng_at_last_cse_change

float

1

degrees

1 × 10-5 degrees

1 × 10-5 degrees

always

conditional

 

TA

UR

alt_at_last_cse_change

float

1

meters

1 meter

1 meter

always

conditional

 

TA

UR

cse_at_last_cse_change

float

1

degrees

1 × 10-5 degrees

1 × 10-5 degrees

always

conditional

 

TA

UR

hspd_at_last_cse_change

float

1

meters/second

1 meter/second

1 meter/second

always

conditional

 

TA

UR

vspd_at_last_cse_change

float

1

meters/second

1 meter/second

1 meter/second

always

conditional

 

TA

UR

orientation

float

1

degrees

0.1 degree

perfect

always

conditional

 

N

UR

depth

float

1

meters

1 meter

perfect

always

conditional

 

N

UR

front

float

1

meters

1 meter

perfect

always

conditional

 

N

UR

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.

Attributes of Platoon, Tank1 and Tank2 (JTFp)

Entity

Original Attributes

Derived From

New Attributes

Platoon

entity_name

Player

initial_parameters

federate_id

affiliation

motion_type

voice_nets

jtids_net

trap_tre

commander_type

<none specified>

GroundPlayer

 

radar_cross_section

AggregateGroundPlayer

radar_cross_section

radar_detectable

detectable

elint_detectable

comint_detectable

ir_detectable

photoint_detectable

air_to_air_engageable

engageable

air_to_surf_engageable

surf_to_air_engageable

surf_to_surf_engageable

composition

composition

time_at_last_cse_change

last_cse_change

lat_at_last_cse_change

lng_at_last_cse_change

alt_at_last_cse_change

cse_at_last_cse_change

hspd_at_last_cse_change

vspd_at_last_cse_change

depth

depth

front

front

orientation

orientation

Tank1

entity_name

Player

initial_parameters1

federate_id

affiliation

motion_type

voice_nets

jtids_net

trap_tre

commander_type

<none specified>

GroundPlayer

 

radar_cross_section

MobileGroundPlayer

radar_cross_section1

radar_detectable

detectable1

elint_detectable

comint_detectable

ir_detectable

photoint_detectable

air_to_air_engageable

engageable1

air_to_surf_engageable

surf_to_air_engageable

surf_to_surf_engageable

damage_state

damage_state1

entity_type

entity_type1

time_at_last_cse_change

last_cse_change1

lat_at_last_cse_change

lng_at_last_cse_change

alt_at_last_cse_change

cse_at_last_cse_change

hspd_at_last_cse_change

vspd_at_last_cse_change

role

role1

Tank2

entity_name

Player

initial_parameters2

federate_id

affiliation

motion_type

voice_nets

jtids_net

trap_tre

commander_type

<none specified>

GroundPlayer

 

radar_cross_section

MobileGroundPlayer

radar_cross_section2

radar_detectable

detectable2

elint_detectable

comint_detectable

ir_detectable

photoint_detectable

air_to_air_engageable

engageable2

air_to_surf_engageable

surf_to_air_engageable

surf_to_surf_engageable

damage_state

damage_state2

entity_type

entity_type2

time_at_last_cse_change

last_cse_change2

lat_at_last_cse_change

lng_at_last_cse_change

alt_at_last_cse_change

cse_at_last_cse_change

hspd_at_last_cse_change

vspd_at_last_cse_change

role

role2

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.

Attribute Relationship Table for Platoon-Tanks MRE in JTFp

Dependency

Type

Specification

detectable1 → detectable

Cumulative

If even one tank is detectable, the entire platoon is detectable. If the platoon is detectable, each tank is detectable.

detectable2 → detectable

Cumulative

detectable → detectable1

Distributive

detectable → detectable2

Distributive

engageable1 → engageable

Cumulative

If even one tank is engageable, the platoon is engageable. If the platoon is engageable, at least one tank must be engageable.

engageable2 → engageable

Cumulative

engageable → engageable1

Distributive

engageable → engageable2

Distributive

damage_state1 → composition

Cumulative

If a damage_state becomes 100%, composition reduces by one, and vice versa .

damage_state2 → composition

Cumulative

composition → damage_state1

Distributive

composition → damage_state2

Distributive

last_cse_change1 → last_cse_change

Cumulative

Elements of the course, such as altitude, velocity and position, are vector quantities.

last_cse_change2 → last_cse_change

Cumulative

last_cse_change → last_cse_change1

Distributive

last_cse_change → last_cse_change2

Distributive

radar_cross_section1 → radar_cross_section

Cumulative

The radar cross-section of the platoon encompasses the radar cross-section of its tanks.

radar_cross_section2 → radar_cross_section

Cumulative

radar_cross_section → radar_cross_section1

Distributive

radar_cross_section → radar_cross_section2

Distributive

composition → depth

Modelling

The composition affects the depth, front line and orientation of the platoon.

composition → front

Modelling

composition → orientation

Modelling

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.

Mapping Functions for JTFp Platoon-Tanks MRE

Dependency

Mapping Function

detectable1 → detectable

detectable ← fd (detectable1, detectable2)

fd : detectable ← detectable1 ∨ detectable2

detectable2 → detectable

detectable → detectable1

(detectable1, detectable2) ← gd (detectable)

gd : detectable1 ← detectable2 ← detectable

detectable → detectable2

engageable1 → engageable

engageable ← fe (engageable1, engageable2)

fe : engageable ← engageable1 ∨ engageable2

engageable2 → engageable

engageable → engageable1

(engageable1, engageable2) ← ge (engageable)

ge : engageablerandom(1, 2) ← engageable

engageable → engageable2

damage_state1 → composition

composition ← fc (damage_state1, damage_state2)

fc : for (i ← 1 to 2)

if (damage_statei = 100%)

{ composition−−; damage_statei ← ∞ }

damage_state2 → composition

composition → damage_state1

(damage_state1, damage_state2) ← gc (composition)

gc : if (δcomposition = −1)

if (damage_state1 < 100%) damage_state1 ← ∞

elsif (damage_state2 < 100%) damage_state2 ← ∞

composition → damage_state2

...

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.

Object Interaction Table for JTFp

Interaction

Sender Class

Sender Attributes

Receiver

Receiver Attributes

Interaction Parameters

ISR

Type

TBMWarning

Player

none

Player

none

send_time, comms_system, net_number

IR

1

TBMLaunchAlert

Player

none

Player

none

send_time, comms_system, net_number, launch_lat, launch_lng

IR

1

InitiateStrikeCommand

Player

none

Player

none

send_time, comms_system, net_number, strike_phase_name, strike_phase_number

IR

3

DetectionReport

Player

none

Player

none

send_time, comms_system, net_number, report_type, entity_id, reported_lat, reported_lng, reported_alt, reported_cse, reported_hspd, reported_vspd, reported_affiliation, reported_type, reported_raid_count, reported_damage

IR

1

RequestAirSupport

Player

none

Player

none

send_time, comms_system, net_number, requestor_id, target_id, time_on_target, target_lat, target_lng

IR

3

SituationReport

Player

none

Player

none

gfc_lat, gfc_lng, rel_to_objective, objective_name, personnel_status, equipment_status, effectiveness_status, combat_intensity

IR

1

AirToDiscreteGroundEngage

AirPlayer

none

MobileGroundPlayer

damage_state

launch_time, time_of_flight, launch_lat, launch_lng, launch_alt, weapon_type, salvo_size, aimpoint, estimated_pk_at_launch

IR

0

AirToAggregateGroundEngage

AirPlayer

none

AggregateGroundPlayer

composition

launch_time, time_of_flight, launch_lat, launch_lng, launch_alt, weapon_type, salvo_size, targeted_systems, estimated_pks_at_launch

IR

0

DiscreteGroundToAirEngage

MobileGroundPlayer

none

AirPlayer

damage_state

launch_time, time_of_flight, launch_lat, launch_lng, launch_alt, weapon_type, salvo_size, estimated_pk_at_launch

IR

0

AggregateGroundToAirEngage

AggregateGroundPlayer

none

AirPlayer

damage_state,composition

launch_time, time_of_flight launch_quadrant, launch_offsets, weapon_systems, ammo_types, salvo_sizes estimated_pks_at_launch

IR

0

DiscreteGroundToGroundEngage

MobileGroundPlayer

none

MobileGroundPlayer

damage_state

launch_time, time_of_flight, aim_pt_lat, aim_pt_lng, weapon_type, estimated_pk_at_launch

IR

0

TroopsHitBeach

Player

none

 

 

num_boat_sorties, num_helo_sorties, lat_of_beach_location. lng_of_beach_location

IR

0

GetLOSVisibility

Player

none

Environment

none

observation_time, sensor_lat, sensor_lng, sensor_alt, target_lat, target_lng, target_alt

IR

2

ReturnLOSVisbility

Environment

none

Player

none

LOS_visibility, relative_humidity, reason, return_id

IR

1

GetAtmosphericCondition

Player

none

Environment

none

time, observation_lat, observation_lng

IR

2

ReturnAtmosphericCondition

Environment

none

Player

none

ceiling, surface_temperature, surface_pressure, visibility, relative_humidity, total_cloud_cover, cloud1_type, cloud1_height, cloud1_amount, cloud2_type, cloud2_height, cloud2_amount, cloud3_type, cloud3_height, cloud3_amount, surface_wind_speed, surface_wind_direction, precipitation_amount, artificial_obscurants, natural_obscurants

IR

1

GetSeaState

Player

none

Environment

none

lat, lng

IR

2

ReturnSeaState

Environment

none

Player

none

state_of_sea, sea_surface_temp

IR

1

ChangeCourse

Player

last_cse_change

Player

last_cse_change

new_lat, new_lng, new_alt, new_hspd, new_vspd

IR

3

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.

Effects of Interactions for JTFp Platoon-Tanks MRE

Interaction

S/R

affects

affects +

Type

TBMWarning-P

S

 

 

1

TBMWarning-T1

S

 

 

1

TBMWarning-T2

S

 

 

1

TBMLaunchAlert-P

S

 

 

1

TBMLaunchAlert-T1

S

 

 

1

TBMLaunchAlert-T2

S

 

 

1

InitiateStrikeCommand-P

S

 

 

3

InitiateStrikeCommand-T1

S

 

 

3

InitiateStrikeCommand-T2

S

 

 

3

DetectionReport-P

S

 

 

1

DetectionReport-T1

S

 

 

1

DetectionReport-T2

S

 

 

1

RequestAirSupport-P

S

 

 

3

RequestAirSupport-T1

S

 

 

3

RequestAirSupport-T2

S

 

 

3

SituationReport-P

S

 

 

1

SituationReport-T1

S

 

 

1

SituationReport-T2

S

 

 

1

AggregateGroundToAirEngage-P

S

 

 

0

DiscreteGroundToAirEngage-T1

S

 

 

0

DiscreteGroundToAirEngage-T2

S

 

 

0

DiscreteGroundToGroundEngage-T1

S

 

 

0

DiscreteGroundToGroundEngage-T2

S

 

 

0

TroopsHitBeach-P

S

 

 

0

TroopsHitBeach-T1

S

 

 

0

TroopsHitBeach-T2

S

 

 

0

GetLOSVisibility-P

S

 

 

2

GetLOSVisibility-T1

S

 

 

2

GetLOSVisibility-T2

S

 

 

2

GetAtmosphericCondition-P

S

 

 

2

GetAtmosphericCondition-T1

S

 

 

2

GetAtmosphericCondition-T2

S

 

 

2

GetSeaState-P

S

 

 

2

GetSeaState-T1

S

 

 

2

GetSeaState-T2

S

 

 

2

ChangeCourse-P

S

last_cse_change

last_cse_change1, last_cse_change2, last_cse_change

3

ChangeCourse-T1

S

last_cse_change1

last_cse_change, last_cse_change2, last_cse_change1

3

ChangeCourse-T2

S

last_cse_change2

last_cse_change, last_cse_change1, last_cse_change2

3

TBMWarning-P

R

 

 

1

TBMWarning-T1

R

 

 

1

TBMWarning-T2

R

 

 

1

TBMLaunchAlert-P

R

 

 

1

TBMLaunchAlert-T1

R

 

 

1

TBMLaunchAlert-T2

R

 

 

1

InitiateStrikeCommand-P

R

 

 

3

InitiateStrikeCommand-T1

R

 

 

3

InitiateStrikeCommand-T2

R

 

 

3

DetectionReport-P

R

 

 

1

DetectionReport-T1

R

 

 

1

DetectionReport-T2

R

 

 

1

RequestAirSupport-P

R

 

 

3

RequestAirSupport-T1

R

 

 

3

RequestAirSupport-T2

R

 

 

3

SituationReport-P

R

 

 

1

SituationReport-T1

R

 

 

1

SituationReport-T2

R

 

 

1

AirToAggregateGroundEngage-P

R

composition

damage_state1, damage_state2, depth, front, orientation, composition

0

AirToDiscreteGroundEngage-T1

R

damage_state1

composition, damage_state2, depth, front, orientation, damage_state1

0

AirToDiscreteGroundEngage-T2

R

damage_state2

composition, damage_state1, depth, front, orientation, damage_state2

0

ReturnLOSVisibility-P

R

 

 

1

ReturnLOSVisibility-T1

R

 

 

1

ReturnLOSVisibility-T2

R

 

 

1

ReturnAtmosphericCondition-P

R

 

 

1

ReturnAtmosphericCondition-T1

R

 

 

1

ReturnAtmosphericCondition-T2

R

 

 

1

ReturnSeaState-P

R

 

 

1

ReturnSeaState-T1

R

 

 

1

ReturnSeaState-T2

R

 

 

1

ChangeCourse-P

R

last_cse_change

last_cse_change1, last_cse_change2, last_cse_change

3

ChangeCourse-T1

R

last_cse_change1

last_cse_change, last_cse_change2, last_cse_change1

3

ChangeCourse-T2

R

last_cse_change2

last_cse_change, last_cse_change1, last_cse_change2

3

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.

Concurrent Interactions Table for JTFp Platoon-Tanks MRE

Concurrent Interactions

Condition

Policy

AggregateGroundToAirEngage-P, any combination of (DiscreteGroundToAirEngage-T1, DiscreteGroundToAirEngage-T2, DiscreteGroundToGroundEngage-T1, DiscreteGroundToGroundEngage-T2)

All sent

Do not send all except AggregateGroundToAirEngage-P

DiscreteGroundToAirEngage-Ti, DiscreteGroundToGroundEngage-Ti

All sent

Do not send DiscreteGroundToAirEngage-Ti

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

All received

Delay all except InitiateStrikeCommand-P by one time-step

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

All received

Ignore DetectionReport-P

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

All received

Delay all except RequestAirSupport-P by one time-step

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

All received

Ignore SituationReport-P

AirToAggregateGroundEngage-P, AirToDiscreteGroundEngage-Ti

All received

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

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

All received

Ignore ReturnLOSVisibility-P

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

All received

Ignore ReturnAtmosphericCondition-P

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

All received

Ignore ReturnSeaState-P

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

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.