Knowing is not enough; we must apply. Willing is not enough; we must do.

-- Goethe

Appendix D

Real-time Platform Reference

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

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

D.2 Steps

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

D.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 RPR (shown in Table 30), we derive a Platoon from AggregateEntity, and a Tank from MilitaryLandPlatform. Our Platoon-Tanks MRE consists of the representations of a Platoon and two Tanks, Tank1 and Tank2.

Object Class Structure Table for RPR

Base Class

1st Subclass

2nd Subclass

3rd Subclass

4th Subclass

BaseEntity

AggregateEntity

 

 

 

EnvironmentEntity

 

 

 

PhysicalEntity

MilitaryEntity

MilitaryPlatformEntity

MilitaryAirLandPlatform

MilitaryAmphibiousPlatform

MilitaryLandPlatform

MilitarySpacePlatform

MilitarySeaSurfacePlatform

MilitarySubmersiblePlatform

MilitaryMultiDomainPlatform

MunitionEntity

 

Soldier

 

CivilPlatform

CivilAirLandPlatform

 

CivilAmphibiousPlatform

 

CivilLandPlatform

 

CivilSpacePlatform

 

CivilSeaSurfacePlatform

 

CivilSubmersiblePlatform

 

CivilMultiDomainPlatform

 

Civilian

 

 

EmbeddedSystem

Designator

 

 

 

EmitterSystem

 

 

 

RadioReceiver

 

 

 

RadioTransmitter

 

 

 

EmitterBeam

TrackJamBeam

 

 

 

SimulationManager

 

 

 

 

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

Attribute/Parameter Table for RPR

Object/Interaction

Attribute/Parameter

Datatype

Cardinality

Units

Resolution

Accuracy

Accuracy Condition

Update Type

Update Condition

AggregateEntity

AggregateMarking

structure

1

 

 

 

 

static

 

AggregateState

enumeration

1

 

 

 

 

conditional

on change

Dimensions

structure

1

 

 

 

 

conditional

AggSizeChange

EntityIDs

unsigned long

0+

 

 

perfect

always

conditional

on change

ForceID

enumeration

1

 

 

 

 

static

 

Formation

enumeration

1

 

 

 

 

conditional

on change

NumberOfEntities

unsigned short

1

 

1

perfect

always

conditional

on change

NumberOfSilentAggregates

unsigned short

1

 

1

perfect

always

conditional

on change

NumberOfSilentEntities

unsigned short

1

 

1

perfect

always

conditional

on change

NumberOfSubAggregates

unsigned short

1

 

1

perfect

always

conditional

on change

NumberOfVariableDatums

unsigned short

1

 

1

perfect

always

conditional

on change

SilentAggregates

structure

0+

 

 

 

 

conditional

on change

SilentEntities

structure

0+

 

 

 

 

conditional

on change

SubAggregateIDs

unsigned long

0+

 

 

perfect

always

conditional

on change

VariableDatums

structure

0+

 

 

 

 

conditional

on change

BaseEntity

AccelerationVector

structure

1

 

 

 

 

conditional

AccelerationChange

AngularVelocityVector

structure

1

 

 

 

 

conditional

AngVelocityChange

DRAlgorithm

enumeration

1

 

 

 

 

conditional

on change

EntityType

structure

1

 

 

 

 

static

 

FederateID

structure

1

 

 

 

 

static

 

IsFrozen

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

Orientation

structure

1

 

 

 

 

conditional

OrientationChange

Position

structure

1

 

 

 

 

conditional

PositionChange

VelocityVector

structure

1

 

 

 

 

conditional

VelocityChange

MilitaryEntity

AlternateEntityType

structure

1

 

 

 

 

static

 

CamouflageType

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

FirePowerDisabled

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

ForceID

enumeration

1

 

 

perfect

always

static

 

IsConcealed

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

MilitaryPlatformEntity

AfterburnerOn

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

HasAmmunitionSupplyCap

boolean

1

TRUE, FALSE

 

perfect

always

static

on change

LauncherRaised

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

PhysicalEntity

ArticulatedParametersArray

structure

0+

 

 

 

 

conditional

on change

ArticulatedParametersCount

unsigned short

1

 

1

perfect

always

static

 

DamageState

enumeration

1

 

 

 

 

conditional

on change

EngineSmokeOn

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

FlamesPresent

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

HasFuelSupplyCap

boolean

1

TRUE, FALSE

 

perfect

always

static

on change

HasRecoveryCap

boolean

1

TRUE, FALSE

 

perfect

always

static

on change

HasRepairCap

boolean

1

