Improving the Compasability of Department of Defense Models and Simulations

by Paul K. Davis

Overview

Making future DoD models and simulations more composable.

Product Details

ISBN-13:	9780833035257
Publisher:	RAND Corporation
Publication date:	07/02/2004
Pages:	173
Product dimensions:	9.00(w) x 6.08(h) x 0.38(d)

Read an Excerpt

Improving the Composability of Department of Defense Models and Simulations

---

By Paul K. Davis Robert H. Anderson

RAND Corporation

Copyright © 2004 RAND Corporation
All right reserved.

---

Chapter One

Introduction

We have two objectives in this monograph: First, to suggest a framework for discussing the challenges and opportunities for model composability in the context of Department of Defense (DoD) applications, and second, to identify concrete efforts that might be taken to make further progress in this endeavor.

Definitions

We distinguish sharply among "model," "program," "simulation," "module," and "component." Appendix A discusses the definitions in more detail and relates our definitions to those used elsewhere. Briefly, however, our usage is as follows

A model is a representation of a system, entity, phenomenon, or process-the model's referent. A model may be implemented in different ways by different computer programs (e.g., programs written in different languages). A dynamic model describes the behavior of the referent over time. Simulation is the act of using a simulation engine (i.e., a simulator) to execute a dynamic model in order to study its representation of the referent's behavior over time. Simulation models and simulation programs are models and programs, respectively, used for simulation. An experimental frame is the set of conditions imposed on a given simulation experiment, e.g., the input values that will be considered,the outputs that will be monitored, and how those outputs will be used. The validity of a model (or its implementing program, or of a simulation experimenting with the model) should be judged with respect to a referent and an experimental frame. That is, does the model adequately represent the referent in the particular experiment, which involves a particular context and use?

Large models are usually best designed to be modular. That is, they have parts that can be independently developed and tested, parts that are seen by the rest of the model as "black-box" building blocks that can be interacted with only through the inputs and outputs of a well-defined interface such as ports. A module may be quite complex internally but still have a simple interface. A module's internal processes may or may not be reviewable by, comprehensible to, or changeable by someone composing a new system.

Large models always have parts, sometimes called components, which may simply be names for notional pieces that are not in fact independent modules. In this monograph, however, components are true modules. Moreover, components are suitable for reuse-not just in other parts of some original model, but elsewhere, and perhaps even by third parties. Informally, one may think of components as relatively portable building blocks.

Composability then, is the capability to select and assemble components in various combinations to satisfy specific user requirements meaningfully. A defining characteristic of composability is the ability to combine and recombine components into different systems for different purposes. Although advocates of composability often operate with an ideal of plug-and-play, we do not require plug-and-play as part of our definition. Indeed, assembling model components in a new way may require weeks or even months of significant rethinking and adjustment, even when some or all of the components being used are quite apt. Also, while advocates of composability and component-based work often emphasize that to be particularly valuable the components should be available in a "market" where competition can take place for both function and cost, we do not require that as part of our definition. By and large, then, we have defined terms to make them inclusive, rather than exclusive, to encourage distinctions among types and degrees of composability.

Background

Impetus for the Study

The subject of model and simulation composability is hardly new. To the contrary, it has been discussed for decades, as reflected in the considerable related literature. The fact remains, however, that the aspirations of the Department of Defense (DoD) for composable systems have not usually been achieved, and there have been some notable disappointments. As a result, the Defense Modeling and Simulation Office (DMSO) asked the RAND Corporation to take a fresh look, one that could help guide a related DMSO-sponsored research and development (R&D) program. The office's starting point is described on its website (Defense Modeling and Simulation Office, 2002):

Certainly we have some ability to "compose" simulations today (e.g., JSIMS, JWARS, MC02, etc), but there are stumbling blocks regarding our ability to do this "rapidly," "flexibly" and efficiently. These stumbling blocks are not insurmountable, but we have discovered that unless models are designed to work together they don't (at least not easily and cost effectively). It is also believed that not all of the solutions will come from technology: many will come in the form of processes.

