Dr. Katherine L. Morse, Science Applications International Corporation
Mikel D. Petty, Old Dominion University
Paul F. Reynolds, University of Virginia
William F. Waite, AEgis Technologies Group
Philomena M. Zimmerman, U. S. Army Research, Development, and Experimentation Command
Introduction & Background
Composability is the capability to select and assemble simulation components in various combinations into simulation systems to satisfy specific user requirements. Composability is more than just the ability to assemble simulations from parts; it is the ability to combine and recombine sets of components into different simulation systems to meet different needs. The components to be composed may be drawn from a component library or repository that could include multiple network interfaces, different user interfaces, a range of classes of entity models, a variety of physical models at different levels of fidelity, and so on. Different sets of components from the repository may be composed into different simulation systems, with the components reused in multiple simulation systems. The defining characteristic of composability is that the components can be composed in a variety of ways to produce different simulation systems, each suited to some distinct purpose, and the compositions will be usefully valid. Composability could have many benefits for the practice of simulation and is an increasingly important issue in simulation system development. A workshop was organized by DMSO in August 2003 to examine the state of composability, refine its definitions and intentions, identify capabilities and technologies needed to support practical composability, and propose research objectives and programmatic initiatives to move towards the goals of the Composable Mission Space Environments program. Approximately 35 experts from government, industry, and academia participated. They were organized into four working groups, each with a distinct perspective on composability: Components, Collaborative Infrastructures, Data and Metadata, and Business Cases. Each group examined composability from its perspective, producing definitions, explanations of key concepts, specifications of enabling technologies and processes, and recommendations for future actions.
Components
From the point of view of components, composability exists in syntactic and semantic forms. Syntactic composability is the engineering implementation of composability and is concerned with the compatibility of implementation details, such as parameter passing mechanisms, external data accesses, and timing mechanisms. Semantic composability is concerned with whether the models that make up the composed simulation system can be composed and remain valid. Modeling issues such as domains of validity and consistent assumptions are central to semantic composability.
Components, i.e. the things that are to be composed, are at the core of composability. To reflect this, an extended redefinition of composability was developed. Composability is a framework for the dynamic registration, discovery, and composition of components that include models, algorithms, services, agents, humans, and systems, to simplify the development of new simulations from currently existing components. Important in this definition is the idea that composability occurs in the context of an organizing framework.
A component is an encapsulated unit with a known set of inputs and expected output behavior; it is an interchangeable element of a system that conforms to a specification. A component’s specification should include details of the component’s interface(s) and model(s). The component’s behavior details may be hidden or unknown. Components that correspond to models of the real world may be larger than a single model of a domain-specific object, but are still small enough to be confined to a single area of subject matter expertise. Of course, not all components are real-world models; some may provide supporting infrastructure to simulation systems, such as a network interface or an event queue. Defining the size or functionality of a component is not amenable to rules applicable in all situations, but the composability definition of “satisfies user requirements” provides a guideline; a component should have capabilities that are useful to potential users as a unit, neither too small nor too large. The criteria for making that determination will necessarily depend on the application.
Components can be integrated with other components through well-defined interfaces associated with each component and documented in the component specification. Broadly understood, component interface becomes essentially synonymous with the component specification, or metadata. A narrower, and perhaps more useful, definition of component interface focuses on the API.
Composability affects modeling, i.e. the development of models as components, during implementation. Initial development of a composable component is more difficult than a non-composable one, but subsequent development is made easier by the use of previously developed components. Contributing to the additional initial effort is the need to document the assumptions and validity limits of the models in a composable component. Modeling practices already considered good in general, such as using parameters instead of constants, developing documentation, checking input for validity limits, and striving for clarity in model implementation, are beneficial in particular to the development of composable components that embody those models. Moreover, the needs of composability support good modeling practices, e.g. the requirement imposed by composability to document a model’s assumptions and limits of validity would help the modeler to consider his/her models more carefully at the outset.
Data and Metadata
Data and metadata are the “glue” that will hold composable components together. The composability process has two steps:
• Identification of components that meet fitness of purpose requirements
• Automatic unification and alignment of data models
“Automatic” in this context refers to the user, not the engineer; tagging the data model will require engineering effort analogous to the agile FOM concept, but probably more extensive. Automatic unification and alignment of data models happens at the syntactic level, i.e. for components determined to be meaningfully interoperable at the semantic level by some other mechanism. What metadata is required to support automatic unification/alignment and how metadata can support determination of semantic interoperability are open questions. The fundamental attributes and properties of a component from a data/metadata perspective are fitness for purpose, i.e. a finite set of purposes. This may require multiple layers of metadata for different levels of detail, and fitness for purpose will have multiple dimensions. Some metadata will be generic across all components, while other metadata will be applied as appropriate for the component. This metadata framework will require assessment processes and metrics for determining the degree to which a component satisfies the requirements for a purpose. The framework should also support recording federation agreement information.
Two recommendations with respect to data and metadata are:
• Develop a composability concept of operations; this should have use cases to clarify composability definition and elucidate requirements
• Develop a metadata framework; this will require participation from modeling subject matter experts from domain communities of interest
Achieving these goals once the composability concept of operations produces detailed requirements will, at a minimum, require the following steps:
1. Develop a “Common Conceptual Modeling Language” that describes components’ functionality, fidelity, performance
2. Define the metadata attributes and metrics for fitness of purpose as an initial description point that is extensible and modifiable, leading to a metadata framework
3. Develop quantitative values for metadata fitness where possible
4. Define a process to determine qualitative values when quantitative values are not practical
5. Develop tools that use the metadata framework to identify semantically composable components
Collaborative Environments for Composability
A collaborative environment (CE) for composable simulations should support electronic collaboration over geographical and temporal dimensions for exchanges of information, access to authoritative data relevant to the simulation domain, and execution of related technical applications and business functions. It should be based on agreed upon standards, rules, and local conventions. A successful CE will enhance users’ ability to effectively work together for a variety of application areas or problem domains throughout a simulation project's lifecycle. It should support distribution and management, e.g. security, information assurance, and quality of service, of all information and processes. It should be based on an open, scalable architecture and contain interoperable models, simulations, tools and data appropriate to the domain.
CEs for composability have some essential common capabilities and services that cut across various application domains. These capabilities support both configuration of a composable simulation and its execution, and include:
• Patterns and templates for component design • Design documentation standards
• Support for VV&A
• Visualization of information
• Configuration and data management
• Execution process management
• Execution monitoring, reporting and improvement
Business Case Summary & Recommendations
Composability has great potential to enhance and facilitate the development of defense-related models and simulations. To realize that potential a number of challenges must be overcome, not all of which are technical. Composability has a technical basis, but technical solutions need to be socialized in order to be successful. The opportunity exists to facilitate propitious business case conditions. The following recommendations are based on the recognition of this opportunity:
• Adopt composability ‘business case’ as an agenda item
• Establish ‘canonical’ composition process models
• Evolve a formal use-case
• Develop simulation architecture conceptual models and simulation representational schema
• Document lessons learned
More Information
For more information, a more detailed version of this article is available:
K. L. Morse, M. D. Petty, P. F. Reynolds, W. F. Waite, and P. M. Zimmerman, “Findings and Recommendations from the 2003 Composable Mission Space Environments Workshop”, Proceedings of the Spring 2004 Simulation Interoperability Workshop, Arlington VA, April 18-23 2004, pp. 313-323.
To view this article online visit: www.sisostds.org/doclib/doclib.cfm?SISO_RID_1005460