TRUE, FALSE

 

perfect

always

static

on change

HatchState

enumeration

1

 

 

 

 

conditional

on change

Immobilized

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

LifeformState

enumeration

1

 

 

 

 

conditional

on change

LightsState

enumeration

1

 

 

 

 

conditional

on change

Marking

structure

1

 

 

 

 

static

on change

PowerPlantOn

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

RampDeployed

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

SmokePlumePresent

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

TentDeployed

boolean

1

TRUE, FALSE

 

perfect

always

conditional

on change

TrailState

enumeration

1

 

 

 

 

conditional

on change

From the OCST (Table 30) and APT (Table 31), we derive the attributes of a Tank and a Platoon. Table 32 lists the attributes of Platoon, Tank1 and Tank2. For brevity, we combine a number of logically-similar attributes derived from the OCST and APT (second column) into one attribute (fourth column). For example, we combine the attributes IsFrozen, IsConcealed, FlamesPresent and LifeformState into an attribute called Status. 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 (RPR)

Entity

Original Attributes

Derived From

New Attributes

Platoon

AccelerationVector

BaseEntity

Acceleration

AngularVelocityVector

AngularVelocity

DRAlgorithm

DRAlgorithm

EntityType

InitialParameters

FederateID

IsFrozen

Status

Orientation

Orientation

Position

Position

VelocityVector

Velocity

AggregateMarking

AggregateEntity

InitialParameters

ForceID

Dimensions

Dimensions

Formation

Formation

EntityIDs

Composition

AggregateState

NumberOfEntities

NumberOfSilentAggregates

NumberOfSilentEntities

NumberOfSubAggregates

NumberOfVariableDatums

SilentAggregates

SilentEntities

SubAggregateIDs

VariableDatums

Tank1

AccelerationVector

BaseEntity

Acceleration1

AngularVelocityVector

AngularVelocity1

DRAlgorithm

DRAlgorithm1

EntityType

InitialParameters1

FederateID

IsFrozen

Status1

Orientation

Orientation1

Position

Position1

VelocityVector

Velocity1

ArticulatedParametersArray

PhysicalEntity

ArticulatedParameters1

ArticulatedParametersCount

DamageState

Status1

EngineSmokeOn

FlamesPresent

HasFuelSupplyCap

HasRecoveryCap

HasRepairCap

HatchState

Immobilized

LifeformState

LightsState

Marking

PowerPlantOn

RampDeployed

SmokePlumePresent

TentDeployed

TrailState

AlternateEntityType

MilitaryEntity

InitialParameters1

ForceID

CamouflageType

Status1

FirePowerDisabled

IsConcealed

AfterburnerOn

MilitaryPlatformEntity

HasAmmunitionSupplyCap

LauncherRaised

<none>

MilitaryLandPlatform

 

Tank2

AccelerationVector

BaseEntity

Acceleration2

AngularVelocityVector

AngularVelocity2

DRAlgorithm

DRAlgorithm2

EntityType

InitialParameters2

FederateID

IsFrozen

Status2

Orientation

Orientation2

Position

Position2

VelocityVector

Velocity2

ArticulatedParametersArray

PhysicalEntity

ArticulatedParameters2

ArticulatedParametersCount

DamageState

Status2

EngineSmokeOn

FlamesPresent

HasFuelSupplyCap

HasRecoveryCap

HasRepairCap

HatchState

Immobilized

LifeformState

LightsState

Marking

PowerPlantOn

RampDeployed

SmokePlumePresent

TentDeployed

TrailState

AlternateEntityType

MilitaryEntity

InitialParameters2

ForceID

CamouflageType

Status2

FirePowerDisabled

IsConcealed

AfterburnerOn

MilitaryPlatformEntity

HasAmmunitionSupplyCap

LauncherRaised

<none>

MilitaryLandPlatform

 

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

Attribute Relationship Table for Platoon-Tanks MRE in RPR

Dependency

Type

Specification

Position1 → Position

Cumulative

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

Position2 → Position

Cumulative

Position → Position1

Distributive

Position → Position2

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

Status1 → Composition

Cumulative

The composition of the platoon changes if tanks are fatally damaged.

Status2 → Composition

Cumulative

Composition → Status1

Distributive

Composition → Status2

Distributive

Velocity → Position

Modelling

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

Velocity1 → Position1

Modelling

Velocity2 → Position2

Modelling

Acceleration → Velocity

Modelling

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

Acceleration1 → Velocity1

Modelling

Acceleration2 → Velocity2

Modelling

...

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

