"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
We demonstrate how designers can employ
and Object Model Template (OMT) to achieve effective Multi-Representation Modelling (MRM). We incorporate
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
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.
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.
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
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.
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.
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.
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.
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.
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
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
, 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
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.
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
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
+ for the interaction. These attributes can be determined from the ADG in Figure 70. Finally, we indicate the type of the interaction. Since in
we do not aggregate or disaggregate, we do not expect the DisaggregateRequest interaction to occur.
Any subset of the interactions in Table 28 may occur concurrently. Next, we show how to resolve the effects of concurrent interactions.
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.
Ignore Type 1
Ignore Type 3
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.