Applying UNIFY : A Process

8.1 Guidelines for MRM Designers

We present guidelines for achieving effective MRM using UNIFY . We justify each guideline briefly and refer to earlier sections in this dissertation for detailed explanations. We assume that a designer desires to construct a multi-model from models that meet their users' requirements. For each model, the designer must identify the representation of entities, relationships among attributes and interactions that change the state of entities. We assume the designer can identify the cross-model relationships in the multi-model, can understand the intertwined semantics of interactions and can make time-steps in the multi-model compatible.

1. G1: Represent entities at levels at which they can interact.
   This guideline arises from FO-1 in §4.2. For effective MRM, entities should interact at a representation level at which their semantics are compatible (see Figure 9 in Chapter 4).
2. G2: Maintain concurrent representations for jointly-executing models.
   Maintaining concurrent representations means preserving them at all times and permitting interactions to change them. MREs maintain concurrent representations (see Chapter 5). Designing MREs can ensure that entities interact at levels at which their semantics are compatible.
3. G3: Make the time-steps of the multiple models compatible.
   If jointly-executing models have compatible time-steps, neither violates any assumptions made by another during any time-step. Achieving compatible time-steps may involve executing some models at finer or coarser time-steps (see §3.3.3). Accordingly, the attributes in the models may be augmented with tolerance values, which determine acceptable variances in the values of the attributes at overlapping simulation times (see §4.2.4).
4. G4: Capture cross-model relationships.
   Capturing relationships among representations involves determining the semantics of attributes that are part of the representations. Attributes with overlapping semantics are likely to be related to one another. Relationships among models can be captured by Attribute Dependency Graphs and mapping functions (see Chapter 6).
5. G5: Propagate the effects of an interaction to all representation levels.
   An interaction affects the attributes at its own representation level as well as related attributes at other representation levels (see FO-2 in §4.2.2). Propagating the effects of interactions to all relevant attributes ensures that multiple representations are consistent.
6. G6: Select mapping functions for each relationship between representations.
   These functions translate value spaces or changes in values among related attributes. Mapping functions must satisfy the properties time-bounded completion, composability and reversibility (see §6.2).
7. G7: Identify semantics characteristics of interactions.
   In §7.5, we presented a taxonomy of interactions, consisting of four classes, in order to reduce the complexity of resolving concurrent interactions. Alternative taxonomies are possible. Classifying an interaction involves understanding its semantics, i.e., its effects on its sender and receiver.
8. G8: Select policies for resolving the effects of dependent concurrent interactions.
   The effects of concurrent interactions may depend on one another (see FO-3, §4.2.3, §7.3). In §7.5.4, we presented example policies for resolving the effects of dependent concurrent interactions. Specifying policies for resolving interactions involves capturing the semantics of their concurrent occurrence.

By following these guidelines, designers can incorporate effective MRM into their applications. A multi-model can satisfy its users' requirements if MRM is effective.

8.2 Using UNIFY with a Specification Methodology

We expect designers of multi-models to achieve effective MRM by employing UNIFY in conjunction with a specification methodology. W e augment an existing specification methodology so that designers can build on familiar modelling techniques when they apply UNIFY . Specification methodologies such as OMTR [Rum91], OOA [Shlaer92] and UML [Alhir98] support specifying model representations and relationships, but not the effects of interactions. In contrast, OMT [OMT98] supports specifying the effects of an interaction in terms of its parameters, its sender, its receiver and the attributes it affects. Since resolving the effects of concurrent interactions is one of the hardest problems in MRM, we regard the support for interactions in OMT suitable for MRM. We augment OMT by permitting designers to specify attribute relationships, interaction types and policies for resolving concurrent interactions.

In the Department of Defense's High Level Architecture (HLA) initiative, multiple models may execute together in a "plug-and-play" fashion. Individual models and multi-models are specified using a methodology called the Object Model Template (OMT). In OMT, individual models, or federates, are specified by tables describing their interface. These tables together are called the Federate Object Model (FOM) for that federate. The FOM for a particular model has the following tables:

• · Object Class Structure Table (OCST) shows the class hierarchy along with information for whether each class is publishable (shareable with other models), subscribable (interesting to the current model) or both.
• · Attribute/Parameter Table (APT) lists object attributes and interaction parameters along with their data type, cardinality, units, resolution, accuracy, accuracy condition, update type and update condition.
• · Object Interaction Table (OIT) lists each interaction, its sender, its receiver, the attributes it affects and whether a model initiates, senses or reacts to it.
• · Enumerated Data Table (EDT) lists the values of all enumerations.
• · Complex Data Table (CDT) lists the definitions of all structured data types.
• · Object Class Definitions (OCD) describes the role of each entity.
• · Object Interaction Definitions (OID) describes each interaction.
• · Attribute/Parameter Definitions (APD) describes each object attribute and interaction parameter.

The OCST and the APT enable a designer to construct the representations for a multi-model. The APT and the OIT enable the designer to describe the interactions for the multi-model. In OMT, the only relationships that can be determined are those of base class and derived class [Strou91]. These relationships capture neither attribute relationships nor complex entity relationships. Furthermore, although in OMT a designer can specify the effects of an interaction, the designer cannot specify effects of concurrent interactions.