D.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 34. The mapping functions are presented as pseudo-code. Error-checking has been omitted for brevity. Pseudo-code in the second column of Table 34 implements specifications in the last column of Table 33. Mapping functions such as those shown in Table 34 translate values or changes in values of attributes.

Mapping Functions for RPR Platoon-Tanks MRE

Dependency

Mapping Function

Position1 → Position

Position ← fd (Position1, Position2)

fl : Position.X ← (Position1.X + Position2.X) / 2

Position.Y ← (Position1.Y + Position2.Y) / 2

Position.Z ← (Position1.Z + Position2.Z) / 2

Position2 → Position

Position → Position1

(Position1, Position2) ← gd (Position)

gl : δPosition1.X ← δPosition2.X ← δPosition.X

δPosition1.Y ← δPosition2.Y ← δPosition.Y

δPosition1.Z ← δPosition2.Z ← δPosition.Z

Position → Position2

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 34 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 73 and applying the mapping functions in Table 34 ensures that the Platoon-Tanks MRE is consistent at all observation times. Next, we determine and resolve the effects of concurrent interactions.

D.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 35. 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 35) 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 attributes Position, Velocity and Orientation.

The last column in Table 35 lists the type of an interaction. Assigning a type requires information about the semantics of an interaction. For example, the semantics of CreateObjectRequest could be that the SimulationManager requests an AggregateEntity to create a new entity as its constituent. If such a request must always be satisfied by an AggregateEntity, CreateObjectRequest is a Type 2 interaction. CreateObjectResult is the response to a CreateObjectRequest. CreateObjectResult could be Type 0 or Type 1, but we assigned it to Type 1 because the SimulationManager may discard an update about the created object. 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 RPR

Interaction

Sender Class

Sender Attributes

Receiver

Receiver Attributes

Interaction Parameters

ISR

Type

ActionRequest

SimulationManager

none

AggregateEntity

none

ObjectCount, ObjectIDs, Action

IR

2

ActionResult

AggregateEntity

none

SimulationManager

none

ActionResult

IR

1

AttributeChangeRequest

SimulationManager

none

AggregateEntity

none

ObjectCount, ObjectIDs, AttributeValueSet

IR

2

AttributeChangeResult

AggregateEntity

none

SimulationManager

none

ObjectID, AttributeChangeResult, AttributeValueSet

IR

1

Collision

PhysicalEntity

Acceleration, AngularVelocity, Status, Orientation, Position, Velocity

PhysicalEntity

Acceleration, AngularVelocity, Status, Orientation, Position, Velocity

CollidingObjectID, CollidingObjectMass, CollidingObjectVelocity, CollisionType, CollisionLocation, EventID, IssuingObjectID

IR

0

CreateObjectRequest

SimulationManager

none

AggregateEntity

none

ObjectClass, AttributeValueSet

IR

2

CreateObjectResult

AggregateEntity

none

SimulationManager

none

CreateObjectResult

IR

1

MunitionDetonation

MilitaryPlatformEntity

none

PhysicalEntity

Acceleration, AngularVelocity, Status, Orientation, Position, Velocity

ArticulatedPartsArray, ArticulatedPartsCount, DetonationLocation, DetonationResult, EventID, FiringObjectID, FinalVelocityVector, FuseType, MunitionObjectID, MunitionType, QuantityFired, RateOfFire, RelativeDetonationLocation, TargetObjectID

IR

0

RemoveObjectRequest

SimulationManager

none

AggregateEntity

none

ObjectCount, ObjectIDs

IR

2

RemoveObjectResult

AggregateEntity

none

SimulationManager

none

RemoveObjectResult

IR

1

WeaponFire

MilitaryEntity

none

 

none

EventID, FireControlSolutionRange, FireMissionIndex, FiringLocation, FiringObjectID, FuseType, InitialVelocityVector, MunitionObjectID, MunitionType, QuantityFired, RateOfFire, TargetObjectID, WarheadType

IR

0

ChangeCourse

BaseEntity

Position, Velocity, Orientation

BaseEntity

Position, 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 36, 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 ChangeCourse can be sent by an entity of class BaseEntity. Since BaseEntity is a base class of Platoon, Tank1 and Tank2, we distinguish the interaction ChangeCourse sent by these three entities as ChangeCourse-P, ChangeCourse-T1 and ChangeCourse-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 73. Finally, we indicate the type of the interaction.

Effects of Interactions for RPR Platoon-Tanks MRE

Interaction

S/R

affects

affects +

Type

ActionResult-P

S

 

 

1

AttributeChangeResult-P

S

 

 

1

CreateObjectResult-P

S

 

 

1

RemoveObjectResult-P

