Working Notes

Definition.

JSIMS definition (from JSIMS Composability Task Force Final Report):

Composability -- the ability to rapidly configure, initialize, and test an exercise by logically assembling a simulation from a pool of reusable elements.

This definition is not entirely disagreeable, and certainly no definition is perfect. However, the use of the term ``logical'' is puzzling and the centrality of the user is not noted. Also use of the term ``exercise'' makes the definition training-centric (which is, of course, perfectly acceptable from a JSIMS perspective).

We suggest the following as an alternative definition (more general than that suggested by JSIMS, but not inconsistent with the JSIMS definition):

Composability -- the ability of a user to rapidly configure, assess and employ a simulation by assembling it from a collection of reusable elements.

Taxonomy

The JSIMS Composability Task Force Final Report identifies three levels of composability:

• Component - the simulation must be composed from fine-grained elements which represent individual models or algorithms, and single host machine or processors
• Package - the simulation is composed by selecting pre-assembled packages which carry numerous models designed to form a consistent subset of the battlespace
• Simulation - a complete simulation has been pre-assembled which can be modified by parameterization, or by substitution of alternative packages drawn from a limited pool

Composability use case

The JSIMS Composability Task Force Final Report describes the following use case for composability:

1. Analyze training needs (i.e., define training scenario). System will present archived library of pre-built compositions.
2. Trainers create (or load from JMSRR) force data (i.e., what units, bases, munitions, platforms, weapon systems, communications systems, etc. are anticipated). Context management provided to ensure simulation consistency.
3. Trainers create (or load from JMSRR) terrain data. Check appropriate context.
4. Trainers create (or load from JMSRR) weather data. Check appropriate context.
5. Based on force, terrain and weather data automatically determine what elements are needed from the JMSRR and present context choices as necessary. System will determine validated sets of combinations.
6. Trainers define any pre-planned events (e.g., initial ATO, OPFOR event, etc.).
7. Trainers define where training audience will be located (distributed audience).
8. Automatically determine what real-world systems could be used (modified by trainers).
9. From database (possibly in JMSRR) automatically define available resources/locations where models can run (distributed execution), then pare down/augment as necessary.
10. Define available locations for control cells (distributed control).
11. Automatically (with manual intervention) analyze force, terrain, and weather data along with trainee and resource locations to determine initial distribution of model elements and define resource requirements.
12. Automatically distribute responsibilities for model execution to execution resources (i.e., once it is decided what resources are needed, those resources need to be informed and reserved. This is both computer resources being informed what model components are needed and personnel being informed what functions they will do.
13. Archive baseline configuration.
14. Load the resources with the appropriate model components:
    1. receive assigned responsibility which would include information on what modeling infrastructure is needed, which terrain is required,
    2. automatically requests appropriate components from JMSRR (note: the resource may already have some components and it would only need to confirm they are the correct version),
    3. verify that the appropriate version of the Core Infrastructure and Life-Cycle applications are being used, if not obtain from the JMSRR,
    4. create initial model for this execution resource,
    5. initiate external interfaces.
15. Verify configuration including communications capability and compatibility of model components (i.e., correct fidelity and interactions), test and debug the composition.
16. Initiate model execution in a distributed environment.
17. Monitor and update resource allocation as needed (i.e., redistribute, and recompose).
18. Modify force, terrain, weather data as directed by game controllers including the addition of new platforms.
19. Re-baseline and archive to JMSRR.

This use case is well-stated and is consistent with the vision of other advanced simulation programs like OneSAF with respect to the key role of the simulation user and the high levels of automated support.

The degree to which, in the general case, a system can determine the consistency (Step 2) and validity (Step 5) of compositions is a subject of our investigation -- and a key to understanding the limits on composability and its relationship to other system objectives.

On the relationship between composability and multiresolution modeling

This problem seems to have both vertical and horizontal dimensions:

• In the horizontal dimension we consider the act of coupling two components for the sake of their interoperation. If the two components are not of the same resolution then we have entered the realm of multiresolution modeling, and current thinking in this area (e.g. the theories of Davis) indicates that multiresolution is fundamentally hard to do correctly.

  Thus, in the horizontal dimension, composability facilitates multiresolution modeling which is fundamentally hard.

• In the vertical dimension we consider the act of coupling two components for the sake of aggregation. Commonly, aggregation/de-aggregation forms the basis for resolving resolution differences in simulations. However, it can be shown that abstraction through aggregation may not provide the best (or even a valid) solution -- for example, Kepler's laws of planetary motion cannot be described in terms of quantum mechanics.

  Thus, in the vertical dimension, composability encourages abstraction through aggregation/de-aggregation, which may in turn hinder the application of other, more suitable, methods for abstraction.

Computability theory and composability

Draft working notes here (pdf file).