A Composability Lexicon
Mikel D. Petty and Eric W. Weisel
Virginia Modeling, Analysis and Simulation Center
Old Dominion University
Norfolk VA 23529
mpetty@vmasc.odu.edu 757-686-6210, eweisel@odu.edu 757-686-6227
Keywords:
Composability, Interoperability
ABSTRACT: Composability is the capability to select
and assemble simulation components in various
combinations into simulation systems to satisfy specific
user requirements.
The defining characteristic of
composability is the ability to combine and recombine
components into different simulation systems for different
purposes. Composability would have many benefits for
the practice of simulation. However, the precise meaning
of the term “composability” and related terminology in
the research literature is surprisingly varied.
Composability has multiple related meanings or levels
that differ primarily by the question of what is being
composed. Nine distinct levels of composability are
identified, defined, and compared.
Two views on
composability, concerned with the syntactic and semantic
aspects of composability respectively, are contrasted.
Interoperability and configurability are related to
composability, but they are different ideas, as
interoperability is necessary but not sufficient to produce
composability at the federate level.
1.
Introduction
Composability is an increasingly important issue in
simulation system development. Different meanings of
the term appear in the simulation research literature; they
are generally similar in concept but often differ in
emphasis or level. The fact that composability means
different things in different contexts has been noted
previously [1]. The goal of this paper is to clarify the
lexicon of composability by giving a single common
definition for the term, listing and defining different
levels of composability, and differentiating composability
from related ideas, such as interoperability.
2.
Definition of Composability
These example definitions of composability from the
literature illustrate the variations that can be found:
The ability to rapidly configure, initialize, and
test an exercise by logically assembling a
simulation from a pool of reusable components
[2].
The ability to create, configure, initialize, test,
and validate an exercise by logically assembling
a unique simulation execution from a pool of
reusable system components in order to meet a
specific set of objectives [3].
The ability to build new things from existing
pieces [4].
The ability to compose models/modules across a
variety of application domains, levels of
resolution and time scales [5].
The following common definition of composability is
proposed. Composability is the capability to select and
assemble simulation components in various combinations
into valid simulation systems to satisfy specific user
requirements.
The components to be composed may be drawn from a
library or repository of components, as suggested in
Figure 1. That library might include multiple network
interfaces, different user interfaces, a range of classes of
implemented entity models, a variety of implemented
physical models at different levels of fidelity, and so on.
Different sets of components from the repository may be
composed into different simulation systems.
The
components may be reused in multiple simulation
systems.
The defining characteristic of composability is that
different simulation systems can be composed at
configuration time in a variety of ways, each suited to
some distinct purpose, and the different possible
compositions will be usefully valid simulation systems.1
Composability is more than just the ability to put
simulations together from parts; it is the ability to
combine and recombine, to configure and reconfigure,
sets of parts from those available into different simulation
systems to meet different needs.
If the compositions aren’t valid, then by definition they
aren’t composable.
1
Component
Repository
Simulation A
11
33
22
33
52
52
Simulation B
11
88
33
22
22
...
N
N
N
N
Figure 1. Notional example of composability.
3.
When uses of the term “composability” in the literature
are compared it is apparent there is one way in which the
meanings often differ. Indeed, that difference is hinted at
in the quotations given earlier. The uses differ on the
question of what is being composed and what is formed
by the composition. A number of different answers can
be found in the literature; they will be referred to as levels
of composability. Nine levels of composability are
defined here.2 These levels have been drawn from
various sources, some of which explicitly or implicitly
include several of the levels defined here in composability
(e.g., [6]). Composability levels from different sources
that were essentially the same have been combined.
Those listed here have different meanings and
implications, but there may be some overlap in
component and scale between them.
1.
2
and auxilliary software components are composed
into simulation events, exercises or experiments [7].
For this to be a level of composability, rather than
simply integration, the composition must be done in
way that allows combining and recombining the
applications into different systems and events (more
on the distinction between composition and
integration later). This level of composability has
also been called “event-level” [7].
Levels of Composability
Application. Applications such as simulations, real
C4I systems, networks, communications equipment,
In this list the levels are named after the unit of
composition, i.e., the components being composed.
Another method of naming the levels is after the result of
composition, i.e., what is produced from the components.
Other sources have taken both the former approach [1] [2]
and the latter approach [7].
2.
Federate. Federates are composed into persistent
federations.3 A federation is persistent if is reused for
a number of different purposes (such as events,
exercises, or experiments), though possibly with
some changes to the set of federates that have been
composed. The composition may be supported by an
interoperability protocol, such as HLA, ALSP, or
DIS.4 Examples of this level of composability
include the Joint Training Confederation and the
The terms “federate” and “federation” have specific
HLA meanings; here they are being used with more
generic meanings analogous to their HLA meanings to
denote simulations linked together, but not necessarily
with HLA.
3
4
DIS is Distributed Interactive Simulation, ALSP is
Aggregrate Level Simulation Protocol, and HLA is High
Level Architecture.
Combat Trauma Patient Simulation [8]. This level of
composability has also been called “federation-level”
[7].
3.
Package. Pre-assembled packages comprising sets of
models that form a consistent subset of the
battlespace are composed into simulations [1] [2].
4.
Parameter. Parameters are used to configure preexisting simulations [1] [2]. The sources also include
in this level of composability, which they call the
“simulation” level, the idea that a limited pool of
packages may be composed into simulations. In the
lexicon of this paper that second level is included in
package level.
5.
6.
Module. Software modules5 are composed into
software executables. The executables may be
federates in a federation or standalone simulation
systems. The OneSAF family of software products is
expected to have this level of composability [9] [10]
[11].
Model. Separate models of smaller-scale processes
or objects6 are composed into composite models of
larger-scale processes or objects. For example,
models of platform/entity sub-systems, such as
sensors and weapons, may be composed into
composite models of platforms/entities, such as
aircraft [7]. Models of physical processes, such as
wind and rainfall, may be composed into composite
models of larger-scale physical phenomena, such as
weather.
The composite models may be
implemented as modules or federates. This level of
composability is a design goal of both ModSAF [12]
and OneSAF [13]. This level of composability has
also been called “object-level” [7], “component” [2],
and “reconfigurable models” [14].
The term “software component” is also used with this
meaning, and if used here, would make this the
“component” level of composability. However, in this
paper the term “component” is used in a general sense as
the units of composition at any level.
5
Here “object” means simulated real-world object, not
software object. The former is not always implemented
as the latter and assuming so is an oversimplification.
Even if a real-world object class, such as an aircraft type,
is implemented as a software object class, it is not correct
to assume that the sub-components of that real-world
object class, such as sensors and weapons, are
implemented as sub-classes of the software object class.
That is a mixing of is-a and part-of relationships.
6
7.
Data. Sets of data are composed into databases. The
data sets may be initially distinct because they
describe different entities, they are from different
sources, or they represent different aspects of some
phenomena. Different data sets were composed to
represent electronic warfare in DIS [15]. SEDRIS is
intended to support such composability for natural
environment databases.
8.
Entity.
Platforms/entities are composed into
groupings such as military units, force structures, and
scenario orders of battle [7].
This level of
composition may be hierarchical, with several layers
of groupings composed into higher level groupings.
This level of composition is typically done with data,
rather than with software, as in ModSAF and
WARSIM. This level of composition has also been
called “federate-level” [7].
9.
Behavior. Low-level atomic behaviors are composed
into high-level composite behaviors, which are to be
executed by autonomous simulation entities in a
computer generated forces system or constructive
simulation. The behaviors may be expressed in a
variety of forms. Examples include hierarchically
organized finite state machines as used in ModSAF
and its variants [16] and process flow diagrams [17].
Table 1 summarizes these composability levels.
4.
Composability as a Simulation System
Requirement
Composability has become established as an official
requirement for new simulation system development. The
best example of this is OneSAF; composability is
mentioned numerous times in the OneSAF Operational
Requirements Document [9]. It appears twice in the
shortcomings list, as the Composability item “Current
SAFs are not composable for specific applications.” and
as the main point of the Fidelity in physical models item
“…ability to compose an exercise or study with increased
or decreased resolution without modification to the code.”
The ORD says that OneSAF will “… provide a
framework and supporting technology that permits
OneSAF components to be selected, configured, and
integrated into a common simulation environment capable
of being tailored to meet requirements of every M&S
domain.” Interestingly, the first and last of these
requirements seem to be at the module level, while the
second seems to be at the model level.
Components
Composition
Example(s)
Application
Event
Unified Endeavor
Federate
Federation
Package
Simulation
Joint Training Confederation
Combat Trauma Patient Simulation
JSIMS
Parameter
Simulation
JSIMS
Module
Executable
OneSAF
Model
Composite model
Data
Database
Entitie
Military unit
Behavior
Composite behavior
ModSAF
OneSAF
Electronic warfare in DIS
SEDRIS
ModSAF
WARSIM
Finite state machines
Process flow diagrams
Table 1. Levels of composability.
5.
Types of Composability
Composability can be understood from both engineering
and modeling perspectives. The common definition given
earlier
emphasizes
engineering
composability.
Engineering and modeling composability have also been
called syntactic and semantic composability, respectively
[4] [18].7 Engineering composability, i.e., the actual
implementation of composability, requires that the
composable components be constructed so that their
implementation details, such as parameter passing
mechanisms, external data accesses, and timing
assumptions are compatible for all of the different
configurations that might be composed. The question in
engineering (syntactic) composability is whether the
components can be connected.
In contrast, modeling (semantic) composability is a
question of whether the models that make up the
composed simulation system can be meaningfully
composed, i.e., if their combined computation is
semantically valid. The term model is commonly defined
as a mathematical or logical representation of some
system or object. Models are often implemented as
computer code and executed over time; that execution is
simulation. Models use equations and algorithms that
7
In this paper we will use the terms engineering/syntactic
and modeling/semantic interchangably, as best suits the
context. In a companion paper we generally use syntactic
and semantic composability [27].
mimic the pertinent aspects of the system or object. Nontrivial simulations may have many models, organized
hierarchically (models invoking sub-models) and
collaboratively (models exchanging data with co-models)
in intricate ways. When composing models, it is
necessary to determine if the inputs each model will
receive, which are often outputs of the models it is
composed with, will be within its domain of validity. For
example, suppose a composite model of an aircraft is
composed from two valid component models, one of the
aircraft’s jet engine and one of its flight dynamics. Even
if both component models are valid, the composition will
not be valid if the engine model produces supersonic
velocities for the aircraft and the flight dynamics model is
only valid for subsonic velocities. Similarly, it is also
necessary to determine if the assumptions made in each
model of a composition are consistent. A model of
aircraft detection composed of components that in some
cases assume infra-red signature is independent of aspect
angle and in others consider aspect angle when
calculating infra-red signature will probably not be valid.
6.
Related
Ideas:
Interoperability,
Integration, and Configurability
Certain other ideas are closely related to composability;
two, interoperability and configurability, are defined and
distinguished from composability.
For simulations, interoperability is the ability of different
simulations, connected in a distributed simulation system,
to meaningfully collaborate to simulate a common
scenario or virtual world. Their collaboration is normally
based on the run-time exchange of simulation data or
services, typically using an interoperability protocol such
as DIS, ALSP, or HLA. Like composability, two types of
simulation interoperability can be identified:
(1)
technical interoperability (compatible, correct use of the
interoperability
protocol)
and
(2)
substantive
interoperability (exchange of information that is mutually
consistent with the interoperating simulations’ model
semantics) [19].8 Substantive interoperability has also
been called meaningful interoperability [20].
It should be clear that these two types of interoperability
are closely analogous to the definitions given earlier for
engineering and modeling (or syntactic and semantic)
composability.
How, then, do interoperability and
composability differ? Essentially, interoperability is the
ability to exchange data or services at run-time, whereas
composability is the ability to assemble components prior
to run-time [6]. Note that interoperability as usually
meant only applies to interoperating federates, analogous
to the federate level of composability. Interoperability is
normally thought of as a property of federates, not of
models or data.
It can be seen that interoperability is necessary but not
sufficient to provide composability.
Composability
(engineering and modeling) does require interoperability
(technical and substantive). Federates that are not
interoperable can not be composed, so interopability is
necessary for composability.9 However, interoperability
is not sufficient provide composability, i.e., federates may
be interoperable but not composable. Recall that an
essential aspect of composability is the ability not just to
combine federates but to combine and recombine
federates into different simulation systems. Federates that
are interoperable in one specific configuration or with one
specific object model, and cannot be combined and
recombined in other ways, are not composable.
Non-persistent federations sometimes provide examples
of interoperability without composability.
A nonpersistent federation is one that exists for the purpose of
supporting a specific event, exercise, or experiment and is
not intended to persist beyond that purpose.10 Examples
8
HLA compliance primarily establishes technical, not
substantive, interoperability.
9
Also, federates that are composable are necessarily
interoperable.
of this type of federation include the Platform ProtoFederation [21] and the MV-22 Osprey operational
evaluation federation [22].
The federates of nonpersistent federations are necessarily interoperable, in that
they interoperate during execution, but they are
composable if and only if the set of federates in the
federation can be changed without requiring substantial
additional integration effort.
The matter of substantial effort is crucial to the distinction
between interoperability and composability. Integration
is the process of configuring and modifying a set of
components to make them interoperable and possibly
composable. Essentially any federate can be integrated
into any federation with enough effort, but composability
implies that the changes can be made with little effort.
The ability to readily combine and recombine is what
distinguishes composable simulations from integrated or
interoperable simulations.
Configurability is the ability to include varying numbers
of identical federates in a federation, e.g., “generating an
exercise with eight rather than four M1A2 tank
[simulators]” [3]. This capability is not the same as the
ability to combine and recombine simulation components
into different simulation systems that defines
composability.
7.
Composability Research
There has been some composability research, primarily
focused on engineering composability, giving attention to
the interfaces and control mechanisms to compose
previously existing software modules or models of
behavior. Some module level composability has been
achieved using dynamically loadable modules [23]. The
degree to which object frameworks can achieve a
composable computer generated forces architecture has
been investigated [10]. That study concluded that
composability based on object frameworks is “an
implementation issue.” Multiple efforts have worked
towards allowing the composition of autonomous
behaviors into more complex composite behaviors [24]
[17]. Architectures that support composability have been
designed [6].
There has been less research into composability theory,
even though the need for such research has been
recognized [5] [25]. The latter reference states the need
clearly: “We are discovering that unless models are
designed to work together, they don’t (at least not easily
10
Indeed, in the context of accreditation it could be
argued that all federations are non-persistent because the
accreditation of a federation is by definition for a specific
purpose only, and the use of the federation for another
purpose requires a new accreditation. However, in this
paper “persistent” and “non-persistent” refer to
development and integration, not accreditation.
and cost effectively). Without a robust, theoretically
grounded framework for design, we are consigned to
repeat this problem for the foreseeable future” [5]. One
theoretical look at composability found that the process of
selecting the set of components to meet given
requirements was unexpectedly complex [26].
[7] G. M. Post, “J9 Composability Summary Comments”,
Electronic mail, June 12 2002.
[8]
M. D. Petty and P. S. Windyga, “A High Level
Architecture-based
Medical
Simulation”,
SIMULATION, Vol. 73, No. 5, November 1999, pp.
279-285.
8.
[9]
United States Army, One Semi-Automated Forces
Operational Requirements Document, Version 1.1,
Online
document
at
URL
http://wwwleav.army.mil/nsc/stow/saf/onesaf/onesaf.htm/,
August 21 1998.
Summary
Composability is an important concept in modeling and
simulation. Composability has various meanings that
differ primarily by what level of component is being
composed. It is useful to be aware of these different
“levels” of composability, as well as of the distinctions
between syntactic and semantic composability and
between composability and interoperability.
9.
Acknowledgement
The work was sponsored by the Office of Naval Research
and the Defense Modeling and Simulation Office under
contract N00014-03-1-0089. That support is gratefully
acknowledged.
10. References
[1] E. H. Page and J. M. Opper, “Theory and Practice in
User-Composable Simulation Systems”, Presentation
for DARPA Advance Simulation Technology Thrust,
October 30 1998.
[2]
JSIMS Composability Task Force, “JSIMS
Composability Task Force Final Report”, September
30 1997.
[3] S. M. Harkrider and W. H. Lunceford, “Modeling and
Simulation Composability” Proceedings of the 1999
Interservice/Industry Training, Simulation and
Education Conference, Orlando FL, November 29
1999-December 2 1999.
[4] D. R. Pratt, L. C. Ragusa, and S. von der Lippe,
“Composability as an Architecture Driver”,
Proceedings of the 1999 Interservice/Industry
Training, Simulation and Education Conference,
Orlando FL, November 29 1999-December 2 1999.
[5] S. Kasputis and H. C. Ng, “Composable simulations”,
Proceedings of the 2000 Winter Simulation
Conference, Orlando FL, December 10-13 2000, pp.
1577-1584.
[6]
M. Biddle and C. Perry, “An Architecture for
Composable Interoperability”, Proceedings of the
Fall 2000 Simulation Interoperability Workshop,
Proceedings of the Fall 2000 Simulation
Interoperability Workshop, Orlando FL, September
17-22 2000, 03S-SIW-073.
[10] A. J. Courtemanche and R. B. Burch, “Using and
Developing Object Frameworks to Achieve a
Composable CGF Architecture”, Proceedings of the
Ninth Conference on Computer Generated Forces
and Behavioral Representation, Orlando FL, May
16-18 2000, pp. 49-62.
[11] A. J. Courtemanche and R. L. Wittman, “OneSAF:
A Product Line Approach for a Next-Generation
CGF”, Proceedings of the Eleventh Conference on
Computer-Generated
Forces
and
Behavior
Representation, Orlando FL, May 7-9 2002, pp. 349361.
[12]
A. Z. Ceranowicz, “ModSAF Capabilities”,
Proceedings of the Fourth Conference on Computer
Generated Forces and Behavioral Representation,
Orlando FL, May 4-6 1994, pp. 3-8.
[13]
C. Henderson and A. Rodriguez, “Modeling in
OneSAF”, Proceedings of the Eleventh Conference
on Computer-Generated Forces and Behavior
Representation, Orlando FL, May 7-9 2002, pp. 337347.
[14] A. Diaz-Calderon, C. J. J. Paredis, and P. K. Khosla,
“Organization and Selection of Reconfigurable
Models”, Proceedings of the 2000 Winter Simulation
Conference, Orlando FL, December 10-13 2000, pp.
386-393.
[15] D. D. Wood and M. D. Petty, “Electronic warfare
and Distributed Interactive Simulation”, in T. L.
Clarke (Editor), Distributed Interactive Simulation
Systems for Simulation and Training in the
Aerospace Environment, SPIE Critical Reviews of
Optical Science and Technology, Vol. CR58, SPIE
Press, Bellingham WA, 1995, pp. 179-194.
[16] R. B. Calder, J. E. Smith, A. J. Courtemanche, J. M.
F. Mar, and A. Z. Ceranowicz, “ModSAF Behavior
Simulation and Control”, Procedings of the Third
Conference on Computer Generated Forces and
Behavioral Representation, Orlando FL, March 1719 1993, pp. 347-356.
[17] S. D. Peters, N. D. LaVine, L. Napravnik, and D. M.
Lyons, “Composable Behaviors in an Entity Based
Simulation”, Proceedings of the Spring 2002
Simulation Interoperability Workshop, Orlando FL,
March 10-15 2002.
[27] M. D. Petty and E. W. Weisel, “A Formal Basis for
a Theory of Semantic Composability”, Proceedings
of the Spring 2003 Simulation Interoperability
Workshop, Orlando FL, March 30-April 4 2003, 03SSIW-054.
[18]
A. Z. Ceranowicz, “Composability Wrapup”,
Electronic mail, June 10 2002.
11. Authors’ Biographies
[19]
J. S. Dahmann, “High Level Architecture
Interoperability Challenges”, Presentation at the
NATO Modeling & Simulation Conference, Norfolk
VA, October 25-29 1999.
MIKEL D. PETTY is Chief Scientist of the Virginia
Modeling, Analysis & Simulation Center at Old
Dominion University. He received a Ph.D. in Computer
Science from the University of Central Florida in 1997.
Dr. Petty has worked in modeling and simulation research
and development since 1990 in the areas of simulation
interoperability, computer generated forces, multiresolution simulation, and applications of theory to
simulation. He previously worked for the Institute for
Simulation and Training at the University of Central
Florida. He has served as a member of a National
Research Council committee on modeling and simulation
and is currently an Associate Editor of the journal
SIMULATION: Transactions of the Society for Modeling
and Simulation International.
[20] D. L. Clark, S. K. Numrich, R. J. Howard, and G.
Purser, “Meaningful Interoperability and the
Synthetic Natural Environment”, Proceedings of the
2001
European
Simulation
Interoperability
Workshop, London Middlesex UK, June 25-27 2001,
01E-SIW-080.
[21] S. M. Harkrider and M. D. Petty, “Results of the
High Level Architecture Platform Proto-Federation
Experiment”, Proceedings of the 8th International
Training and Education Conference, Lausanne
Switzerland, April 22-25 1997.
[22]
L. Huntt, A. Markowich, and L. Michelletti,
“Modeling and Simulation Augments V-22
Operational Testing”, Proceedings of the 2000
Interservice/Industry Training, Simulation and
Education Conference, November 27-30 2000,
Orlando FL, pp. 945-953.
[23] D. Franceschini, J. Zimmerman, and G. McCulley,
“CGF System Composability through Dynamically
Loadable Modules”, Proceedings of the Eighth
Conference on Computer Generated Forces and
Behavioral Representation, Orlando FL, May 11-13
1999, pp. 341-347.
[24] S. von der Lippe, J. S. McCormack, and M. Kalphat,
“Embracing Temporal Relations and Command and
Control in Composable Behavior Technologies”,
Proceedings of the Ninth Conference on Computer
Generated Forces and Behavioral Representation,
Orlando FL, May 16-18 2000, pp. 183-192.
[25] P. Davis, P. A. Fishwick, C. M. Overstreet, and C.
D. Pegden, “Model composability as a research
investment: Responses to the featured paper”,
Proceedings of the 2000 Winter Simulation
Conference, Orlando FL, December 10-13 2000,
pp.1585-1591.
[26] E. H. Page and J. M. Opper, “Observations on the
Complexity
of
Composable
Simulation”,
Proceedings of the 1999 Winter Simulation
Conference, Phoenix AZ, December 5-8 1999, pp.
553-560.
ERIC W. WEISEL is a Project Scientist at the Virginia
Modeling, Analysis & Simulation Center at Old
Dominion University. He received a M.S. in Operations
Research from the Florida Institute of Technology in 1995
and a B.S. in Mathematics from the United States Naval
Academy in 1988. He is currently a Ph.D. student in
modeling and simulation at Old Dominion University.
His research interests include simulation formalism and
composability. He is also President of WernerAnderson,
Inc., a private veteran-owned small business that performs
research and development in the areas of defense-related
operations research and simulation. He previously served
as a U.S. Navy submarine officer with experience in
nuclear engineering, operations management, navigation,
and joint operations.