S

 

 

1

Collision-T1

S

Acceleration1, AngularVelocity1, Status1, Velocity1, Orientation1, Position1

Acceleration, Status, AngularVelocity, Velocity, Orientation, Position, Composition, Acceleration2, Status2, AngularVelocity2, Velocity2, Orientation2, Position2, Acceleration1, Status1, AngularVelocity1, Velocity1, Orientation1, Position1

0

Collision-T2

S

Acceleration2, AngularVelocity2, Status2, Velocity2, Orientation2, Position2

Acceleration, Status, AngularVelocity, Velocity, Orientation, Position, Composition, Acceleration1, Status1, AngularVelocity1, Velocity1, Orientation1, Position1, Acceleration2, Status2, AngularVelocity2, Velocity2, Orientation2, Position2

0

WeaponFire-T1

S

 

 

0

WeaponFire-T2

S

 

 

0

ChangeCourse-P

S

Position, Velocity, Orientation

Position1, Velocity1, Orientation1, Position2, Velocity1, Orientation2, Position, Velocity, Orientation

3

ChangeCourse-T1

S

Position1, Velocity1, Orientation1

Position, Velocity, Orientation, Position2, Velocity2, Orientation2, Position1, Velocity1, Orientation1

3

ChangeCourse-T2

S

Position2, Velocity2, Orientation2

Position, Velocity, Orientation, Position1, Velocity1, Orientation1, Position2, Velocity2, Orientation2

3

ActionRequest-P

R

 

 

2

AttributeChangeRequest-P

R

 

 

2

CreateObjectRequest-P

R

 

 

2

RemoveObjectRequest-P

R

 

 

2

Collision-T1

R

Acceleration1, AngularVelocity1, Status1, Velocity1, Orientation1, Position1

Acceleration, Status, AngularVelocity, Velocity, Orientation, Position, Composition, Acceleration2, Status2, AngularVelocity2, Velocity2, Orientation2, Position2, Acceleration1, Status1, AngularVelocity1, Velocity1, Orientation1, Position1

0

Collision-T2

R

Acceleration2, AngularVelocity2, Status2, Velocity2, Orientation2, Position2

Acceleration, Status, AngularVelocity, Velocity, Orientation, Position, Composition, Acceleration1, Status1, AngularVelocity1, Velocity1, Orientation1, Position1, Acceleration2, Status2, AngularVelocity2, Velocity2, Orientation2, Position2

0

MunitionDetonation-T1

R

Acceleration1, AngularVelocity1, Status1, Velocity1, Orientation1, Position1

Acceleration, Status, AngularVelocity, Velocity, Orientation, Position, Composition, Acceleration2, Status2, AngularVelocity2, Velocity2, Orientation2, Position2, Acceleration1, Status1, AngularVelocity1, Velocity1, Orientation1, Position1

0

MunitionDetonation-T2

R

Acceleration2, AngularVelocity2, Status2, Velocity2, Orientation2, Position2

Acceleration, Status, AngularVelocity, Velocity, Orientation, Position, Composition, Acceleration1, Status1, AngularVelocity1, Velocity1, Orientation1, Position1, Acceleration2, Status2, AngularVelocity2, Velocity2, Orientation2, Position2

0

ChangeCourse-P

R

Position, Velocity, Orientation

Position1, Velocity1, Orientation1, Position2, Velocity1, Orientation2, Position, Velocity, Orientation

3

ChangeCourse-T1

R

Position1, Velocity1, Orientation1

Position, Velocity, Orientation, Position2, Velocity2, Orientation2, Position1, Velocity1, Orientation1

3

ChangeCourse-T2

R

Position2, Velocity2, Orientation2

Position, Velocity, Orientation, Position1, Velocity1, Orientation1, Position2, Velocity2, Orientation2

3

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

D.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 37.

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 37) or for instances of interactions (e.g., all the other rows in Table 37). In RPR, 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 ActionRequest-P and RemoveObjectRequest-P 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 RPR Platoon-Tanks MRE

Concurrent Interactions

Condition

Policy

MunitionDetonation-Ti, Collision-Ti

Always

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

RemoveObjectRequest-P, any combination of (ActionRequest-P, AttributeChangeRequest-P, CreateObjectRequest-P)

Same object

Order all before RemoveObjectRequest-P

CreateObjectRequest-P, any combination of (ActionRequest-P, AttributeChangeRequest-P, RemoveObjectRequest-P)

Same object

Order all after CreateObjectRequest-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

D.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 74 shows an RPR 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 73 and mapping functions in Table 34. 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 37. 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.