We augment OMT with tables that permit a designer to capture relationships among attributes and specify policies for resolving the effects of concurrent interactions. The inability to express entity relationships is a serious shortcoming in OMT. The class hierarchy captured by the OCST captures static entity relationships such as inheritance, but not the dynamic relationships among entities, for example, relationships of configuration. Therefore, we augment OMT with an Attribute Relationship Table (ART). This table lists each attribute dependency, its class and specifications for its associated mapping function. In OMT, the OIT and APT permit interactions to be specified in detail. We augment the OIT in OMT with a column for specifying the class for each interaction. Once the class for an interaction has been specified, policies for resolving the effects of concurrent interactions can be formulated. We augment OMT with a table, the Concurrent Interactions Table (CIT), which permits a designer to specify such policies. The CIT permits a designer to specify policies in terms of combinations of classes of interactions or individual interactions. Table 11 is an ART and Table 12 is a CIT for the example application developed in Chapters 6 and 7. With these additions, designers can employ OMT and UNIFY to incorporate MRM into their applications.

Example Attribute Relationship Table

Dependency	Type	Specification
Hits1 → Str	Cumulative	Str is the weighted sum of Hits1 and Hits2. Changes to Str are distributed to Hits1 and Hits2 according to weights on the dependencies.
Hits2 → Str	Cumulative
Str → Hits1	Distributive
Str → Hits2	Distributive
Ammo1 → Fire	Cumulative	Fire is the weighted sum of Ammo1 and Ammo2. Changes to Fire are distributed to Ammo1 and Ammo2 according to weights on the dependencies.
Ammo2 → Fire	Cumulative
Fire → Ammo1	Distributive
Fire → Ammo2	Distributive
Pos1 → Pos	Cumulative	Pos is the centroid of Pos1 and Pos2.
Pos2 → Pos	Cumulative
Pos → Pos1	Distributive
Pos → Pos2	Distributive
Vel → Pos	Modelling	Position Pos changes with Velocity Vel according to physical laws.
Vel1 → Pos1	Modelling
Vel2 → Pos2	Modelling

Example Concurrent Interactions Table

Concurrent Interactions	Condition	Policy
Move_Platoon, any combination of (Move_Tank1, Move_Tank2)	All received	Ignore all except Move_Platoon
Detonation, any combination of (Collide_Tank1, Collide_Tank2)	All received	Add compensatory interaction for competitive effects to Dam1 or Dam2; actual damage less than sum of damages
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

8.3 Process for Effective MRM

UNIFY can be summarised by the process diagram in Figure 48. The unshaded boxes represent steps in the process of applying UNIFY , whereas the shaded boxes represent steps in the design of models or a multi-model. The dashed arrows represent feedback in the process. We view designing models, constructing a multi-model and achieving MRM as iterative processes. We employed a running example of a Platoon-Tanks MRE in Chapters 6 and 7 in order to explain our techniques for effective MRM. Here, we present the process of applying those techniques.

UNIFY does not address the design of individual models. However, the steps in UNIFY depend on the successful completion of steps in the design of individual models. For example, constructing an MRE requires that the designer identify the representations of jointly-executing models, ModelA and ModelB. Conversely, constructing an MRE may provide insights into identifying representations of the models. Likewise, constructing an ADG and selecting mapping functions for an MRE requires that the designer identify the relationships within and among jointly-executing models. In the design of a model, identifying relationships can be carried out in parallel with identifying interactions. In like fashion, in UNIFY , constructing an ADG and selecting mapping functions can be carried out in parallel with classifying interactions and selecting policies for resolving concurrent interactions. In practice, these steps may be carried out sequentially; however, their relative order is unimportant.

Verification and validation (V&V) is an important step in the design of models. V&V is undertaken to ensure that a model is effective, i.e., meets its users' requirements. V&V for a multi-model depends on V&V for constituent models as well as V&V for MRM. V&V for constituent models is outside the scope of our work. V&V for MRM involves ensuring that jointly-executing models satisfy MRM requirements: multi-representation interaction (R1), multi-representation consistency (R2) and cost-effectiveness (R3). The MRE approach satisfies R3. If R1 and R2 are not satisfied, a designer must iterate through the process of achieving MRM. In turn, the designer may have to re-examine the construction of jointly-executing models.

We list the steps in UNIFY for the Platoon-Tanks MRE from Chapters 6 and 7. The Platoon-Tanks multi-model captured the combined semantics of a Platoon model and a Tank model. We employed UNIFY in order to achieve effective joint execution of the Platoon and Tank models. The steps we undertook in the process of employing techniques in UNIFY are listed below along with the sections in which we performed each step.

1. 1. Construct an MRE for the jointly-executing models: §6.1. The Platoon-Tanks MRE captured the concurrent representations of a Platoon and two Tanks. The MRE could interact at either or both representation levels at any time.
2. 2. Capture dependencies among the attributes in the MRE: §6.1. An ADG captured the dependencies among Platoon and Tank representations. By classifying and weighting dependencies, we captured their static and dynamic semantics.
3. 3. Select mapping functions for each dependency: §6.2. We selected mapping functions to translate values or changes in values among Platoon and Tank attributes. These mapping functions ensured that the Platoon-Tanks MRE was internally consistent at all observation times.
4. 4. Classify interactions: §7.6.2. We classified the interactions in the Platoon and Tank models according to our taxonomy. This classification enabled us to capture the semantics of interactions.
5. 5. Select policies for resolving concurrent interactions: §7.6.2. We selected policies for capturing the dependencies among concurrent interactions. These policies resolved the effects of dependent concurrent interactions.
6. 6. Construct a CE and an IR for the MRE: §6.3 and §7.6.2. A CE consists of an ADG and application-specific mapping functions, whereas an IR consists of policies for resolving the effects of interactions. We presented processes for the operation of a CE and IR for the Platoon-Tanks MRE. A CE and IR maintain internal consistency within an MRE when concurrent interactions occur.

The above steps constitute a process for achieving effective MRM for an application. The process and the techniques employed in each step are part of UNIFY , our approach for effective MRM. We demonstrated how to apply UNIFY to a multi-model application. We present our experience in applying the above process to several models in the appendices. Next, we evaluate UNIFY .