The goal of DMSO's Composable Mission Space Environments (CMSE) initiative, sometimes referred to as "composability," is to identify the issues related to "composability" and then target DMSO initiatives (and related research from other organizations) ... [and] lay the groundwork for increased reuse and the improved ability to compose simulations more rapidly, flexibly, and efficiently.

Consistent with this, DMSO urged RAND to open all doors, ask all questions, and provide a fresh assessment of composability issues. Although composite modeling and simulation (M&S) frequently involves hardware and human components, most of our focus in this monograph is on software in the form of models.

Is a Focus on Model Composability Desirable?

It became clear early in our research that a good deal of skepticism exists in the community about the desirability of model composability, at least as a major objective in development efforts. It is therefore appropriate to address this issue at the outset, rather than merely assuming that DoD interest in a subject necessarily implies its appropriateness. It was not long ago, after all, that DoD's passion seemed to be imposing the Ada language across the board. Could model composability be an equally dubious concept? Upon reflection, the answer is clearly No-at least with the broad definition of composability that we use. As mentioned in the definitions, modularity and composability are closely related. Modularity is necessary when dealing with complex systems, and some degree of composability is surely possible and desirable. There are a number of reasons. We present them here largely as assertions, but they will probably be convincing to most readers who are practitioners of modeling and simulation, and a substantial related literature exists on the subject. The reasons we emphasize relate to all phases of M&S:

1. Creating a simulation of a large, complex system requires breaking the problem down into parts that can be addressed separately-to reduce the effects of interruption, to permit specialization, to facilitate computing alternative ways of handling a given component, to maintain the software over time, and to reduce risk by relying upon previously proven components where possible. Often, it is best that such parts be "modules." Creating a system of systems is necessarily dependent on coupling such modules together. 2. Understanding complex systems requires decomposition because no one can otherwise comprehend the whole's details-much less explain them. How to decompose and whether one needs only one breakdown or many is always an issue, but the need for decomposition is well established.

3. Testing systems is vastly simplified if one can do it module by module, and then at the system level.

4. Controlling M&S costs is important, and those costs are strongly correlated with the amount of new code writing. The economic incentives for reuse, then, can be considerable. If a program has 3 million lines of code, which can be written at the rate of 75 lines per person-day, and each person-day costs $500, then the associated cost is $20 million. If even half of the program were a reuse of earlier code, the savings might be on the order of many millions, and the time to complete the program might be many months shorter. To be sure, however, reuse is not free. There are significant costs entailed in understanding the components, modifying them to suit the new purpose, and documenting them as they evolve for the new application. Nonetheless, considerable cost savings can be realized if the composability feature is used multiple times.

5. Maintaining and modifying M&S are also greatly simplified with a modular construction: Individual modules can be substantively modified or updated as software as necessary, without endangering the overall system. This is in contrast to the common situation in which an organization is afraid to improve a particular algorithm for fear that the whole system, written years earlier, will collapse.

6. Using M&S is also improved by modularity. For example:

Conducting distributed war games and exercises, which have come into their own in recent years, depends fundamentally on the ability to compose, e.g., to combine ground-combat, aerospace, and naval models. Preparing military forces for flexibility requires M&S flexibility so that different concepts and systems can be assessed or used in a wide range of operating circumstances. Such flexibility is at the heart of capabilities-based planning.

Modularity, then, is good. As noted above, however, composability is more than modularity.

What Should We Be Expecting of Model Composability?

Clarifying what types of composability are actually achievable and what types are especially valuable is very important. With this in mind, many objectives often stated as part and parcel of composability should be scrutinized in a fresh look. Table 1.1 itemizes some of them. Some are dubious, but none are strawmen-we have heard all of them advocated vociferously by senior military officers and even by senior DoD officials over the past decade. Significantly, however, not all visionary goals are useful; some are downright counterproductive, as many of us learned when studying the dangers of utopian thinking in political philosophy. Many historical mathematicians would probably have agreed, having spent years of their lives trying to accomplish things that Gödel later proved to be impossible.

Do we want to build any, some, or all of these objectives into the very definition of composability in the DMSO context? As implied by the definitions given above, the answer is No. Instead, we consider composability as a matter of degree and context. So also is the desirability of composability. Consider an experience that many readers have probably had. After reading a text or attending a course that stressed the virtue of always building programs in small modules, many have begun building a "real" model, only to find that the tedium associated with such a "requirement" simply doesn't pay its way. Instead, they found it faster, easier, and in some ways more elegant to build the program in a direct, unified way, without the boilerplate required for the rigorous modularity that assures that modules can be tested and run independently. The desirability of building for composability has something to do with scale and context.

Another experience that many have probably shared is that of having gone to the trouble to develop a component-ready model and its documentation, and then observing that in fact only work-group companions or some colleagues "down the hall" ever use the model, thereby suggesting that much of the extra effort was wasted. Companies with bottom lines in mind will not invest in composability unless they can see the corresponding system being used and adapted enough over time to justify the costs.

As for having a commercial marketplace of model components on which to draw, it remains unclear where that image applies. It is one thing to savor the marketplace of plug-in modules for software such as Microsoft Excel; it is another to imagine frequent shopping for major combat models, which take a great deal of time and effort to evaluate and, later, to learn. Table 1.2 gives examples of components that illustrate the enormous range of cases, examples that should reinforce the sense that achieving composability is a drastically difficult matter, depending on level of detail and other factors. There are, then, many cautionary anecdotes and logical reasons to suggest that we should contain enthusiasm for composability in general and instead look more deeply into precisely what is needed, what level of detail and in what context, how difficult it is to achieve, and where it would pay off most handsomely. That background of considerations has motivated the approach in the rest of this monograph.

Shared, Accessible Data for Composability

One critical composability-related subject that we do not discuss in this monograph is the matter of data: creating, sharing, and reusing relevant databases on matters ranging from digitized terrain to characteristics of weapon systems. Many researchers involved with composability-related work emphasize that the data problem is one of the most important and most vexing issues. We have chosen to focus on model issues here, in part because of time limitations and in part because the data issue is significantly different from model issues. However, we include in Appendix C a brief summary of others' recommendations on data issues.

Approach

Setting aside the issue of data, our approach in the remainder of this monograph (Figure 1.1) is to review critically the very concept of composability and muse about what makes it difficult, in the process defining numerous distinctions discussed in Chapter Two; and then to draw on the insights from that exercise to move (in Chapter Three) to a set of tentative suggestions about how the DMSO and other offices might work to improve the situation in a program of investments and priorities.

We have also included a number of appendices elaborating on particular issues.

Appendix A provides definitions and related discussion.

Appendix B is an essay about the subtleties of composability.

Appendix C summarizes briefly the findings of a recent workshop on ways to improve data sharing and reusability.

Appendix D is an extended discussion illustrating with a toy problem some of the more subtle substantive problems that arise in efforts to compose models and to characterize M&S at a high level.

Appendix E describes two substantial examples of composability in practice, based on work at RAND and at Lockheed-Martin (Sunnyvale). Both focus on analysis, rather than on applications to training or operations.

Appendix F summarizes some highlights of past work on simulation-based acquisition (SBA), primarily to note overlaps with this monograph.

Finally, Appendix G summarizes comments received by us at the workshop mentioned earlier.

With this introduction, then, let us now turn to a review of the broad range of reasons for the difficulty of model composability.

Chapter Two

Factors Affecting Composability

Initial Comments

The ability to compose models or simulations from diverse components obviously depends on the components themselves and on the context in which such composition takes place. In this chapter, we list a number of the factors that affect composability; these factors can be grouped compactly as in Figure 2.1. The list is broad, although surely not yet comprehensive. The initial version formed the basis for discussion at the workshop noted above, and what appears here is an iteration reflecting that workshop, review comments, and further thinking. Even so, the list is a beginning for discussion rather than an endpoint.

(Continues...)

---

Excerpted from Improving the Composability of Department of Defense Models and Simulations by Paul K. Davis Robert H. Anderson Copyright © 2004 by RAND Corporation. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---